「通信プロトコル」を含む日記 RSS

はてなキーワード: 通信プロトコルとは

2019-12-28

anond:20191228091800

通信プロトコルの話なんだから別にナンセンスじゃなくね?

Slack採用してたXMPPとか電子メール通信プロトコルチャットに応用したものだぞ

ジャックドーシーがSMTPって言ってるけどこれが電子メール通信プロトコル

わかりにくいけど共通した話なんだよコレ

2019-11-30

anond:20191130142226

ネットの海と同一化した草薙素子だって通信プロトコルOS世代交代で、恐らくそこそこ簡単死ぬ

やはり数億年の年月をかけて改善を繰り返してきて今に存在する生の人間さん最強やな

anond:20191130140544

ゲームだけじゃなくて、電子データってのは、互換機を用意する手間がかけられなくなったら死ぬんだよねえ。

劣化なく無限回観れるからお得、とか思っていたレーザーディスクは、LD再生機を用意することが難しくなって死んだ。

ネットの海と同一化した草薙素子だって通信プロトコルOS世代交代で、恐らくそこそこ簡単死ぬ

2019-06-26

Mastodonから知る分散SNS本質

インターネット日常的に利用する諸氏はMastodonというマイクロブログサービスを知っているだろう。

ある程度のIT知識を持った者ならば自身マイクロブログサービスを始められるオープンソースソフトウェアだ。

2017年当時学生だったハンドルネームnullkalがmstdn.jpというドメインを取得しMastodonサーバーを開設したことによって日本で注目を浴びた。

これらは一部の真実表現している。

しかし、本質ではない。一部の真実表現しているので誤りでは決してないが、本質かと言われれば決してそうではないと返せる。

Mastodon(と分散SNS)という言葉存在を知る多くの人々が本質理解できていなかったため「劣化Twitter」などと評価せざる得なかった。

そして、不幸なことにMastodon話題となった当初、それを報じるインターネットメディアもまたMastodon本質理解できていなかったので、Mastodonに関する記事を読んだ多くの人々の評価Mastodonアカウントを作らずとも「劣化Twitter」として固定されてしまった。

私の友人はMastodonを指してこう言った。

Mastodonって不人気だけど何故かプログラマーな人が多いよね」

おかしな話だ。コンピュータインターネット技術に詳しく専門分野に関しての審美眼には信頼のあるプログラマーが何故か不人気なものクールさを見出していると言うのだから

そこでこのエントリでは、日本情報も多いMastodonを例にして分散SNS本質解説しつつ、何故プログラマー分散SNSクールさを見出しているのかを語っていこうと思う。

本質はActivityPubの中へ潜んでいる

2007年インターネット上に「OpenMicroBlogging」と呼ばれる通信プロトコルが登場した。

OpenMicroBloggingは分散SNSで使われることを想定した通信プロトコルで、OpenMicroBlogging実装SNSとして「Identi.ca」が開設される。

Facebook2004年設立Twitter2006年設立であり、Facebook設立からわずか3年後、Twitter設立からわずか1年後に分散SNSが登場したことになる。

オープンSNSでよく語られるのは「中央集権SNSへのアンチテーゼ」だ。

これらの表現は悪いわけでない、悪いわけでないが分散SNS理解へ誤解を生む。

誤解を生む理由は「わかりやすい」のだ。「自身サービス内で強権を奮うFacebook運営Twitter運営へNOを突きつけよう!」「我々の手にオープンSNSを!」といういかにもな正義は非常にわかやすい。

からこそ一部でこの表現が支持されてしまい声たかかに叫ばれ、多くの人々の分散SNS本質的な理解を妨げた。

インターネットを長らく観測してきたお歴々はご存知だろうが、そもそもユーザー自身管理者となり自分自身ルール運用できるオープンSNS分散SNS登場以前から存在している」のだ。

日本国内であればmixiクローンSNSとして「OpenPNE」などがFLOSSコミュニティでは非常に有名だ。

では、これまでのオープンSNS分散SNSは何が違うのか?

分散SNS大前提として通信プロトコルありきで開発されている点が違うのだ。

