  |
はてなキーワード: 通信プロトコルとは
インターネットを日常的に利用する諸氏はMastodonというマイクロブログサービスを知っているだろう。
ある程度のITの知識を持った者ならば自身でマイクロブログサービスを始められるオープンソースなソフトウェアだ。
2017年当時学生だったハンドルネームnullkalがmstdn.jpというドメインを取得しMastodonサーバーを開設したことによって日本で注目を浴びた。
しかし、本質ではない。一部の真実を表現しているので誤りでは決してないが、本質かと言われれば決してそうではないと返せる。
Mastodon(と分散SNS)という言葉と存在を知る多くの人々が本質を理解できていなかったため「劣化Twitter」などと評価せざる得なかった。
そして、不幸なことにMastodonが話題となった当初、それを報じるインターネットメディアもまたMastodonの本質を理解できていなかったので、Mastodonに関する記事を読んだ多くの人々の評価がMastodonへアカウントを作らずとも「劣化Twitter」として固定されてしまった。
私の友人はMastodonを指してこう言った。
「Mastodonって不人気だけど何故かプログラマーな人が多いよね」
おかしな話だ。コンピュータやインターネットの技術に詳しく専門分野に関しての審美眼には信頼のあるプログラマーが何故か不人気なものへクールさを見出していると言うのだから。
そこでこのエントリでは、日本語情報も多いMastodonを例にして分散SNSの本質を解説しつつ、何故プログラマーが分散SNSへクールさを見出しているのかを語っていこうと思う。
2007年、インターネット上に「OpenMicroBlogging」と呼ばれる通信プロトコルが登場した。
OpenMicroBloggingは分散SNSで使われることを想定した通信プロトコルで、OpenMicroBlogging実装SNSとして「Identi.ca」が開設される。
Facebookは2004年設立、Twitterは2006年設立であり、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と言えばTwitterやFacebookやInstagramなどを想像してしまい、分散SNSと言われるとMastodonやGNU Socialを連想してしまう。
はっきりと言おう、この認識自体が根本的に最初の誤解であるのだ。
分散SNSは通信プロトコルありきで開発されており、ActivityPubなどの通信プロトコルによってSNSサーバー同士が相互接続し形成されている。
このネットワークそのものが分散SNSだ。Mastodonは分散SNSを形成するSNSサーバーでしかない。
すなわちMastodonは分散SNS方式SNS、分散SNS型SNSなどと表現したほうがより正確な意味を持たせられるのだ。
ただこれは情報技術に詳しいはずの技術者でさえ誤解しやすい部分であり、よりわかりやすく説明するためにActivityPubなどで形成されるネットワークのことを「Fediverse Network」と表現することが多くなっている。
つまり「Mastodon ≒ 分散SNS」「Fediverse Network ＝ 分散SNS」という図式が成り立つ。
Mastodonはやろうと思えばFediverse Networkに接続しないこともできるということを理解しておかなければならない。
ActivityPubなどの通信プロトコルによってSNSサーバー同士が相互接続することにより形成されるネットワーク(＝ Fediverse Network)そのものが分散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を使えば良いというような形式のネットワークをインターネット老人会のお歴々はよくご存知で、おそらくこう表現するのではないか。
GMailが使えないのであればYahoo!Mailを使えば良い。それと全く同じだ。
そうつまり、分散SNSの本質それは「SNSの形態を取った次世代のE-Mail」なのである。
分散SNSの本質はSNSの形態を取った次世代のE-Mailであるからこそ「Twitterの代替」や「中央集権SNSへのアンチテーゼ」などという言説は分散SNSの本質を表現できているとは言えないのだ
TwitterはE-Mail Networkのような特性を持っておらず、E-Mail NetWorkはそもそも分散されている(E-Mail NetWorkはそのように設計されたから)。
ましてや、そもそもシステムの根本から違うので「劣化Twitter」という言説もまた分散SNSの本質などではない。分散SNSはTwitterクローンですらないのだから。
分散SNSの本質はSNSの形態を取った次世代のE-Mailであるからこそ、そのアカウント数はE-Mailと同様にゆっくりと増え続ける。
過去の日本ではユーザーが望む望まない、ユーザーが使う使わないへ関係なくDoCoMo携帯電話のiモードへ加入するだけでE-Mailアカウントが付いてきた。
分散SNSのアカウントはそのようにして増える。今後登場するであろう人気WebサービスがActivityPubをサポートしているとユーザーは意識せずともFediverse Networkへアクセスできてしまうのだ。
分散SNSの本質はSNSの形態を取った次世代のE-Mailであるからこそ、プログラマーたちにとってクールなのだ。
現在、GMailアカウントがどのように使われているか？を少し考えるだけで、SNSの形態を取った次世代のE-Mailである分散SNSがどれだけ刺激的で新しいインスピレーションを生み出してくれるかが理解できるだろう。
一種の表現技法だと思う(結論)。猫なで声とか甘える声とかダンディ喋りとかと同じ次元で理系早口があるのではないかと(例示)。自分でもやるけど、理系早口は誠意だと思っている(結論)。
仲間同士では情報交換の効率が最大になるように話しているだけだが、仲間でない人にやるときは、仲間にするのと同じ通信プロトコルを使うことで最大限の敬意を表現している(詳解i)。蛇足ながら、この通信プロトコルは単語の定義から始めることが多いので、どうしても長くなる。決められた時間の中で十分な情報を提供するためにどうしても高速で話さないといけないという事情もある(蛇足i)。
また、どうせ内容はわかってもらえないだろうという感覚から、せめてわからないことをわからせてあげよう、わかるためには大体どのくらいの要素を理解しないといけないかだけはわかるようにしてあげようという誠意でもある(詳解ii)。
なお、研究報告のシーンでは理系早口的な発表は意外にも疎んじられる。わかりやすい発表のためには「網羅性を追求するよりも代表性を重視せよ」などと教えられ、だらだら長い発表を詰め込むために早口になるような場合、発表技術が未熟だと見なされる(蛇足ii)。
まあ要するに好意的な感情を表現する方法のひとつだと主張したいわけで、昆虫がヒトに求愛ダンスするようなものなので、キモくても優しく聞いてるふりしてください(懇願)(結論)。
お盆休みで暇だから、テレパシーの通信プロトコルについてぼんやり考えてた。
映画・アニメ・漫画とかで、直接相手の心に話しかけるタイプのテレパシー描写が出てくるけど、どの作品も送信側のリクエストに対して無防備すぎる。
受信側は、「ポートは解放・ファイアウォールは無し」みたいな設定にされていることが多い。
また、通信リクエストを許可してからテレパシーを受信するわけではないので、着信拒否はできない。
どの場面も、いきなり電話がかかってきて、受話ボタン押してないのに相手が一方的に話しかけてくる感じのテレパシー描写だ。
まあ、受信側は初回通信時「あれ？なんか声が聞こえるぞ。」というテレパシーに対して無知であることも多いので、対策がなされていないのも仕方ないのかもしれない。
でも、二度三度と今後も通信していくんだったら、スパムテレパシーを防ぐファイアウォールや何らかのフィルタリング機能がないとノイローゼになるだろう。
テレパシー相手が、ツイッターでいうところのクソリプを延々と飛ばしてくるやつだったらと思うとぞっとする。
最後に、凝ったテレパシー設定が出てくる作品があったら読みたいので教えてください。
過去に読んだSFでも、地球外生命体がテレパシー（あるいは、そうと明言されてはいないが、脳に直接メッセージを送り込む方法）でコンタクトしてくる作品はいくつかあったけど、人類は相手からの信号に対して無防備だったなあ。
ヒトをヒトたらしめているのはその “脳の大きさ” に他ならないが、その肥大化した脳は大きくなればなるほど「情報を求め、常にインプットされる情報が多くなるように行動する」というロジックを脳の基本的な機能として組み込んでいった。
そのロジックに従い情報を吸収し続けた結果として脳が肥大化したのか、大きくなったからこそより情報を欲するようになったのかはニワトリ・タマゴと同種の話であろうが、いつの頃からかヒトはこの巨大な脳のために常に情報をインプットし続けるよう行動するという習性が備わった。
そう考えると今、皆がひたすらにスマートホンに顔をうずめている光景も納得がいく。現時点で最も効率良く、場所や時間に縛られずに情報を得られる “窓” がスマートホンだからだ。
コミュニケーション欲求も、とどのつまりは自分の社会的位置情報の取得、あるいは周囲の “ノード” との相関関係の確認作業である。他者との “共感” のやりとりにしても、「分かり合う、分かり合えるかどうか」というのはつまりは情報通信プロトコルの動作確認的な意味合いが強い。相手と“会話”という名の情報通信が可能かどうか。他者との関係性は情報流入のためのインフラそのものであり、インフラの出来によって得られる情報量に大きく差がでるのだ。
ここにおいて情報の中身や質は関係がない。常にインプットし続けることこそが目的であり、それこそが脳の “要求” なのだ。脳への情報インプット効率を高めるためにヒトは “インターネット” を構築しそこを覗くための窓である “スマートホン” を作った。すべてはヒトの脳が欲したものだ。
スマートホンに顔をうずめ常に何かしらの情報を追っている方が、よりヒトの脳が求める要求に忠実なのであり、“より人間らしい” のだ。スマートホンなどに抵抗を感じ「おかしい」と声高に叫んでいるような人間は、古い習慣に囚われ脳の要求を無視する「人間らしくない」生き物だ。ヒトであるならば素直に脳の要求に従い、貪欲に情報を貪り続けなければならない。
ヒトはもうスマートホンを捨てられない。情報によって強化された脳がより強く情報を求め、もうそれを抑制することはできない。まるでクスリによって手に入れたチカラに依存し飲み込まれていった鉄雄のように、ヒトも制御できない情報流入で溺れ壊れていく。その過程の真っ只中に我々はいる。mn3
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：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) 氏はWebSphereやJBoss、Jenkins、WebLogic、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]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
真夜中に眠れないほど精神的にめいってしまったから書いた。久方振りに「どうしようもない」ほどの体調不良を経験してるが…涙も治そうという気力も出ないことに危機感を感じてる。本音しか書けなくなってしまったよ
…TMくん（ @tm2501 ）のはてブや発言を読んでいると痛々しいと思うんだが、いわゆる「イタイ人」ではないんだよなーと思ってて、色々考えた結果「精神面リストカッター」というあたりで腑に落ちた。彼の魂はどうすると救われるかなと思ったりする。
一応、振られたから返しておきます。「精神的リストカッター」ってなんぞですか？
あ、言葉自体は私の造語なので…。「肉体ではなく精神（ココロ）に対し自傷行為を繰り返す人」くらいの解釈でおねがいします。ちなみにTMくんに自覚があるかどうかは関係ない。外野から見てそう見えるって話なので。
小学校でたときには少なからず、自覚があったので否定はしません。（詳しくは今日の朝に投稿した記事で）それは歪んだ家庭環境ゆえに仕方ないものだと思ってます。気がついたときに僕が病まずに努力し続ける精神を獲得するためにはこれ以外の方法が当時はなかったと
あ、その行為自体は否定するつもりはないのです。あんまりいい意味に使われない言葉ではあるので申し訳ない。…どっちかというと、今のTMくんがどういう方向に進みたいのか、永遠にリスカし続けることをよしとするのかみたいなのが見えてこないなーと思って。
そこで望みが叶えば、ある種真人間になれるチャンスはあると思うのですが…自分の現状から言えば、劣化版有村悠みたいな末路しか見えないのは認めますね。彼よかコミュ力・社会性はあるが、才能も知識もない。行くも引くも地獄になるのは確かに目に見える話ですね
真人間じゃないとという考えが、凝り固まってるなあと思います。バイリンガルを目指せばいいだけなんだけどね、これって。別にどれか1つのコミュ世界だけじゃないわけだし。それに、才能や知識なんかなくたって、生きていける世界は多々あるんですよ。
言われてみると、昼と夜の顔（公私）を両方ともをちゃんと作ろうとすると、どうしてもひとつの顔につながるようなルートを求めてしまうのがダメなのかもしれませんね。才能や知識のいらぬ世界で大多数の人は生きていくはずだが、それを説明する言葉を僕はもってない
なんとなくだけどオンリーワンでNo.1以外は全部ダメ！思考が見え隠れしてるなあと思います。合わせ技で1本！もありなんだよとかそういう風に考えられるといいかなあと。あと、公私は無理に1つにしなくていいと思う、というのが私自身の経験則。
「オンリーワンでNo.1以外は全部ダメ！思考」真に戦うべきはこの思考なんですよねぇ…。これのおかげでたった一人でブログを大きく出来たけど、これのせいで二つの道を緩やかに成立させることが手抜きに感じてしまう。どちらか一本をすごく真面目にしてしまう
青二才の敵は青二才自身の自意識。 ここに気付いたのはエライ。 あと一歩だ。頑張ろう。
オタクのコミュニケーションは手軽に深いコミュニケーション体験を得られて、麻薬的な快感を味わえてしまうんですよね。それをうっかり10代前半とか半ばに覚えると、なまじ味わってしまっただけに、この感覚を味合わえないコミュニケーションを異様に軽視しだすと思います。オタクのコミュ障の原点は多分ここなんだと思う。、刺激が強いコミュニケーションを求め続けた結果がそれかも……という事で次なる仮説を考えておりますｗそれぞれ味わいは違うけどおいしい、って理解ができればなんとかなるとも思うんですが、ジャンキーなヲタコミュにハマると難しいかもですねぇ。
無分別にオタクな用語をバラまいた結果、それまで築けていた間柄が傷つき、ボロボロになっていく過程こそが、コミュ障への過程そのものなのではないか。まさにどこかのヤマアラシのジレンマではないか。さて。この段階で分別があり、それまで使ってたコミュニケーションも手放さなければ、おそらくコミュ障の症状は軽度で済むと思う。問題は「闇に呑まれよ」ではないが、なんとかしてこのジャンキーな快感を味わえるコミュ方を駆使したい誘惑に抗えなかった人だ。当人は、ただ刺激の強いコミュニケーションをしたいだけなんだけど、周囲から見たら突然コミュニケーションのプロトコルが変わった人は一般的に「奇人」と言われる。親や友人に奇人扱いされるようになったら、いよいよオタクのコミュニティにしか居場所がなくなる。距離感がおかしくなるのは、自分の通信プロトコルが変わった自覚なしに、相手に通じない、刺激的なプロトコルを発し続けた結果なのか。通じればコミュが成立するけど、通じないコミュニケーションはひたすらノイズでうるさいだけだ。けど 「ぼくのかんがえたさいきょうのプロトコル」 が通じないことは二重の苛立ちを生む（素晴らしい物が認められない苛立ちと、通じないことそのものへの苛立ち）けど、自分のプロトコルに酔ってるから捨てられず被害が収束しないのか。本来はバカバカしいし投げ捨てるべき物なんだけど。あと、ここまで来ると多分、通常の汎用的なプロトコルが下に見えてしょうがない。だからこれを採択する気はないし、おそらくこれを使ってる連中を見下してる。とすると余計に殻に籠もって、自分だけの歪なプロトコルに益々酔いしれていくのか。うわあ。本来は相手に通じてナンボのプロトコルなのに、どんどん自分にしか使えない役に立たないプロトコルに入れ込んでいくアンビヴァレンツ。しかも翻訳すら許さない（翻訳はこの役に立たないゴミにあるはずのない品位を貶めることになるため）からゴミ加減が益々ｋｓｋするだけなのに余計に…うわあ。あとはこのサイクルが行くところまで行って煮詰まれば、どこに出しても恥ずかしいコミュ障がいっちょ上がってしまうのか。ぐへえ。やばい。開ける気の無かったパンドラの箱を無用に開けた気分だ。しかも希望がないorz。
この話の元は、まぁ案の定実体験なんですが、10代前半のオタ成り立て（罹患したて）の頃が案の定一番酷くて、「自分の日常会話が全てマンガやアニメのセリフで成立できてる」って信じ切ってた頃があったんですよ。だからプロトコルに酔うというのは実体験なんです。オタク人生２５年、もっと早く気付こうよ。ヒントはいっぱいあったし、多分この話は20年前ぐらいの自分でも理解できるよきっと。
自覚があるので読ませてもらいました。私自身汎用的なプロトコルとの上下関係を明確に定義したことはありません。ただ、私の中でこれで勝たなきゃ本当に母親に幼いときから押されていた「そんなこともできない奴」の烙印で一生涯潰され続ける。その絶望と戦ってたら、こうなりました
多分ここに明確な上下関係を見出す人は少ないと思います。快楽に支配されると、快感にならないものは意識すらしないからです。ただ、使い方によっては確かに武器にも杖にもなると思いますが、頼りすぎると自分に跳ね返ってくるだけです。
そこなんですよね。承認欲求が強すぎる状態を僕の基準地点にしてるから話がずれたり、煽り耐性が落ちてしまったりしてる。問題だとは思うのですが、オタク界隈の悩みゆえ明確な言語化・相談ができにくい内容。ゆえにバランスのいい状態でかつ僕の自己同一性が守られる形をもってない。そういう意味じゃ少し違うのかなぁ…と思うのです。まがいなりにも自分の頭と目で作ってきたモノに評価を受け、オタク的な人だけではなく幅広い層からの支持から得た自信なので、それゆえに過信しすぎていた部分が強かった。（成功体験と認識してしまうとそれを修正するのは難しい）
なるほど。あの鋭い舌鋒の台所を垣間見た気分です。でもこれを明確にコントロールできる人はやはりそういないですよ。タイミングの調節だけなら簡単にできるけど、威力とかキレ味のコントロールは強めることにしか大概の人は興味ないでしょうから、強さだけを求めてしまうと思います。成功体験と結びつくと尚更修正は辛いと思います。自分でつかみ取ったもので構築したとなったらなおさらですわ。壊す必要はないけど、見つめ直すことはオススメします。
全くそのとおりです。昔に比べて、「一般的な思考」よりも、先にエッジの効いた青二才節が先に思いつくようになったため、知らぬ間に相手から失言扱いされるケースが増えました。演じ分けとまで言わなくても、「一般的な思考」と並列できる程度には戻したいですねぇ…。最近、悩んでいるのはその力加減なのです。オタクブロガーのままリア充で真人間になるという路線でここ数箇月書いてきていたが、これがどちらからも不評であり、僕自身が疲れはててしまう事に最近気づいてしまったため、力加減の変えどころが分からず、思案していますね。正しい変化とか、更生とかそういう枠組みに入りたいとは思わないが…自分のやっていること、考えていることに無理や限界があるというのはわかる。そういう時の選択肢が欲しいねぇ…自分で作りこんでしまった自我ゆえに、一般的な処方箋を頭ごなしに押し付けられるのは御免だ。適切なモノを選ばないと
「炎上以外成功してないから、他のEXITを見つけられないから困っている」というところまで自覚があるならもう少し。炎上以外の方法で注目を集められる実力を身につけよう
個人的にはオタクのままリア充になって、自分がいる場所の視野を広げてしまいたいなぁ…と最近は考えるようになりました。それゆえ、オタク同士の座談会にわざと女性（ナース親子）を呼んで、ホモソーシャル的な議論にしないような事をしました。
と思ってたら、どうしてこういう小手先に頼ろうとするかな。 その程度の工夫でなんとかなるような悩みならそんなにひねくれたりしないでしょう。 強がらないでもっと自分の抱えてる悩みを真剣に見つめよう
本人がまとめててワロタｗｗｗ http://togetter.com/li/485119
開発終了といってもずいぶん前から更新は止まっていたわけで、明確に開発終了が宣言されただけで公開終了になるわけではない。
しかし FFFTP といえば FTP クライアントの定番なので、ネット上で様々な意見が飛び交っている。それについて思うままに書き散らかしてみる。
みんなが「ホームページ」なるものを持ち始めたころ、ファイルをアップロードするのに使ったなつかしい思い出がある。BlogやWikiのようにオンラインで編集できる時代になったことへの感慨も含むのか。
もちろんFTPがプロトコルとしてセキュアでないことは言うまでもないが、いまだに業務で使わざるを得ないことがある。LAN内の転送なら速度は最強かもしれないし、FTPのミラーサーバは世の中にごまんとある。短絡的に「オワコン」の一言で片付けられる問題ではないだろう。
ほとんどのユーザはお客さん気分であることを再確認し、「FreeBSD への貢献」をたたき込んだ自分とは違う人種だと思った。
もともとFTP以外の通信プロトコルを想定して設計していないだろうから難しいように思う。ただ、ユーザは動いているプログラムの中のことなど考えない。
モチベーションが低下する理由ってたくさんあるなぁと。長続きしているオープンソースプロジェクトはすごい。
ゲームを作りたい C言語の基礎を学ぶ それだけじゃゲームが作れないことが判明
win32apiを学ぶ 多すぎて？状態で挫折
ゲーム作るのはあきらめよう！チートだ！ アセンブリが面倒で挫折
向き不向きってあるよね・・・。もう勉強したくない・・・。
俺には向いてないんだろな。だってwin32apiでGUI作りで投げ出したくなったもん
俺の読んだ本
明快C言語 ダイテルC言語（例題飛ばしたのでほとんど意味なし） やさしいC 独習C
windowsゲームプログラミング（最後のテトリスとブロック崩しが面倒で飛ばした）
独習java（ガベージあたりで挫折） windows32api徹底理解 ホームページ作成の本（名前失念）
アセンブリ言語の教科書（100ページあたりでソースを読み解くのが・・・以下略）
何のために勉強しているかわからなかった・・・たぶんC言語の基礎すら身についてないと思う
じゃあweb関連や初心者用言語（php,ruby,pythonとか）学べばいいじゃんってネットで指摘されたんだけどさ
そうじゃないんだよ問題なのは。ライブラリの使い方がわからないし必要な技術がそれだけじゃないだろうし
今roboformのようなもの作りたいんだけどどうつくったらいいんだろ（guiは無理なのでコンソールで）
perlとかruby,phpで記述して通信プロトコルの勉強すればできるんだと思うんだけど俺にはもう体力が残ってない
あまりにも無駄な遠回りをしてきた。でも願望だけが空回りしてる。ライブラリもごまんとあるうえに通信プロトコルも勉強しないといけないんでしょ。甘えっていわれてもかまわない誰か助けて
