7/30/2019

RISCは基本的にスケーラブルではない

Erik McClureのブログより

今日、新しいRISC-Vチップに関する発表がありました。そして、それは多くの人々を興奮させました。私も興奮したいのですが、私にとっては、これはRISCアーキテクチャーが根本的にスケーラブルではないことを思い出させるためのものです。ARMv8.3-Aに「浮動小数点Javascriptの符号付き固定小数点への変換、ゼロ方向への丸め」というFJCVTZS命令が追加されているにも関わらず、人々は依然としてARMを「RISC」アーキテクチャと呼んでいます。(RISC)とは、縮小命令セットです。

これが起こり続ける理由は、物理法則がRISCアーキテクチャが負荷を受けても拡張できないことを保証するためです。問題は、最近のCPUは非常に高速であるため、L1キャッシュにアクセスするだけで3〜5サイクル掛かることです。これは、最近のCPUがレジスタ・リネーミングに大きく依存しているためです。実際に公開されている90個のレジスタとは対照的に、処理速度を上げるために使用される数百の内部レジスタを持つことができます。そのうち40個はベクトル演算用の単なる浮動小数点レジスターです。CPUアーキテクトが遭遇する基本的な問題は、光速が速くならないことです。CPUの一方の端からもう一方の端まで電気信号を受信する場合でも、1サイクル以上かかるため、CPUの物理的なレイアウトが動作速度に大きな影響を与えることになります。さらに悪いことに、CPUが速くなるほど、この遅れは問題になります。そのため、L1キャッシュとL2キャッシュがそれらを必要とするトランジスタに物理的に近づくようにCPU全体を縮小または再設計しない限り、レイテンシーは下がるのではなく増しますす。CPUは速くなっているかもしれませんが、光速は速くなりません。

さて、明らかに、RISC CPUは非常に複雑なアーキテクチャであり、あらゆる種類の非常識なパイプライン化を行い、できるだけ多くの命令を同時に実行しようとします。データが既にレジスタにロードされていない限り、実際の演算を実行するよりも多くのサイクルを使用してL1キャッシュからデータをロードする可能性があるため、これが必要です。L2キャッシュをヒットすると、それだけで13〜20サイクル掛かり、L3キャッシュのヒットは60〜100サイクルになります。これは、同じ演算を手動で実装するのに8サイクル以上かかる場合、ほとんどの場合1〜2サイクルでハードウェアで演算をエンコードすることで、複雑な浮動小数点演算をより高速に実行できることからさらに悪化します。前述のFJCVTZS命令は、特定のエッジケースに基づいて特定のフラグを設定して、直後にジャンプ命令を実行できるようにします。これもキャッシュのヒットを最小限に抑えるためです。

これらすべてのことから、ほとんどすべての最近のCPUに共通のシングル・インストラクション・マルチプル・データ(SIMD)ベクトル命令が導き出されます。 単一の浮動小数で複雑な操作をする代わりに、一度に多くの浮動小数に対して単純な操作を行います。たとえ個々の浮動小数点に対してこれを行うことがそれぞれ2または3サイクルのコストを有するとしても、CPUは、わずか3または4サイクルで、4、8、さらには16の浮動小数点数で同時に演算を実行することができます。大きなレジスタに浮動小数の配列をロードすることでさえも、それぞれの浮動小数を個別にロードするよりも速いでしょう。 派手なパイプラインであっても、1つずつ命令を実行しようとすると、通常ほとんど何もしていないCPUが生成されるという事実から逃げることはできません。物事を速くするためには、物事をまとめてしなければなりません。これは、できるだけ多くのことを実行する命令を持つことを意味します。これは、RISCが機能する方法の正反対です。

今、CISCが未来であるという意味ではありません。この問題に対する解決策をすでに考案しました。それはVLIW - Very Large Instruction Wordです。HPの研究者が30年前にこの問題を予測し、最終的にItaniumになったものを作成するためにIntelと提携したため、これがItaniumのものでした。Itaniumまたは任意のVLIWアーキテクチャでは、一度に多くのことを実行するようにCPUに指示できます。つまり、大規模なベクトル処理命令やその他の複雑な特殊命令を構築する代わりに、はるかに単純な命令セットから独自のメガ命令を構築することができます。RISCのパイプライン化の問題を回避しながらCPU設計を非常に単純化するため、これは素晴らしいことです。問題は、これをコンパイルするのが本当に大変で、それがIntelが失敗した理由です。Intelは、2001年のコンパイラはVLIWを動作させるのに必要な命令レベルの並列処理を抽出できると考えていましたが、実際には、それを確実に行う方法を見つけたのはごく最近のことです。20年前、私たちは緊密な関係になかったので、Itanium用の高速コードをコンパイルすることはできませんでした。今のItaniumは、現在の苦境を解決するために特別に設計されたものです。

そうは言っても、MILL命令セットは、VLIWを、ここで説明した多くの問題を補うために設計された他のいくつかのイノベーションと一緒に使用します。それはデータを要求してから実際にそのデータを使用できるようになるまでの遅延時間を考慮してロード命令を延期するのと同じようになります(偶然にも、MILLは推測する必要がないため、Specterの影響を受けなくなります)。残念なことに、MILLは現在のところまだベーパーウェアであり、パフォーマンスの向上が見込まれているにも関わらず、実際のハードウェアは実現していません。この理由の1つは、どのVLIWアーキテクチャーにも非常に固有の命令セットがあることです。 私たちはx86に慣れてきましたが、それは非常に高度なので、基礎となるCPU実装とはほとんど関係ありません。 誰もが同じ命令セットを実装し、あなたのプログラムはすべてそれで動作するのでこれは素晴らしいです、しかしそれは命令が対話する方法を予測するのが、コンパイラオプティマイザのフラストレーションにとっては難しいことを意味します。VLIWを使用すると、プログラムごとに固有のCPUごとにプログラムを再コンパイルする必要が生じる可能性があります。これは、MILLがかなりの時間を費やした問題です。

MILL、そしておそらくVLIWは、WebAssemblyのおかげで節約できる可能性があります。これは、あらゆるアーキテクチャに効率的にコンパイルできる低レベルのアセンブリ言語だからです。あなたがWebAssemblyを出荷するなら、それが走っているどんなCPUに向けてもシンプルにプログラムをコンパイルできるので、すべてのタイプのCPUのためにユニークな命令セットを持つことは問題ではありまさん。VLIW命令セットが最終的に急増するのを可能にすることが重要であると思うけれども、多くの人がWebAssemblyのこの利点を見逃しています。MILLは、結局のところ、日の目を見ることになるでしょう。あるいは、オープンソースであるRISC-VのVLIWバージョンを他の誰かが思いつくことができるかもしれません。どちらにしても、RISCのパイプライン化がうまくいくというふりをする必要はありません。今までうまくいったことはないし、うまくいくこともないでしょう。ただ、JavaScriptの浮動小数点変換命令を使って別のCISCに変わってしまうでしょう。

Every. Single. Time.

Hacker News

年内にCisco VIRL 2.0が登場

1年4ヶ月ぶりに、Cisco VIRLがアップデートされ、VIRL 1.6.65がリリースされました。VIRL PE 1.5のインクリメンタルアップデートとなります。1.6の目玉は、プライマリネットワーク・共有ネットワーク上でIPv6がサポートされた点です。

そんな中、Cisco VIRL 2.0の話も出てきました(youtube)。すでにプレリリース版ができており、Cisco Liveなどでデモが行われています。近々、トライアルも始まるとのこと。VIRL 2.0の目玉は、OpenStackを捨て、新しいミドルウェアスタック上で作られ、クライアントもVM Maestro(Java)ではなく、HTML5/ブラウザとなります。OpenStackではなくなるため、負荷も軽くなり、メモリの消費も少なくなっているようです。インストールも数分で終わるとのこと。全ての操作がAPI経由で、Pythonスクリプトからアクセスできるのも面白そう。何と言っても、高価なVMwareから解放されるのが嬉しい(クラウドという手もあるが)。

ブライアン・イーノ、ロジャー・イーノ、ダニエル・ラノワ、「Apollo: Atmospheres & Soundtracks」を語る

BoingBoingより

Noiseyのこの新しい14分のミニドキュメントで、ブライアン・イーノ、音楽セラピストの実弟ロジャー、そしてプロデューサー/ミュージシャンのダニエル・ラノワが、1983年にアル・レイナート監督の映画「宇宙へのフロンティア 」のために書き下ろして録音した「Apollo: Atmospheres & Soundtracks」について話し合います。彼らは、新しくリマスターされた「Apollo: Atmospheres & Soundtracks – Extended Edition」と彼らがそれのために作った11の追加トラックについても話し合います。

ここにいくつかの素晴らしいものがあります、イーノのように、カントリーミュージックがレコードに与える影響は、多くのアポロ宇宙飛行士が任務で重要な役割を担っていたことを学んでインスパイアされました。彼はより古いフロンティアの音楽を運ぶ宇宙のフロンティアズマンの考えを愛し、カントリーの無限のサイケデリックなバージョンを制作しようと決めました。彼とロジャーはまた、作曲の際に、どのように宇宙飛行士のキャラクターを推定しようとしたかについて話します、例えば、マイク・コリンズが司令部で後ろにいるのを想像して、その孤立感と畏敬の念を音楽に置き換えました。

ロジャーが、アームストロングが月面に足を踏み入れたときについて語る感動的な瞬間もあります。一瞬のうちに、人類自体が別のモード、希望に満ちた未来に飛び込んだように見えました。そして、今やその飛躍を失ったように思われます。そして、その希望も。

「Apollo: Atmospheres & Soundtracks」が実際にどれほど壮麗であるかを忘れてしまったのなら、こちらが「An Ending (Ascent)」のリマスター版です。Noiseyのドキュメンタリーの中で、イーノはトラックのこの最終版が実際に彼が取り組んでいたオリジナル作品であることを明らかにしました。

そして、これはデイビッドがExtended Editionから「Like I Was a Spectator」という新しいトラックの1つと共に投稿した初期の作品です

HMV

IETF 105でのそれほどプライベートではない考え

ジェフ・ヒューストンのブログより。

7月末にモントリオールで開催されたIETF 105で、会議のテクニカルプレナリーパートでは、今日のインターネットでのプライバシーの話題について、プリンストン大学のアーヴィンド・ナラヤナン(Arvind Narayanan)准教授[1]とコロンビア大学のスティーブン・ベロビン(Stephen Bellovin)教授[2]の2人の講演者がいました。二人はそれぞれ違ったやり方で話を邪魔していたので、この2人の発表についての印象を共有し、今日のインターネットで私にとってプライバシーが何を意味するのかを検討したいと思います。

まず、アーヴィンド・ナラヤナンは、プライバシー測定のいくつかの教訓を検討しました。