思い出して欲しい。Identi.caの前にOpenMicroBloggingが作られていることを。

後に整理されてIdenti.caは「GNU Social」と、OpenMicroBloggingは「OStatus」と呼ばれるようになるが、Mastodonもまた通信プロトコルありきで開発されており、MastodonがありきとしたのがそのOStatusなのだ

OStatusのベースであるOpenMicroBloggingは設計が古いため、現在ではOStatusの事実上の後継であるモダン設計のActivityPubへ差し替えられるという大きな変化はあったが基本は変わらず、MastodonはActivityPubありきで開発されている。

分散SNSとは何なのか?

多くの人々はSNSと言えばTwitterFacebookInstagramなどを想像してしまい、分散SNSと言われるとMastodonGNU Socialを連想してしまう。

はっきりと言おう、この認識自体根本的に最初の誤解であるのだ。

分散SNS通信プロトコルありきで開発されており、ActivityPubなどの通信プロトコルによってSNSサーバー同士が相互接続形成されている。

このネットワークのもの分散SNSだ。Mastodon分散SNS形成するSNSサーバーしかない。

すなわちMastodon分散SNS方式SNS分散SNSSNSなどと表現したほうがより正確な意味を持たせられるのだ。

ただこれは情報技術に詳しいはずの技術者でさえ誤解しやすい部分であり、よりわかりやす説明するためにActivityPubなどで形成されるネットワークのことを「Fediverse Network」と表現することが多くなっている。

まりMastodon分散SNS」「Fediverse Network分散SNS」という図式が成り立つ。

Mastodonはやろうと思えばFediverse Network接続しないこともできるということを理解しておかなければならない。

分散SNS本質

分散SNSとは何か?

ActivityPubなどの通信プロトコルによってSNSサーバー同士が相互接続することにより形成されるネットワーク(= Fediverse Network)そのもの分散SNSであると言った。

では分散SNS本質とは何か?

それを知るためにはFediverse Network特性を知らなければならない。

Fediverse Network形成するActivityPubを現在は様々なSNSサポートしている。

代表例を挙げればマイクロブログサービス型の「Mastodon」「GNU Social」「Pleroma」「Misskey」「microblog.pub」、Facebookのような名鑑名簿型の「Friendica」「Hubzilla」、写真投稿型の「PixelFed」、動画投稿型の「PeerTube」、電子掲示板型の「Prismo」などがActivityPubをサポートしている。

ここで疑問を投げかけてみよう。

もし、何らかの理由Mastodonの開発が停止し、この世から完全にMastodonサーバー消滅した場合、Fediverse Networkはどうなるか?

答えは簡単だ「Fediverse Networkは維持されたまま」である

単にこの世からMastodonが消え失せるだけであってActivityPubが形成するFediverse Network対応しているのはGNU SocialやFriendicaなど他にも多数あるのだ。

Mastodonが使えないのであればGNU Socialを使えば良いというような形式ネットワークインターネット老人会のお歴々はよくご存知で、おそらくこう表現するのではないか

「まるでE-Mail Networkだ」

GMailが使えないのであればYahoo!Mailを使えば良い。それと全く同じだ。

うつまり分散SNS本質それは「SNS形態を取った次世代E-Mail」なのである

分散SNS本質SNS形態を取った次世代E-Mailであるからこそ「Twitter代替」や「中央集権SNSへのアンチテーゼ」などという言説は分散SNS本質表現できているとは言えないのだ

TwitterE-Mail Networkのような特性を持っておらず、E-Mail NetWorkそもそも分散されている(E-Mail NetWorkはそのように設計されたから)。

ましてや、そもそもシステム根本から違うので「劣化Twitter」という言説もまた分散SNS本質などではない。分散SNSTwitterクローンですらないのだから

分散SNS本質SNS形態を取った次世代E-Mailであるからこそ、そのアカウント数はE-Mailと同様にゆっくりと増え続ける。

過去日本ではユーザーが望む望まない、ユーザーが使う使わないへ関係なくDoCoMo携帯電話iモードへ加入するだけでE-Mailアカウントが付いてきた。

分散SNSアカウントはそのようにして増える。今後登場するであろう人気WebサービスがActivityPubをサポートしているとユーザー意識せずともFediverse Networkアクセスできてしまうのだ。

分散SNS本質SNS形態を取った次世代E-Mailであるからこそ、プログラマーたちにとってクールなのだ

現在GMailアカウントがどのように使われているか?を少し考えるだけで、SNS形態を取った次世代E-Mailである分散SNSがどれだけ刺激的で新しいインスピレーションを生み出してくれるかが理解できるだろう。

これが分散SNSだ。

2018-06-25

インターネットに期待しすぎていた。

所詮通信プロトコルだった。

批判されて恨んで、刃物で刺して殺害とか

人類って二千年前以上前からやってること進歩ないのな。

2018-03-12

anond:20180310195735

一種表現技法だと思う(結論)。猫なで声とか甘える声とかダンディ喋りとかと同じ次元理系早口があるのではないかと(例示)。自分でもやるけど、理系早口は誠意だと思っている(結論)。

仲間同士では情報交換の効率が最大になるように話しているだけだが、仲間でない人にやるときは、仲間にするのと同じ通信プロトコルを使うことで最大限の敬意を表現している(詳解i)。蛇足ながら、この通信プロトコル単語定義から始めることが多いので、どうしても長くなる。決められた時間の中で十分な情報提供するためにどうしても高速で話さないといけないという事情もある(蛇足i)。

また、どうせ内容はわかってもらえないだろうという感覚から、せめてわからないことをわからせてあげよう、わかるためには大体どのくらいの要素を理解しないといけないかだけはわかるようにしてあげようという誠意でもある(詳解ii)。

なお、研究報告のシーンでは理系早口的な発表は意外にも疎んじられる。わかりやすい発表のためには「網羅性を追求するよりも代表性を重視せよ」などと教えられ、だらだら長い発表を詰め込むために早口になるような場合、発表技術が未熟だと見なされる(蛇足ii)。

まあ要するに好意的感情表現する方法ひとつだと主張したいわけで、昆虫がヒトに求愛ダンスするようなものなので、キモくても優しく聞いてるふりしてください(懇願)(結論)。

2017-08-14

創作物におけるテレパシーセキュリティ

お盆休みで暇だからテレパシー通信プロトコルについてぼんやり考えてた。

映画アニメ漫画とかで、直接相手の心に話しかけるタイプテレパシー描写が出てくるけど、どの作品送信側のリクエストに対して無防備すぎる。
受信側は、「ポート解放ファイアウォールは無し」みたいな設定にされていることが多い。
また、通信リクエスト許可してからテレパシーを受信するわけではないので、着信拒否はできない。
どの場面も、いきなり電話がかかってきて、受話ボタン押してないのに相手一方的に話しかけてくる感じのテレパシー描写だ。

まあ、受信側は初回通信時「あれ?なんか声が聞こえるぞ。」というテレパシーに対して無知であることも多いので、対策がなされていないのも仕方ないのかもしれない。
でも、二度三度と今後も通信していくんだったら、スパムテレパシーを防ぐファイアウォールや何らかのフィルタリング機能がないとノイローゼになるだろう。
テレパシー相手が、ツイッターでいうところのクソリプを延々と飛ばしてくるやつだったらと思うとぞっとする。

最後に、凝ったテレパシー設定が出てくる作品があったら読みたいので教えてください。
過去に読んだSFでも、地球外生命体がテレパシー(あるいは、そうと明言されてはいないが、脳に直接メッセージを送り込む方法)でコンタクトしてくる作品はいくつかあったけど、人類相手から信号に対して無防備だったなあ。

2016-11-09

http://anond.hatelabo.jp/20161108221758

半導体製造装置通信プロトコルに SECS ( SEMI Equipment Communications Standard )ってのがあり、「セクス」と読むのだが、新人が入るたびに打ち合わせで変な顔された。

2016-03-20

最近は引きこもって組み込み関連の勉強してるが、なかなか進まない

機械工学専攻からSEになって3年たつが、上司レベル高すぎて全然ついていけない・・・

OS, コンパイラ, CPU自作をして、ここらへんの知識身に着けたい。(とりあえずは、市販本見ながら作って動かす)