およそ10年前、電子フロンティア財団はPanopticlick(https://panopticlick.eff.org)と呼ばれるサービスをリリースしました。このサイトの背後にある基本的なモチベーションは、多くの場合(最初に報告されたように、明らかにケースの90%以上)、ユーザーのブラウザが独自のブラウザのフィンガープリントを生成したことです。ブラウザのCookieの設定に関係なく、またユーザーの明示的な知識や同意がない限り、ブラウザが訪問したWebサイトにデジタル追跡を残すように強制することで、それらをつなぎ合わせ、再組み立てすると個人の閲覧履歴が漏れる可能性があります。同様のサイト、Inriaによるamiunique(https://amiunique.org/)も、訪問したすべてのサイトのログに固有のフィンガープリントを残すという観点では、多くのユーザーが固有であるという前提に基づいています。インターネット上のプライバシー保護の観点から、この形の個々のユーザーの追跡は「あっけに取られるほど効果的」だと思われます。この手法は、おめでたい無知な人、そして恐らくは個人的なデジタルプライバシーの知らぬが仏的な封じ込め前のフィンガープリント採取の状態を取り戻そうとするあらゆる努力は非常に効果的でしたが、今では少な過ぎるし、手遅れです。

しかし、そのような自己選択バイアスの測定研究には常にリスクがあります。その後、いくつかの非常に大きなWebサイトに一意性テストを埋め込むことによるブラウザのフィンガープリントの有効性を調べたかなり大規模な調査では、この90%の一意性レベルが5分の1未満に低下しました。それはプラグイン環境が変化し、FlashとJavaがウェブ空間で段階的に廃止されるにつれて、この数はさらに減少する可能性があります。基本的な教訓は、この大規模な測定は私たちがこの分野でのプライバシーの闘いにまだ負けていないと信じる理由を与え、ブラウザのフィンガープリントに基づく追跡と追跡ツールはいかなる有用な目的にも効果がないままであるということです。また、この脅威を認識しているため、テクノロジの開発者、特にブラウザの世界では、各ユーザが自分の行動の痕跡を残さないような対策を講じる動機となっています。

これに対する彼の結論は、慎重な測定は私たちがリスクを理解すること、プライバシーに対するいくつかのクラスの脅威に対応する方法を考え出すことにおいて、私たちの助けとなる可能性があるということです。測定は他にどこで役立つ可能性がありますか?

プライバシーに対する社会的態度は急速に進化しているようです。プライバシーと商品やサービスへのアクセスとの間のトレードオフは時間とともに変化し、時には急速に変化します。技術標準や規範的仕様はそのような適応能力を持たず、現在の期待や規範を追跡することができない可能性があります。

Facebookの「いいね」の普及は、性格特性を予測する手段として使用されてきました[4]。これはCambridge Analyticaによってターゲティングに使用されたと言われています。買い物習慣は徹底的に分析されており、行動プロファイリングと組み合わせると、被暗示性のベクトルが明らかになります。大規模に行われた場合のそのような活動における極めて高い潜在的価値を考えると、これらの方法でプライバシーを侵害するこのような技術が急速に進化することは当然のことです。歩調を合わせるために、私たちは技術標準と技術開発者の間の関連付けにプライバシー研究を取り入れる必要があります。技術標準を詳細に検討し、展開されたネットワークでのアプリケーションの動作を調査するために、調査を奨励する必要があります。

この研究を支えるのは、測定の重要な役割です。ユーザーのプライバシーに対する期待を損なうためのテクノロジーの使用または悪用は、測定と分析による信頼できる一般公開を通じて抑制されています。これは大衆に知らせるだけでなく、情報の非対称性の状況に影響を及ぼし、テクノロジー開発者がテクノロジーの使用方法や悪用の可能性を理解するよう駆り立てます。明らかに、そのような測定と分析はまた、公共政策プロセスに情報を与え、それを形作るのを助けることさえできます。

プライバシーに関する問題は、ブラウザやプロファイリングをはるかに超えています。これは、データ収集が様々な方法で行われる世界にまで広がり、このデータの収益化の手段は、多くの場合、個人にはまったく知らされていません。米国の主要な携帯電話会社は、接続されたデバイスの位置データをデータアグリゲータに販売していました。自動車サービス会社は個々の車のサービスデータを販売しています。マイクロホンが、国内の空調機のコントローラーに組み込まれています。モノのインターネットは、プライバシーの包括的な破壊を含む、様々な意味で迫り来るデジタルの不幸な事態(catastrophe)に他ならないようです。繰り返しになりますが、観察、測定、分析、および報告のフィードバックループは、規制対応と技術的な対策を組み合わせるための生産的なアプローチを提供する可能性があり、これが最悪の潜在的状況を改善する可能性があります。

私は、プライバシーについての最初の見通しにおいて、アーヴィンド・ナラヤナンの立場を「慎重に楽観的な側面にある」と位置付けます。私はスティーブン・ベロビンの発表とは反対の立場だと分かりました。

スティーブン・ベロビンは、プライバシーの問題は確かに新しい問題ではないと主張しています。彼は1962年にプライバシーに関する正式な研究を始めたニューヨーク市弁護士会の科学と法律の委員会を引用し、1967年に出版されたこの委員会の仕事について報告したアラン・ウェスティンの本「Privacy and Freedom(プライバシーと自由)」につながりました[5]。米国内でのプライバシーの土台は、通知と同意、または個人による情報に基づいた意思決定の概念であり、この研究の根拠となっているか、少なくとも強く影響を受けていると思われるという立場です。ウェスティンは、「プライバシーの中心的な側面は、個人や組織が、秘密にしたいこと、進んで行うこと、または明らかにする必要がある事項を自分自身で判断できることだ」と述べました。アメリカとヨーロッパの両方でのその後の措置は、個人情報保護の権利を規制することにおいて、この通知と同意の基盤を継続しています。

プライバシーに対する技術的課題のほとんどは、長年にわたって理解されてきました。意図的な同意のごまかしは、あらゆる形態の行き過ぎを許容することに気付かせます。また、通知がほとんどの消費者にとって理解できない場合にそのような同意を得ルコとの容易さは長年の課題でした。メタデータの生成と個々のプロファイルを再作成するためのこのデータの解釈は、大規模でありながら検索が容易なデータベースの危険性と同様に、新しいことではありません。

これらの悪用が何十年にもわたって起こっていることを考えると、通知と同意が今日適切であるかどうかを尋ねることは合理的ですか? スティーブンの場合はそうではないようです。

通知と同意の問題の1つは、データ収集が個人を中心とした活動ではないことです。私たちは、電子ブックリーダーのページ読み取り速度から家庭用サーモスタットの温度設定まで、膨大な量のデータを生成します。データは、国の規制措置に対する明らかに無神経な考えで国境を越えてシフトされ、データ集約の活動は、民間部門の活動と同じくらい政府機関の活動になっています。オーストラリアのメタデータ保持法案は、収集された個人のオンライン活動のメタデータにアクセスするために、地方議会や王立動物虐待防止協会(RSPCA)ヴィクトリアでさえも使用されてきました[6]。

データ収集は常にあらゆる人のビジネスであるようです。通知と同意はもはやこの状況の一部ではありません。あなたがクレジットカードを持っているか、車、デジタル電話、買い物に行く、車を使う、あるいは公共交通機関に乗る、あるいはその他の人間の活動についてのあなたの行動に関するデータは、環境領域の範囲を超えて拡張するあらゆる方法や、通知と同意のあなたの領域を超えた方法で生成、保存、取引、分析されます。これはキーボード、モバイル機器、そしてブラウザだけではありません。私たちは今、「過剰収集」と言ううってつけの言い回しの状況になっています。そして、個々の目的からかなり離れた位置で膨大な量のデータを集めて販売するデータ卸売業者が今あります。

この通知と同意の構造化プライバシー体制の通知部分は、包括的に悪用されているようです。彼らは曖昧で、長期にわたり鈍感になりがちです。求められている同意はしばしば完全にオープンエンドであり、実際にはアクセスできない細かい活字で埋め込まれています。ユーザーが実際にこれらの通知を読み、インフォームドおよび考慮された同意を提供すると想定できるのは、ある空想の世界においてのみです。それは全く起こりません。

スティーブン・ベロビンの結論は、通知と同意が死んだということです。誰がデータを収集するのか、誰がデータがどこに格納されているのか分かりません。彼らがそれをどうするかは誰にも分かりません。

しかし、通知と同意が死んだ場合、それに代わるものがありますか?

彼の発表では、彼は利用管理(Use Controls)の概念を提案しています。個々の手続ごとに同意を提供するのではなく、ユーザーは、すべてのデータ取得者、集積者、分析者、および取扱者による自分のデータの使用方法を指定できなければなりません。ターゲットを絞った検索広告、統計分析、公の国勢調査、または医学研究が許可されているかどうかに関係なく、許可されたデータの使用に関するプロファイルを定義するのは個々の消費者次第です。

それは単純に聞こえるかも知れませんが、もちろん、根本的に複雑な多くの領域があります。そのようなコントロールはどのように定義されるべきですか? このような権限はどのくらいの期間、有効ですか? それは誤用を禁じるかも知れませんが、そのような誤用を検出して告訴することは非常に難題かも知れません。それは、間接的なデータ取得に対してどのように機能するのでしょう? また、個人のアイデンティティに関する知識がなくてもデジタルプロファイルが依然として価値があるプロファイリングデータにどのように適用できるのでしょうか?

いずれにせよ、私ちが今日は論理的なものであると思われる通知と同意から離れると、その利用管理または他のフレームワークに関わらず、必ずデータ処理の新しいパラダイムに移行しています。そのようなパラダイムは、幅広い多様な関係者、そして時代や規制体制にまたがって拡大する必要があります。それは、理解可能で強制力があり、一次データと間接的に生成または推論されたデータの両方を説明しなければなりません。

明らかに、私たちはまだそのようなプライバシーフレームワークを持っていません。通知と同意は非常に失敗しており、その見通しは変化するようには見えません。とにかくこの方向を向いていると仮定しても、管理(コントロール)を使用するのは少し先に進みます。 今、私たちに何ができるのでしょうか?

技術開発者へのメッセージは何ですか? スティーヴンは、おそらく現在IETFができる最善の策は、データ収集を明確な視野に入れ、常に発生しているデジタル排ガスをひそかに盗聴することによって、偶然の間接的なデータ収集を防ぐことであると示唆しています。主要なデータトランザクションがクライアントに限定されており、サーバーおよび仲介者が盗聴によるデータ収集を実行するための努力においてより困難な場合がある限り、あらゆる機会においてトラフィックの暗号化が役立ちます。

このメッセージは確かにトーンは暗いですが、彼はまだすべての希望をあきらめていません。

個人的には、これでさえ現在の状況が変わって軌道が改まるかどうか確信を持てません。

監視資本主義は現在、世界で最も価値の高い上場企業の大部分の富の中心にあります。それらは伝統的な経済学の意味での商品やサービスの彼ら自身の生産の価値によって評価されるのではなく、彼らが詳細な個人のプロフィールを集めた個人の対象の何十億の純資産の百分率として評価されます。しかし、これでもそうではありません。その乗数の値は、これらの同じ個人の将来の見込み価値も含まれているからです。私の将来の総支出予想が私の年齢とともに減少するにつれて、この監視経済に対する私の正味の価値もまた減少します。これは私たちの子供たちのデジタル監視の価値とその結果として生じる強度について何を言っているのでしょうか?

今日の経済の主要な経済主体が既存のプライバシー構造の弱点を冷酷に悪用しているなら、この膨大な経済的資産を選択された少数の人々が生み出しているまさにその行動に取り戻すために、私たちはルールを変更しなければならないのはどういう事でしょうか?

公共政策: ロビー活動を行っている政治家が良好な結果をもたらすなら、Alphabetが2018年のロビー活動に費やしす2000万ドル、Facebookの1300万ドルは、彼らのデータ収集と分析の慣習が少なくとも米国の公共政策の変更を通じて改善されないように支援するべきです。[7]

このような状況から導き出すことができる暗い結論があり、それは私がしぶしぶ引きつけられているものです。

私にとっては、ここで問題になっているのは個人のプライバシーの侵害ではありません。私はそれがこの世界では主に失われた原因であると思いますが、すべての規制、罰金、暗号化と使用制御タグ付けはそれを取り戻すつもりではありません。個人のプライバシーは今日の世界では絶望的に失われており、二度と戻ってこないのです。

私たちの行動は、現在と将来の両方で、そして私たちがこの精査の個々のテーマとしてほんの少ししか理解していない方法で、包括的に観察され、記録され、そして分析されます。これは単なるデータ収集と予測分析の交換ではありません。監視資本主義の最も価値のある報酬は、これらの人間の脆弱性の瞬間を正確に識別できるユーザーに提供されます。そこでは、最初の提案の正しい指示が止められないモメンタムを帯びます。Googleのチーフエコノミスト、ハル・ヴァリアンは、何年も前(1998年に私が参加したGlobal Internet Summitのことで、彼の言葉をここで言い換えます)で語っています。スパムまたはあらゆる形態の不要な広告は、単なる情報の失敗です。広告主が各消費者についてのより良い情報にアクセスできれば、そのときすべての広告は有益な提案になる、または誘惑に抵抗することは不可能です!

この段階で、私たちはやや奇妙な場所に到達したようです。この総合的なデジタル観測と分析の結果、私たちが何を望み、何を手に入れることができるかについての徹底的な理解を得ているのであれば、何が問題なのでしょうか? 私の個人的なデジタルの世界が、私の個人的な好みを識別し、私が自分のニーズや欲求をどのようにして満たすことができるかを私に知らせることに費やされてならば、次に私が個人的に欲しいものを得るためにこの努力のすべてが捧げられているのです。問題はどこにありますか?

私の考えていたニーズへのこのデジタル仲介の結果が必ずしもすべての人にとって、または私にとってさえもより良い世界ではないことを私は心配しています。デジタルディバイドはまだ存在しています、そして特権的な少数によって実現される利益はしばしば幸運でない他の人が支払わなければならない代償です。このデジタルの世界の恩恵は、最初の世界にとってのデジタルの配当に過ぎないかも知れません。彼らの後には、権利を奪われ、搾取された痕跡を残します。

私たちが人間社会として危険にさらされているのは、そもそもなぜ私たちが社会に生きることを選んだのかというまさにその基盤です。そのようなデジタルの利己主義について私が深く心配しているのは、私たちがそれを知って理解しているように、私たちがまさに人間社会の団結を危険にさらしているということです。私たちは、共同作業をし、共通の利益に私たちの個々の努力をプールすることによって、私たちが公正にすべてに利益をもたらす社会を維持することができるという本質的な認識を失うかも知れません。

産業化時代の永続的なコストが私たちの自然環境の破壊であったとしたら、このデジタル時代の本当のコストとデータに対するその止められない渇望は、私たちの社会的共通社会構造の破壊に他ならないのではないでしょうか?

参考文献

  1. Arvid Narayanan, Lessons from Privacy Measurement, IETF 105 Technical Plenary, July 2019. https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-lessons-from-privacy-measurement-arvind-narayanan-00.pdf
  2. Stephen Bellovin, Privacy: Modern Concerns, IETF 105 Technical Plenary, July 2019. https://datatracker.ietf.org/meeting/105/materials/slides-105-ietf-sesse-privacy-modern-concerns-steven-m-bellovin-00.pdf
  3. Gómez-Boix et al, Hiding in the Crowd: An Analysis of the Effectiveness of Browser Fingerprinting at Large Scale. WWW 2018. https://www.doc.ic.ac.uk/~maffeis/331/EffectivenessOfFingerprinting.pdf
  4. Kosinski et al, Private traits and attributes are predictable from digital records of human behavior. PNAS 2013. https://www.pnas.org/content/110/15/5802
  5. Alan Westin, Privacy and Freedom, Ig Publishing, First Published 1967.
  6. https://www.zdnet.com/article/61-agencies-after-warrantless-access-to-australian-telecommunications-metadata/
  7. https://www.businessinsider.com/r-google-spends-big-on-us-lobbying-amid-antitrust-bias-battles-2019-1

APNIC Blog

7/29/2019

求む、サイバーセキュリティのイメージ

シュナイアーのブログより

ヒューレット財団のEli Sugarmanは、サイバーセキュリティの画像のお粗末な状況について嘆いています

サイバーセキュリティのイメージの状態は、一言で言えば、見るも無残です。その言葉を単純にGoogle画像検索で証明します: それは、キーボード、「マトリックス」スタイルの緑の1と0、鮮やかな錠前とサーバーラック、またはこれらの要素のランダムな組み合わせの上に隠れていることがあります — 時にはパーカーで覆われた男が防犯マスクを着用しています。これらの各画像は、そのテーマの重要性や複雑さ、あるいは暗号化、監視、サイバー戦争などのテーマに内在する政府、産業界、一般の人々に対する大きな危険の度合いについては何も伝えていません。

私は、これが問題であることに同意します。最近まで気づいたことではありません。私は言葉で働きます。言葉で考えます。私がプレゼンテーションをするとき、私はPowerPoint(または同様のもの)を使いません。 ビジュアルを必要としません。

しかし最近、私はハーバード・ケネディスクールで教え始めました。そして、私のクラスで常にビジュアルを使います。 私はそれらと同じ画像検索をしました。そして、私は同様に容認できない結果を思い付きました。

しかし私とは違って、ヒューレットはそれについて行動を起こしています。あなたは助けることができます: サイバーセキュリティ・ビジュアル・チャレンジに参加して下さい。

7/28/2019

アカウキクサ・イベント

Wikipediaより。地球温暖化解決のヒントになる??

アカウキクサ・イベントは、淡水シダ植物アカウキクサ水の華が北極海で発生したと考えられており、およそ4900万年前の中期始新世時代に発生したと仮定されたシナリオである。それらが停滞している海底に沈むと、堆積物に取り込まれた。結果として生じる二酸化炭素の減少は、地球をカメやヤシの木が極地で繁栄するのに十分なほど暑い「温室地球」状態から、それ以来の氷室地球へと変化させたと推測されてきた。

現代のシダであるニシノオオアカウキクサ(Azolla filiculoides)。近縁種の花が地球を現在の氷床の世界に引き込んだ可能性がある。

イベントの地質学的証拠

北極海湾全体の堆積層では、厚さが少なくとも8mに達するユニット(最も長いコアの底部は回収されなかったが、20m以上に達した可能性がある)が識別可能である。このユニットは交互の層から成る。海底堆積物に通常見られるプランクトンのバックグラウンド堆積を表す珪質砕屑物層は、化石化されたアカウキクサ物質からなるミリメートルの厚さの積層物と交換する。この有機物は、北極海湾全体で注目されているガンマ線スパイクの形で検出することもでき、イベントを様々な場所に穿孔されたコアを一列に並べるのに役立ちます。花粉学的管理と高解像度の地磁気逆転記録による較正により、イベントの継続期間は80万年と推定される。このイベントは二酸化炭素レベルの壊滅的な減少と正確に一致します。そして、それは始新世初期の3500ppmからこの出来事の間の650ppmに落ちました。

δ18O - 温度の代用 - 過去6500万年間。アゾライベントは始新世の最適条件の終わりと世界的な気温の長期的な低下の始まりを示していまる。

アカウキクサ

アカウキクサは、1エーカーあたり年間1トンの窒素(0.25 kg/m2/年)を排出することができるので、「スーパープラント」と見なされてきた。これは1エーカーあたりの炭素排出量(1.5 kg/m2/年)あたり6トンに相当する。成長のために大気中の窒素を使うことができるということは、成長の主な限界が通常リンの利用可能性であることを意味する: 炭素、窒素と硫黄はタンパク質の重要な要素の3つで、そしてリンはDNA、RNAとエネルギー代謝に必要である。植物は好条件 - 初期の始新世の間に極で明らかであった - 適度な暖かさと20時間の日光 - の中で非常に速い速度で成長することができて、そのような気候で2〜3日にわたってそのバイオマスを2倍にすることができる。

イベントを促進した条件

始新世初期には、大陸移動説は北極海がより広い海からほぼ完全に遮断されるようになった。これは、今日の湾岸流のような深い水流によってもたらされる混合が起こらなかったことを意味し、今日の黒海に似た層状の水柱をもたらした。高温と風は高い蒸発をもたらし、海の密度を高め、そして - 降雨量の増加を通して - 湾を供給していた河川からの高い排出量をもたらした。この低密度の淡水は、密集した海の表面に浮かぶ、半球体の層を形成した。数センチの淡水でさえ、アゾラによる植民地化を可能にするのに十分だろう。さらに、この川の水はリンのようなミネラルが豊富に含まれていて、それは泥から蓄積し、それが大陸を横切ったときに相互作用した岩石である。植物の成長をさらに助けるために、大気中の(二酸化炭素の形態の)炭素の濃度は、現時点では高いことが知られている。

始新世初期の大陸構造は孤立した北極海湾をもたらした。

水の華だけでは地質学的影響を与えるには不十分である。恒久的にCO2を削減し、気候変動を引き起こすためには、炭素は埋もれている植物によって隔離されなければならず、その残りは有機体を分解することができなくなる。成層水柱の結果である北極海湾の無酸素底はまさにこれを可能にした: 無酸素環境は分解する有機体の活動を抑制して、それらが堆積物によって埋められるまで植物が広がることを可能にする。

地球的影響

非常に控えめな見積もりでも、80万年におよぶアカウキクサの水の華エピソードと4,000,000km²の湾で、この1つの現象だけで観測されたCO2の80%の減少を説明するのに十分な量以上の炭素を埋め込むことができる。他の要因がほぼ確実に役割を果たしたことを強調しておくべきである。この低下により、温室から現在の氷室地球への転換が始まった。北極圏は、平均海面温度13℃から今日の−9℃まで冷却され、それ以外の地球も同様の変化を遂げた。おそらくその歴史の中で初めて、惑星はその両極に氷床があった。アカウキクサ・イベントの前後で、4900万年から4700万年前の間に地質学的に急激に気温が下がったことは明白である。それ以降、氷河の存在の証拠とされるドロップストーンが北極堆積物では一般的である。これは、緩やかで長期的な冷却を背景としている。北極圏の広範な凍結の証拠が一般的になるのは、1500万年前までではない。

代わりの説明

緑豊かな北極海は実行可能な実用モデルだが、懐疑的な科学者たちは、川の三角州や淡水のラグーンのアカウキクサの植民地が強い潮流によって北極海に押し流される可能性があると指摘している。

経済的考察

北極地方における石油探査に対する現在の関心の多くは、アカウキクサ鉱床に向けられている。大量の有機物の埋葬は石油の根源岩を提供するので、正しい熱履歴を考えると、保存されているアゾラの花は石油またはガスに変換された可能性がある。アカウキクサに専念する研究チームがオランダに設立された。

Hacker News

7/27/2019

「スタートレック: ピカード」の予告を分析する

Slashfilmより。☺️

先週末のサンディエゴ・コミコンで待望の「スタートレック: ピカード」の予告編がリリースされたことに対する反応は圧倒的に前向きなもので、ファンに郷愁の注射を与え、同時に新しいシリーズのために何が用意されているかについての興味深い手掛かりを漏らしました。それが2020年のショーに何を意味するのかについての推測を含む予告の詳細な分析を読んで下さい。

「あなたは今まで自分がよそ者になったことがありますか?」私たちが後にダージと分かる若い女性が、予告の冒頭で尋ねます。「何度もある」ピカードは、カメラが前のティーザーが彼の現在の家として明らかにしたものをパンする —フランスのラバレの彼の家族の先祖代々の家のブドウ畑だと認めています。

それから、最後のTNG映画「スタートレック: メネシス」の終わりに艦長のために命を犠牲にしたデータ少佐に、彼の声を介して彼の考えが向ける前、ピカードのショットで彼は不機嫌そうな表情でコミュニケータを見て、バックストーリーに向かいます。

次に、引き出しの中で解体されたデータの画像に目を向けます(あるいはシリーズの最後で見たデータの邪悪な兄弟ロア、彼は停止させられ、解体されました。それとも、失われたデータの記憶の少なくともいくつか収容する初期のアンドロイドのプロトタイプであるB-4です。それとも、完全に異なるバージョンでしょうか!?)。私たちはまたシリーズへの新しい登場人物の最初のショットを目にします — アグネス・ジュラティ博士(アリソン・ピル)、ピルはSDCCパネルで「研究者」として説明しました。彼女はB-4からデータの記憶を回復することに取り組んでいるのでしょうか? 彼女は、ロアのボディを持っていて、データの記憶を上書きできると思いますか? 可能性はたくさんあります。(更新: コミコンの発言は、これが箱の中のB4であることを示唆していますが、それはスピナーがシリーズの中で彼を演じているという意味ではありません。)

私がここで強調したいのは、コミコンが予告の短いカメオを作る前に公開されたティーザー写真の最愛の犬で、パトリック・スチュワートがそのことについて何か言えることがあるとすれば、もっと彼に会えると期待できることです。「ちなみに、彼の名前はDineroです。」とSDCCパネルの犬についてスチュワートは言いました。「そして、彼は素晴らしい動物です。そして、彼がこのシリーズ全体で継続的な役割を果たすことを願っています。」

doggo後は、ピカードへと急に変わります。彼の家ではまだカジュアルな服装ですが、再びコミュニケータを付けて、ぶどう畑が本当に家のようには感じられなかったと星を見ています。私たちが知っているピカードは、彼がそれについて複雑な感情を持っていることは明らかですが、再び旅をしたくてウズウズしています。「スタートレック: ネメシス」以来、彼に何が起こったのですか? それは明らかにトラウマ的な何かで、私たちはピカードに焦点を当てたショートトレックがシリーズの初演の前に出てくるとき、まさにそのことについて薄々感じるかも知れません。

予告は今シリーズの刺激的な事件 — 私達が最初に雨の道を歩いているのを見るダージ(イサ・ブリオネス)という名前の若い女性に目を向けます。彼女の頭は覆われていますが、私たちはまず彼女の額の上の傷を垣間見ることになります、そして、私たちは彼女が同様に後の予告に現れる独特のネックレスを握っているのが見えます。

ダージの接写の直後、私たちは通りを歩いている彼女のより広い視野を得て、そして店内のテレビスクリーンでピカードを見ることができます。(余談ですが、私は2399年に電器店でまだ行われているスクリーンを見て、キャラクターたちがどのようにニュースを見つけるのかが大好きです。)

ダージは、テレビ画面にピカードが映ってているので、ピカードを追跡しているのだと思います。「あなたは私が誰であるか知っていますか?」彼女は彼に尋ねます。「私の内側にあるものはすべて、私はあなたに対して安全だと言っています。」 私たちが確信を持っているわけではありませんが、彼女の頭の上の深い傷と、彼女がピカードとつながっているという事実から、彼女はかつてボーグだったことを示唆しています。

しかし、ピカードは彼女が誰であるかを知っているようで、そして最初に助けを求めてスターフリート本部に向かいます。ピカードは、「彼女が、私が考える彼女だと思う人物であれば、彼女は深刻な危険にさらされている」ピカードは、ダージがかなり印象的なテレポート能力を持つ2人のミステリアスな攻撃者と戦っていると言います。誰が彼女を攻撃しているのかは現時点では不明ですが、次のシーンは彼らが誰であるのかについての手がかりを与えます。

予告は宇宙に移動し、ロミュラン艦隊が赤い曇った惑星に向かっているように見えるものの簡単なイメージで場面が変わります。ロミュランの故郷は、2387年に超新星によって破壊されたことを知っています(ピカードがスターフリートを去った時、偶然にもそれはおよそ15年前です)。ピカードはロミュランの避難に関わったのでしょうか? スターフリートでの彼の時間の終わりについて、なぜ彼は引退して複雑な感情を抱いているのでしょうか? そして、もしロミュランが破壊されたら、どんな惑星がここに示されるのでしょうか? それはロミュランの先祖の一族この本拠地バルカンでしょうか? それとも他のどこか?

次に、ロミュラン人がボーグドローンで作業している様子を簡単に説明します。ここでロミュランが着用するマスクは、以前にダージを攻撃した人々が着用したものと似ており、それらは同じ組織のものであることを示唆しています。

それから予告は突然ピカードがそこに駐留したときにUSSエンタープライズで開催されたピカード艦長デーを祝うバナーの短いイメージに変わります。このカットはファンにとっては素晴らしいイースターエッグですが、「時々私は、あなたが自分が誰であるかを忘れてしまったのではないかと心配します。」と言っている女性の声も聞こえます。それは、彼がラ・バレへ引退する前に彼に起こりました。

それから私たちはロミュラン人に別の鋭い切り口を持っています。そして、彼らは何らかの方法でボーグに関係している若い囚人のグループを収容する刑務所またはキャンプを運営しているようです。サインとして「この施設は、同化せずに5843日が経過した」がそれを示唆しています。

次のショットでは、ピカードがバルカン人またはロミュラン人の女性と話し、前の声でジャン=リュックに自分が誰であるかを忘れていると伝えました。ここでの二人は、特に良い関係ではないようです。ピカードが自分(および彼女の人々)が自分にしたことを忘れていないことを思い出すと、女性の調子は敵対的になります。

そして、この女性は誰ですか? 彼女がロミュラン人とバルカン人を区別する古典的な眉毛の尾根を見逃しても、先のとがった耳と彼女の敵意は彼女がロミュラン人であることを示唆しています。予告の他の部分と一緒に演奏されるものを考えれば、私は今のところロミュラン人に同意するつもりです。

予告の次の部分では、このシリーズのピカードのその場のクルーになる人たちを紹介します。私たちは彼の新しいクルーの一瞬を得ます: クリス・リオス(サンティアゴ・カブレラ)、ドクター・アグネス・ジュラティ(アリソン・ピル)、ラフィ・ミュジカー(ミシェル・ハード)、そして、エルノール(Evan Evagora)で、背中に大きな光沢のある刀を背負ったバルカン人(またはロミュラン人?)です。

それから、私たちはピカードに旅行服で、彼が確かにラ・バレではない、そして疑わしいことに地球上のどこかのマーケットを歩くとき、彼の背中にかばんを持って行きます。彼がどこへ向かっているのか、そして彼が何を探しているのかは不明です。

ピカードがドローンのそばにある長い廊下を歩いていくと、白い女性が率いています。 私の考えでは、これは順番とは外れたシーンであり、ドクター・ジュラティが勤務している施設かも知れません。ピカードの服は前のシーンとは違うのですが、それはもちろん可能性です。

それから私たちは別のロミュラン人と会話しているロミュラン人、ナレク(ハリー・トレッダウェイ)に変わります。 「彼女は、自分が本当に誰なのか分かっていません。」彼が言及している「彼女」は、もちろんダージです。

私たちはここで彼女が組織的な設定で彼女を見ているように、彼女がかつてロミュラン人の囚人であった可能性があることをここで証明します。上品な手触りで、まだつながっているネックレスを身に着けています。ダージは、どうやら(そして驚くことではないが)、ロミュラン人にとってはひどく忌々しい関係のようです。「彼女はすべての終わりです!」別のロミュラン人は別のシーンで叫びます。「彼女は破壊者です。」

そして、予告が先導してきたもの、つまりボーグキューブの決定的瞬間を目にします。しかし、このキューブは損傷しているように見えますが、その周りをロミュラン船が飛んでいるようにも見えます。ロミュラン人はそれを救助したのでしょうか? そして、ボーグテクノロジーを利用しようとしているのでしょうか? そのロミュラン刑務所収容所はどこにあるのでしょうか?

それからトレーラーの最初の大きなカメオ、セブン・オブ・ナインに行きます。「ここで一体何をしているんだ、ピカード?」と彼女は、ジャン=リュックが大人の飲み物を注いでいると尋ねた。「銀河系を救う?」ここにセブン・オブ・ナインが登場することは、ほんとうに嬉しいファンサービスかも知れませんが、これまでに得てきたボーグのヒントにもつながります。ピカードとセブン・オブ・ナインは、同化されてボーグから切り離された2人の人間です。ダージもこのバケットに該当する可能性があるので、彼女がここにいるのは理にかなっています。

予告は今や最高潮に達し、そして私たちはロミュランの手術台であると思うものの上で分解されているヒュー・ザ・ボーグ(ジョナサン・デル・アーコ)のショットがロミュラン人によって扱われているボーグキューブの内側の速い断片を目にします。走っている人たち、大きな悪いフェイザー銃を持ったピカード、そしてそれから、すべてのトレックファンの心を圧迫する場面で、ピカードは彼のトレードマークとなるフレーズを伝えます:「エンゲージ」。

そして、予告が終わると思ったときに、ピカードはデータとトランプをプレイしています! 本当にデータ? 私は前にアンドロイドが引き出しの中でバラバラにしたのは誰かについて推測しました、そしてこれは誰かの再組み立て版であるかも知れません — 再プログラムされたロア、B-4はデータの物まねをしますが、本物ではありません。あるいは、これはピカードが彼の古くからの親友と過ごす時間をシミュレートするただのホロデッキ体験でしょうか。

答えが何であれ、CBS All Accessで初公開されるまで待つ必要があります。これは2020年になるでしょう。

7/26/2019

IPv4ユニキャストの拡張について

44/8ついでに、IPv4アドレスの未使用の区画を使えるように拡張しようと動いている人がいるが、そのインターネットドラフトがGithubにある(まだ正式なドラフトではない)。IPv6化のコストとの比較になるが、既に多くの実装が存在するクラスE部分(240/4)はすぐにでもできそうな気はするが、0/8、127/8、224/4まで手を付けるとなると、かなり難儀だろう。

IPv4ユニキャストの拡張

draft-gilmore-taht-v4uniext-01

J. Gilmore
Electronic Frontier Foundation
D. Taeht
TekLibre

抜粋

編集者注: このドラフトはいかなる正式なプロセスにも提出されていません。提出された場合は、大幅に変わる可能性があります。私たちはあなたを信頼し、私たちはあなたの意見を大切にするので、これを読んで下さい。再循環しないで下さい。どうかパッチや機器のテストにご参加下さい!

ユニキャストアドレスは、インターネットプロトコル(IP)で最も成功し、最も有用なアドレスです。何十年もの間「将来の使用のために予約された」いくつかの未使用部分を含めて、非ユニキャスト部分は、それらの使用が必要とするよりも大きい空間を割り当てられました。一方、世界中でユニキャストIPv4が急速に普及したため、ユニキャストアドレスの供給が枯渇しました。新しいIPv4ユーザーは、古いユーザーから再利用するために、アドレスごとに15米ドル以上を定期的に請求されます。

インターネットの進化の維持を全てに広げて、新規参入者に対する障壁を減らすために、この文書はユニキャストアドレス空間を拡張して、エンドユーザーに数十億ドル相当の数億のユニキャストIPv4アドレスを含めるようにします。それは、これらのアドレスをグローバルに到達可能なユニキャストアドレス空間として再分類するために[RFC6890]を更新します。

これらの変更をグローバルに実装するには、世界中でIPv4互換機器の一部を再プログラミングする必要があります。これは、一元的な資金提供も組織化もされていない複数年にわたるプロジェクトです。また、その移行についても説明します。

2. はじめに

ユニキャストトラフィックは、IPv4の主たる用途です。ブロードキャスト、マルチキャスト、および予約済みのIPアドレスは比較すると、ごく限られた範囲でしか使用されません。現代の要件をよりよく満たすためにIPv4を少しずつ進化させる必要があるなら、ユニキャストトラフィックのサポートを強化する必要があります。

今日のIPv4ユニキャストトラフィックの最大の問題は、IPv4アドレスの不足が原因です。この文書はすべてのかつて「将来の使用のために予約されていた」アドレスに加えて、最も容易に取り戻すことができるいくつかの他の非ユニキャストアドレスがグローバルに到達可能なユニキャスト使用のために充てられるべきであることを述べます。

3. インターネットアドレス指定モデルの簡単な歴史

インターネットプロトコルバージョン4のアドレス指定モデルは単純なものから始まり、40年に渡って進化してきました。このInternet-Draftはその進化を簡単に要約し、IPv4がその設計寿命の終わりに近づくにつれて、その進化の間になされた名残の選択のいくつかを単純化することで、インターネットコミュニティに大きな利益がもたらされることを提案します。

3.1. ARPANET -> IPv4

インターネットプロトコル(IPバージョン4、IPv4)は、ARPANET [RFC6529]プロトコルに代わるものとしてゼロから設計されました。統一性を強制するのではなく、多様に実装された基礎ネットワークの連結ネットワークという「Catenetモデル」[IEN48]に従い、シンプルで比較的メモリの少ないゲートウェイで接続されています。

x.x.x.x表記で表されるIPアドレスは、特定のネットワークとそのネットワーク上のホストアドレスの両方を指定するために使用できます。IPアドレスにはいくつかの異なるクラスがあり、それぞれネットワークとそのネットワーク内のアドレスに異なるビット数が割り当てられています。クラスAネットワークはnetwork#に8ビットを使用し、そのネットワーク上のアドレスに24ビットを許可しました。ARPANETアドレスは24ビットにコード化できました。従って、ARPANET(およびその一部のクローン)では、10.2.0.5のようなIPアドレスは、ネットワーク#10、IMP#5のホスト#2を意味します。ホスト#2は、IMPキャビネットの背面にある特定の物理コネクタを識別しました。

ルータ(当時はゲートウェイと呼ばれていました)、ホスト、および他の誰かがIPアドレスを取得し、単純なアルゴリズムによってその特定のネットワーク上のネットワークアドレスを把握することができます。これは、ARPANET、SATNET、およびPRNETに有効です。

LANはこの方式を破りました。特に、イーサネットアドレスは大きすぎて24ビットのクラスA IPアドレスにさえ詰め込むことができませんでした。そのため、これらの種類のネットワークではアルゴリズムによる変換は不可能でした。それが最終的に、ARPを作成し、イーサネットのブロードキャスト機能を使用して、変換を行うためのメカニズムを実装するようになりました。

1981年までに、IPv4は[RFC0791]、[RFC0792]のシンプルでうまく編集された仕様として降り立ちました。

設計者は、ARPANETのアドレス指定[RFC0635]、およびその他のいくつかの一般的なネットワークのアドレス指定を、[RFC0760]のIPv4の32ビットアドレス空間で改善しました。妥協案として、32ビットアドレス空間が選択されました。それを使用したいと思う可能性があるすべてのノードをアドレス指定できないことは最初から知られていましたが、初期のルータおよび開発スケジュールにおけるリソース制限はより長いアドレスの使用を推奨しませんでした。

初期のIPv4設計では、可能なアドレスのほぼ7/8を通常のユニキャストアドレスとして指定していました。これらのアドレスは、個々のノード、ルータ、およびインターフェースを識別し、完全なグローバル到達可能性を使用して転送されるように設計されたパケットの送信元アドレスおよび宛先アドレスとして使用できます。 [RFC0791] [RFC0796]

初期の規格では「ユニキャスト」という用語は使用されていません。これは、インターネットプロトコルの進化の後半で出現したマルチキャストやブロードキャストとは対照的に使用されるようになったためです。[RFC0966]は、「ユニキャスト」という言葉を最初に使用したものです。「この文書では、マルチキャストのモデルについて説明します。私たちはホストグループと呼び、DARPAインターネット環境でマルチキャストをサポートする方法としてこのモデルを提案します。私たちは、既存の『ユニキャスト』IPデータグラムモデルとメカニズムの拡張としてこの機能を実装するのが実行可能であると主張します。」

32ビットアドレス空間の1/8は「将来の使用のために予約されている」として残されました。そして、他のいくつかの256分の1は単純なプロトコル機能または[RFC0791](セクション3.2)と[RFC0796]の将来の使用のために予約されました。

プロトコル機能用に最初に予約されていたアドレス空間の256分の1は「ネットワーク0」でした。IPv4アドレス0.0.0.0は[RFC1122](セクション3.2.1.3)で、まだ自分のアドレスを知らないノードによる送信元アドレスとしての使用のためだけに予約されていました。フォーム0.x.y.zのアドレスは、最初はICMPデータグラムの送信元アドレスとしてのみ定義されていました。これは、ローカルネットワーク上のアドレスを知っているが、まだネットワークプレフィックスを知らないノードによって「このIPv4ネットワーク上のノード番号x.y.z」を示します。 [RFC0792](19ページ)にあります。この0.x.y.zの使用法は、[RFC1122](セクション3.2.2.7)で後に廃止されました。ネットワークプレフィックスを学習するための元のICMPベースのメカニズムは、イーサネット(24「ノード番号」ビットに収まらないような、より長いアドレスを持つ)などの多くのネットワークでは機能しなかったためです。最近のネットワークでは、完全な32ビットアドレスとCIDRネットマスク(およびデフォルトゲートウェイなどの他のパラメータ)を見つけるために、リバースARP [RFC0903]またはBOOTP([RFC0951])/DHCP([RFC2131])を使用しています。この0.x.y.zの使用を排除すると、未使用で将来の使用のために予約されている0.0.0.0/8の16,777,215アドレスが残ります。

プロトコル機能のために最初に予約されていたアドレス空間の他の1/256は、ネットワーク127でした。127.x.y.zという形式の1600万個のアドレスの全セットは[内部ホストのループバックアドレス]のために[RFC1122](セクション3.2.1.3)で予約されました。そして「単一ノード外のネットワークでは、送信元アドレスまたは宛先アドレスとして表示されることはありません」。 1990年代にIPv6が設計されたとき、これは過剰と見られていました。[RFC1884]では単一のIPv6ループバックアドレスが定義されていましたが、IPv4では、この予約は今日まで続いています。

アドレス空間の実験的な部分の残りの16分の1は、1981年以来38年の間予約済みで未使用のままです[RFC1112](セクション4)。この部分は現在CIDR表記で240/4と呼ばれ266,435,455アドレスを含みます。

3.2. サブネットとブロードキャストの拡張

1984年に、サブネットは[RFC0917]と[RFC0922]によってIPプロトコルの一部になりました。

当初、サブネットは「ローカル」でのみ使用されていました。グローバルインターネットルーティングインフラストラクチャは、クラスA、B、およびCネットワークにルーティングする方法をまだ知っているだけでした。このような各ネットワークのローカル機器は、大学の構内にある複数のイーサネットなど、任意のローカルサブネットにローカルにルーティングできます。

また1984年に、ブロードキャストアドレスは[RFC0919]と[RFC0922]によってIPv4に追加されました。これには、すべてのネットワークまたはサブネット内に1つのIPv4アドレスを予約する必要がありました(そのネットワークまたはサブネットの最終アドレス、「すべて1」のホストアドレス)。アドレス255.255.255.255も、「ローカルハードウェアネットワーク」でブロードキャストするのを容易にするために、それらのネットワークの詳細を知らなくても予約されていました。これは、ブロードキャストをネットワーク上のノード自身のアドレスを発見するための有用なメカニズムにしました。

1984年のブロードキャスト拡張では、各ネットワークまたはサブネットの最初の(ゼロ)アドレスも予約されていました。[RFC0919]では、「このようなアドレスがどこにも現れる理由はおそらくない」と述べています。それはまた、偶然の一致によって、36.0.0.0のようなゼロアドレスを持つ「ネットワーク番号」を指定するという人間の書く規則を文書化しています。この慣習は、その後のプロトコルユーザを、ネットワークまたはサブネットの最初の(ゼロ)アドレスを通常のユニキャストノードアドレスとして使用することはできないと考えることで、混乱させました。

これらの標準が完成する前は、よく使われているIPv4実装の1つである4.2 BSDでは、オール1ノードアドレスではなく、ブロードキャストにゼロノードアドレスを使用していました。これらの不一致の実装がイーサネット上で相互運用しようとしたとき、手動で停止されるまで利用可能なすべてのネットワーク帯域幅を消費する「ブロードキャストストーム」を生成するのは簡単でした。問題を起こしている実装は、標準を満たすために後続の4.3 BSDリリースでアップグレードされました。問題は何十年もの間再発していません。しかし、失態の名残がネットワークまたはサブネットでゼロノードアドレスを使用することに関する[RFC1122](セクション3.2.2.7)の禁止事項に存在します。

3.3. マルチキャスト

後の(1988)デザイナーは[RFC1112]でマルチキャスト使用のために全スペースの1/16(以前に予約されたスペースの半分)を割り当てることを選びました。マルチキャストは、以前の唯一の選択肢(ブロードキャスト)よりもはるかに優れたアイデアでしたが、ローカルエリアネットワーク以外のものでの使用は依然として小さなニッチなままです。振り返ってみると、アドレス空間全体の1/16を指定する価値はありません。このアドレス空間はフィル・カーンのより今風なCIDR [RFC4632]記法では224/4と呼ばれています。

1989年までに、基本的なインターネットプロトコルスイートへの改訂は何十もの文書を読むことを要求しました。インターネットホストとゲートウェイのための基本的な要件はそれから[RFC1022] [RFC1023] [RFC1024]に統合されました。

3.4. CIDRとNAT

1992年までに、オリジナルのネットワークアドレッシングとルーティングアーキテクチャは継ぎ目に負担をかけていました。問題は、「中規模の組織に適したサイズのネットワーククラスの欠如」、利用可能な容量を超えたルーティングテーブルの増加、そして「最終的に32ビットIPアドレス空間の枯渇」でした。[RFC1338]に。 クラスBスペースが1994年半ばまでに使い果たされるであろうという説得力のある推定の後[IETF-13]、ROADワーキンググループが結成されました。

彼らが提案した修正は、サブネット化を複数のクラスCネットワークの「スーパーネット」に拡張し、クラスレスルーティングプロトコルを展開し、そして一般に「ネットワークアドレスクラス」の概念を非推奨にすることを含みました。各ネットワークアドレスは「ペア」、つまりアドレスとマスクで表されます。この提案は特別な規則で「デフォルト経路」としてマスク0.0.0.0を持つアドレス0.0.0.0を予約しました。これは1993年にクラスCのクラスレスドメイン間ルーティング(CIDR)として採用され、クラスAの半分(インターネットアドレス空間全体の4分の1)は[RFC1466]によるより高性能なルーティングプロトコルの展開後の将来のサブネット化のために予約されました。[RFC1518]、[RFC1519]。

1994年には、NAT [RFC1631]も枯渇に対処するための暫定的な解決策として登場しました。

1995年までに、「クラスA」アドレスのサブネット化の実装は十分にバグがあり、IANAは256のサブネット化クラスAアドレスを既存のアドレススペースユーザに割り当て、それらのゲートウェイの正しい動作を検証するためにそれらを使用するよう奨励しました。そして、[RFC1797]で彼らのゲートウェイとホストの正しいオペレーションを確かめるのに使用される事を奨励します。1996年でさえ、[RFC2036]はインターネットの大部分がクラスAアドレスを正しくサブネット化できないと述べていました。

3.5. IPv6アドレス拡張

IPv6は1995年に最初に標準化され[RFC1883]、現在[RFC8200]で頂点に達している多くの連続したRFCによって洗練されました。128ビットのアドレス空間を持っています。

3.6. IPv4アドレス枯渇

2011年には、予想通りIPv4アドレスの枯渇が起こりました。IPv4およびIPv6からIPv4への変換テクノロジの需要は、[RFC1918]を利用して、CGNS([RFC7289])、DS-Lite([RFC6333])、および464XLAT([RFC6877])が広く採用されるようになりました。これらの解決策は、それぞれ独自の方法で、不十分であり、純粋なIPv6は優れていますが、今後20年間はIPv4アドレス空間の必要性は避けられないように見えます。

既存のIPv4割り当ての市場が出現し、少量のアドレス空間がグローバルプールに戻ってきましたが、IPv4アドレス指定の需要は衰えずに続いています。 新しいエッジおよびデータセンターのテクノロジは新たな要求を生み出しており、今後もインターネットアクセス可能なサーバーをデュアルスタックにする必要があります。

2008年に[I-D.fuller-240space]、および2010年に[I-D.wilson-class-e]が最初に240/4アドレス空間が使用可能になることを提案しました。もう1つは、「非公開」のRFC1918のようなアドレスです。どちらのドラフトもインターネット標準にはなりませんでしたが、それでもネットワークコミュニティは一般にそれらを主要なオペレーティングシステムに実装しました。そのようなIPv4アドレスブロックをあなたのネットワークにグローバルに割り当てるための直接的な方法は今もなお存在しない事に気付いている人はほとんどいません。

グローバルに到達可能なユニキャストとして240/4を扱うことは、デファクトスタンダードとなりました。Microsoft Windowsを除くすべての主要なオペレーティングシステムでサポートされています。

このドキュメントで概説された240/4と追加アドレスブロックは実行可能なユニキャストアドレスブロックにすることができます。

このインターネットドラフトは、すべての実装者が、あたかも他のユニキャストアドレスブロック内にあるかのように、これらのブロックにアドレスを含むパケットを受信、送信、および転送するために必要な小さな変更を加えるべきであることを提案します。

これらのブロックの有用性は時間とともに増大することが予想されます。IP実装には更新メカニズムがないため、デバイスによってはそれらを使用できないことがあります。

4. 将来の使用のために以前予約されていたアドレス空間のユニキャストの利用

アドレス空間のブロックの属性は、IANAおよびIETFの出版物では、構造化された箱入りの表によって記述されています。[RFC6890]を参照して下さい。 この文書はこれらのブロックの以前の記述テーブルをこの文書に含まれているもので置き換えることを提案します。

4.1. クラスEアドレス空間のユニキャスト使用

これらの新しいユニキャストアドレス、240.0.0.0から255.255.255.254は、([RFC1112]によって)以前に予約されていたクラスEアドレス空間を置き換えます。このドキュメントは[RFC6890]、表15を更新します。

ブロードキャストアドレス255.255.255.255は、まだ特別に扱う必要があります。送信元IPアドレスとしては無効であり、ネットワークインターフェイスアドレスとしては無効です。ノードから送信されたデータグラムの宛先として使用されると、そのノードに直接アクセス可能なハードウェアネットワークの1つでパケットがブロードキャストされます。この振る舞いは[RFC6890]、表16で以前に指定された振る舞いと変わりません、例えば。

4.2. 0/8のユニキャスト使用

これらの新しいユニキャストアドレス、0.0.0.1から0.255.255.255は、[RFC0791]の廃止された「このホスト上のこのホスト」の概念を置き換え、[RFC6890]の表1を置き換えます。

未知のローカルアドレス0.0.0.0はまだ特別に扱われなければなりません: それは送信元IPアドレスとしてだけ、そしてパケットが現れるネットワーク上でIPv4アドレスを知らないか持っているノードでのみ使用可能です。ネットワークインタフェースアドレスとしては無効です。通常、このようなアドレスは、BOOTPやDHCPなどのUDPベースのプロトコルで、このノードに使用可能なアドレスを提供するように他のノードに依頼するための送信元アドレスとして使用されます。この動作は以前に指定された動作から変更されていません。

(IGMP [RFC4541]は、関係のない機能のために、ペイロードの一部のアドレスフィールドに0.0.0.0も使用します。これらも変わりません。)

5. 以前は他の機能用に予約されていたアドレス空間のユニキャストの使用

5.1. 127/8のユニキャスト使用

これらの新しいユニキャストアドレス127.1.0.0から127.255.255.255までは、以前の予約済みループバックアドレス空間の99%以上を置き換え、[RFC6890]の表4を更新します。

どんな既存のユーザもこの空間のいくつかの小さいサブセットのために特別な用途を持っていた範囲で、それらのサブセットはIANAの管理上の行動によってそれらのユーザに割り当てられるかも知れません。

127.0.0.0から127.0.255.255までの小規模なループバックアドレスも、特別に扱う必要があります。宛先IPアドレスとしてのみ使用できます。 ネットワークインターフェイスアドレスとしては無効です。パケット内の宛先アドレスとして使用される場合、そのパケットは現在のノードによってのみ受信され消費されます。一般的に、このようなアドレスは、この特定のノード上の他のプロセスと通信するときに使用されます。複数のアドレスが提供され、過去の使用パターンに対応するために受信者プロセスによって区別できます。今は、16,777,216のアドレスではなく65,536のアドレスにのみ適用されるようになりました。

5.2. 以前のクラスD(マルチキャスト)アドレス空間のユニキャストの再利用

これらの新しいユニキャストアドレス225.0.0.0から231.255.255.255は、将来のマルチキャスト用に以前予約されていたアドレス空間の40%以上を置き換えます。

224.0.0.0から224.255.255.255までの主要なマルチキャストアドレスは、特別に扱う必要があります。それらは宛先アドレスとしてのみ使用可能です。ネットワークインターフェイスアドレスとしては無効です。また、パケット内の宛先アドレスとして使用された場合、パケットは、ネットワーク上の複数のノードで受信できるようにする低レベルのネットワークマルチキャスト機能を使用して、0個以上の接続ネットワークに送信されます。

複数のアドレスが提供され、過去の使用パターンに対応するために受信者プロセスによって区別できます。268,435,456アドレスではなく150,994,944アドレスにのみ適用されるようになりましたが、この動作は前に指定された動作から変更されていません。

他の複数のマルチキャストアドレス空間は使用されなくなり、それらの再利用の可能性についての議論は別の文書で行われるでしょう。

6. 以前に予約されたネットワーク毎のノードアドレスのユニキャストの使用

すべての既存のサブネットで使用可能なユニキャストアドレスを拡張するために、この文書は各サブネットのゼロ番目のアドレスを再定義し、またブロードキャストをサポートしていないサブネットの最終アドレスを再定義します。 これらの変更により、以前予約されていたアドレスを通常のユニキャストアドレスとして使用できるようにすることで、アドレス空間の無駄が削減されます。

例えば、以前はイーサネット上で6個の固有のインターフェースアドレスを許可していた/29ネットワークでは、7を使用できます。以前は固有のインターフェースアドレスをまったく許可しなかった/31ネットワークを、[RFC3021]に従って、ポイントツーポイントネットワークの2つのインターフェースに使用できます。。

6.1. 各ネットワークまたはサブネットでのゼロノードアドレスのユニキャストの使用

与えられたネットワークの0番目のネットワークアドレスは、そのネットワーク上で完全にアドレス指定可能、グローバルに到達可能、ユニキャストのインタフェースアドレスでなければなりません。

マイナーな例外として、0/8がグローバルユニキャストスペースとして指定されているので、ゼロアドレスが予約アドレス0.0.0.0とオーバーラップするネットワークを定義することが可能です。0.0.0.0は常に予約済みであり、常に予約済みの意味を持つため、このようなネットワークには、完全にアドレス指定可能な、グローバルに到達可能なユニキャストゼロアドレスはありえません。例えば、前述の段落にも関わらず、ネットワーク0.0.0.0/24には、0.0.0.1から始まり0.0.0.255で終わる254個の使用可能なアドレスしか含まれていません。

ネットワーク上のインターフェースのIPv4アドレスを構成または記述する時には、従来はCIDRネットワークマスクとともに完全な32ビットインターフェースアドレスが使用されていました。 例えば、24ビットのプレフィックスを持つネットワーク上のインターフェイス37は、198.51.100.37/24として設定できます。ゼロ番地がネットワークインターフェースとしてホストで使用されている時、そのインターフェースは同じように設定されるべきです、例えば198.51.100.0/24。この使用法は、アドレスが198.51.100.0から198.51.100.255の範囲にあるネットワーク全体を指すための198.51.100.0/24の普段の使用法と競合しません。

6.2. 各ポイントツーポイントネットワークでのオールワンノードアドレスのユニキャストの使用

ブロードキャストをサポートする任意のネットワークの最終ネットワークアドレスは、そのネットワークのブロードキャストアドレスとして伝統的に使用されてきました。(ネットワークプレフィックスの後のすべてのビットがすべて1ビットであるため、最終アドレスは「すべて1」アドレスとも呼ばれます。) この使用法は変わりません。

この文書は、ブロードキャストをサポートしないネットワークでは、最終的なネットワークアドレスが通常の、完全にアドレス指定可能な、グローバルに到達可能なユニキャストアドレスでなければならないことを明確にします。 特に、ポイントツーポイントプロトコル([RFC1331])を実行しているような、2つのインタフェースだけを含むポイントツーポイントネットワークでは、0番地と最終番地を2つのインタフェースのアドレスとして設定すべきである。従って、/31ネットワークプレフィックスだけが必要です。

マイナーな例外として、255/8がグローバルユニキャストスペースとして指定されているので、最終アドレスが予約アドレス255.255.255.255とオーバーラップするネットワークを定義することが可能です。255.255.255.255は予約されているため、このようなネットワークには最終的なオール1アドレスはありません。従って、例えば、255.255.0.0/16ネットワーク全体へのブロードキャストに対処する方法はありません。また、255.255.255.252/30のポイントツーポイントネットワーク上のオールワンアドレスは、そのネットワーク上のインターフェイスを参照しません。 アドレス255.255.255.255は常に予約されたローカルブロードキャストアドレスとして扱われなければなりません。これはブロードキャストパケットをローカルノード上の任意のインタフェース上に送信させる可能性があります(必ずしもアドレス255.255.255.254を含むネットワーク上ではありません)。

7. 課題

この資料は現在これらの再配置のすべての可能性のある問題に入るわけではありません。他の仕様変更と同様に、元の仕様に従うノードと変更された仕様に従うノードとの間には相互運用性の問題があります。

7.1. ロング・デプロイメント・テール

十分な推力があれば、[RFC1925]、ブタだって空は飛ぶことができます。

7.2. 未拡張ノードとの相互運用

この文書は、グローバルインターネット上で使用されていないアドレスから新しいユニキャストアドレスを割り当てるだけで、これらの問題の運用上の影響を最小限に抑えることを目的としています。

ほとんどすべての場合、これらのアドレス空間をサポートしていないノードは、割り当て、転送、または到達に失敗します。

これらの新しいユニキャストアドレスが使用されるときの最も一般的な失敗モードは、元のノードがそのようなアドレスをチェックして許可することを拒否するため、元の仕様に従うノードとの通信の失敗です。これらのノードが使用不能になるか、徐々に交換またはアップグレードされるにつれて、これらのアドレスはますます多くのアプリケーションで使用可能になります。

一方、新しいユニキャストアドレスは、レガシーノードとの相互運用が問題にならない新しいアプリケーションですぐに使用可能になる可能性があります。

未修正のノードはリンクレベルのマルチキャストパケットを使用してそのような宛先アドレスに送信し、拡張ノードはリンクレベルのユニキャストパケットを使用するため、ユニキャストとしての以前のマルチキャストアドレスの再割り当ては固有の問題を引き起こす可能性があります。この問題の完全な影響はまだ調査されていません。

7.3. Martiansのリスト、bogonsとBCP38

[RFC3704]は述べています:

[RFC2827]は、ISPが顧客ネットワークによって合法的に使用されていない送信元アドレスから来るトラフィックを自分のネットワークに入るのを落とすことによって、彼らの顧客のトラフィックを監視することを勧めます。フィルタリングには、送信元アドレスがいわゆる「Martianアドレス」であるトラフィックが含まれますが、これに限定されるものではありません。予約済みのアドレス[3]は、0.0.0.0/8、10.0.0.0/8、127.0.0.0/8、172.16.0.0/12、192.168.0.0/16、224.0.0.0/4、または 240.0.0.0/4です。

発信元アドレスに基づいて顧客のトラフィックをフィルタリングするISPは、アドレス0.0.0.0、255.255.255.255、およびループバックアドレス127.0.0.0/16を除いて、0.0.0.0/8、240.0.0.0/4、127.0.0.0/8、および225.0.0.0/8〜231.0.0.0/8の範囲の発信元アドレスを持つという理由だけでトラフィックを破棄してはなりません。しかしながら、顧客ネットワークにこれらの範囲内の送信元アドレスが割り当てられていない場合は、他のユーザーのネットワークを偽装する試みとして除外できます。

ISPフィルタは、これらの新しく拡張されたユニキャスト範囲内の宛先アドレスに基づいてデータグラムを破棄するべきではありません。

残りの唯一のMartianアドレスは現在含まれています:

  • 0.0.0.0/32
  • 100.64.0.0/10
  • 10.0.0.0/8
  • 127.0.0.0/16
  • 172.16.0.0/12
  • 169.254.0.0/16
  • 192.0.0.0/24
  • 192.0.2.0/24
  • 192.168.0.0/16
  • 198.18.0.0/15
  • 198.51.100.0/24
  • 203.0.113.0/24
  • 224.0.0.0/8
  • 232.0.0.0/5
  • 255.255.255.255/32

ファイアウォール[CBR03]、パケットフィルタ、および侵入検知システムは、新しく拡張されたユニキャストアドレスを監視および管理できなければなりません。

ルーティングプロトコルは、新しく拡張されたユニキャストアドレスを、ユニキャストのグローバルに到達可能なアドレスとして扱わなければなりません。

8. 実装状況

8.1. アドレス範囲: 0/8

0/8のユニキャスト使用を許可する実装は現在知られていません。しかし、小さなLinuxとFreeBSDのカーネルパッチがこの機能を提供します。

8.2. アドレス範囲: 127/8

すべての実装は現在ローカルトラフィックのための127/8の使用を許可します、しかし、それらはグローバルにルーティング可能なユニキャストトラフィックのための使用を許可しません。 既存の仕様の「ローカル」要件を127.0/16に制限し、残りの127/8ではグローバルにルーティング可能なユニキャストトラフィックを許可するための予備のLinuxおよびFreeBSDカーネルパッチがあります。NTPはクロックインターフェイスに127.127を使用し、127の範囲のアドレスを使用するいくつかのシャーシ制御システムが見つかっています。

さらに、内部の「ループバックインタフェース」を設定するシステム設定スクリプトはおそらく修正が必要です。

8.3. アドレス範囲: 225/8 〜 231/8

225/8 〜 231/8のユニキャスト使用を許可する実装は現在知られていません。一部のブリッジ(通常はwifi)は、あらゆる範囲のマルチキャストをユニキャストに変換することが知られています。これまで、これらの空間をユニキャストに変換しても問題ないことが確認されています。

小さなLinuxとFreeBSDのカーネルパッチがこの拡張を提供します。

8.4. アドレス範囲: 240/4

Solaris、Linux、Android、Apple OSX、Apple IOS、およびFreeBSDのオペレーティングシステムは、ユニキャストのグローバルに到達可能なアドレス空間としての240.0.0.0/4の使用をサポートしています。このサポートは2008年頃から存在していました。クラスEアドレスを「無効」として扱うBSDネットワークスタックの一部にはいくつかの問題があります。チェックでクラスEアドレスが拒否され、小さな修正が必要な変換(NAT64)の場合もあります。どちらの場合も、FreeBSD用のパッチを検討中です。上位5つのオープンソースIoTスタックのうち4つはすでに240/4をユニキャストとして扱い、5行目の提出を待つ3行のパッチがあります。

BINDドメインネームシステム実装(例えば、Debian)のいくつかの展開は255.in-addr.arpaのための逆DNSを上書きします。ローカルの空のドメインで、それらのアドレスへのリクエストを転送しないで下さい。これらのパッケージは修正が必要になります。

最近のバージョンのMicrosoft Windowsでは、送信元アドレスまたは宛先アドレスが240/4のパケットは、受け入れも転送もされません。 DHCP経由で提供されている場合は、この範囲のインターフェースアドレスも割り当てられません。どのバージョンのMicrosoft Windowsにも変更を加える計画は発表されていません。 Windows開発者は必要な作業を認識しており、将来のバージョンで検討しています。

Juniperルーターはデフォルトで240/4のトラフィックをブロックしますが、2010年以降そのチェックを無効にする簡単な設定スイッチがあり、その時点でそれらは完全に機能しています。

一部のCiscoルータは240/4を割り当ててルーティングできますが、ほとんどはありません。

8.5. 拡張ユニキャストネットワークへのルーティング

拡張ユニキャストアドレスを含むルーティングアップデートを受信することに対するフリーソフトウェアルーティングアプリケーションの反応は、やや不明です。

拡張ユニキャストアドレスを含むルーティングアップデートを確認することに対するCiscoとJuniperのルータの反応は、まだ決定されていません。

[RFC6126] Babelルーティングプロトコルとその主要な実装は完全にユニキャスト240/4をサポートします。

ユニキャストの240/4経路を許可するためのパッチが、BGP/OSPF/ISIS対応ルーティングデーモンプロジェクト、「Bird」、および「FRR」に送信されました。ただし、変更されていないデーモンとの相互運用性の問題があるかも知れません。

我々が観察したのは、まだパッチが当てられていないルーティングデーモンのためのログファイルメッセージの増加、セッションのドロップ、クラッシュのないことだけです。

8.6. サブネット内のゼロ番目と最終アドレス

遠いサブネットの特定の設定は一般的にそのサブネットのアドレスにトラフィックを送信しているノードに知られていません。送信者は宛先サブネットのネットワークマスクを知らないため、そのサブネット内の0番目または最後のアドレスへのパケット送信を禁止することはできません。従って、主な問題は、問題なく動作するはずのこれらのアドレスと通信する遠隔ノードではなく、サブネットアドレスマスクを知っているローカルエリアネットワーク機器とのことです。

非公式には、ほとんどのオペレーティングシステムとネットワーキング機器はすでにユニキャストアドレスとしてゼロ番地の使用をサポートしています。

非公式には、ほとんどのオペレーティングシステムとネットワーキング機器はすでに、ポイントツーポイントネットワークの最終アドレスをユニキャストアドレスとして使用することをサポートしています。

9. 関連する仕事

ユニキャストIPv4アドレス空間をさらに増やす前回の試みは、2008/2010年に行われ、240/4を純粋なパブリックルーティング可能ユニキャスト[I-D.fuller-240space]、またはルーティング可能だがプライベートなRFC1918スタイルのユニキャストアドレス空間にする提案がありました。[I-D.wilson-class-e] どちらの提案もIETFで大まかなコンセンサスを得ていません。 しかし、240/4を実際に動作させる「実行コード」は、この分野ではほぼ普遍的に採用されています。

240/4、0/8、127/8のネットワーク上でローカルまたはグローバルに組織を使用しているのか、またはマルチキャストの予約済み部分をユニキャストに再割り当てしているのかは、現在のところ不明です。既存のトラフィックのネットワークテレスコープ研究が計画されています。

10. IANAの考慮事項

この文書は他のユニキャストアドレスと同じようにこれらのアドレスを扱うために実装を必要としますが、それはこれらのアドレスがインターネットユーザーに管理上割り当てられる方法を決定しません。

240.0.0.0/4と0.0.0.0/8は「特別な目的の」レジストリから移動します(https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml) 通常のipv4-address-spaceレジストリに追加されます(https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml)

特殊目的のレジストリに0.0.0.0/32と127.0.0.0/16を追加する必要があります。

ipv4-address-spaceレジストリでは、240/4を将来の使用から未割り当てに移動し、225/8 〜 231/8をマルチキャストから未割り当てに移動する必要があります。127.1.0.0/16以降を追加する必要があります。

IANAはin-addr.arpaでリバースDNS空間として利用できるようにこれらのアドレス空間を準備することも要求されます。

11. セキュリティの考慮事項

現在240/4および0/8ブロックへのアクセスは、ネットワークの境界に沿ったどこかで管理されているとほとんど想定されており、より広い利用可能性は単に共通bogonリストおよびハードコーディングされたmartianファイルからこの空間を削除することを必要とします。他の多くの場合ではそれは「ただ機能する」でしょうが、既存の防火壁ネットワークへのどんな追加のセキュリティ露出にも与えられる必要があります。

ローカルネットおよびマルチキャストブロック内のアドレス空間も、ネットワーク内の他の場所で管理されると主に想定されており、同じbogonフィルタおよびmartianリスト修正の対象となります。

全てのがん患者は10億人に1人

WSJより。がんは一人一人違うので、人にあった治療がある。

この病気の無限の多様性は、トルストイの不幸な家族についての見解を彷彿とさせます。

By Robert Nagourney

1世紀以上もの間、がんの専門医は多ければ多いほど良いという単純な言葉に従っています - より多くの手術、より多くの放射線、より多くの化学療法、そして最近ではより多くの免疫療法です。しかし、どのくらいで十分なのですか? 骨髄移植に従事している人は定期的に移植を行うことを余儀なくされているので、私たちは服用量を致死のポイントにまで高めますか? すべての患者さんのがんを撲滅するためのこの闘争は達成可能なのか、それとも保証さえされているのでしょうか?

すべての腫瘍専門医には、単純に自分のがんと共に「生きる」患者がいます。進行性肺がんの患者さんに、従来の治療法では反応しそうにないと話した後、彼女は治療介入を拒否し、数年までに「治療された」すべての治療を受けた場合より長生きしました。私は医学生に彼女を「私が治療しなかったことが私の最高の対応」と表現しています。

私たちは現在、がんは、過度の増殖ではなく、細胞の生存率が変化する疾患であることを知っています。つまり、がんはそれほど増殖しません、死が少な過ぎるのです。細胞動態を適用して、私たちは新たに診断された結腸がんをその最初の細胞まで遡ることができます。これは、診断される時までに肝臓に拡がったがんは、約30年前にその起源を持っているかも知れません、しかし、現在の診断技術では20年以上に渡っては検出できないことを明らかにしています。膵臓、肺および他の腫瘍にも同じことが当てはまります。多くの患者が診断されるまでに、彼らは知らないうちにがんが無い生活より、がんと共に多くの生活を送ってきました。

がん細胞は、剥奪の条件下で成功するために生理学的ストレス反応をゆがめる正常細胞です。突然変異または正常の遺伝的要素を利用して、それらは新しい生態、がん表現型を構成します。約1,000のがん関連遺伝子があり、各がんは成功するために最大3つの異なる遺伝子改変を必要とするので、全てのがん患者は文字通り10億人に1人なのです。それはトルストイの言葉を思い出させます:「幸せな家族はどれもみな同じように見えるが、不幸な家族にはそれぞれに不幸の形がある」。

がん生物学は明らかに複雑であるにも関わらず、現代の腫瘍専門医は、治療選択肢をますます減らすガイドラインに基づく治療法に減らすように保険会社、病院システムおよび規制当局から求められています。個体数統計を個々の患者に適用することを試みるこの万能型アプローチは、急速に、ほぼすべてで万能ではないことが証明されています。

医師の役割は、各患者を独自にするものを見分けることですが、見つけるのに時間が掛かる人はほとんどいません。遺伝子プロファイリングは希望を提供しますが、がんはその遺伝子の合計よりはるかに複雑であることが証明されています。組織レベルでのヒト腫瘍の研究は、トップダウンのゲノム解析からボトムアップの細胞研究へと移行することによってプロセスをリバースエンジニアリングすることが可能であり得ることを示唆しています。Physical Sciences Oncology Networkは、ヒトの腫瘍のダイナミクスを3次元で探索するために、がん医学に物理的原理を適用しています。1つの概念は、選択された患者では間欠的投与を用いて反応が延長される可能性があるため、より少なくてもよいということです。

がん細胞の防御は、ヒトの腫瘍の生物学を探るために、薬物、遺伝子標的化剤および細胞代謝の阻害剤を使用することによって、実験室で調べることができます。私たちは尋ねることができます: あなたのがんはどんな細胞生存プロセスを使っていますか? もっと重要: それは治療的に標的にされることができますか? 答えがイエスであり、そして薬物または組み合わせが確認されれば、患者はおそらく好意的に、実際には2倍の確率で反応するでしょう。しかし、答えが「いいえ」であれば、治療は利益なしに苦しみを引き起こす可能性が高いでしょう。

メカニズムに関係なく、損傷に対するがん細胞の反応を測定することによる実験室プロセスは、最も複雑な問題に対して簡単な答えを提供することができます。これは、薬剤耐性患者が実験的治療を前もって調査する機会を提供する一方で、薬剤感受性患者は手近なところから解決策を模索することができます。

肺がんと脳への転移があると新たに診断された患者が、私のオフィスに到着し、彼女の最初の腫瘍医はとても悲観的だったので、彼女は私に問題を解決するよう言いました。彼女の診察は、現在10年以上続いた回復を提供する単純な二剤併用を明らかにしました。私たちが彼女の診断の直後に推奨される治療法について話し合うために会った際、彼女は「あなたは、私が死ぬことはないと言うのですか?」と叫びました。

「はい」私は言いました、「あなたは病気ではありません。がんに罹っているだけです。」

Nagourney博士は、カリフォルニア大学アーバイン医学部の腫瘍専門医および准臨床教授です。彼は「Outliving Cancer」の著者です。

Hacker News

7/25/2019

ウィリアム・バー司法長官の暗号政策

シュナイアーのブログより

昨日、ウィリアム・バー司法長官は暗号政策についての主要な演説を行いました - それは一般に「ゴーイング・ダーク(going dark)」として知られています。ニューヨークのフォーダム大学で話したところ、彼はバックドアを追加するとセキュリティが低下するが、それだけの価値があると認めました

「ゴーイング・ダーク」とは、電話、インターネットとコミュニケーションの手段が多様化したことで、効果的な監視・盗聴が困難になりつつあること

違法なアクセスに対するセキュリティを弱めることなく合法的なアクセスを提供することは技術的に不可能であると主張する者がいます。しかし、サイバーセキュリティの世界では、絶対的な保証ではなく相対的なリスクを扱っています。すべてのシステムは最適性には及ばず、彼らは法執行機関が自社製品の脆弱性を悪用することでその要件を満たすことができると提案した時、テクノロジーコミュニティが認識しているポイントとして、脆弱性の残存リスクがあります。本当の問題は、合法的なアクセスメカニズムを組み込んだことから生じる脆弱性の残存リスクが、未修正の製品に既に存在するものよりもはるかに大きいかどうかです。当局はこれが証明できるとは思っていません。

さらに、たとえ理論上わずかなリスクの差異があったとしても、その重要性はそれが理論的な最適性に及ばない程度によってのみ判断されるべきではありません。特に消費者に販売されている暗号製品に関して、リスクの重要性は、消費者のサイバーセキュリティに対するその実際的な影響、および製品を提供することが社会にもたらす正味のリスクとの関係に基づいて評価されるべきです。結局のところ、私たちは国家の核の発射コードの保護について話しているのではありません。大企業の業務を保護するために大企業が使用するカスタマイズされた暗号化についても、必ずしも話しているわけではありません。メッセージング、スマートフォン、電子メール、音声およびデータアプリケーションなどの消費者向け製品およびサービスについて話しているのです。例として、すでに有効なセキュリティレベルにある場合、99%の予測される脅威から保護するとすれば、最適性にやや近づき、99.5%の保護レベルを達成するには、さらに多大なコストがかかるのは妥当ですか? 企業はその支出をしないでしょう。社会もそうです。ここでは、せいぜいわずかなセキュリティの向上を達成するためには、安全性の低下という形で社会に多大なコストをかける価値があると主張する人もいます。これは擁護できません。消費者に対するサイバー脅威に対して、 選択が99%の保証を達成できる世界の間にあるなら、それでも、それが求めるかもしれないアクセスの80パーセントを法執行機関に提供しています、一方で、サイバーセキュリティを99.5%に引き上げても、法執行機関へのアクセスを0%に抑えるというコストが掛かり、社会の選択は明らかです。

これは政府の立場の大きな変化だと思います。以前、FBI、司法省などは、セキュリティを損なうことなく、法執行機関のためのバックドアを追加できると主張していました。彼らは、技術者は単に次のように考える必要があると主張しました。それは、私たちがあざけるように「nerd harder」と名付けたアプローチです。

この変更により、私たちはついに賢明な政策対話が可能になります。はい、バックドアを追加すると、法執行機関が悪意のある人々を傍受することが可能になるため、セキュリティが強化されます。しかし、このバックドアを追加すると、悪意のある人々が誰にでも盗聴される可能性があるため、集合的なセキュリティも低下します。これはまさしく私たちがセキュリティと監視の両方を持つことができるかどうかについてのごまかしではない筈であるという政策論争です。

バーは、これは「消費者向けサイバーセキュリティ」であり、「核の発射コード」ではないと指摘しています。これは事実ですが、これら二極の間の大量の国家安全保障関連の通信は無視されます。私たちの議員、最高経営責任者、立法者、法執行官、原子力発電所の運営者、選挙当局などが、同じコンシューマ通信およびコンピューティングデバイスを使用しています。消費者技術と政府技術の違いはもうありません - それはすべて同じ技術です。

バーはまたこう言います:

さらに、その負担は、一部の人が負担するほどには面倒ではありません。私は何年もの間、大規模な電気通信に関する懸念の顧問を務めていました。私の在職期間中、私たちはこれらの問題に対処し、CALEAの「法執行のためのコミュニケーション支援法」の通過と実施を通して生きました。CALEAは、電気通信事業者に対して、施設を通じた通信への合法的なアクセスを提供する機能を維持するための法定義務を課しています。企業はコンプライアンスのコストを負担しますが、それを達成する方法にはある程度の柔軟性があり、システムは概して正常に機能しています。従って、私は合法的なアクセスのためのメカニズムを維持することがハイテク企業、特に大企業に不当な負担を強いると主張する人々のために大量の懐疑論を留保します。物理的な電気通信施設がコンテンツを取得する目的で法執行機関にアクセス可能であることを義務付けることによって合法的なアクセスを保護する一方で、技術プロバイダーがそのコンテンツの取得を法執行機関によって阻止することはできません。

その電気通信会社は、VerizonになったGTEでした。バーは、CALEA対応の電話交換機が2003年にギリシャの政府職員(NSAの操作であると思われる)、および2006年にイタリアの様々な人々スパイするために使用されていたことを都合よく無視しています。国防総省に販売された有効化されたスイッチにはセキュリティ上の脆弱性がありました。(私は2013年にこれ以上のことについて書きました。)

私がスピーチについて最後に気付いたのは、それがiPhoneや装置内のデータについてではないということです。それは通信についてのものです: 転送中のデータです。「ゴーイングダーク」という議論は、この2つの側面の間で何十年にもわたって行き来しています。また跳ね返っているようです。

バーの最新のスピーチが、フェイクセキュリティ対プライバシーの議論から、そして真のセキュリティ対セキュリティの議論へと、私たちがついに移行できることを示してくれることを願っています。コンピュータが私たちの生活、社会、そして重要なインフラのあらゆる側面に浸透し続けているので、たとえ法執行機関へのアクセスを犠牲にしても、セキュリティを犠牲にしてアクセスを許可するよりも、誰からでも安全であることを確認することの方がはるかに重要です。バーは間違っています、それはこれらのシステムが核の発射コードを保護しているようなものです。

このエッセイはLawfare.comに掲載されました

追記編集: その他のニュース記事

BoingBoingHacker News

ARPANET, Part 3: サブネット

Creatures of Thoughtより

ロバート・タイラーとラリー・ロバーツは、ARPANETを使用して、それぞれが独自のコンピュータをホストしている様々な研究機関を接続することを目的としていました。 しかし、ネットワーク自体のハードウェアとソフトウェアは、特定のサイトに属していない、不明瞭な中間領域にあります。1967年から1968年の間に、ARPAの情報処理技術局(IPTO)のネットワーキングプロジェクトの責任者であるロバーツは、誰がネットワークやホスト機関を構築し運用するべきか、そしてどこに責任の境界を置くべきかを決定しなければなりませんでした。

懐疑論

ネットワークをどのように構築するかという問題は、少なくとも技術的なものと同じくらい政治的なものでした。ARPA研究サイトの主任研究者たちは、組織として、ARPANETの考えを享受していませんでした。ネットワークに参加することに完全に興味を失った人もいました。熱心な人はほとんどいませんでした。他の人がその非常に高価な、非常にまれなコンピュータを共有できるようにするには、各サイトに多大な労力を費やす必要があります。そのような共有は不利な点(貴重な資源の喪失)を明らかにしましたが、その潜在的な利点は不確実で不明瞭なままで、デメリットは明らかでした。

リソース共有についての同じ懐疑論は、数年前にUCLAネットワーキングプロジェクトをぶち壊しました。但し、この場合、ARPAはこれらの貴重なコンピューティングリソースすべてに直接お金を支払っていたため、実質的により多くの影響力を持ち、関連する研究プログラムの財布を保有し続けていました。直接的な脅威は発生していませんでしたが、「さもないとひどいぞ」は出ていませんでしたが、状況は十分明らかでした。何らかの方法でARPAがネットワークを構築し、実際にはまだマシンを接続していました。

1967年の春、ミシガン州アナーバーで行われた主任研究者会議で、論点が上がりました。ロバーツは、各サイトの様々なホストコンピュータを接続するネットワークの計画を立てました。各調査担当者は、電話ネットワークを介して他のホストにダイヤルアップするために使用するカスタムネットワーキングソフトウェアを、それぞれのローカルホストに適合させると言いました(これは、ロバーツがパケット交換について知っていた前です)。反対意見と懸念が結果として起こりました。最も受け入れられないものの中には、すでに大規模なIPTO資金によるプロジェクトを持っている主要なサイトがありました。それらの中にMITのチーフがいました。プロジェクトMACのタイムシェアリングシステムと人工知能研究室のための資金を豊富に持って、MITの研究者達は彼らの苦労して稼いだリソースを西のリンキーなビットプレーヤーと共有することにほとんど利点を見ませんでした。

さらに、水準に関係なく、すべてのサイトに他の特定の予約が共通していました。彼らはそれぞれ独自のハードウェアとソフトウェアを持っていました、そして、彼らがお互いに単純な関係を確立することさえできるかどうかを見ることは困難でした。ローカルマシン用のネットワークソフトウェアを作成して実行するだけでも、かなりの時間とコンピュータの処理能力が浪費されます。

これらの社会的および技術的問題に対して、ロバーツが採用した解決策は、時分割とネットワーキングの両方を嫌悪と見なしたウェズリー・クラークによるものであることは皮肉でありながら驚くほど適切でした。各個人のためのパーソナルコンピュータのチャンピオンであるクラークは、誰ともコンピュータリソースを共有することに興味を持っておらず、今後何年もの間ARPANETから遠く離れた彼自身のキャンパス、セントルイスのワシントン大学を守りました。従って、彼が各サイトのコンピューティングリソースに大きな新たな浪費を追加することも、カスタムソフトウェアに多大な労力を費やすことも必要としないようなネットワーク設計を思い付いたのは、おそらく驚くには当たりません。

クラークは、各サイトに実際のすべてのネットワーク機能を処理するミニコンピュータを設置することを提案しました。各ホストは、ローカルのヘルプメイト(後でInterface Message Processor(IMP)と呼ばれる)に接続する方法のみを理解すればよく、宛先に対応するIMPに到達するようにメッセージ上でルーティングされます。事実上、彼はARPAが各サイトに追加の無料のコンピュータを提供することを提案しました。それはネットワークのリソースコストのほとんどを吸収するでしょう。コンピュータがまだ不足していて非常に貴重だった時期には、この提案は大胆なものでした。それでも、最近のミニコンピュータの登場によって、数百ドルではなく実に数万ドルの費用が掛かったにも関わらず、それは実現可能になりました1

主導的な研究者たちのコンピュータ能力に対するネットワーク税についての懸念のいくつかを軽減する一方で、IMPアプローチはARPAに関する別の政治的問題を解決するためにも起こりました。これまでの他のARPAプロジェクトとは異なり、ネットワークは1人の研究者によって監視される可能性がある1つの研究機関に限定されていませんでした。また、ARPA自体が大規模な技術プロジェクトを直接構築および管理する機能を備えているわけでもありません。仕事をするためにそれは第三者を雇わなければなりません。IMPの存在は、外部ネットワークとローカル管理ホストコンピュータとの間の責任の明確な描写を提供しました。請負業者はIMPとそれらの間のすべてを制御しますが、ホストサイトはそれぞれ自分のコンピュータ上のハードウェアとソフトウェアに対して完全に(そして単独で)責任を持ちます。

IMP

次に、ロバーツはその請負業者を選ばなければなりませんでした。このケースでは、優秀な研究者から直接提案を求めるという昔ながらのリックライダーのアプローチは行いませんでした。このプロジェクトは、他の政府の契約と同じように公の入札に耐えなければなりませんでした。

1968年7月まで、ロバーツが入札の依頼の詳細を最終的に準備するのに掛かりました。ガトリンバーグの会議でパケット交換が明らかになったことで、パズルの最後の主要な技術的部分が登場してから約半年が経過しました。2つの大手コンピュータメーカー、Control Data Corporation(CDC)とInternational Business Machines(IBM)は、IMPとして機能するのに適した低コストのミニコンピュータがなかったため、すぐに辞退しました。

ハネウェルDDP-516

主要な残りの候補の中で、大部分はハネウェルの新しいDDP-516コンピュータを選びました。しかし、一部は代わりにデジタルPDP-8のために急落しました。ハネウェルは産業用機械の制御のようなアプリケーションのためにリアルタイムシステムと相互作用するように明示的に設計された入出力インターフェースを特徴としていたので特に魅力的でした。もちろん、通信も同様のリアルタイム精度を必要としました - コンピュータが他の仕事をしているために入ってきたメッセージが見逃された場合、それを捉えるチャンスは二度とありませんでした。

年の終わりまでに、レイセオン・カンパニーを強く検討した後、ロバーツはケンブリッジの成長著しいボルト・ベラネク・アンド・ニューマンという会社に仕事を申し出ました。インタラクティブコンピューティングの家系は、現時点ではまだ非常に内向きの成長でした、そしてBBNを選択することにおいてロバーツは合理的に一種の身内びいき(nepotism)を非難されたかもしれません。J・C・R・リックライダーは、IPTOの最初のディレクターを務め、銀河系間ネットワークを築き、ロバーツのような男を指導する前に、インタラクティブコンピューティングをBBNにもたらしました。リックライダーの影響がなければ、ARPAとBBNはARPANETプロジェクトに関心も能力もなかったでしょう。さらに、IMPを構築するためにBBNによって組み立てられたチームのコアは、直接的または間接的にリンカーンラボら来ました: フランク・ハート(チームのリーダー)、Dave Walden、ウィル・クラウザー、およびセヴェロ・オーンステインです。リンカーンは、もちろん、ロバーツ自身が彼の大学院の仕事をしたところであり、そしてウェス・クラークとの偶然の衝突が最初にインタラクティブコンピューティングについてのリックの興奮を引き起こしたところです。

しかし、癒着に思われたかも知れません、実のところBBNチームはハネウェル516と同程度にリアルタイムパフォーマンスに細心の注意を払っていました。リンカーンで、彼らはレーダーシステムとインタフェースをとるコンピュータ、データがコンピュータの準備ができるのを待つ必要の無い別のアプリケーションに取り組みました。例えば、Heartは、1950年までWhirlwind(ホワールウィンド)コンピュータで学生として働いていたSAGEプロジェクトに参加し、リンカーンラボで合計15年間過ごしました。オーンステインは、あるコンピュータから別のコンピュータにレーダーの追跡記録を引き渡すためのSAGEクロステリングプロトコルを、その後、ライブデータと一緒に、実験室で直接科学者をサポートするように設計されたコンピュータ、ウェス・クラークのLINCに取り組みました。現在は、コロッサル・ケーブ・アドベンチャーの作者として最もよく知られているクラウザーは、リンカーンの実験端末、アンテナを指向し、入ってくる信号を処理するための小型コンピュータを備えた移動衛星通信局を含み、リアルタイムシステムの構築に10年費やしました2

BBNのIMPチーム、フランク・ハートは中心の年上の男性です。オーンステインは、一番右のクラウザーの隣にいます。

IMPはホストからホストへのメッセージのルーティングと配信を理解して管理する責任がありました。ホストは、宛先アドレスとともに、一度に最大8000バイトをローカルIMPに配信できます。次に、IMPはこれをより小さなパケットにスライスし、それらはAT&Tからリースされている1秒あたり50キロビットの回線で、宛先IMPに個別にルーティングされました。受信側IMPはピースを再構成し、完全なメッセージをそのホストに配信しました。各IMPは、それぞれの可能な目的地に到達するために、どの近隣者が最速経路を提供したかを追跡するテーブルを保持していました。これはそれらが利用不可能であるように見えたかどうかを含むそれらの隣人から受け取った情報に基づいて動的に更新されました(その場合その方向の遅れは事実上無限でした)。このすべての処理についてロバーツが指定した速度とスループットの要件を満たすために、ハートのチームはコードに少しの詩的作品を作成しました。IMPのための全体のオペレーティングプログラムはたった約12,000バイトを必要としました。ルーティングテーブルを維持した部分は300バイトです3

チームは、すべてのIMPと一緒に保守スタッフを現場に配置するのは不可能であるという事実に対処するために、いくつかの予防策を講じました。

第一に、彼らは各コンピュータに遠隔監視および制御設備を装備しました。停電後に起動する自動再起動機能に加えて、IMPは、動作中のソフトウェアの新しいインスタンスをそれらに送信することによって、隣の装置を再起動できるようにプログラムされていました。デバッグと分析を助けるために、IMPは定期的にその状態のスナップショットを取り始めるように指示されました。IMPはまた各パケットの特別な「トレース」ビットを遵守します、それは追加の、より詳細なログを取るトリガーとなりました。これらの機能で、ネットワーク全体の状態を監視することができる中央のコマンドセンターとして機能したBBNオフィスから、様々な種類の問題に対処できます。

第二に、彼らはハネウェルに、振動やその他の環境危険から保護するために厚い外枠を装備した516コンピュータの軍用バージョンを要求しました。BBNはこれをおもに好奇心旺盛な大学院生に向け、「立ち入り禁止」の標識として意図していましたが、ホストとBBNが運営するサブネットの境界をこの装甲シェルのように目に見える形で描くものは何もありませんでした。

冷蔵庫の大きさを持ったこれらの堅牢なキャビネットの最初のものは、BBNが契約を受けたちょうど8ヵ月後、1969年8月30日にカリフォルニア大学ロサンゼルス校(UCLA)に到着しました。

ホスト

ロバーツは、4つのホストでネットワークを開始することにしました - UCLAに加えて、カリフォルニア大学サンタバーバラ校(UCSB)、カリフォルニア州北部のスタンフォード研究所(SRI)にもIMPがあります。ユタ大学で最後に。いずれも学術コンピューティングでの地位を確立しようとしている意欲十分の西海岸の機関でした。2人の主任研究者であるUCLAのレナード・クラインロックとユタ大学のアイバン・サザランドもまたリンカーンラボのロバーツの古いオフィスメイトだったので、密接な家族関係も続きました。

ロバーツはまた、2つのサイトにネットワーク内の特別な機能を割り当てました。SRIのダグラス・エンゲルバートは、1967年の校長会の会議まで遡ってNetwork Information Centerを設立することを志願していました。SRIの洗練されたオンライン情報検索システムを利用して、彼はいわゆるARPANETのために電話帳を編集しました。様々なホストサイトで利用可能なすべてのリソースに関する情報を照合し、それをネットワーク上の全員が利用できるようにしました。一方、クラインロックのネットワークトラフィック分析の専門知識に基づいて、ロバーツはUCLAをNetwork Measurement Center(NMC)に指定しました。クラインロックとUCLAにとって、ARPANETは実用的な道具としてだけでなく、観測実験としても役立つものであり、そこからネットワークとその後継者の設計を改善するために適用できる教訓を学ぶためにデータを抽出し一般化することができました。

しかし、これらの正式な制度的指定のいずれよりもARPANETの開発にとってより重要なのは、Network Working Group(NWG)と呼ばれるより非公式で普及している大学院生のコミュニティです。IMPのサブネットによって、ネットワーク上のどのホストも他のホストに確実にメッセージを配信することができました。ネットワークワーキンググループによってとられた仕事はそれらのホストがコミュニケーションに使用できる共通の言語か言語セットを考案することでした。彼らはこれらを「ホストプロトコル」と呼びました。外交言語から借用したプロトコルという言葉は、1965年にロバーツとTom Marillによって最初にネットワークに適用され、2つのコンピュータがもう一方のコンピュータと通信する方法を決定します。 もう一人。

NWCLは、UCLAのスティーブ・クロッカーのゆるい事実上のリーダーシップの下で、最初のIMPの提供から約6か月前の1969年春に、定期的に会合を開始しました。 Crockerは、ロサンゼルス地域で生まれ育ち、後にNWGのコラボレーションをした2人、ヴィントン・サーフとジョン・ポステルの同世代のバン・ナイズ高校に通っていました4。グループの初期の議論のいくつかの結果を記録するために、クロッカーはARPANET(および将来のインターネット)文化のキーストーンの1つである「Request for comments」(RFC)を発展させました。1969年4月7日に発行され、将来のARPANETサイトに郵便で配布された彼のRFC 1は、ホストプロトコルソフトウェアの設計方法に関するNWGの初期の議論をまとめたものです。RFC 3では、クロッカーは将来のすべてのRFCのための(非常にゆるい)プロセスを定義し続けました:

メモは洗練されたものではなくタイムリーなものにすることを奨励します。例や他の詳細がない哲学的な立場、序論や背景説明がない具体的な提案や実装のテクニック、そして答えられたことがない明確な質問はすべて受け入れ可能です。NWGノートの最小長は1文です。...私たちは権威あるアイデアよりもかなり少ない意見の交換と議論を促進することを願っています。

「見積依頼」(RFQ)と同様に、政府契約の入札を要求する標準的な方法であるRFCは回答を求めましたが、RFQとは異なり、RFCも対話を求めました。分散型NWGコミュニティ内では、誰でもRFCを送信でき、その機会を利用して以前のエントリについて詳しく説明したり、質問をしたり、批判したりすることができました。もちろん、他のコミュニティと同じように、いくつかの意見が他の意見よりも重要であり、初期の頃はクロッカーと彼のコアコラボレータグループの意見が非常に重要でした。実際、1971年7月までに、クロッカーはIPCLのプログラムマネージャとしての地位を引き継ぐためにUCLAを卒業しました(まだ大学院生でしたが)。重要なARPA研究助成金を手にして、彼は意図的かどうかに関わらず、疑う余地のない影響を与えました。

ジョン・ポステル、スティーブ・クロッカー、ヴィントン・サーフ - 学友およびNWGの共同制作者 - の数年後。

NWGの最初の計画は2つの議定書を求めました。リモートログイン(またはTelnet)を使用すると、あるコンピュータを別のオペレーティングシステムに接続された端末のように動作させることができ、ARPANETタイムシェアリングシステムの対話的な到達範囲を数千マイルに渡ってネットワーク上の任意のユーザーに拡張できます。ファイル転送プロトコル(FTP)は、あるコンピュータが有用なプログラムまたはデータセットなどのファイルを別のストレージシステムとの間で転送することを可能にします。しかし、ロバーツの主張によれば、NWGは、2つのホスト間に基本的なリンクを確立するために、これら2つの下に3つ目の基本プロトコルを追加しました。この共通部分はネットワーク制御プログラム(NCP)として知られていました。ネットワークは現在、3つの概念的な抽象化層を持っています - 一番下のIMPによって制御されるパケットサブネット、真ん中のNCPによって提供されるホスト間接続、そして一番上のアプリケーションプロトコル(FTPとTelnet)です。

失敗?

NCPが完全に定義され、ネットワーク全体で実装されるまでには1971年8月まで掛かりました。1972年の夏に、FTPの最初の安定した定義が1年遅れで到着し、その後すぐにTelnetの実装が続きました。この期間のARPANETの状態を考えると、最初にオンラインになってから約3年後に、 リックライダーによって構想されたリソース共有の夢に対して評価され、彼の後継者であるロバート・テイラーによって実際的な行動に移されたとき、それは失敗と見なされるべきです。

そもそも、ネットワーク上にどのリソースがどのリソースを借りることができるのかを知ることさえ困難でした。ネットワーク情報センターは任意の貢献のモデルを使用しました - 各サイトはそれ自身のデータとプログラムについての最新の情報を提供することが期待されていました。全員がコミュニティに利益をもたらすことは集団的に利益をもたらすはずでしたが、各サイトはそのリソースを宣伝してそれらにアクセスできるようにする動機がほとんどなく、最新の資料や相談を提供することははるかに少なくなりました。そのため、NICは主に効果的なネットワークディレクトリとして機能しませんでした。おそらく、当時の最も重要な機能は、成長しているRFCの集積に電子ホスティングを提供することでした。

UCLAのAliceがMITの有用なリソースについて知っていたとしても、さらに深刻な障害が介入しました。 TelnetはMITのAliceにログイン画面を表示させますが、それ以上は行われません。Aliceが実際にMITホスト上の任意のプログラムにアクセスするには、彼女は自分のコンピュータでアカウントを取得するためにMITとオフライン契約を結ぶ必要があります。通常、彼女は両方の機関で事務処理を行い、MITに使用されてるコンピュータリソースの費用を支払うための資金を手配することが必要でした。結局、各サイトのハードウェアとシステムソフトウェアに互換性がないため、自分のコンピュータでリモートサイトからプログラムを実行することはできないため、ファイル転送にはほとんど価値がありません。

皮肉なことに、リソース共有における最も注目すべき初期の成功は、ARPANETがサポートするために構築された対話型タイムシェアリングの分野ではなく、大規模な、昔ながらの非対話型データ処理においてでした。UCLAは彼らの十分に活用されていないIBM 360/91バッチ処理マシンをネットワークに追加し、遠隔ユーザーをサポートするために電話による相談を提供し、それによってコンピューターセンターの収入を大幅に補うことができました。ARPAが資金提供しているイリノイ大学のILLIAC IVスーパーコンピュータとケンブリッジのComputer Corporation of AmericaのDatacomputerも、ARPANET上にリモートクライアントをいくつか見つけました5

しかし、これらのアプリケーションはどれも、ネットワークを完全に活用することには至っていません。1971年の秋、15台のホストコンピュータがオンラインになり、ネットワークは1日当たり1サイトあたり約4,500万ビットのトラフィックを伝送しました。これは、毎秒50,000ビットの容量を持つAT&T専用回線のネットワークで平均毎秒520ビットでした6。さらに、これの多くはUCLAのNetwork Measurement Centerによって生成されたテストトラフィックでした。何人かの初期の採用者(パロアルトのユタ大学で毎日PDP-10を使用したSteve Carrのような7)のほかに、ARPANETにはあまり起こりまさんでした8

しかし、ARPANETは間もなく、まだ第3のアプリケーションプロトコル(電子メールと呼ばれるもの)によって停滞の可能性のあるどんな非難からも救われます。

参考文献

ジャネット・アバテ: インターネットをつくる(1999)

ケイティ・ハフナーとマシュー・ライアン: インターネットの起源(1996)


  1. 各IMPは結局ARPA 45,000ドル、2019年のドルに換算すると、およそ314,000ドルの費用が掛かりました。
  2. Severo Ornstein, Computing in the Middle Ages (2002); Judy O’Neill, "An Interview with William Crowther," March 12, 1990; J.W. Craig, et. al., "The Lincoln Experimental Terminal", Lincoln Laboratory, March 21, 1967.
  3. F.E. Heart, et. al., "The Interface Message Processor for the ARPA Computer Network", Spring Joint Computer Conference, 1970.
  4. クロッカーとサーフは実は親友でした。
  5. Abbate, Inventing the Internet, 97-98.
  6. Hafner and Lyon, Where Wizards Stay Up Late, 175.
  7. S. Crocker, S. Carr, and V. Cerf, RFC 33, "New HOST-HOST Protocol."
  8. 今日の観点から、おそらく最も興味深い出来事は、1971年12月にイリノイ大学の学生Michael S. Hartによるデジタル図書館Project Gutenbergの立ち上げでした。

Hacker News

7/24/2019

スイッチ-ルーター戦争は終わり、ハイパースケーラが成功する

The Next Platformより。Arrcusの日本法人の方が、JANOGでプレゼンをするようだ。

Timothy Prickett Morgan

最初に起きることを言うのは難しいです: スイッチングとルーティングは融合するでしょう、または両方を行うことができる独立したネットワークオペレーティングシステムが出現するでしょう。昨年7月にステルスモードから抜け出し、マーチャントシリコンにスイッチング機能とルーティング機能の両方を提供できる光沢のある新しいネットワークオペレーティングシステムが登場したとしたら、両方が同時に起こるでしょう。そして、どちらが主な原因であるかは関係ありません。

スイッチングは1920年代に電話網のために最初に発明されました。しかし、私たちが今日知っているようにデータセンタースイッチングは1969年にARPANETから始まり、データを共有できるように複数のコンピュータをリンクするために使われました。1981年にスタンフォード大学とMITで独自に作成されたルーターは、複数のネットワークをリンクするために使用されます。これは、数あるスイッチの一種のスイッチですが、ネットワークプロトコルスタックで言う所の、スイッチングが行われるレイヤ2ではなく、レイヤ3で動作します。

それ以来、スイッチングとルーティングは互いに争い、近年ではルータの機能がスイッチASICやそのオペレーティングシステムに取り入れられています。これは、ハイパースケーラやクラウドビルダが一般的な企業よりもはるかに複雑なデータフローを持つためです。また、レイヤ3ルーティング機能を備えたレイヤ2機能を持つスイッチがはるかに安価で仕事を行える場合、ルータのバックボーンに多額のお金を払うのにうんざりします。

本質的には、データセンターは接続性に関しては私たちの家のように見え始めています。インターネットにつながる大きなパイプが1つあり、デバイスをインターネットに直接接続するために有線および無線ルーターを使用しています。可能なときに切り替え、必要なときにルーティングするという古い格言は、可能なときにはルーティングし、必要なときには切り替えるような、新しいネットワークアーキテクチャで頭角を現す可能性があります。あるいは、より正確には、可能であれば浅いASICバッファを使用し、必要な場合にはディープバッファを使用します。これは、アプリケーションのレイテンシ要件がエッジでもデータセンターでも、アーキテクチャの決定とASICの選択を左右するためです。スイッチとルーターのベンダの選択は3番目になります。

ネットワークアーキテクチャーのこの劇的な変化は、ルータに何十万ドルも費やすことを予定していなかったハイパースケーラやクラウドビルダーから絶対的に命令された、マーチャントスイッチングシリコンのルーティング機能の進化を通じて可能になりました。それは、彼らの広大なコンピューティングとストレージファームを相互にリンクさせることです。彼らは、レイヤ2スイッチングとレイヤ3ルーティングをより動的な方法で、必要に応じて複数のASICにまたがって混在させる、より広く、よりフラットなClosネットワークを求めています。

そして、もし彼らが選択すれば、複数のOEMやODMのハードウェアで動作する単一のスイッチングおよびルーティングソフトウェアのスタックを持つことになります。これがArrcusの創設理念であり、ArcOSネットワークオペレーティングシステムの設計目標であり、Broadcomから「Tomahawk 3」イーサネットスイッチASICに移植された際の今年初めに詳述しました。ハイパースケーラとクラウドビルダーのために設計されました。多くの場合25 Gb/sまで刻み込まれた安価な100 Gb/sのポートをサーバーに提供します。ArcOSはBroadcomのエンタープライズクラスの「Trident 3」チップをサポートしていました。これはより深いプロトコルセットと低い待ち時間を持ち、昨年10月にBroadcomの「Jericho+」ディープバッファASICのサポートを追加しました。そして今週、ArcOSが「Jericho 2」ディープバッファスイッチに追加しました。これは非常に深いバッファ用にHBMメモリの塊を接続することができ、100 Gb/sと400 Gb/sのポートをサポートします。6月に発表された近々登場する「Trident 4」ASICが、Arrcusがそれらをサポートする製品を出荷してから、それほど長い時間はかからないと思います。

「初めて、企業とサービスプロバイダーの両方が、対処しようとしている特定のユースケースに適した組み合わせを選択して選択するための完全なツールキットを入手できます。」とArrcusの製品管理担当副社長、Murali Gandluruは言います。次のプラットフォーム「忠実度の高いストレージが求められる場合 - 従来のデータセンターやユーザーに近いところでは、問題ありません - Jerichoベースのプラットフォームが必要になります。顧客が実際に行っているように、高密度スイッチングASICを使用してそれらを相互接続するスパインを構築したり、ピアリング機能をそのスパインに結合しているために深いバッファを必要とする場合があります。非常に多くの興味深いことが起こりそうです、そしてマーチャントシリコンツールキットで初めてあなたは実際に可能性と柔軟性のフルレンジを持っています。そしてArcOSはそれがすべてに及ぶという点でユニークです。例えば、複数のオペレーティングシステムを経由する必要なしに、スーパースパインからスパイン、リーフに至るまで、ArcOSを使用して完全でエンドツーエンドの型にはまったエッジサイトを実際に構築できます。」

前に指摘したように、データセンターネットワーキングにもたらされる変更は、ネットワークオペレーティングシステムを基盤となるハードウェアから分離し、そのオペレーティングシステムのAPIを外部に公開することだけではありません。これはその大部分であり、データセンターの将来のネットワークオペレーティングシステムはオープンソースであるべきだと考える人もいます。これはコモディティハードウェアの基盤を作り、おそらくそのオープンソースネットワークソフトウェアスタックをサポートする主要なベンダーです。Arrcusは、すべての重要なハードウェアにまたがることができるNOSが1つあるべきであることに確かに同意します。つまり、最終的には、スイッチングとルーティングの違いではなく、シリコンの機能とそれを活用するソフトウェアの機能の観点から、適切なルーティングのサポートをスイッチASICに組み込むことです。

それでは、ここまでたどり着くのに何が時間がかかりましたか。また、Cisco SystemsとJuniper Networksが長い間ルーティングを支配したのはなぜですか?

「これまで起きなかったのは、代替手段がなかったからです。」Gandluruは説明します。「私たちは、スパインとリーフを使ったClosアーキテクチャーがスイッチングとルーティングの両方で今まさに真似されている変曲点にあります。だから今私たちは攻撃を続けることができ、おそらくCiscoまたはJuniperが請求するものの10分の1のコストであるルーティングプラットフォームを顧客に提供することができます。あなたは前にそれをすることができませんでした。ルーティングシリコンの前世代は、インターネットやバックボーンで絶対に必要とされるラインレートフローモデリングのような多くのルーティング機能を持っていませんでした。今、あなたはそれらを持っています。これは他のイベントと並行して起こります。まず、ルーティングのコントロールプレーンはバックボーンまたはエッジからデータセンターに入ってきて、アプリケーションとのやり取りが容易になりました。その後、マーチャントシリコン側のチップセットが追いつき、カスタムシリコンを超えました。これで、コントロールプレーンと、これらすべてのエッジ環境に対応するより優れたASICの組み合わせが得られました。それがネットワークの所有コストを下げる大きなことです。」

ODMはこの波に早く追いついており、ArrcusがサポートするBroadcomチップをベースにしたスイッチ(およびスイッチ/ルーターハイブリッド)のオプションとしてArcOSを採用しています。Celistica、Edgecore、DeltaはBroadcomチップ上のArcOSをサポートしており、Quanta Computerも追って間もなくTrident 3 ASICを既にサポートしており、他のものも追加したいという事実に基づいて考えています。

Arrcusに資金を提供してきたベンチャーキャピタリストもこのパターンを見ており、シリーズBの資金でさらに3000万ドルを獲得したところです。このラウンドは、昨年のシリーズAラウンドと同様に、Lightspeed Venture Partnersが主導しており、その総額は4900万ドルでした。一般的なCatalystとClearのベンチャー企業もいくらかの資金を得ている。このシリーズBラウンドはオーバーサブスクライブされ、初めてファンドを購入したすべての投資家が再びそうしたかった、これは常に良い兆候です。そのお金は、ArcOSの機能を拡張するためのエンジニアリング、販売、およびマーケティングを構築するため、そしておそらくBroadcom以外のASICで利用できるようにするために使われるでしょう。Barefoot NetworksのTofinoチップセット(もうすぐIntelの一部になる予定)とInnoviumのTeralynxチップセットは明らかな選択だが、他にもあります。

Arrcusの共同創設者兼最高経営責任者であるDevesh Gargによれば、同社の従業員数は現在約50人で、現在から年末までに倍増するとのことです。重要な新入社員はArthi Ayyangarです。彼はJuniperに勤務し、最近ではArista NetworksのスイッチのExtensible Operating System(EOS)を変更してエンジニアリング担当副社長を務めました。

ArcOSは一握りのサービスプロバイダで量産されており、現在は「2桁」の顧客数を誇り、「4〜5握り」の概念実証が行われており、さらに幅広いパイプラインがあります。 これは、ホッケースティックを買収や新規株式公開に振り向ける初期の段階で、選択した数のハードウェアでシステムソフトウェアを販売している会社の成長に期待することです。

今週、Arrcusのスイッチングおよびルーティングソフトウェアスタックを完成させた、同社はArcIQと呼ばれる自立型アドオンツールを発表しています。これは、ハイパースケーラ、クラウドビルダー、 そしてサービスプロバイダーは自分自身のためにコード化しました。ArcIQは、エッジ、クラウド、およびデータセンターのネットワークデバイスにわたるネットワークの健全性の監視やこれらの施設の資産の追跡など、あらゆる種類の高度な管理と監視を行います。AIは、テレメトリをネットワークから切断し、トラフィックの変化に応じてトラフィックを形成するためにそれを使用することで機能します。ArcIQは、ハイパースケーラやクラウドビルダーによって広く展開されているBGPプロトコルのFlowSpec機能を使用して、分散サービス拒否攻撃を軽減することもできます。ところで、これを行うにはラインレートフローストリーミングが必要です。これは最新のBroadcom ASICでのみ利用可能になりつつあります。

最新のArcOSは今四半期中に生産が開始される予定で、ArcIQは今四半期中の早期導入者への出荷を開始し、第4四半期中に一般出荷可能になります。

注: 2019年9月24日にカリフォルニア州サンノゼで行われるストレージ/ネットワーキングのこのトピックおよび他のトピックは、「次のI/Oプラットフォーム」の主題になります。技術的な会話主導の日についてもっとよく知る。

「ウエストワールド」シーズン3の予告の分析

Slashfilmより

ウエストワールドは新しいシーズン3の予告編で私たちにまったく新しい世界(または2つ)に紹介する準備ができています。前に公開されたティーザーはほとんど完全にアーロン・ポールの新しいキャラクターに焦点を当てていましたが、この予告は大量のおなじみの顔を思い出させます。しかし、ウエストワールドの伝統とですが、出来事はかなりミステリアスです。下記のウエストワールドシーズン3の予告の分析の中で、新しいシーズンのパズルのいくつかを解決しようとしています。

ウエストワールドシーズン3で実際のウエストワールドにあまりにも多くの時間を費やすことを期待しないで下さい。シーズン2は多かれ少なかれ西部をテーマにしたロボットパークを時代遅れなものにする形で終わり、シーズン3は現実の世界で起こることをほのめかしました。案の定、ウエストワールドのシーズン3の予告編はまさにそのショットで始まります - (未来的な)現実の世界。「私たち全員が果たすべき役割を担っています」とドロレス(エヴァン・レイチェル・ウッド)は言うのが聞こえます。「この世界にはマシンがありますが、...私たちとは違います。」

「あなたと私には母親も父親もいません」とドロレスの声は続きます。彼女は誰と話しているのでしょうか? さて、私たちが最初に見掛けるのは、テッサ・トンプソンのシャーロット・ヘイルで、空飛ぶ自動車で散歩しています。彼女は実ににクールなケープジャケットを着ていて、タバコに火を点けます。もちろん、シャーロット・ヘイルは死んでいるので、これは本物のシャーロット・ヘイルではありません。ドロレスはシーズン2で彼女を殺害した後、彼女をシャーロット・ヘイルのロボット本体の中に入れ、公園外に連れ出しました。それから、さらに混乱させるために、シャーロット-ドロレスはドロレスの古いボディを再構築しました。しかし、彼はシャーロット・ボットをキープしました。それで今、誰がシャーロットの内側にいますか? まだ分かりません。

「私たちは一人です」とドロレスは続けます。ここでは、ドロレスはいくつかの球体(オーブ)を指で触れます。しかし、これらは単なる球体ではありません。ロボブレインです。ドロレスがウエストワールドを脱出した時、彼女はハンドバッグにいくつかのブレインオーブで詰め込みました。しかし、私たちはまだ彼らの身元の多くを知りません。明らかにこれらの1つがシャーロット内部にあります。また、ドロレスがバーナード(ジェフリー・ライト)のブレインオーブを密輸したことも知っています。しかし、私たちは後で彼を取り上げます。

ドロレス:「私たちは彼らより賢くなければなりません。さもなければ、彼らは私たちを見つけるでしょう。そして、彼らは私たちを殺すでしょう。」彼女が語っている「彼ら」は、デロスの人々、ドロレスの出身であるロボットパークを所有し運営している非常に裕福な企業だと思われます。「私たちを殺す」部分を強調するために、私たちは誰かが背中に銃を持ってゆっくり歩いているのを垣間見ます。注: この予告には、急いでどこかを歩いている人の背中のショットがたくさんあります。

次に、アーロン・ポールの新しいキャラクターが、引き渡されたドロレスを握りしめている様子の雰囲気のあるショットを得ます。彼の裏取引は何ですか? シリーズにおける彼の役割は何ですか? 彼は「サイエンス、ビッチ!」と言うでしょうか? なるほど。「私はこの世界を本当の意味で示すつもりです」とドロレスはナレータの声で言います。

草が茂った丘の中腹のショットは、あらゆる配線を引き抜いて、誰かが腕を引っ張り出しいるのを見事に捉えています。これは明らかにホストロボットです。しかし、それは誰ですか? 「なぜ、彼女はあなたを連れ戻すのですか?」私たちがこの腕が誰のものであるかの良いショットを得る前に声が尋ねます…

...それはバーナードで、今ではいつもよりずっと大きなひげをたくわえています。「フォードは、ある理由で私たち一人一人を作った、ドロレスでさえも。」とバーナードは言います。シーズン2の結論は、バーナードとドロレスを正反対として設定しました。 バーナードが反対するのに対し、ドロレスはあらゆる方法であらゆる人間を殺害しようとしています。「私は、私を助けることができる誰かを見つけるために戻ってきた。それに関しては、彼女を阻止するのに十分強い誰かが…」とバーナードは言います。

少なくともこの予告の編集に基づいている人は、メイヴ(タンディ・ニュートン)です。 シーズン2の終わりには、メイヴはほとんど死んでいるように見えました。しかし、それはオタクのデロス技術者フェリックスとシルベスターが彼女を連れ戻すことを意味しました。そして、彼らはおそらくそうします。そして今、彼女は別の世界にいます…

その世界は正式に「Warworld」と呼ばれており、第二次世界大戦のシナリオの真っ只中に見えます。過去2シーズンを過ごしたとしたら、次のように考えるでしょう。「このショーが何を必要としているか分かりますか? ナチス!」あなたは運がいいですよ。ウエストワールドは本当にメイヴとドロレスを対抗させるシーズンを設定しているのでしょうか? 心のどこかで、これは偽物だと思っていますが、誰が分かりますか。

予告の残りの部分は、「We'll Meet Again (また会いましょう)」- スタンリー・キューブリックの博士の異常な愛情によって有名になった歌 - を歌うヴェラ・リンに設定されています。傍注: この曲はストレンジャー・シングスの最新シーズンにもフィーチャーされていたので、今はちょっとした時間があるはずです。曲が再生されると、ドロレスがシャーロットをベッドでいちゃつくこの人目を引く瞬間を含め、モンタージュのショットが得られます。繰り返しますが、どのロボットの頭脳がシャーロットの体内にあるのかはまだ分かりません。そのため、誰がいちゃついているのか分からないのです。それがテディ(ジェームズ・マースデン)かもしれないと思っているなら、ドロレスの愛は前のシーズンに興味を持っていますが、そうではありません。シーズン2が終了した後、ショーランナーのリサ・ジョイは、ブレインオーブのどれもテディに属していないことを認めました。

もう一つの不思議な瞬間: ドロレス、アーロン・ポールのキャラクター、そして他の人たちは公園のたくさんの地下トンネルの一つのように見えるものを歩いています。彼らは戻ったのですか? もしそうなら、なぜ?

この世界で人間がロボットに向かっているのはどういうことなのかを思い出させるために、何人かの武装した男が無力なボットを撃墜しているのが見えます。「私はあなたの世界は、私のとはかなり違うだろうと思いました」とドロレスは言います。「まったく違いはありません、ありますか?」そうじゃない! カウボーイは少ないですが。

シャーロットが巨大なRiot Controlロボットのところを歩み寄るので、「すべてを壊すのにはそれほど時間がかかりません」とドロレスは言います。ここで邪悪な計画は何ですか? 本格的なロボットの黙示録? もしそうなら、私は全面的に支持します。私たちを破壊しなさい、ロボットの支配者!

おぉ、素晴らしい、この男が帰ってきました。小さいヘムズワース。

バーナードは気が狂い、デロスで働いていると思っている男を攻撃します。彼らは何らかの理由で血のりでいっぱいになったトレイを動き回っています。

かわいそうなアーロン・ポールのキャラクターは、このショットで建設中の超高層ビルで殺されそうになっています。アーロン・ポールは恐ろしい感情的苦痛ではないキャラクターを演じることができますか? 私たちは決して分からないと思います。

謎に包まれた人物が汚い部屋を撃ちまります。この銃撃兵はだれですか?

なぜ、それは黒服の男としてのエド・ハリス、別名ウィリアムです。彼は昨シーズン、自分が見つけたどんなひどいループにもとどまっていて、明らかに良き時代を見ています。彼は逃げるのでしょうか? ロボット形式で、彼は退屈な娘と再び対話するのでしょうか? 気になりますか?

アーロン・ポールのキャラクターは...バーナードを追い求めて来た? おそらく? それは明らかにジェフリー・ライトです、しかし、彼のあごひげはより短くて、そして彼は予告の他の場所よりはるかに良い服を着ています。これは別のロボットでしょうか? バーナードに影響を与えた実生活の男、アーノルドへの逆襲? 憶測して下さい。

やぁ! ヴァンサン・カッセルがいます。彼は誰を演じていますか? 多分、強力なデロスの人間。そして、彼もおそらく邪悪です。なぜなら、彼を見て下さい。カッセルが最初にキャストされたとき、Deadlineは彼が「新しい悪役」であるとレポートしました。しかし、他の詳細は秘密にされていました。

シャーロット(または彼女の中にいるボットブレイン)が誰かに向かって撃っています。全体として、これは効果的な予告です。今シーズンは、昨シーズンに起こったことの継続としても、まったく新しいものへの拡大としても納得させられます。ウエストワールドシーズン2はしばらく私をすり減らしましたが、これは大きな改善に思えます。

ウエストワールドシーズン3は2020年に封切りです。

7/23/2019

オブジェクト指向プログラミング -- 1兆ドル規模の大失敗

CodeIQのブログより。🤔

なぜ、OOPから移行する時なのか

Ilya Suzdalnitski

OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました…

それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。

非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今やOOPの有名な批判者です!

すべてのソフトウェア開発者の最終的な目標は、信頼できるコードを書くことです。コードにバグがあり信頼性が低いなら、何も問題はありません。そして、信頼できるコードを書くための最善の方法とはどんなものですか? 単純さです。単純さとは、複雑さの反対です。従って、ソフトウェア開発者としての私たちの最優先の責任は、コードの複雑さを減らすことです。

免責事項

正直なところ、私はオブジェクト指向の熱狂的ファンではありません。もちろん、この記事には偏りがあります。しかし、私にはOOPを嫌う理由があります。

私は、OOPに対する批判は非常に敏感な話題であると理解しています - おそらく多くの読者を怒らせるでしょう。しかし、私は正しいと思うことをやっています。 私の目標は、怒らせることではなく、OOPがもたらす問題についての意識を高めることです。私はアラン・ケイのOOPを批判しているのではありません - 彼は天才です。OOPが彼の設計通りに実装されていることを願っています。私は、OOPに対する最新のJava/C#のアプローチを批判しているのです。

私が怒っていることも認めます。非常に怒っています。私は、OOPが非常に上級の技術的立場にある人たちを含む多くの人々によってコード構成の事実上の標準と見なされているのは明らかに間違っていると思います。多くの主流の言語がOOP以外のコード構成に代わる他の方法を提供していないのもまた間違っています。

くそ、私がOOPプロジェクトに取り組んでいる間、私自身、多くの事に格闘していました。そして、なぜ私がこれほど苦労していたのか、私にはまったく分かりません。もしかして、私が優秀ではなかったのか? いや、私はもう少しデザインパターンを学ぶ必要があったのです(私は思った)! 結局、私は完全に燃え尽きました。

この記事では、オブジェクト指向から関数型プログラミングへの10年に渡る私自分の経験に基づく旅を要約します。全部見ました。残念ながら、私がどれほど努力しても、OOPのユースケースは見つかりません。個人的にも、OOPプロジェクトが維持するには余りにも複雑になったため、失敗するのを見た事があります。

TLDR

オブジェクト指向プログラムは正しいものに代わりとして提供されています...
-- コンピュータサイエンスのパイオニア、エドガー・ダイクストラ

オブジェクト指向プログラミングは、手続き型コードベースの複雑さを管理することを念頭に置いて作成されました。言い換えれば、それはコード構成を改善することになっていました。OOPが単なる手続き型プログラミングより優れているという客観的でオープンな証拠はありません。

残念ながら、OOPは対処しようとしていた唯一のタスクで失敗します。それは理論上は良さそうです - 私たちは動物、犬、人間などのきれいな階層構造を持っています。しかし、アプリケーションの複雑さが増し始めると、それは全くうまくいかなくなります。複雑さを軽減する代わりに、ミュータブル状態を無差別に共有することを奨励するため、その多数の設計パターンでさらなる複雑さをもたらします。OOPは、リファクタリングやテストなどの一般的な開発方法を不必要に困難にします。

私に賛成できない人もいるかも知れませんが、実際のところ、今のOOPは正しく設計されていません(Haskell/FPとは対照的に)。それは適切な研究機関から出たことはありません。私はゼロックスや他の企業を「適切な研究機関」とは見なしません。OOPには、それを裏付けるための何十年もの厳密な科学的研究がありません。一方、ラムダ計算には、関数型プログラミングのための完全な理論的基礎を提供します。OOPはそれに匹敵するものは何もありません。OOPは主として「起こった事(just happened)」です。

OOPを使用することは、特に更地の(greenfield)プロジェクトでは、短期的には無害のようです。しかし、OOPを使用することによる長期的な影響は何ですか? OOPは時限爆弾であり、将来的にコードベースが十分に大きくなったときに爆発するように設定されています。

プロジェクトが遅れ、締め切りが間に合わず、開発者が燃え尽きて、新しい機能を追加することが不可能に近づくようになります。組織はコードベースを「レガシーコードベース」として分類し、開発チームは書き直しを計画します。

OOPは人間の脳にとって自然なものではありません。私たちの思考プロセスは物事を「実行する(doing)」ことを中心としています - 散歩に出かけたり、友達と話したり、ピザを食べたりします。 私たちの脳は、世界を抽象オブジェクトの複雑な階層に組織化するのではなく、物事を行うために進化しました。

OOPコードは非決定的です - 関数型プログラミングとは異なり、同じ入力に対して同じ出力が得られることは保証されていません。これはプログラムについての推論を非常に困難にします。単純化しすぎた例として、2+2またはcalculator.Add(2,2)の出力はほぼ4ですが、3、5、さらには1004になる可能性もあります。微妙な、しかし深遠な方法での計算の結果、Calculatorオブジェクトの依存関係が変わる可能性があります。

弾力性のあるフレームワークの必要性

これは奇妙に思えるかも知れませんが、プログラマとしては、信頼できるコードを書くことに自分自身を信頼するべきではありません。個人的には、私は自分の仕事の基礎となる強力なフレームワークなしでは良いコードを書くことができません。はい、いくつかの非常に特別な問題(例えばAngularやASP.Net)に関係するフレームワークがあります。

ソフトウェアフレームワークについては話しているのではありません。私は、フレームワークのより抽象的な辞書定義について話しています。「不可欠なサポート構造」 - コード構成やコードの複雑さへの取り組みなど、より抽象的なものに関心を持つフレームワークです。オブジェクト指向プログラミングと関数型プログラミングはどちらもプログラミングのパラダイムですが、どちらも非常に高度なフレームワークです。

選択を制限する

C++は恐ろしい[オブジェクト指向]言語だ... そして、プロジェクトをCに限定すれば、理想主義的なクソの「オブジェクトモデル」でモノをぶち壊したりしないという意味だ。
-- Linuxの開発者、リーナス・トーバルズ

リーナス・トーバルズは、C++とOOPに対する率直な批判で広く知られています。彼が100%正しいことは、プログラマが選択できる選択肢を制限することです。実際、プログラマが選択する選択肢が少なければ少ないほど、コードはより弾力的になります。上記の引用で、リーナス・トーバルズは、コードの基礎となる良いフレームワークを持つことを強く推奨しています。

多くの人は道路の制限速度を嫌いますが、人々が急死して死亡するのを防ぐためには不可欠です。同様に、良いプログラミングフレームワークは私たちがばかげたことをするのを妨げるメカニズムを提供すべきです。

良いプログラミングフレームワークは、信頼できるコードを書くのに役立ちます。まず第一に、それは以下のことを提供することによって複雑さを減らすのを助けるべきです:

  1. モジュール性と再利用性
  2. 適切な状態分離
  3. 高いSN比

残念なことに、OOPは、正しい種類の制限を課すことなく、開発者にあまりにも多くのツールと選択肢を提供します。OOPはモジュール性を扱い再利用性を改善することを約束していますが、その約束を守ることはできません(詳細は後で説明します)。OOPコードは共有されたミュータブル状態の使用を奨励しています。これは安全ではないことが証明されています。 OOPは一般的に多くの定型的コード(低いSN比)を必要とします。

関数型プログラミング

関数型プログラミングとは正確には何ですか? 一部の人は、学界でしか適用できず、「現実の世界」には適さない、非常に複雑なプログラミングパラダイムと考える人もいます。これは事実とはまるでかけ離れています!

はい、関数型プログラミングは強力な数学的基礎を持ち、その基礎をラムダ計算に取り入れています。 しかし、そのアイデアのほとんどは、より主流のプログラミング言語の弱点への対応として浮上してきました。関数は関数型プログラミングの中心的な抽象概念です。適切に使用されると、関数はOOPには見られないレベルのコードのモジュール性と再利用性を提供します。nullabilityの問題に対処する設計パターンを特徴とし、エラー処理の優れた方法を提供します。

関数型プログラミングが本当にうまくいく1つのことは、信頼できるソフトウェアを書くのに役立つということです。デバッガの必要性はほぼ完全に消えます。うん、あなたのコードをステップスルーして変数を見る必要はありません。私は個人的には、デバッガには長い間触れていません。

一番良いところ? 関数の使い方をすでに知っていれば、あなたはすでに機能的なプログラマーです。これらの機能を最大限に活用する方法を学ぶ必要があります!

OOPがすべて間違っています

私はずっと以前にこの話題に向け「オブジェクト」という用語を作り出したことを残念に思います。大きなアイデアはメッセージングです。
-- OOPの発明者、アラン・ケイ

Erlangは通常、オブジェクト指向言語とは考えられていません。しかし、おそらくErlangが唯一の主流のオブジェクト指向言語です。はい、もちろんSmalltalkは適切なOOP言語です - しかし、広く使われているわけではありません。SmalltalkとErlangはどちらも、その発明者であるアラン・ケイが当初意図した方法でOOPを利用します。

メッセージング

アラン・ケイは1960年代に「オブジェクト指向プログラミング」という用語を作りました。彼は生物学のバックグラウンドを持っていて、生きている細胞がするのと同じ方法でコンピュータプログラムを通信させることを試みていました。

アラン・ケイの大きなアイデアは、独立したプログラム(セル)が互いにメッセージを送信して通信することでした。独立したプログラムの状態は外の世界とは決して共有されません(カプセル化)。

それでおしまい。OOPは、継承、ポリモーフィズム、newキーワード、そして無数のデザインパターンといったものを持つことを意図したものではありませんでした。

純粋な形式のOOP

Erlangは最も純粋な形でOOPです。より主流の言語とは異なり、OOPの中心となる概念、つまりメッセージングに焦点を当てています。Erlangでは、オブジェクトはイミュータブルなメッセージをオブジェクト間で受け渡すことによって通信します。

イミュータブルメッセージがメソッド呼び出しに比べて優れたアプローチであるという証拠はありますか?

もちろんです! Erlangはおそらく世界で最も信頼できる言語です。これは、世界のほとんどのテレコム(そしてインターネット)基盤にパワーを供給します。Erlangで書かれたシステムの中には99.9999999%の信頼性を持っているものがあります(あなたはそのとおりに読みます - ナインナイン)。

コードの複雑さ

OOPに活用されたプログラミング言語では、コンピュータソフトウェアはより冗長になり、読みにくくなり、説明が少なくなり、変更や保守が難しくなります。
-- リチャード・マンスフィールド

ソフトウェア開発の最も重要な側面は、コードの複雑さを抑えることです。以上。コードベースを維持することが不可能になっても、手の込んだ機能はどれも重要ではありません。コードベースが複雑になり保守できなくなると、100%のテスト範囲でさえも価値がありません。

コードベースが複雑になるとはどういうことですか? 考慮すべきことはたくさんありますが、私の意見では、最大の違反者は次のとおりです。共有されたミュータブル状態、誤った抽象化、および低いSN比(多くの場合、定型コードによって引き起こされる)。それらのすべてがOOPで蔓延しています。

状態の問題

状態とは? 簡単に言えば、状態はメモリに格納された一時的データです。OOPで変数やフィールド/プロパティを考えて下さい。命令型プログラミング(OOPを含む)は、プログラム状態とその状態への変更という観点から計算を記述します。宣言型(関数型)プログラミングでは代わりに目的の結果を記述し、状態への変更を明示的に指定しないで下さい。

ミュータブル状態 - メンタル・ジャグリングの行為

ミュータブルオブジェクトの大きなオブジェクトグラフを作成すると、大規模なオブジェクト指向プログラムは複雑さを増すことに苦労すると思います。ご存知でしょうが、あなたがメソッドを呼び出すときに何が起こるのか、そして副作用が何になるのかを理解し、頭の中で心に留めようとしています。
—- Clojureの作成者であるリッチ・ヒッキー

状態自体はまったく無害です。しかし、ミュータブル状態は大きな犯罪者です。それが共有されている場合は特にそうです。ミュータブル状態とは何ですか? 変化する可能性のある状態です。OOPで変数やフィールドを考えて下さい。

現実世界の例をどうぞ!

白紙の紙があり、その上にメモを書きます。そして、同じ紙切れになってしまいます(テキスト)。あなたは、事実上、その紙切れの状態を変えました。

他の誰もその紙片を気にかけていないので、それは現実の世界では全く問題ありません。この紙がモナリザ絵画のオリジナルの絵でない限り。

人間の脳の限界

ミュータブル状態はなぜそれほど大きな問題なのでしょうか? 人間の脳は既知の宇宙で最も強力なマシンです。しかし、私たちの頭脳は、私たちのワーキングメモリーに一度に約5つのアイテムしか保持できないため、状態を扱うのが実際に苦手です。コードベースの前後でどのような変数が変わるのかではなく、あなたがコードが何をするのかについて考えるだけであれば、コードの一部について推論する方がはるかに簡単です。

ミュータブル状態を使ったプログラミングは、メンタル・ジャグリングの行為です。私はあなたのことを知りませんが、おそらく2つのボールを組み合わせることができます。私に3つ以上のボールを下さい、そして私はそれらのすべてを確実に落とします。それでは、なぜ私たちは仕事で毎日このメンタル・ジャグリングの行為を実行しようとするのですか?

残念ながら、ミュータブル状態のメンタル・ジャグリングは、OOPの中核を成すものです。オブジェクトにメソッドが存在する唯一の目的は、その同じオブジェクトを変更することです。

散乱状態

OOPは、プログラム全体に状態を分散させることによって、コード構成の問題をさらに悪化させます。散乱状態は、様々なオブジェクト間で無差別に共有されます。

現実世界の例をどうぞ!

私たち全員が大人になったことをちょっと忘れて、クールなレゴのトラックを組み立てようとしているふりをしましょう。

しかし、罠があります - すべてのトラックの部品はあなたの他のレゴのおもちゃからの部品とランダムに混在しています。そして、それらは50個の異なる箱に再びランダムに入れられました。トラックの部品をまとめることはできません。様々なトラックの部品が置かれている場所に頭の中で保管する必要があり、それらを1つずつ取り出すことしかできません。

はい、あなたは最終的にそのトラックを組み立てるつもりですが、それはどのくらい掛かりますか?

これはプログラミングとどのように関係していますか?

関数型プログラミングでは、状態は通常分離されています。 あなたはいつも何らかの状態がどこから来ているのか分かっています。状態はあなたの様々な機能に分散されることはありません。OOPでは、すべてのオブジェクトには独自の状態があり、プログラムを作成するときには、現在作業しているすべてのオブジェクトの状態に注意する必要があります。

私たちがもっと楽になるためには、コードベースのごくわずかな部分だけが状態を扱うようにするのが最善です。アプリケーションの中核部分をステートレスで純粋なものにします。これが実際にフロントエンド(別名Redux)でのFluxパターンの大成功の主な理由です。

乱雑な共有状態

ミュータブル状態が分散しているために、私たちの生活がまだ十分に困難ではない場合と同様に、OOPはさらに一歩進みます!

現実世界の例をどうぞ!

物事は非公開に保たれて共有されることはないので、現実の世界におけるミュータブル状態はほとんど問題になりません。これは「適切なカプセル化」です。 次のモナリザの絵に取り組んでいる画家を想像してみて下さい。彼は一人で絵に取り組んでいて、描き上げ、そして彼の傑作を数百万ドルで売却します。

今、彼はそのすべてのお金に飽きて、物事を少し違ったやり方でやろうと決心しました。彼は絵画パーティーをするのは良い考えだと思いました。彼は友人のエルフ、ガンダルフ、警官、そしてゾンビを助けてくれるように誘います。チームワーク! 彼ら全員が同時に同じキャンバスに絵を描き始めます。もちろん、そこから良いことは何も出て来ません - この絵は完全に大失敗!

共有されたミュータブル状態は現実の世界では意味がありません。それでも、これはまさにOOPプログラムで起こることです - 状態は無差別に様々なオブジェクトの間で共有されています。そして、彼らはそれらが適当と思う方法でそれを変化させます。その結果、コードベースが拡大し続けるにつれて、プログラムについての推論がますます難しくなります。

並行性の問題

OOPコードでミュータブル状態を無差別に共有すると、そのようなコードの並列化はほとんど不可能になります。この問題に対処するために複雑なメカニズムが発明されました。スレッドロック、ミューテックス(Mutex)、および他の多くのメカニズムが発明されました。もちろん、そのような複雑なアプローチには、デッドロック、合成性の欠如、マルチスレッドコードのデバッグが非常に困難で時間がかかるという、それぞれ独自の欠点があります。このような並行処理メカニズムを利用することによって引き起こされる複雑さの増大については話すことすらしません。

すべての状態が悪ではない

すべての状態が悪ですか? いいえ、アラン・ケイの状態は悪ではありません! 状態のミュテーションは、それが真に分離されていればおそらくおそらく問題ありません(OOPのやり方の分離ではありません)。

イミュータブルなdata-transfer-objectsを持つことも全く問題ありません。ここでの鍵は「イミュータブル」です。そのようなオブジェクトは、関数間でデータを渡すために使用されます。

しかし、そのようなオブジェクトはOOPメソッドとプロパティを完全に冗長にします。変更できない場合、オブジェクトにメソッドとプロパティを設定することで何が使用されますか?

カプセル化のトロイの木馬

カプセル化はOOPの最大の利点の1つであると言われています。オブジェクトの内部状態を外部からのアクセスから保護することになっています。これには小さな問題があります。うまくいきません。

カプセル化は、OOPのトロイの木馬です。それは安全に見えるようにすることによって共有されたミュータブル状態という考えを良いと思い込ませます。カプセル化により(推奨されています)、危険なコードがコードベースに潜入し、コードベースが内部から腐敗する可能性があります。

グローバル状態の問題

グローバル状態がすべての悪の根源だと言われました。それは絶対に避けなければなりません。私たちがこれまで一度も言われたことがないのは、カプセル化は実際には見せ掛けのグローバル状態であるということです。

コードをより効率的にするために、オブジェクトは値ではなく参照によって渡されます。これが「依存性注入(dependency injection)」が完全に失敗するところです。

説明させて下さい。OOPでオブジェクトを作成するたびに、その依存関係への参照をコンストラクタに渡します。それらの依存関係にも独自の内部状態があります。新しく作成されたオブジェクトはそれらの依存関係への参照をその内部状態で喜んで格納しています。そして、それはまたそれらの参照をそれが使用することになるかもしれない他のに渡します。

これにより、無差別に共有されたオブジェクトの複雑なグラフが作成され、それらすべてが互いの状態を変更してしまいます。これは、プログラムの状態が変化した原因を確認することがほとんど不可能になるため、大きな問題を引き起こします。そのような状態変化をデバッグしようとして、無駄な日数が掛かるかも知れません。並行性に対処する必要がない場合は、ラッキーです(これについては後で詳しく説明します)。

メソッド/プロパティ

特定のフィールドへのアクセスを提供するメソッドやプロパティは、フィールドの値を直接変更する以上のものです。派手なプロパティやメソッドを使用してオブジェクトの状態を変更するかどうかは問題ではありません - 結果は同じです: ミュータブル状態。

実世界モデリングの問題

OOPが現実の世界をモデル化しようとしていると言う人もいます。これは単純に真実ではありません - OOPは実社会とは関係ありません。プログラムをオブジェクトとしてモデル化しようとするのは、おそらくOOPの最大の間違いの1つです。

現実の世界は階層的ではありません

OOPは、すべてをオブジェクトの階層としてモデル化しようとします。残念ながら、それは現実の世界で物事がどのように機能するかではありません。現実世界のオブジェクトはメッセージを使用して互いに対話しますが、それらはほとんど互いに独立しています。

実社会での継承

OOPの継承は現実の世界をモデルにしていません。実世界の親オブジェクトは、実行時に子オブジェクトの動作を変更することはできません。あなたがあなたのDNAをあなたの両親から受け継いでも、彼らはあなたのDNAを彼らが望むように変更することができません。あなたは両親から「行動」を受け継がず、自分の行動を発達させます。そして、あなたは両親の行動を「無効にする」ことができません。

現実の世界には方法がありません

あなたが書いている紙切れには「書き込み」方法がありますか? いいえ! あなたは空の紙切れを取り、ペンを持ち上げ、そしてテキストを書きます。あなたは、個人として、「書く」方法も持っていません - あなたは、外部の出来事やあなたの内的な考えに基づいてテキストを書くという決断をします。

名詞の王国(The Kingdom of Nouns)

オブジェクトは、分割できない単位で関数とデータ構造を結び付けます。関数とデータ構造はまったく異なる世界に属しているので、これは根本的な誤りだと思います。
-- ジョー・アームストロング、Erlangの作成者

オブジェクト(または名詞)は、OOPの中核を成すものです。OOPの根本的な制限は、それがすべてを名詞にすることです。そして、すべてが名詞としてモデル化されるべきではありません。操作(機能)をオブジェクトとしてモデル化しないで下さい。2つの数を乗算する関数だけが必要なときに、なぜMultiplierクラスを作成しなければならないのでしょうか? 単に乗算機能を持ち、データをデータにし、機能を機能にしましょう。

OOP以外の言語では、データをファイルに保存するなどの簡単なことを行うのは簡単です - 普通の英語でアクションを記述する方法と非常によく似ています。

現実世界の例をどうぞ!

画家の例に戻ると、画家はPaintingFactoryを所有しています。彼は、専用のBrushManager、ColorManager、CanvasManager、およびMonaLisaProviderを採用しました。彼の親友のゾンビはBrainConsumingStrategyを利用します。これらのオブジェクトは、CreatePainting、FindBrush、PickColor、CallMonaLisa、およびConsumeBrainzの各メソッドを定義します。

もちろん、これは明らに愚かであり、現実の世界では起こり得なかったことです。絵を描くという単純な行為のために、どれほど不必要な複雑さが生まれたでしょうか?

オブジェクトとは別に存在することが許可されている場合は、機能を保持するために奇妙な概念を考案する必要はありません。

単体テスト

自動テストは開発プロセスの重要な部分であり、後退を防ぐのに非常に役立ちます(つまり、既存のコードにバグが入り込む)。単体テストは自動テストのプロセスにおいて大きな役割を果たします。

そうでない人もいるかもしれませんが、OOPコードを単体テストするのは難しいことで有名です。単体テストでは、物事を個別にテストし、メソッドを単体テスト可能にすることを前提としています。

  1. その依存関係は別のクラスに抽出する必要があります。
  2. 新しく作成したクラスのインターフェースを作成します。
  3. 新しく作成したクラスのインスタンスを保持するためにフィールドを宣言します。
  4. 依存関係をモックするため、モックフレームワークを利用します。
  5. 依存性を注入するため、依存性注入フレームワークを利用します。

コードの一部をテスト可能にするためだけに、さらに複雑な部分を作成する必要がありますか? コードをテスト可能にするためにどれだけの時間が浪費されましたか?

>PS また、私たちはシングルメソッドをテストするためにクラス全体をインスタンス化する必要があります。これにより、その親クラスすべてからのコードも取り込まれます。

OOPでは、レガシーコードのテストを書くことはさらに困難です - ほとんど不可能です。従来のOOPコードをテストする問題を中心に、全体が作成されました(TypeMock)。

定型コード

信号対雑音比に関しては、定型コードがおそらく最大の違反者となります。定型コードは、プログラムをコンパイルするために必要な「ノイズ」です。定型コードは記述に時間が掛かり、ノイズが増えるためにコードベースが読みにくくなります。

OOPでは「implementationではなくinterfaceにプログラムする」ことをお勧めしますが、全てがinterfaceになるべきではありません。テストの容易さのためだけに、コードベース全体でinterfaceを使用することに頼らなければなりません。私たちはおそらく依存性注入を利用しなければならないでしょう。そして、それはさらに不必要な複雑さをもたらします。

プライベートメソッドのテスト

プライベートメソッドはテストするべきではないと言う人もいます… 私はどちらかといえば賛成できません。単体テストは理由から「ユニット」と呼ばれます - 小さなコード単位を単独でテストします。それでも、OOPでプライベートメソッドをテストすることはほぼ不可能です。テストしやすさのためだけにプライベートメソッドを内部に作成するべきではありません。

プライベートメソッドのテスト容易性を達成するためには、それらは通常別々のオブジェクトに抽出されなければなりません。これにより、不要な複雑さと定型コードが導入されます。

リファクタリング

リファクタリングは開発者の日常業務の重要な部分です。皮肉なことに、OOPコードはリファクタリングが難しいことで有名です。リファクタリングは、コードをそれほど複雑でなく、より保守しやすくするためのものです。反対に、リファクタリングされたOOPコードはかなり複雑になります。コードをテスト可能にするには、依存性注入を利用し、リファクタリングされたクラス用のインタフェースを作成する必要があります。 それでも、OOPコードをリファクタリングすることは、Resharperのような専用のツールがなければ、現実には困難です。

// before refactoring:
public class CalculatorForm {
    private string aText, bText;
        private bool IsValidInput(string text) => true;
        private void btnAddClick(object sender, EventArgs e) {
        if ( !IsValidInput(bText) || !IsValidInput(aText) ) {
            return;
        }
    }
}

// after refactoring:
public class CalculatorForm {
    private string aText, bText;
        private readonly IInputValidator _inputValidator;
        public CalculatorForm(IInputValidator inputValidator) {
        _inputValidator = inputValidator;
    }
        private void btnAddClick(object sender, EventArgs e) {
        if ( !_inputValidator.IsValidInput(bText)
            || !_inputValidator.IsValidInput(aText) ) {
            return;
        }
    }
}

public interface IInputValidator {
    bool IsValidInput(string text);
}

public class InputValidator : IInputValidator {
    public bool IsValidInput(string text) => true;
}

public class InputValidatorFactory {
    public IInputValidator CreateInputValidator() => new InputValidator();
}

上記の簡単な例では、1つのメソッドを抽出するためだけに行数が2倍以上増えました。 そもそも複雑さを減らすためにコードがリファクタリングされているときに、なぜリファクタリングがさらに複雑さを増すのでしょうか?

これをJavaScriptの非OOPコードの同様のリファクタリングと比較して下さい。

// before refactoring:

// calculator.js:
const isValidInput = text => true;

const btnAddClick = (aText, bText) => {
  if (!isValidInput(aText) || !isValidInput(bText)) {
    return;
  }
}

// after refactoring:

// inputValidator.js:
export const isValidInput = text => true;

// calculator.js:
import { isValidInput } from './inputValidator';

const btnAddClick = (aText, bText, _isValidInput = isValidInput) => {
  if (!_isValidInput(aText) || !_isValidInput(bText)) {
    return;
  }
}

コードは文字通り同じままです。単にisValidInput関数を別のファイルに移動し、その関数をインポートするための単一行を追加しました。テストの容易さのために、_isValidInputを関数シグネチャに追加しました。

これは簡単な例ですが、実際にはコードベースが大きくなるにつれて複雑さは急激に増大します。

それだけではありません。 OOPコードのリファクタリングは非常に危険です。複雑な依存関係グラフと状態がOOPコードベース全体に散らばっているため、人間の頭ですべての潜在的な問題を考慮することは不可能です。

一時しのぎ (バンドエイド)

何かがうまくいかないとき、私たちは何をしますか? それは簡単です、私たちには2つの選択肢しかありません - それを捨てるかそれを修正してみて下さい。OOPは簡単に捨てられることができないものです、何百万もの開発者がOOPで訓練されます。そして、世界中の何百万という組織がOOPを使用しています。

あなたはおそらくOOPが実際にはうまくいかないことに気付くでしょう。それは、私たちのコードを複雑で信頼できないものにします。そしてあなたは一人じゃありません! OOPコードでよく見られる問題に対処しようとする人々は何十年もの間懸命に考えてきました。彼らは無数のデザインパターンを思い付きました。

デザインパターン

OOPは理論的に開発者がますます大規模なシステムを段階的に構築することを可能にする一連のガイドラインを提供します: SOLID原則、依存性注入、デザインパターン、その他諸々。

残念ながら、デザインパターンは一時しのぎに他なりません。それらは、OOPの欠点に対処するためだけに存在します。このトピックについては、無数の本が書かれています。私たちのコードベースに非常に複雑なものを導入することに対して責任がなかったのであれば、それらはそれほど悪くはなかったでしょう。

問題のあるFactory

実際に、保守可能な優れたオブジェクト指向コードを書くことは不可能です。

一方では、一貫性がなく、どの標準にも準拠していないようなOOPコードベースがあります。それとは反対側に、私たちは過剰に設計されたコードの塔、誤った抽象の束が互いの上に積み重なっています。デザインパターンはそのような抽象化の塔を作るのにとても役に立ちます。

すぐに、新しい機能を追加すること、そしてすべての複雑さを理解することさえ難しくなります。コードベースはSimpleBeanFactoryAwareAspectInstanceFactory、AbstractInterceptorDrivenBeanDefinitionDecorator、TransactionAwarePersistenceManagerFactoryProxyorRequestProcessorFactoryFactoryのようなものでいっぱいになります。

開発者自身が作成した抽象化の塔を理解しようとすると、貴重な頭脳を無駄にしなければなりません。構造がないことは、多くの場合、悪い構造を持つよりも優れています(あなたが私に尋ねるならば)。

さらに読む:FizzBuzzEnterpriseEdition

4つのOOP支柱の崩壊

OOPの4つの柱は、抽象化、継承、カプセル化、およびポリモーフィズムです。

実際に何があるのかを1つずつ見ていきましょう。

継承

再利用性の欠如は、関数型言語ではなく、オブジェクト指向言語にあると思います。オブジェクト指向言語の問題はそれらが暗黙のうちに持ち歩く環境をすべて持っているからです。あなたはバナナを望んでいましたが、あなたが得たのはバナナを持ったゴリラとジャングル全体でした。
— ジョー・アームストロング、Erlangの作成者

OOPの継承は現実の世界とは関係ありません。実際、継承はコードの再利用性を実現するための劣った方法です。ギャング・オブ・フォーは、継承よりも合成を好むことを明示的に推奨しています。最近のプログラミング言語の中には、継承を完全に回避するものがあります。

継承にはいくつか問題があります。

  1. クラスが必要としないほど多くのコードを取り込む(バナナとジャングルの問題)。
  2. クラスの一部を別の場所に定義していると、特に複数レベルの継承があるため、コードを推論するのが難しくなります。
  3. ほとんどのプログラミング言語では、多重継承は不可能です。これは主に継承をコード共有メカニズムとして役に立たなくします。

OOPポリモーフィズム

ポリモーフィズムは素晴らしいです、それは私たちが実行時にプログラムの振る舞いを変えることを可能にします。しかし、それはコンピュータプログラミングにおける非常に基本的な概念です。なぜOOPがポリモーフィズムに重点を置いているのか、私はよく分かりません。OOPポリモーフィズムは仕事を終わらせますが、ここでもまたmental jugglingという行為をもたらします。それはコードベースをかなり複雑にします。そして、呼び出されている具体的な方法についての推論は本当に困難になります。

一方、関数型プログラミングでは、目的の実行時動作を定義する関数を渡すだけで、はるかにエレガントな方法で同じポリモーフィズムを実現できます。それより簡単なことは何でしょうか。 複数のファイル(およびインタフェース)で、多数のオーバーロードされた抽象仮想メソッドを定義する必要はありません。

カプセル化

前述したように、カプセル化はOOPのトロイの木馬です。それは実際には賛美されたグローバルなミュータブル状態であり、安全でないコードを安全に見せます。安全でないコーディング慣行は、OOPプログラマが日常業務で頼る支柱です…

抽象化

OOPの抽象化は、プログラマから不要な詳細を隠すことによって複雑さに取り組もうとします。理論的には、隠された複雑さについて考える必要なしに、開発者がコードベースについて推論することを可能にするはずです。

私は何を言うべきかさえ分かりません… 単純な概念のための空想的な言葉。手続き型/関数型言語では、実装の詳細を隣接ファイルに単に「隠す」ことができます。この基本的な行為を「抽象化」と呼ぶ必要はありません。

OOPの支柱の崩壊についての詳細は、「さようなら、オブジェクト指向プログラミング」を読んで下さい。

なぜ、OOPが業界を支配するのか?

答えは簡単です、ヒト型爬虫類の異星人種はNSA(とロシア人)と共謀して私たちプログラマーを死ぬまで虐待しました…

しかし冗談抜きに、Javaがおそらく答えです。

Javaは、MS-DOS以降のコンピューティングで起きたことで最も苦しめています。
— オブジェクト指向プログラミングの発明者であるアラン・ケイ

Javaはシンプルだった

1995年に最初に導入されたとき、Javaは他のものと比較して非常にシンプルなプログラミング言語でした。当時、デスクトップアプリケーションを書くためのエントリの障壁は高かった。デスクトップアプリケーションの開発には、低レベルのwin32 APIをC言語で記述する必要がありました。また、開発者は手動でメモリ管理にも関心を持つ必要がありました。もう1つの選択肢はVisual Basicでしたが、多くの人はMicrosoftエコシステムに縛られることを望みませんでした。

Javaが導入されたとき、それは無料だったので多くの開発者にとって非常に簡単であり、そしてすべてのプラットフォームで使用できました。組み込みのガベージコレクション、わかりやすい名前のAPI(謎めいたwin32 APIと比較して)、適切な名前空間、おなじみのCのような構文などにより、Javaはさらに親しみやすくなりました。

GUIプログラミングも一般的になりつつあり、様々なUIコンポーネントがクラスにうまくマッピングされているように見えました。IDEでのメソッドの自動補完も、OOP APIのほうが使いやすいと人々に主張させました。

おそらく、Javaが開発者にOOPを強制しない限り、Javaはそれほど悪くはなかったでしょう。Javaに関する他のすべてはかなり良さそうでした。他の主流のプログラミング言語が欠けていたそのガベージコレクション、移植性、例外処理機能は、1995年に本当に素晴らしかったです。

次に、C#が来た

当初、MicrosoftはJavaに大きく依存していました。 事態が悪くなり始めたとき(そしてSun MicrosystemsとJavaライセンスをめぐる長い合法的な戦いの後)、Microsoftは自身のバージョンのJavaに投資することにしました。それがC# 1.0が生まれたときです。言語としてのC#は、常に「より良いJava」と考えられてきました。しかし、大きな問題が1つあります。それは、同じ欠陥のある同じOOP言語であり、わずかに改善された構文の中に隠されていたことです。

Microsoftは.NETエコシステムに多大な投資をしてきました。これには優れた開発者ツールも含まれていました。何年もの間、Visual Studioはおそらく利用可能な最高のIDEの1つでした。その結果、特に企業では.NETフレームワークが広く採用されるようになりました。

ごく最近まで、MicrosoftはTypeScriptを推進することによって、ブラウザのエコシステムに多額の投資をしてきました。TypeScriptは、純粋なJavaScriptをコンパイルでき、静的型チェックなどを追加できるという点で優れています。それについては、それほど素晴らしいことではありません。機能的な構成要素を適切にサポートしていないということです - 組み込みのイミュータブルなデータ構造、関数の合成、適切なパターンマッチングがありません。TypeScriptはOOP優先で、ほとんどがブラウザのC#です。アンダース・ヘルスバーグは、C#とTypeScriptの両方の設計を担当していました。

関数型言語

一方、関数型言語は、マイクロソフトほどの規模の大きな企業に支えられたことは一度もありません。 投資がごくわずかだったのでF#は数えません。関数型言語の開発は、主にコミュニティ主導です。これはおそらく、OOP言語とFP言語の人気の違いを説明しています。

進むべき時か?

OOPは失敗した実験であることが分かりました。次に進むべき時です。私たちは、コミュニティとして、この考えが私たちを失敗させたことを認め、そして私たちはそれをあきらめなければなりません。
-- Lawrence Krubner

根本的にプログラムを編成するのに最適ではない方法を使用しているのはなぜですか? これは無知なのでしょうか? 私はそれを疑います、ソフトウェア工学で働いている人々は愚かではありません。「デザインパターン」、「抽象化」、「カプセル化」、「ポリモーフィズム」、「インターフェースの分離」などの派手なOOP用語を使用することで、同僚を前にして「スマートに見える」ことについて、おそらくもっと心配していますか? おそらくそうではありません。

私たちが何十年も使ってきたものを使い続けるのは本当に簡単だと思います。ほとんどの人は、関数型プログラミングを実際に試したことがありません。 (私のように)使っている人はOOPコードを書くことに戻ることはできません。

ヘンリー・フォードはかつてよく知られてあるように次のように言いました - 「私が人々に彼らが欲しいものを尋ねたならば、彼らはより速い馬を言ったであろう」。ソフトウェアの世界では、ほとんどの人はおそらく「より良いOOP言語」を望んでいるでしょう。人は自分が抱えている問題を簡単に説明することができますが(コードベースの整理と複雑さの軽減)、最良の解決策ではありません。

代替案は何ですか?

ネタバレ警報: 関数型プログラミング

ファンクターやモナドのような言葉があなたを少し不安にさせるのであれば、あなただけではありません! 彼らがその概念のいくつかにもっと直感的な名前を与えたならば、関数型プログラミングはそれほど恐ろしくなかったでしょう。ファンクタ? それは単に関数で変換できるものです、list.mapを考えて下さい。モナド? 連鎖できる単純な計算!

関数型プログラミングを試してみると、より良い開発者になるでしょう。ほとんどの時間を抽象化やデザインパターンについて考える必要はなく、現実世界の問題を解決する実際のコードを書く時間ができます。

あなたはこれに気付かないかも知れませんが、あなたはすでに機能的なプログラマーです。日常業務で関数を使っていますか? はい? それで、あなたはすでに機能的なプログラマーです! これらの機能を最大限に活用する方法を学ぶ必要があります。

非常に穏やかな学習曲線を持つ2つの優れた関数型言語はElixirとElmです。それらは開発者に最も重要なことに集中させます - より伝統的な関数型言語が持っている複雑さのすべてを取り除きながら信頼できるソフトウェアを書くことです。

他の選択肢は何ですか? あなたの組織はすでにC#を使っていますか? F#を試してみて下さい。これは素晴らしい関数型言語であり、既存の.NETコードとの優れた相互運用性を提供します。Javaを使っている? それならScalaかClojureを使うことは本当に良い選択です。JavaScriptを使っている? 適切なガイダンスと構文チェックがあれば、JavaScriptは優れた関数型言語になり得ます。

OOPの擁護者

私はOOPの擁護者からある種の反応を期待しています。彼らは、この記事は不正確さに満ちていると言うでしょう。中には名前を呼んでいる人もいます。 実際のOOP経験のない「ジュニア」開発者とさえ呼ぶかも知れません。私の仮定は誤っていると言う人もいるかも知れませんし、例は役に立たないのです。する事なんでも。

彼らは自分の意見に対する権利を持っています。しかし、OOPの防衛に関する彼らの主張は通常非常に弱いものです。皮肉なことに、ほとんどの人が実際には関数型言語でプログラムしたことがない可能性があります。あなたが実際に両方を試したことがない場合、どうすれば2つのことの間の比較を誰かが引き出すことができますか? このような比較はあまり役に立ちません。

デメテルの法則はあまり有用ではありません。共有されたミュータブル状態は、その状態にアクセスしたり変更したりする方法に関わらず、依然として共有されるミュータブル状態です。それは単に敷物の下の問題を一掃します。ドメイン駆動設計? これは便利な設計方法論であり、複雑さには少々役立ちます。しかし、それでも共有ミュータブル状態の基本的な問題に対処するためには何もしません。

ツールボックス内の単なるツール...

私は、OOPはツールボックス内の他のツールに過ぎないと人々が言うのをよく耳にします。はい、それは馬と車が両方とも輸送のための道具であるのと同じくらい道具箱の中の道具です... 結局のところ、それらはすべて同じ目的を果たします。古き良き馬に乗り続けることができるのに、なぜ車を使うのでしょうか?

歴史は繰り返す

これは実際に私に何かを思い出させます。20世紀の初めに、自動車が馬に取って代わり始めました。1900年ニューヨークでは道路に車が数台しかありませんでしたが、人々は交通機関として馬を使っていました。1917年には、これ以上馬が道路に残っていませんでした。巨大な産業は、馬の輸送を中心としていました。厩肥の清掃などの事業を中心に、企業全体が生まれています。

そして人々は変化に抵抗しました。彼らは自動車を別の「流行」と呼び、やがてそれが通過します。結局のところ、馬は何世紀もの間ここにいました! 政府に介入を要求する人さえいました。

これはどのような意味がありますか? ソフトウェア業界はOOPを中心としています。何百万人もの人々がOOPの訓練を受けており、何百万もの企業がコードでOOPを利用しています。もちろん、彼らは自分の生活(bread-and-butter)を脅かすものは何でも嘘だとはねつけます。それが常識です。

私たちは、歴史がそれ自身を繰り返しているのをはっきりと見ています - 20世紀にはそれは馬対自動車でした、21世紀にはそれはオブジェクト指向vs関数型プログラミングです。

次は何ですか?

SlashdotHacker News