あとは、コーディング能力鍛えたい。

c++,cはもちろん、

ツール作成のために、

bash, java script, ruby, sinatra, rails,

競技プログラミングOSSソースを読んで勉強なんかがいんだろうか

FPGAとか通信プロトコルの知識も身に着けたい。。。

なんで、上司はここらへんのこと当たり前のようにできるんだ・・・

平気で連休自作ツール業務改善できてしまうんだ。。。

頑張って、追い付いて、貢献したい

2016-02-15

人類が『鉄雄』になる

ヒトをヒトたらしめているのはその “脳の大きさ” に他ならないが、その肥大化した脳は大きくなればなるほど「情報を求め、常にインプットされる情報が多くなるように行動する」というロジックを脳の基本的機能として組み込んでいった。

そのロジックに従い情報を吸収し続けた結果として脳が肥大化したのか、大きくなったからこそより情報を欲するようになったのかはニワトリタマゴと同種の話であろうが、いつのからかヒトはこの巨大な脳のために常に情報インプットし続けるよう行動するという習性が備わった。

そう考えると今、皆がひたすらにスマートホンに顔をうずめている光景も納得がいく。現時点で最も効率良く、場所時間に縛られずに情報を得られる “窓” がスマートホンだからだ。

コミュニケーション欲求も、とどのつまり自分社会的位置情報の取得、あるいは周囲の “ノード” との相関関係確認作業である他者との “共感” のやりとりにしても、「分かり合う、分かり合えるかどうか」というのはつまり情報通信プロトコルの動作確認的な意味合いが強い。相手と“会話”という名の情報通信が可能かどうか。他者との関係性は情報流入のためのインフラのものであり、インフラの出来によって得られる情報量に大きく差がでるのだ。

ここにおいて情報の中身や質は関係がない。常にインプットし続けることこそが目的であり、それこそが脳の “要求なのだ。脳への情報インプット効率を高めるためにヒトは “インターネット” を構築しそこを覗くための窓であるスマートホン” を作った。すべてはヒトの脳が欲したものだ。

スマートホンに顔をうずめ常に何かしらの情報を追っている方が、よりヒトの脳が求める要求に忠実なのであり、“より人間らしい” のだ。スマートホンなどに抵抗を感じ「おかしい」と声高に叫んでいるような人間は、古い習慣に囚われ脳の要求無視する「人間らしくない」生き物だ。ヒトであるならば素直に脳の要求に従い、貪欲に情報を貪り続けなければならない。

ヒトはもうスマートホンを捨てられない。情報によって強化された脳がより強く情報を求め、もうそれを抑制することはできない。まるでクスリによって手に入れたチカラに依存し飲み込まれていった鉄雄のように、ヒトも制御できない情報流入で溺れ壊れていく。その過程の真っ只中に我々はいる。mn3

2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

2015-05-29

http://anond.hatelabo.jp/20150529094642

思った。

http://www.gizmodo.jp/2015/05/brillo.html

この記事書いた奴頭悪い。

翻訳の以前にさ、OSを同時に二つ発表することなんてあまり考えられないし、

仮に二つ発表したとして、一般ユーザーデベロッパーで使用OSがかわるってこと?

BrilloはOSで Weaveは通信プロトコル名前らしいけど。

The common standard that makes it all possible is called Weave.

スタンダード版となる、一般ユーザー向けは「Weave」です。

なんでやねん

2013-04-30

青二才の人はどうすれば精神リストカットをやめられるのか

真夜中に眠れないほど精神的にめいってしまたから書いた。久方振りに「どうしようもない」ほどの体調不良経験してるが…涙も治そうという気力も出ないことに危機感を感じてる。本音しか書けなくなってしまったよ

TMくん( @tm2501 )のはてブや発言を読んでいると痛々しいと思うんだが、いわゆる「イタイ人」ではないんだよなーと思ってて、色々考えた結果「精神リストカッター」というあたりで腑に落ちた。彼の魂はどうすると救われるかなと思ったりする。

一応、振られたから返しておきます。「精神リストカッター」ってなんぞですか?

あ、言葉自体は私の造語なので…。「肉体ではなく精神ココロ)に対し自傷行為を繰り返す人」くらいの解釈でおねがいします。ちなみにTMくんに自覚があるかどうかは関係ない。外野から見てそう見えるって話なので。

小学校でたときには少なからず、自覚があったので否定はしません。(詳しくは今日の朝に投稿した記事で)それは歪んだ家庭環境ゆえに仕方ないものだと思ってます。気がついたときに僕が病まずに努力し続ける精神を獲得するためにはこれ以外の方法が当時はなかったと

あ、その行為自体は否定するつもりはないのです。あんまりいい意味に使われない言葉ではあるので申し訳ない。…どっちかというと、今のTMくんがどういう方向に進みたいのか、永遠にリスカし続けることをよしとするのかみたいなのが見えてこないなーと思って。

そこで望みが叶えば、ある種真人間になれるチャンスはあると思うのですが…自分の現状から言えば、劣化有村悠みたいな末路しか見えないのは認めますね。彼よかコミュ力社会性はあるが、才能も知識もない。行くも引くも地獄になるのは確かに目に見える話ですね

真人間じゃないとという考えが、凝り固まってるなあと思いますバイリンガルを目指せばいいだけなんだけどね、これって。別にどれか1つのコミュ世界だけじゃないわけだし。それに、才能や知識なんかなくたって、生きていける世界は多々あるんですよ。

言われてみると、昼と夜の顔(公私)を両方ともをちゃんと作ろうとすると、どうしてもひとつの顔につながるようなルートを求めてしまうのがダメなのかもしれませんね。才能や知識のいらぬ世界で大多数の人は生きていくはずだが、それを説明する言葉を僕はもってない

なんとなくだけどオンリーワンNo.1以外は全部ダメ!思考が見え隠れしてるなあと思います。合わせ技で1本!もありなんだよとかそういう風に考えられるといいかなあと。あと、公私は無理に1つにしなくていいと思う、というのが私自身の経験則

オンリーワンNo.1以外は全部ダメ!思考」真に戦うべきはこの思考なんですよねぇ…。これのおかげでたった一人でブログを大きく出来たけど、これのせいで二つの道を緩やかに成立させることが手抜きに感じてしまう。どちらか一本をすごく真面目にしてしま

青二才の敵は青二才自身の自意識。 ここに気付いたのはエライ。 あと一歩だ。頑張ろう。


オタクコミュニケーションは手軽に深いコミュニケーション体験を得られて、麻薬的な快感を味わえてしまうんですよね。それをうっかり10代前半とか半ばに覚えると、なまじ味わってしまっただけに、この感覚を味合わえないコミュニケーションを異様に軽視しだすと思いますオタクコミュ障の原点は多分ここなんだと思う。、刺激が強いコミュニケーションを求め続けた結果がそれかも……という事で次なる仮説を考えておりますwそれぞれ味わいは違うけどおいしい、って理解ができればなんとかなるとも思うんですが、ジャンキーヲタコミュにハマると難しいかもですねぇ。

無分別にオタクな用語をバラまいた結果、それまで築けていた間柄が傷つき、ボロボロになっていく過程こそが、コミュ障への過程のものなのではないか。まさにどこかのヤマアラシジレンマではないか。さて。この段階で分別があり、それまで使ってたコミュニケーションも手放さなければ、おそらくコミュ障の症状は軽度で済むと思う。問題は「闇に呑まれよ」ではないが、なんとかしてこのジャンキー快感を味わえるコミュ方を駆使したい誘惑に抗えなかった人だ。当人は、ただ刺激の強いコミュニケーションをしたいだけなんだけど、周囲から見たら突然コミュニケーションプロトコルが変わった人は一般的に「奇人」と言われる。親や友人に奇人扱いされるようになったら、いよいよオタクコミュニティしか場所がなくなる。距離感おかしくなるのは、自分通信プロトコルが変わった自覚なしに、相手に通じない、刺激的なプロトコルを発し続けた結果なのか。通じればコミュが成立するけど、通じないコミュニケーションはひたすらノイズでうるさいだけだ。けど 「ぼくのかんがえたさいきょうのプロトコル」 が通じないことは二重の苛立ちを生む(素晴らしい物が認められない苛立ちと、通じないことそのものへの苛立ち)けど、自分プロトコルに酔ってるから捨てられず被害が収束しないのか。本来はバカバカしいし投げ捨てるべき物なんだけど。あと、ここまで来ると多分、通常の汎用的なプロトコルが下に見えてしょうがない。だからこれを採択する気はないし、おそらくこれを使ってる連中を見下してる。とすると余計に殻に籠もって、自分だけの歪なプロトコルに益々酔いしれていくのか。うわあ。本来は相手に通じてナンボのプロトコルなのに、どんどん自分しか使えない役に立たないプロトコルに入れ込んでいくアンビヴァレンツ。しか翻訳すら許さない(翻訳はこの役に立たないゴミにあるはずのない品位を貶めることになるため)からゴミ加減が益々kskするだけなのに余計に…うわあ。あとはこのサイクルが行くところまで行って煮詰まれば、どこに出しても恥ずかしいコミュ障がいっちょ上がってしまうのか。ぐへえ。やばい。開ける気の無かったパンドラの箱無用に開けた気分だ。しか希望がないorz

この話の元は、まぁ案の定実体験なんですが、10代前半のオタ成り立て(罹患したて)の頃が案の定一番酷くて、「自分日常会話が全てマンガアニメセリフで成立できてる」って信じ切ってた頃があったんですよ。だからプロトコルに酔うというのは実体験なんです。オタク人生25年、もっと早く気付こうよ。ヒントはいっぱいあったし、多分この話は20年前ぐらいの自分でも理解できるよきっと。

自覚があるので読ませてもらいました。私自身汎用的なプロトコルとの上下関係を明確に定義したことはありません。ただ、私の中でこれで勝たなきゃ本当に母親に幼いときから押されていた「そんなこともできない奴」の烙印で一生涯潰され続ける。その絶望と戦ってたら、こうなりました

多分ここに明確な上下関係を見出す人は少ないと思います快楽に支配されると、快感にならないもの意識すらしないからです。ただ、使い方によっては確かに武器にも杖にもなると思いますが、頼りすぎると自分に跳ね返ってくるだけです。

そこなんですよね。承認欲求が強すぎる状態を僕の基準地点にしてるから話がずれたり、煽り耐性が落ちてしまったりしてる。問題だとは思うのですが、オタク界隈の悩みゆえ明確な言語化・相談ができにくい内容。ゆえにバランスのいい状態でかつ僕の自己同一性が守られる形をもってない。そういう意味じゃ少し違うのかなぁ…と思うのです。まがいなりにも自分の頭と目で作ってきたモノに評価を受け、オタク的な人だけではなく幅広い層からの支持から得た自信なので、それゆえに過信しすぎていた部分が強かった。(成功体験認識してしまうとそれを修正するのは難しい)

なるほど。あの鋭い舌鋒の台所を垣間見た気分です。でもこれを明確にコントロールできる人はやはりそういないですよ。タイミングの調節だけなら簡単にできるけど、威力とかキレ味のコントロールは強めることにしか大概の人は興味ないでしょうから、強さだけを求めてしまうと思います成功体験と結びつくと尚更修正は辛いと思います自分でつかみ取ったもので構築したとなったらなおさらですわ。壊す必要はないけど、見つめ直すことはオススメします。

くそのとおりです。昔に比べて、「一般的な思考」よりも、先にエッジの効いた青二才節が先に思いつくようになったため、知らぬ間に相手から失言扱いされるケースが増えました。演じ分けとまで言わなくても、「一般的な思考」と並列できる程度には戻したいですねぇ…。最近、悩んでいるのはその力加減なのです。オタクブロガーのままリア充真人間になるという路線でここ数箇月書いてきていたが、これがどちらからも不評であり、僕自身が疲れはててしまう事に最近気づいてしまったため、力加減の変えどころが分からず、思案していますね。正しい変化とか、更生とかそういう枠組みに入りたいとは思わないが…自分のやっていること、考えていることに無理や限界があるというのはわかる。そういう時の選択肢が欲しいねぇ…自分で作りこんでしまった自我ゆえに、一般的な処方箋を頭ごなしに押し付けられるのは御免だ。適切なモノを選ばないと

炎上以外成功してないから、他のEXITを見つけられないから困っている」というところまで自覚があるならもう少し。炎上以外の方法で注目を集められる実力を身につけよう

個人的にはオタクのままリア充になって、自分がいる場所視野を広げてしまいたいなぁ…と最近は考えるようになりました。それゆえ、オタク同士の座談会にわざと女性ナース親子)を呼んで、ホモソーシャル的な議論にしないような事をしました。

と思ってたら、どうしてこういう小手先に頼ろうとするかな。 その程度の工夫でなんとかなるような悩みならそんなにひねくれたりしないでしょう。 強がらないでもっと自分の抱えてる悩みを真剣に見つめよう

本人がまとめててワロタwww   http://togetter.com/li/485119

2011-09-06

FFFTP 開発終了に思うこと

開発終了といってもずいぶん前から更新は止まっていたわけで、明確に開発終了が宣言されただけで公開終了になるわけではない。

しかFFFTP といえば FTP クライアントの定番なので、ネット上で様々な意見が飛び交っている。それについて思うままに書き散らかしてみる。

なつかしい・おつかれさま

みんなが「ホームページ」なるものを持ち始めたころ、ファイルアップロードするのに使ったなつかしい思い出がある。BlogWikiのようにオンライン編集できる時代になったことへの感慨も含むのか。

FTPオワコン

もちろんFTPプロトコルとしてセキュアでないことは言うまでもないが、いまだに業務で使わざるを得ないことがある。LAN内の転送なら速度は最強かもしれないし、FTPミラーサーバは世の中にごまとある。短絡的に「オワコン」の一言で片付けられる問題ではないだろう。

だれか開発を引き継いでほしい

ほとんどのユーザはお客さん気分であることを再確認し、「FreeBSD への貢献」をたたき込んだ自分とは違う人種だと思った。

SCPに対応してほしい

もともとFTP以外の通信プロトコルを想定して設計していないだろうから難しいように思う。ただ、ユーザは動いているプログラムの中のことなど考えない。

「開発を継続していくモチベーションが保てなくなった」

開発者曽田さんのこの一言はとても重く感じる。

モチベーションが低下する理由ってたくさんあるなぁと。長続きしているオープンソースプロジェクトはすごい。

2010-03-21

プログラミングに挫折した

ゲームを作りたい C言語の基礎を学ぶ それだけじゃゲームが作れないことが判明

win32apiを学ぶ 多すぎて?状態で挫折

ゲーム作るのはあきらめよう!チートだ! アセンブリが面倒で挫折

向き不向きってあるよね・・・。もう勉強したくない・・・。

俺には向いてないんだろな。だってwin32apiでGUI作りで投げ出したくなったもん

俺の読んだ本

明快C言語 ダイテルC言語(例題飛ばしたのでほとんど意味なし) やさしいC 独習C

windowsゲームプログラミング(最後のテトリスブロック崩しが面倒で飛ばした)

独習java(ガベージあたりで挫折) windows32api徹底理解 ホームページ作成の本(名前失念)

アセンブリ言語の教科書(100ページあたりでソースを読み解くのが・・・以下略

何のために勉強しているかわからなかった・・・たぶんC言語の基礎すら身についてないと思う

じゃあweb関連や初心者用言語(php,ruby,pythonとか)学べばいいじゃんってネットで指摘されたんだけどさ

そうじゃないんだよ問題なのは。ライブラリの使い方がわからないし必要な技術がそれだけじゃないだろうし

roboformのようなもの作りたいんだけどどうつくったらいいんだろ(guiは無理なのでコンソールで)

perlとかruby,php記述して通信プロトコル勉強すればできるんだと思うんだけど俺にはもう体力が残ってない

あまりにも無駄な遠回りをしてきた。でも願望だけが空回りしてる。ライブラリごまんとあるうえに通信プロトコル勉強しないといけないんでしょ。甘えっていわれてもかまわない誰か助けて

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん