5/29/2020

2020年の開発者の調査結果 (Stack Overflow)

Stack Overflowのブログより

10回目の年次開発者アンケートの結果をお知らせできることをうれしく思います! 65,000人の開発者が、今日のソフトウェアの状況についての考えを共有しました。

ベン・ポッパー

数え方にもよりますが、Stack Overflowが毎年実施している開発者アンケートは、今年で10年目になります。ソフトウェア業界はこの10年間で大きく変化しましたが、少なくとも短期的には、今、世界全体が経験している公衆衛生の危機ほどは、それほど破壊的な単一のテクノロジーはなかったことも事実です。

この調査の結果は、約65,000人の開発者の意見と経験を反映しています。しかし、この調査はCOVID-19が世界的なパンデミックになり、世界中の国々がロックダウンが行われる前の2月に実施されたことに注意することが重要です。私たちは、このデータに反映されている興味深い統計や変更の一部を一般の人たちと共有したいと考えていますが、謙虚で現実的なものであることが重要であることも理解しています。同じ調査が今日行われた場合、開発者の回答の多くは大きく異なって見えるかも知れません。

とはいえ、2020年の開発者調査には、エキサイティングで興味深くて面白いハイライトがたくさんあります。詳しく見ていきましょう。

最愛の言語

Rustは、私たちが調査したプロの開発者の間で最も愛されている言語としてその地位を維持しました。とはいえ、調査に参加した開発者の大多数は、この言語に慣れていません。Rustがとても愛されている理由を理解したい方は、ここにあるトピックで詳しく説明しています。TL; DR – Rustはパフォーマンス、制御、メモリの安全性、そして大胆不敵な同時実行性を約束します – 特にシステム・プログラミングにとって魅力的な組み合わせです。また、線型(アフィン)型や衛生的なマクロなど、いくつかの興味深い機能が主流に取り入れられました。オープンな開発プロセスと相まって、多くのプログラマー(それを使用しないプログラマーでも)がRustを高く評価していることは理にかなっています。

その言語や技術を使って開発を行っていて、今後もそれを使用して開発を続けることに関心を示した開発者の割合

しかし、2番目の座では、今年の調査で興味深い変化が見られました。昨年は、PythonとTypeScriptは統計的なデッドヒートで銀メダルを分け合っていました。2020年には、TypeScriptの人気が急上昇し、Pythonが3位に留まっています。TypeScriptについて詳しく知りたい場合は、GlitchのJenn Schifferとの最近のポッドキャストを聞いてみて下さい。ポッドキャストで、Glitchが非常に人気のある言語になった理由を説明しています。

TypeScriptの人気が急上昇したことは、Microsoftの方向転換とオープンソース運動の採用を際立たせています。フロントエンドWebとNode.JSのコードベースのサイズと複雑さが増すにつれて、TypeScriptの静的型付けを採用することで、開発者はコードの正確性に対する信頼を高めることができます。TypeScriptは段階的な導入できるので、開発者はリスクの高い移植プロジェクトを行う必要がなく、すぐに利益を得ることができます。TypeScriptは最後の甘味料として、ブラウザーで広く利用可能になる前に、ECMAScriptの多くの変更(矢印関数、非同期、クラスなど)をポリフィルします。 Stack OverflowのJavaScriptの多くが、実際にTypeScriptに変換したものであることから、私たち自身も納得しています。

Pythonには静的型付けがありません(ヒントはありますが)。これは、トップ3の中で一風変わった存在になっています。Python2から3への移行について多くの議論が交わされているため、中には悪意のあるものがあるかも知れません。TypeScriptが急増し、Pythonが後退したと思う理由を下のコメント欄で教えて下さい。他の考えについては、以下の20分間の議論をチェックしてみて下さい。

オールド・フェイスフル、ニュー・スクール

サイト信頼性エンジニアとDevOpsのスペシャリストは、依然として個人の貢献者として最も高い報酬を得ている役割の1つです。回答者のほぼ80%がDevOpsが少なくともある程度重要であると考えており、44%が少なくとも1人の専任のDevOps従業員がいる組織で働いています。この傾向の理由は驚くことではありません。常時接続の時代に、ユーザは自分のアプリとサービスがいつでもどこでも利用できることを期待しています。そして、この調査はCOVID-19の広範囲にわたるロックダウンの前に実施されたことを思い出して下さい。多くのチームが突然完全にリモート化した世界では、DevOpsの重要がさらに高まると予想されます。

コーディングの問題で行き詰まった時にどのような手順を踏むかを尋ねたところ、回答者の90%がStack Overflowにアクセスすると回答しました。でもね、あなたは既に知っていたんですよね。コーディング問題の解決策を検索し、最初の結果として紫色のリンクが見つかった場合の感想を尋ねたところ、以前にもそのようなことがあったことが分かりました。幸いなことに、回答者の52%は「こんにちは、旧友」という温かい認識を感じたと答えました。一方で、以前に一度この回答を検索したのを忘れていたことに気付いて、イライラしたと答えたのはわずか14%でした。

Stack Overflowでソリューションを見つけることで、開発者の時間を節約できますが、開発者は多くの時間を仕事に費やしています。75%以上の開発者が、少なくとも時々残業すると答えています。25%は、週に1〜2日以上残業しています。世界中の開発者が在宅勤務に移行するにつれて、仕事と私生活の境界線を引き、両者のバランスを取ることが難しくなってきています。非同期で仕事をする方法を学ぶこと、社会的距離を置いて同僚と交流すること、そしてここStackでのテレワークを経験したベテランからのアドバイスをいくつか紹介しています。

別れの思い

多様性と一体性について進歩を続けていますが、まだ長い道のりがあります。今年の調査には65,000人以上の人が参加しました。Stack Overflowのネットワークの枠を超えて、より多様なプログラマからの回答を求めるために、私たちは例年よりも独自のチャンネルでの調査をこれまでよりも宣伝を減らし、サイトに頻繁に利用しないユーザから回答を得る方法を模索しました。このアプローチには、ソーシャル・プロモーションと、過小評価されているプログラマへの働きかけも含まれていました。

過小評価されたグループでは増加は見られましたが、代表の差は私たちが期待したほど大きくありませんでした。一部の人種・民族グループには増加が見られましたが、その他の人種や民族は同程度化減少しました。同様に、女性性別の回答者はわずかに増加しましたが、ノンバイナリー、ジェンダークエリ、またはノンコンフォーミングの回答者は変わらずでした。私たちには、まだやらなければならないことがたくさんあることを認識しており、年次調査で得られたデータは、私たちが変化を起こし、前進していくな中で、より歓迎されて包括的なものになるための目標を設定するのに役立っています。

今後もあらゆるプログラマとの関係改善に取り組んでいきたいと思います。今年の調査への回答では、15%以上の人が、Stack Overflowは少なくとも昨年より歓迎されていると感じています。これは引き続き私たちの組織の最優先事項のひとつであり、このニュースは心強いものです。

結果の詳細については、ここで詳しく紹介しています。いつものように、今年の調査の匿名化された結果は、まもなくOpen Database License(ODbL)の下で公開される予定です。

私たちの年次開発者調査は、通常、最も広く読まれているリリースの一つです。私たちは、今は多くの人々にとって困難な時期であり、世界中の人々が大きな混乱を感じていることを理解しています。Stack Overflowが引き続き皆さんにとって貴重なリソースとして機能し続け、このコミュニティがお互いをサポートし合うために団結できることを願っています。

Hacker NewsSlashdot

5/28/2020

ポートスキャンを実行しているWebサイト

シュナイアーのブログより。ブラウザにlocalhostへのポートスキャンをさせている、なぜ?

セキュリティ研究者のチャーリー・ベルマーは、eBayなどの商用Webサイトが訪問者のポートスキャンを実施していると報告しています

彼らがスキャンしているポートのリストを見て、彼らはホスト上で実行されているVNCサービスを探しています。これは、銀行サイトのために報告されたものと同じです。私は、ポートとそれらが知られているものを選び出しました(私がよく知らないポートはブランクになっています)。

  • 5900: VNC
  • 5901: VNC port 2
  • 5902: VNC port 3
  • 5903: VNC port 4
  • 5279:
  • 3389: Windows remote desktop / RDP
  • 5931: Ammy Admin remote desktop
  • 5939:
  • 5944:
  • 5950: WinVNC
  • 6039: X window system
  • 6040: X window system
  • 63333: TrippLite power alert UPS
  • 7070: RealAudio

理由を誰にも分からないようです。

私は自分の目を信じることはできませんでしたが、それはすぐに再現できました(私の観察については以下を参照して下さい)。

私はいくつかのサイトにサーフィンし、これを行っているサイトをもう1つ見つけました(Citibankのサイト、私の観察については以下を参照して下さい)

さらに、少なくともebay.comとcitibank.comでは、同じポートが同じ順序でスキャンしていることが分かります。これは、両方のサイトで使用されているライブラリが存在する可能性があることを意味します。 (私はこれまでこの問題をデバッグしていません。)

疑問は、

  • このポートスキャンは、何らかの標準のフィンガープリントやセキュリティ・ライブラリに組み込まれたものか? (もしそうなら、どのようなものか?)
  • このような動作をブロックできるFirefoxのプラグインはあるか? (またはそのようなブロッキングを既存のプラグインに追加できるか?)

私も興味があります。

神秘的な電波バーストは、宇宙のミッシング・マターの問題を明らかにする

Slashdotより

sciencehabitが伝えます。

宇宙論者によれば、宇宙の「普通の」物質のおよそ半分は、星、惑星、そして私たちを構成するもので、銀河間の空間に浮遊する物質のたなびきのようなものとして存在していると言います。しかし、これまで天文学者はそれを確認する良い方法を持っていませんでした。新しい研究では、高速電波バースト(FRB) - 遠い銀河から発せられる強力なミリ秒単位の電波パルス - を使用して銀河間の物質の重量を測定し、結果が予測と一致しています。「FRBをプローブとして使用することは、しばらくの間、エキサイティングな見通しでした」と、トロント大学の天文学者ポール・ショルツは言います。「今、私たちはローカルなFRBのサンプルを作り上げたので、これが実行できるようになりました。本当にエキサイティングです。」過去数十年に渡り、宇宙学者たちは宇宙を構成する物質の目録をまとめてきました。約68%は暗黒エネルギーであり、宇宙の膨張を加速させる謎の力です。さらに27%は、銀河をまとめる暗黒物質の塊です。いわゆる通常の物質はわずか5%です。

宇宙論者は、通常の物質がどれくらいあるべきかを知っています。彼らは、ビッグバンが生み出した筈の量を、まだ宇宙空間に響き渡っているこの宇宙イベントのマイクロ波の波紋からそれを計算できます。しかし、彼らは、銀河と高密度のガス雲として輝くその約半分しか見ることができません。残りの部分は、典型的なオフィスの一室にある原子1〜2個分に希薄化された銀河間ガスであり、これまでほとんど検出することができませんでした。これは、2007年の最初のFRBバーストまで不可能でした。このような散発的なバーストは非常に明るく短いため、FRBは当初、機器の不具合または地球上の発生源から発生したと考えられていました。(いくつかの初期の「FRB」は、展望台の電子レンジからのものであることが判明しました。) しかし、FRBの検出が増えるつれ、天文学者らは、それらが宇宙の遠く離れた場所から来ていることに気付きました。しかし、珍しいため、それらを正確に特定することは困難でした。観測者は、1つを捕らえるにも、正確に正しい方向に向けて捕まえる必要があり、他のスコープをソースに集中させる時間もありませんでした。最近では、空の大部分を連続的に見る望遠鏡が、より多くのFRBをまとめて手に入れています。

CDCによると、COVID-19の患者の死亡率の新しい「最良推定値」は0.4%

Slashdotより

匿名の読者がCNNのレポートを引用しています。

米国疾病対策管理センターは、数理モデルの作成者や公衆衛生当局者向けの新しいガイダンスで、新型コロナウイルスの感染症の約3分の1は無症候性であると推定しています。CDCはまた、その「最良推定値 (best estimate)」は、症状を示すCovid-19患者の0.4%が死亡するだろうと述べています。そして、新型コロナウイルスへの感染の40%は、症状が出る前に起こっていると推定しています。

CDCによると、この数値は「連邦政府全体の数学モデラーによって使用されている」5つの計画シナリオの一部です。これらのシナリオのうちの4つは、「病気の重症度とウイルス感染性の下限と上限」を表しています。5番目のシナリオは、CDCの「米国におけるウイルス感染と病気の重症度に関する現在の最良推定値」です。そのシナリオでは、CDCはCovid-19で症状が出た人の0.4%が死ぬだろうとの推定を説明しています。65歳以上の場合、CDCはその数を1.3%としています。49歳以下の人については、症状のある人の0.05%が死亡すると推定しました。

CDCは、これらの数値は4月29日以前に政府機関が収集した実際のデータに基づいており、変更される可能性があることを警告しています。それでも、0.4%という「現在の最良推定値」の数値は、世界保健機関が3月上旬に警告した3.4%の死亡率よりも大幅に低くなっています。

「私が見たところ、「最良推定」は極めて楽観的であり、『最悪の場合』のシナリオは最良推定値であったとしてもかなり楽観的である。確かに、より悪いシナリオを検討したいと思うだろう。」と、ワシントン大学の生物学者カール・バーグストロムはCNNに言いました。「これらをモデリングのための公式パラメーターセットとして導入することにより、CDCは連邦政府機関が作成するモデルに影響を与えるだけでなく、今後のモデリング論文でCDC標準パラメーターセットを使用するように圧力を掛ける事になるため、より広範な科学的議論にも影響を与えている。」と同氏は述べています。「これらのパラメーターセットは、現在の科学的コンセンサスと比較して、致死率を大幅に過小評価していることを考えると、これは非常に問題がある。」

更新: 科学者らは低過ぎると言っているとのこと(BuzzFeed, Hacker News)。

5/27/2020

恐怖と集団思考が、不必要な世界的ロックダウンを引き起こした?

RealClear PoliticsよりSlashdotでも取り上げられている。

By イノン・ワイス

欠陥のあるモデルへの依存

新しいウイルスの脅威に直面して、中国は国民を厳しく取り締まりました。学者は、 間違った情報を利用して、欠陥のあるモデルを作りました。指導者たちはこれらの欠陥のあるモデルに頼りました。反対意見は隠されました。メディアは恐怖を煽り、世界はパニックに陥りました。

それは、史上最大の医療・経済上の失敗の1つとして知られるようになるかも知れない話です。集団思考に疑問を呈するために、1国を除いて、集団思考に疑問を呈する全ての西洋諸国が集団的失敗は、今後数十年間、経済学者、医師、心理学者によって確実に研究されるでしょう。

物事の見通しを立てるために、ウイルスは現在、65歳未満のほとんどの人の感染致死率は、1日あたり13〜101マイルの運転するよりも危険ではないことが知られています。控えめに見積もっても、COVID-19の致死率は、既存のベースラインの死亡率とほぼ一致しています。

それでも、私たちは数十億人の健康な若者を自宅軟禁し、がん検診を停止し、大恐慌以来の最悪の失業率に陥っています。これは、50歳未満の健康な人であれば、99.99%の生存率を有するウイルスなのです(1, 2)。

ニューヨーク市の感染率は、25%以上に達しましたが、45歳未満の全市民の99.98%が生存しており、これは通常の事故による死亡率に匹敵しています。

しかし、もちろん、ロックダウンの議論の要点は、このような措置を行わなければ、さらに悪化していたであろうということです。スウェーデンは国境、小学校、レストラン、企業を閉鎖したことはなく、マスクを義務付けたこともありませんでしたが、60歳未満のすべての人々の99.998%が生存しており、病院は過密にはなりませんでした。

なぜ、大きなリスクを負うことのなかった大多数の人々をロックダウンしたのでしょうか? 副次的な被害(コラテラル・ダメージ)はどうだったのか? それをこのシリーズで探求していきたいと思います。

専門家は早い段階で慎重なアプローチを取った

2月上旬、世界保健機関は渡航禁止は必要ではないと言いました。2月17日、米国での最初のロックダウンのちょうど1か月前に、国立アレルギー感染症研究所の長年の責任者であるアンソニー・ファウチ博士は、この新型コロナウイルスは、米国に対する危険性は「ごくわずか」であると述べました。3月上旬、米国の外科医長は、「マスクは一般市民が新型コロナウイルスの感染を防ぐのに有効ではない」と述べました。イタリアがロックダウンを開始した3月9日の遅くまで、ファウチ博士は「コミュニティが広がっている場所であっても、大規模な集会を中止することは勧めず、『個人的意見 (a judgment call)』と言いました。NBAの試合はまだ行われていました。

では、どのようにして、このような慎重な口調から、一夜にして、アメリカ人の97%を自宅軟禁にすることになったのでしょうか?

誤った仮定と誤ったモデルを入力する

中国はウイルスの発生の規模を隠していましたが、このデータを信じた多くの科学者は感染した患者の2%から5%が死亡すると信じました。これは10分の1で外れていたことが判明しました、しかし、学術的な疫学者は、今までも破滅的な週末予測を行なってきた歴史があります。

インペリアル・カレッジの疫学者ニール・ファーガソンによる3月16日の報告書は、イギリスをロックダウンさせ、世界的なロックダウンのドミノ効果に貢献したとされています(または非難されています)。それ以来、このモデルは「全く信頼できず、バグだらけ」であるという激しい批判にさらされています。

これは、2005年に鳥インフルエンザで2億人が死亡すると予測したニール・ファーガソンと同じです。過去15年間の総死亡者数は455人でした。これは、2009年にイギリスで豚インフルエンザで65,000人が死亡する予測したニール・ファーガソンと同じです。最終的な数は392人程度でした。2020年には、50万人のイギリス人が新型コロナウイルスで死亡すると予測しました。

彼のモデルには、深い欠陥があり、アメリカは200万人以上の死を恐れ、ほぼ国全体をロックダウンすることを正当化するために使用されました。ファーガソン博士はシェイクスピアの劇や悲劇の登場人物です。皮肉にも行動を起こすための切実な必要性に関する彼の3月17日のプレゼンテーションは、ファーガソン氏自身が2日後にCOVID-19に対して陽性反応を示したため、ボリス・ジョンソンや他のイギリスの高官たちを感染させた可能性があります。彼は、既婚女性と密かに会うために彼自身が隔離規則を破り、5月に不評を招いて辞任しました。

しかし、私はファーガソンのような人に責任を負わせません。あなたがハンマーであれば、すべてが釘のように見えます。政府の指導者たちが、多様な視点を持ち、自分自身で批判的に考えることに失敗したことを非難します。

政治家たちは、ロックダウンのおかげで死者が減ったと主張している

市民に隔離を強要するのは、後になってそれがすべて大失敗だったと認めることになるため非常に恥ずかしいことです。そのため、政治家やモデル作成者は、死亡率の低下がロックダウン自体に基づいていると主張するのが簡単なのです。これは成功だった!

しかし、いくつかの不都合な心配の種がその物語を破裂させ続けています。そして、スウェーデン以上の存在はありません。西側で唯一、市民をロックダウンさせなかった国です。スウェーデンは国境、レストラン、企業、学校をロックダウンしませんでした。当局が取った唯一の法的措置は、50人を超える集まりを伴うイベントを禁止することでした。

米国で最もよく知られ、評判の高いモデルの1つは、Institute for Health Metrics and Evaluationのものであり、一般にホワイトハウスが引用しています。IHMEモデルは、ロックダウンと社会的距離、あるいはその欠如を考慮に入れているため、彼らはスウェーデンでの予測によって検証されるべきです。

以下は、5月3日に撮影されたスウェーデンのIHMEモデルのスクリーンショットで、実際の結果(黒い線)と共に示されています。このモデルでは、スウェーデンが厳密な社会的距離を保つための措置を講じなかった場合、11日以内に毎日2,800人が死亡すると予測し、最終的な死者の合計は75,000人にもなると予測しています。

これらは複雑な長期予測ではなく、数ヶ月分のデータに基づいて今後2週間で何が起こるかを予測したものです。しかし、1日の死亡者のピークはベースライン予測より75%も低く、最悪の場合の予測より96%低くなりました。

ウプサラ大学(スウェーデンで最古の大学)も負けず劣らず、イギリスと同様にスウェーデンがコースを放棄してロックダウンする可能性のあるモデルを提示しました。しかし、スウェーデンは屈しませんでした。ウプサラ大学のモデルでは、1か月で9万人の死者数が予測されましたが、実際の結果は約3,500人程度でした。

死者数以外にも、病院の収容能力に関する終末的な予測もありましたが、それらのモデルは著しく誇張されたものであることも判明しました。3月29日、コロンビア大学はニューヨーク市で13万6千床の病院用ベッドの必要性を予測しました。これまでに使用された最大値は1万2千床以下でした。ピーク時には、ニューヨーク市はまだ6分の1の病院のベッドが、10分の1のICUベッドが開いていました。ニューヨーク市とスウェーデンの両方の病院にはまだ収容能力がありました。

スウェーデンの短期的な結果は予測をはるかに下回っていますが、ノルウェー、フィンランド、デンマークよりは悪いのですが、イギリス、フランス、スペイン、イタリア、ベルギーよりは良いです。スウェーデンはまた、長期的な集団免疫、より速い経済回復、ロックダウンの巻き添え被害による死亡者数の減少からも恩恵を得ている可能性が高いです。

政治指導者たちは、初期の証拠が自分たちのモデルと矛盾している場合、それを無視した

このような結果を早い段階で知ることができなかったと言う人もいるので、後になってロックダウンが不当なものになったとしても、情報不足のために早くから必要だったのではないかという意見がありますが、それは明らかに誤りです。イタリアの驚くべき死者数は、世界中の初期の恐怖を煽りましたが、3月17日までにイタリアの死者数の中央値は80歳以上で、30歳未満の死者数は一人もいなかったことは明らかでした。さらに、亡くなった人の99%が他の持病を患っていることも分かっていました。

より合理的な戦略は、老人ホームを封鎖し、健康な若者は外に出て、免疫を付けることでした。そうではなく、私たちは反対のことをしてきました。COVID-19の患者を老人ホームに強制的に連れて行き、そして若者を軟禁しました。

カリフォルニア州のサンタクララ郡のような場所があります。人工呼吸器を使っていないCOVID-19の患者が病院の収容能力の2%未満しか占めていないのに、ロックダウンが3か月目に突入しています。まだ、実質的に自宅軟禁下にある200万人の市民がいます。この地域の一部の医師や看護師は、病院が破産を回避できるように給与を20%カットしました。おそらくこの無意味な大惨事の縮図を反映しています。

そこには、もちろん、人々は全てに沿って私たちに警告していました。その中には、Google Scholarで世界で最も引用されている100人の科学者にランクされているスタンフォード大学医学部のジョン・P・A・イオアニディスも含まれています。3月17日の重要な日に、彼は「起きつつある大失態? コロナウイルスのパンデミックが定着するにつれ、私たちは信頼できるデータが無いまま意思決定を行っている」—と題するエッセイを発表しました。しかし、ほとんど注目されませんでした。主流メディアは、良いニュースや反対意見に興味を示しませんでした。その代わりに、世界は人為的な災害へと一歩一歩踏み込みました。

イノン・ワイスは、技術系起業家、米軍退役軍人であり、教育を受けたバイオ・エンジニアでもあります。

2020年、AndroidのIPv6はまだ壊れています

Daniels Networking Blogより

TwitterでIPv6についての興味深い議論になりました。その後、誰かが、Android OSバージョン11でDHCPv6をサポートするかを尋ねました。

IP networks @rtaccon · May 21, 2020
Replying to @danieldibswe
AndroidはDHCPv6をサポートしておらず、Googleは「修正しない (Won’t Fix)」としています。2012年以降、Googleの公開「Issue Tracker」で、AndroidのDHCPv6サポートを求めるチケットが公開されましたが、11月6日に問題のステータスが「修正しない(意図された動作)」に変更されました。
https://issuetracker.google.com/issues/36949085
IP networks
@rtaccon
@Enno_Insinuator @ehorley
@androidがAndroid 11でDHCPv6をサポートするかどうか知っていますか?

最初にRFC 2460でIPv6が開発された際、次のような考えがありました。

IPv4について学んだことをすべて忘れ、IPv6を一から設計する

これは理論的には良さそうに聞こえますが、IPv4から学んだ教訓を完全に無視しています。言うまでもなく、グリーンフィールドのようなものは存在しません。ほとんどすべてのネットワークは既存のものであり、最初からやり直すことはできません。エンド・ツー・エンドの接続性、どこでも/64、SLAACのみが許可されているという非常に輝く目的がありました。「戦争がなかったらいいのに」と言っているようなものですが、残念ながら人々は愚かであり、戦争は起こります。そこには、成長していくティーンエイジャーに似たナイーブさがあります。あなたは世界を変えたいと思っても、現実世界は、お金と巨大企業と汚い政治家によって運営されていることに気付くでしょう。

この混乱全体は、SLAAC + RDNSSとDHCPv6の聖なる戦争につながりました。SLAACは当初、DNSサーバーを設定するオプションすらなかったことに注意して下さい。基本的に、これは部分的な実装しか持っていなかったことを意味します。DNSサーバがあるとかなり便利ですが…。当初、Microsoftのオペレーティング・システムはSLAACをサポートしていましたが、RDNSSはサポートしていませんでした。AndroidはDHCPv6のサポートをしたくありませんでした。つまり、同じサブネット上でこれら2つのオペレーティング・システムを同時にサポートすることはできないということでした。

驚いたことに、2020年になってもAndroidのIPv6実装はまだ壊れています。設計上、 彼らはそれを修正するつもりはありません。Googleとロレンツォ・コリッティからいくつかの有効な議論がありますが、それらはかなり弱いです。皮肉なのは、人々はそれを求めているが、Googleはそれを実装しようとはしていないということです。彼らは喜んであなたをスパイし、あなたに広告を出し、あなたのデータを販売しますが、DHCPv6を実行するのを許すことはあなたに害を及ぼすでしょう。

SLAACが動作すること、そしてかなり大規模な環境でも動作することは間違いありませんが、それでもDHCPv6の方が優れていると思います。ここでの誤りは、多くのIPv6エバンジェリストがビジネス要件を無視して浮世離れした見方をしていることです。どのホストがどのIPをいつ持ったかを追跡する必要があるビジネス要件とコンプライアンス要件があります。また、企業は愚かなことをします。それはまさに事実です。あなたが何をするかを決めるのはGoogleではありません。

もちろん、SLAACとDHCPv6の両方を同時に実行することもできますが、なぜでしょうか? 上記のGoogleのスレッドを読むと、多くの人が多くの時間を無駄にしており、DHCPv6の実装を望んでいるという理由や、非常に有効なビジネス上の理由があることが分かります。ここにいくつか紹介します。

  • megacorp.comなどのサフィックスを割り当てる機能
  • ホストをDNSに登録する
  • 特定の時間にどのIPがどのホストにあったかを追跡する
  • PXEを介したイメージの展開(DHCPオプションを検討)
  • WLCなどで使用されるその他のDHCPオプション
  • ネットワーク全体でDNSサーバーを簡単に交換できる機能(Umbrellaの展開を考えてください)
  • RADIUSサーバーにDHCPリクエストを表示させるDot1Xの展開
  • IP電話への対応が必要である

いくつかの使用例には回避策があると確信していますが、私が言いたいの次のとおりです。企業はDHCPv6、Googleを必要といています。またはその事については誰でもいいのですが、手元にある選択肢を押し付けるべきではありません。従って、残念ながら、2020年になっても、Androidはまだ壊れたIPv6の実装なのです。

Hacker News

カフェイン: ビタミンのような栄養素、またはアダプトゲン(適応促進薬)

Ray Peatのブログより

お茶とコーヒー、癌などの変性疾患、そしてホルモンについての疑問。

栄養に関する誤った考えを広める大衆向けの健康文化が流行っており、コーヒーを飲むことがこの文化の長年の根強い標的になっています。コーヒーは食品ではなく薬物であり、その薬物作用は有害であり、この害はいかなる栄養上の利益によっても補われないと一般に言われています。ほとんどの医師は、コーヒーに関するこれらの「常識的」な考えのほとんどに同意し、コーヒーに関する科学的情報の吸収に対する権威ある障壁を形成します。

私は、ダイエットやヘルスケアにおけるコーヒーの位置づけを再考してみるのも良いことだと思います。

コーヒーを飲む人は、癌を含む甲状腺疾患の発生率が、飲酒しない人よりも低いです。

カフェインはアルコールやアセトアミノフェン(タイレノール)などの毒素から肝臓を保護します。コーヒーを飲んでいる人は、コーヒーを飲まない人よりも血清酵素の上昇や肝障害の他の兆候を示す可能性が低くなります。

カフェインは、放射線、化学性発がん物質、ウイルス、エストロゲンによって引き起こされる癌を予防します。

カフェインはプロゲステロンと相乗作用し、血液や組織中の濃度を高めます。

嚢胞性乳房疾はカフェインが原因ではなく、実際にはカフェインの効果は保護する可能性が高く、様々な研究により、コーヒー、紅茶、カフェインが乳がんに対して保護することが示されています。

コーヒーにはマグネシウムだけでなく、ビタミンB1を含む他の栄養素も非常に多く含まれています。

カフェインは「燃料使用効率とパフォーマンスを向上させます」: J・C・ワグナー1989。

コーヒーを飲む人は自殺の発生率が低い。

カフェインは神経へのセロトニンの取り込みをサポートし、血小板の凝集を抑制します。

コーヒーを飲む人は体内のカドミウムが低いことが分かっています。コーヒー作りは水から重金属を取り除きます。

コーヒーは食事と一緒に摂取すると鉄分の吸収を抑制し、鉄分の過剰摂取を防ぐのに役立ちます。

カフェインはナイアシンのように、正常な細胞の代謝回転を妨げることなく、ストレスによって誘発される細胞死を防ぎ、アポトーシスを抑制します。

カフェインは神経細胞の死を防ぐことができます。

コーヒー(またはカフェイン)は、パーキンソン病を予防します(ロスら、2000)。

カフェインを大量に摂取させることによって引き起こされる出生前の成長遅延は、食事に糖分を補給することによって防ぐことができます。

カフェインは、組織ストレスの重要な要素であるキサンチン・オキシダーゼを阻害することで、フリーラジカルの生成を停止させます。

カフェインは運動後に血清カリウムを低下させます。血小板を安定させ、トロンボキサンの産生を減少させます。

ビタミンの定義としては、それが食品に含まれる有機化学物質で、不足すると特定の疾患または疾患群を引き起こすことです。ビタミンであることが提案されている様々な物質は必須であると認識されておらず、必須ではないいくつかの物質はしばしばビタミンと呼ばれます。これらの問題は科学的調査が十分に行われていないこともありますが、非科学的な力が栄養学的な考えを規制していることも少なくありません。

「病気」の定義は、教科書を書く人が示唆するほど明確ではありませんし、生物学における「因果関係」は、私たちが常に信じている以上に複雑なものです。

栄養学は最も重要な科学の1つであり、確かに宇宙物理学や核物理学と同じくらい権威があり、十分な資金が提供されるべきですが、人々は「それを理解するのに脳外科医は必要ない」と言いますが、誰も「それを理解するのに栄養士は必要ない」とは言いません。その理由の一部には、医学が科学的栄養学を違法な継子として扱い、科学的栄養学が科学的ヘルスケアの中心的部分であることを20世紀を通じて認めるのを拒否していたためです。1970年代には、医師や栄養士は、ビタミンEが循環器系の疾患を予防したり、治療したりできるという考えをいまだに馬鹿にしており、赤ちゃんだけでなく高齢者にも、生命、成長、免疫、治癒に不可欠な栄養素が不足している「完全静脈栄養」が与えられていました。医学と科学は強力に制度化されていますが、人々が合理的な行動を促すための制度や職業は存在していませんでした。

このような環境では、ほとんどの人が栄養学には、定義、論理、根拠の微妙な点は重要ではないと感じており、「4つの食品グループ」または「7つの食品グループ」または「栄養ピラミッド」なのかを決めることに多大なエネルギーが費やされて来ました。政府や準政府の栄養政策の背後にある動機は、医療機関がメキシコの赤ん坊が6か月の年齢に達したとき豆を食べ始めるべきであるか、離乳後に白人以外はミルクを必要としないと言うときのように、健康のための単純な科学的な懸念の他に何かを表しています。長期の母乳育児を敬遠する文化の中では、これらの教義の影響は深刻なものになりかねません。

科学的栄養学な世紀の後、公共の栄養政策は、ほぼ同じくらいの害を及ぼしており、彼らは良くなるというよりも早く悪化しています…。

この文化にの中で、私たちが切実に必要としているのは、人生の複雑さ、そして私たち自身がいる政治的生態学的状況の認識です。「システム思考」ではない思考は、注意深く扱われるべきです。健康についてのほとんどの現代的な思考は、問題システムの関連する部分を考慮することを怠っています。塩、コレステロール、鉄、不飽和脂肪、飽和脂肪、大豆に関する「公式の」推奨事項は、一般に不適切で非科学的で、生物学的知識よりもビジネス上の関心によって強く動機付けられてきました。

これまでの定義では、栄養素と薬物を明確に区別することはほとんどありませんでしたが、新しい商業的動機がその区別をさらに曖昧にするのを促進しています。

必須栄養素、防御(解毒、抗ストレス)栄養素、ホルモン調節栄養素、自己実現栄養素、成長調節栄養素、構造調整剤、寿命延長剤、トランスジェネレーション活性(刷り込み)栄養素など、栄養素と生物学的調整剤の間の線は状況によって異なることが多いです。ビタミンDやAには明らかにホルモンのような特性がありますし、ビタミンEの効果や食品に含まれる多くのテルペノイド、ステロイド、バイオフラボノイドには、ホルモンのような作用だけでなく、抗酸化作用と酸化促進作用も含まれています。「アダプトゲン」の概念には、薬のような働きをするものと栄養素のような働きをするもののが含まれます。

一部の研究では、微量の栄養素が数世代にわたって受け継がれる可能性があることを示唆していますが、現在では、このような世代を超えた影響は「刷り込み(imprinting)」のような現象によって引き起こされていることが証拠によって示されています。しかし、栄養素の遺伝的影響は非常に複雑であるため、その認識は、成長と発達の複雑さを織り交ぜた最も複雑な科学の1つとして認識させるでしょう。

不十分な栄養は成長を妨げるという考えは、最終的に到達する成長率とサイズの面から良い栄養を定義できるという考えにつながりました。医学では、あたかも食品の量と組織の量が必然的に良いものであるかのように、「よく栄養を与えられた」として肥満の標本を参照するのが一般的です。しかし、毒物が成長を刺激し(「ホルミシス」)、食事制限は寿命を延ばす可能性があります。それでも、最適な成長率や最適なサイズなどの基本的なことを決定する必要があります。

栄養学の教科書では、カフェインは栄養素ではなく薬物であると明確に記述されており、まるで栄養素が薬物ではなり得ないことが明らかであるかのように扱われています。必須栄養素のいずれかを単独で使用すると、通常の食品の成分として食べた場合に通常は持っていなかった生物への特定の効果のために、薬物として使用できます。そして、自然食品には、必須栄養素以外に何千もの化学物質が含まれています。これらの多くは非必須栄養素と呼ばれていますが、その重要性はますます認識されきています。真実は、それらが何のために「必須ではない」のか、よく分からないということです。生物についての明確な知識が得られるまで、私は薬や栄養素のように絶対に分類すべきではないと思います。

コーヒーに起因する悪影響は通常、短期間に大量に摂取することです。カフェインは一般に血圧を上昇させると言われていますが、この効果はわずかであり、通常のコーヒーの使用中には発生しない可能性があります。実験者は通常、重要な要素を無視します。普通の水を飲むと、特に高齢者では血圧が極端に上昇する可能性があり、食事(炭水化物を含む)を食べると血圧が下がります。カフェインが作り出す代謝率の上昇は、グルコースの細胞消費を増加させるので、空腹時のコーヒー摂取の効果を研究する実験では、アドレナリンの増加(グルコースの減少による)と組み合わせて、体温と代謝率の増加の影響を測定しており、カフェイン固有の効果の問題を混乱させているのです。

ある研究では(Krasil’nikov, 1975)、脳の血管への影響を研究するために、薬物が頸動脈に直接導入されました。カフェインは血管の抵抗を減らしながら、脳の血液量を増加させました。この効果は脳代謝の刺激とその結果としての血管を拡張する二酸化炭素の増加から期待されるものです。

全身の場合、二酸化炭素の増加により血管抵抗も減少します。これにより、循環は増加しますが、送り出される血液の量に比べて、心臓の働きは低下します。しかし、全身の代謝が上がるため、十分な栄養が重要になってきます。

妊娠中の女性がコーヒーを飲んではならないと主張するために使用されてきた動物実験では、妊娠中の動物に大量のカフェインを投与すると、胎児の成長が遅れるという結果が出ています。しかし、単に多くのショ糖を与えるだけで成長の遅れを防ぐことができました。カフェインは妊娠を妨げる可能性のあるいくつかの代謝問題を修正する傾向があるので、合理的に組み立ててられた実験は、例えばビリルビンとセロトニンを下げ、低血糖を防ぎ、子宮灌流を増やすことによって、プロゲステロン合成、甲状腺およびコルチゾールと相乗作用して肺の成熟を促進し、追加の栄養素を提供など、母親がコーヒーを使用することで胎児に利益をもたらす可能性があります。

カフェインについて最も一般的な誤解の1つは、それが線維嚢胞性乳房疾患を引き起こすということです。いくつかのグループは、そうではないことをかなりはっきりと示しました。しかし、彼らは、驚くほど無能だが、非常に広く知られている、オハイオ州立大学のJ・P・ミントンによるその種の古典的な一連の論文を除いて、悩まなければならない理由はありませんでした。ミントンは、健康な乳房に脂肪が高い割合で含まれており、炎症を起こして罹患している乳房に腺状物質の割合が増加していることに気付かず放置していました。脂肪細胞は、低レベルのサイクリックAMPを持っています。これは、正常な細胞分化に関連する調節物質で、癌細胞の増殖を阻害するカフェインの能力を仲介することに関与しています。ミントンは、乳房の病気の程度が癌に至るまでcAMPが段階的に増加し、カフェインによってcAMPが増加すると主張しました。癌細胞(および正常な乳房細胞)の成長を阻害するカフェイン以外の様々な物質は、サイクリックAMPの量を増やすことによって作用し、エストロゲンはcAMPの量を減らして細胞の増殖を促進します。ミントンの主張は、証拠から論理的に論じているのであれば、乳房の病気の程度に比例して、カフェインを多めに使うべきでした。カフェインの乳房に対する影響は、エストロゲンの効果に反して、プロゲステロンの効果に似ています。

過去30年間の多くの研究は、カフェインが乳房のエストロゲンの発がん性の影響を含むあらゆる種類の発がん性に対して非常に保護的であることが示されています。カフェインは現在、いくつかの標準的な癌治療の効果を改善したり、副作用を減らすために一緒に使用されています。コーヒーの実には、カフェイン以外にも突然変異や癌を防ぐ物質があり、癌に対して強力な治療効果を示しています。多くの植物性の物質には突然変異や癌に対する保護がありますが、私はコーヒーほどの副作用がないものを知りません。

カフェインについて話をするには、尿酸についても話をする必要があります。体内で合成される尿酸は、興奮剤であると同時に、非常に重要な抗酸化物質であり、その構造はカフェインと非常によく似ています。尿酸の欠乏は深刻な問題です。カフェインと尿酸は、プリンと呼ばれる化学物質のグループに属しています。

プリン体は(ピリミジンとともに)、核酸、DNA、RNAの構成成分ですが、それ以外にも多くの機能があります。一般的に、プリン体に関連する物質は興奮剤であり、ピリミジンに関連する物質は鎮静剤です。

基本的なプリン構造が酸化されると、酸素原子の追加により、ヒポキサンチン、キサンチン、尿酸となります。プリン環の窒素にメチル基(CH3)が付加されると、分子は水溶性が低くなります。キサンチン(プリン代謝の中間体)には2つの酸素原子があり、3つのメチル基が追加されると、トリメチルキサンチン(カフェイン)になります。メチル基が2つあるとテオフィリンになり、お茶に含まれることから名付けられました。私たちには、メチル基を追加および削除できる酵素システムがあります。例えば、赤ちゃんにテオフィリンが投与されると、テオフィリンはカフェインに変換することができます。

私たちは、カフェインと他のプリン誘導体のメチル基と酸素原子のすべてを変更できる酵素を持っています。カフェインは通常、例えばメチル化された尿酸などの変更された形で排泄されます。

尿酸が「抗酸化剤」として機能する方法の1つは、ストレス下でフリーラジカルの危険な発生源になる可能性がある酵素キサンチンオキシダーゼの活性を変更することです。カフェインもこの酵素を抑制します。尿酸とカフェイン(および様々な中間キサンチン)が酸化的損傷から保護する方法は他にもいくつかあります。例えば、コーヒーを飲む人は、コーヒーを飲まない人よりも腎臓のカドミウムのレベルが低いことが分かっており、コーヒーは腸での鉄の吸収を抑制し、鉄分の過剰摂取を防ぐのに役立ちます。

毒素やストレス因子は、多くの場合、脳、肝臓、免疫系などの細胞を殺し、細胞が交換されるよりも早くエネルギーを消費してしまいます。「PARP」と呼ばれる遺伝子損傷を修復する酵素システムがあります。この酵素の活性化は、主要なエネルギー消耗であり、それを阻害する物質は細胞の死を防ぐことができます。ナイアシンとカフェインは、この酵素を十分に阻害して、正常な細胞代謝回転を妨げることなく、この特徴的な種類の細胞死を防ぐことができます。つまり、不要な細胞の死を防ぐことで腫瘍を発生させません。

プリン体は様々な調整過程で重要な役割を果たしており、カフェインは他の方法でこの複雑なシステムに適合し、ストレスから保護します。例えば、お茶は異常な血液凝固を防止することで循環器系疾患を防ぐことができると提唱されており、そのメカニズムはカフェイン(またはテオフィリン)がストレス誘発性血小板凝集を抑制する傾向があるようです。

血小板が凝集すると、血栓の発生に寄与する様々な要因が放出されます。セロトニンはこれらの1つであり、肥満細胞、好塩基球、神経細胞など他の種類の細胞からも放出されます。セロトニンは血管のけいれんを引き起こし、血圧の上昇、血管の漏出と炎症、および他の多くのストレスメディエーターの放出を引き起こします。カフェインは、血小板凝集を阻害するだけでなく、セロトニンの放出を阻害したり、セロトニンの取り込みと結合を促進する傾向があります。

J・W・デイビスらは1996年、高い尿酸値レベルがパーキンソン病の進行を防ぐように見えることを発見しました。彼らはこの効果を尿酸の抗酸化機能に起因するとしていました。それでも、尿酸レベルを低下させるコーヒーの飲用は、尿酸よりもパーキンソン病に対してはるかに強力に保護するように見えました。

コーヒーの健康を守る働きよりも重要なのは、おそらくその方法です。コーヒーが有害であることを示す証拠を集めようとして、その逆を発見した研究は、いくつかの病気への洞察を提供しました。例えば、コーヒーのセロトニンへの影響は、二酸化炭素や甲状腺ホルモンと非常によく似ています。コーヒーの飲酒がパーキンソン病の発生率が低いことに関連していることに気づくと、甲状腺と二酸化炭素、セロトニン、エストロゲン、肥満細胞、ヒスタミン、血液凝固が相互作用して神経細胞死を引き起こす方法に注目が集まる可能性があります。

カフェインがどのようにして、このような広範囲の問題に有益であるかについて考えることは、それらの根底にある生理学と生化学の類似性についての視点を与えることができ、ストレス、生物学的エネルギー、適応性の影響を拡大することができます。

例えば、コーヒーを飲む人は自殺の発生率が低いという観察は、「セロトニン再取り込み阻害剤」と呼ばれる新しい抗うつ薬を使用している人々の自殺率の大幅な増加と生理学的に関連している可能性があります。セロトニンの過剰は、学習の無力感や代謝率の低下など、うつ病のいくつかの特徴を引き起こし、コーヒーはセロトニンの取り込み(不活性化または貯蔵)を刺激し、代謝エネルギーを高め、気分を改善する傾向があります。動物実験では、無力感や絶望の状態を逆転させ、いわゆる抗うつ薬よりも効果的なことが多いです。

カフェインの血圧への影響、より活発に代謝する細胞による燃料の使用に関する研究では、呼吸と栄養への影響は明らかにされていませんが、これらの実験の中には、コーヒーを飲む人が通常自分で学んでいることを確認しています。

しばしば、低血糖の症状を持っていると思っている女性は、最低限の量のコーヒーを飲んでも不安で揺れていると言います。時々、私は、食事と一緒にクリームまたは牛乳と一緒に約2オンスのコーヒーを飲むようにしてはどうかと提案しました。これにより、低血糖の症状が軽減され、食事の合間に症状がなくなることがよくあります。カフェインがアスリートの持久力を改善する理由は正確には分かっていませんが、コーヒーが通常の活動で人の「持久力」を高める場合も同じプロセスが関係していると思います。

カフェインは、甲状腺とプロゲステロンに顕著な類似点があり、コーヒーやお茶の使用はそれらの生産を維持するか、またはそれらの不足を補うのを助けることができます。 女性は月経前に自発的により多くのコーヒーを飲み、カフェインは血中および脳内のプロゲステロンの濃度を増加させることが知られているので、これは自発的かつ合理的な形態のセルフメディケーションです。医学編集者は、因果関係が逆転したものを見て、実際に緩和している症状のためにコーヒーを飲むことを非難するのが好きです。一部の女性は、コーヒーと一緒にプロゲステロンサプリメント摂取すると効果が強くなることに気づきました。これは、おそらくカフェイン関与している甲状腺とプロゲステロンの間の相乗効果に似ています。これは甲状腺とプロゲステロンの相乗効果に似ていて、カフェインは様々なメカニズムで甲状腺の分泌を局所的に活性化する傾向があり、例えばサイクリックAMPを増加させたり、甲状腺細胞内のセロトニンを減少させたり、また全身のストレスメディエーターを低下させたりするので、おそらくこれが関与していると考えられています。

医学編集者は、たとえ科学的にゴミであったとしても、重要な偏見を補強する記事を公開したがります。悪いアイデアの勢いは、おそらく、その開発に費やされた大量の光沢のある紙の量によって測ることができます。環境のためにも、編集者が固定観念ではなく、証拠や生物学的メカニズムの観点から考えるようにしてくれるといいのですが。

参考文献

省略

Hacker News

ユニカーネル: Linux支配の次のステージ

acm.orgより

概要

ユニカーネルは、多くの重要な領域でLinuxよりもはるかに優れていることを実証しており、Linux支配の時代が終焉を迎えるかも知れないと提唱する人もいます。それどころか、ユニカーネルの利点はLinuxの次の自然な進化を表すものであると信じています。ユニカーネルのアプローチから最高のアイデアを採用することができ、実戦でテストされたコードベースと大規模なオープンソース・コミュニティとともに、Linux支配を続けることができるからです。この論文では、アップストリーム可能なユニカーネルのターゲットがLinuxカーネルで実現可能なことを示し、初期のLinuxユニカーネル・プロトタイプを通じて、簡単な変更をいくつか加えるだけで、劇的なパフォーマンス向上の利点をもたらすことを示します。

1. はじめに

Linuxは、今日のコンピュータ・システムのほとんど全ての種類の創造可能なOSの中で支配的な存在になっています。Linuxは、何十億もの人々のポケットの中に、何百万もの家で、車で、飛行機で、宇宙船で[15]実行されており、ネットワーク全体に組み込まれており、上位500のスーパーコンピュータ[2]で実行されています。 これを達成するために、Linuxカーネルは、ハイパーバイザ、リアルタイムOS、SDNルータ、コンテナ・ランタイム、BPF仮想マシン、およびEmacsのサポートレイヤーなど、幅広い機能をサポートし、継続的に拡張され続けています。このように増え続ける要件のセットと、それに伴う複雑さの増大[26]を考えると、ある疑問が生じます。単一のカーネルで、本当にこのような広範囲の条件とユースケースを効率的に処理できるのだろうか?

実際、Linuxカーネルの構造は、今日の多くの主要なユースケースにとって問題があるという証拠があります。まず、高性能なI/Oを必要とするアプリケーションは、カーネルをバイパスしてハードウェア・デバイスに無制限にアクセスするためにへの妨害されないアクセスするためにDPDK[4]やSPDK[5]などのフレームワークを使用します[14,28]。これらのアプリケーションの中で最もパフォーマンスに影響を受けるのは、Ceph[32]のようなインフラ・コンポーネントなど、展開のための専用マシン全体にすることが多いです。

クラウドでは、クライアントのワークロードはセキュリティのために専用の仮想マシン内で実行されます。これらのワークロードは、シングルプロセスの言語ランタイムに書き込まれ、VM間で並列にデプロイされるケースがますます増えています。このように、多くのユーザとプロセスのリソースを多重化するように設計されたカーネルは、代わりに多くのシングルユーザ、多くの場合シングルプロセスの環境に複製されています[31]。

それに応じて、ターゲット・アプリケーションを専用カーネルとリンクさせ、仮想または物理のハードウェアに直接展開するモデルであるライブラリOSやユニカーネルのアイデアを探求する研究システムが復活しています[12]。Linuxと比較して、ユニカーネルは、起動時間[22]、セキュリティ[33]、リソース使用率[24]、I/Oパフォーマンス[29]で大きな利点を実証しています。実際、ユニカーネルはサーバーレス・コンピューティングの新しいモデルに大きな期待が寄せられており、Linuxの優位性が間もなく終了を迎えるかも知れないと予測している人もいます[18]。

Linuxは、マルチプロセッサのスケーラビリティ[20]、仮想化[7]、プロセスのコンテナ化[25,30]など、多くの重要な側面で研究システムに遅れをとってきました。しかし、これらの各側面で、Linuxは追いついただけでなく、すぐに標準となりました。私たちは、ユニカーネルが次の自然な進化を遂げると考えています。Linuxは、研究用ユニカーネル・システムから得た最高のアイデアの一部を採用することができ、大規模なコミュニティと、テスト済みのコードベースとともに、現在および将来のドメイン全体の標準えあり続けることができます。

この論文では、Linux自体をユニカーネルに変換する、つまりアプリケーションのワークロードに不要と見なされるカーネル機能を回避またはバイパスしながら、ターゲット・アプリケーションを最適化されたユニカーネル・バイナリに構築するためにコードベース内にサポートを追加するというアイデアを探っています。予備的な結果ではありますが、私たちの初期の結果は、ユニカーネル・ターゲットがアプリケーションのパフォーマンスをすぐに向上させることを示唆しています。さらに、ユニカーネル・ターゲットをサポートするためにLinuxに加えられた必要な変更はほとんどなく、自己完結型であるため、アップストリームのコミュニティに受け入れられる可能性が高いと私たちは考えています。

まず、セクション2でユニカーネル・モデルの利点について詳しく説明します。次に、いくつかの設計目標について議論し、セクション3でLinuxをユニカーネルに適応させるために取ることができるいくつかのアプローチを検討し、セクション4で初期のプロトタイプのアプローチについて説明します。次に、セクション5で最適化の機会について、セクション6では研究課題について議論します。

2. ユニカーネル

ユニカーネルは、アプリケーションをオペレーティング・システム・コンポーネントのライブラリ(メモリ管理、スケジューラ、ネットワークスタック、デバイスドライバーを含む)と単一のフラットアドレス空間にリンクし、スタンドアロンのバイナリイメージを作成する、クラシック・システム・テクニックのクラウド時代の手段です[22]。このアプローチの利点は、アプリケーションのパフォーマンスを向上させたり、非常に制限された実行領域内でサポートしたりするために、ターゲットアプリケーションのニーズに合わせてカーネル機能を特化できることです。

近年、新しいユニカーネル・システムの数が増加しており、そのほとんどがクラウドやインターネットのワークロードを対象としています。簡素化されたIOパスとドメインクロッシングの削除は、ネットワーク駆動型のワークロードのレイテンシとスループットを向上させるための一般的な技術であるため、ネットワーク性能はユニカーネルにとって一般的な原動力となっています。ユニカーネルTCP/IPスタックで実行されているMemcachedは、Linuxのそれと比較して、200%を超えるスループットの改善を示しています[29]。同様に、ユニカーネルのメモリフット・プリントが小さく、起動時間が短いことは、専用環境にクライアント・ワークロードを展開するクラウド・プロバイダーにとって有益です。マイクロVM内に展開されたユニカーネルは、コンテナと比較して起動時間が6倍から10倍改善されました[18]。同様に、micropythonユニカーネルのイメージサイズは1MBで、実行に必要なメモリはたったの8MBでした[24]。

ライブラリOSを搭載したアプリケーションは、SGXエンクレーブ[8]のような高度に制限された実行領域で実行させたり、ソフトウェアで定義された一連のインターフェースの背後で実行させたりできるため、保護と分離がユニカーネルの研究の動機が高めています[13,33]。

ユニカーネルのセキュリティと性能の面でメリットがあるにもかかわらず、研究システムや実験プラットフォームの領域以外ではまだ広く採用されていません。これは、レガシー・ソフトウェア・インターフェイスを部分的にしかサポートしていないランタイムへのアプリケーションの移植に伴う開発者のエンジニアリング負担の増加が原因であると考えています。

問題の原因は、ユニカーネルの開発方法にあります。今日、新しいユニカーネルの作成には、2つのアプローチの何かがあります。カーネルが大部分をゼロから構築するクリーン・スレート・アプローチと、既存のカーネル・コードベースからユニカーネルに不要と思われる機能を取り除くストリップダウン・アプローチです。クリーン・スレート・アプローチでは、ユニカーネルの設計者は、カーネルの構築に使用される言語と方法論を完全に制御することができます。このような自由度により、結果として得られる実装は非常に特殊化され、特定のクラスのアプリケーションに限定されます(例えば、MirageOSはOCamlで記述されたアプリケーションのみをサポートします[21])。クリーン・スレート・ユニカーネルでの実装は、性能のために微調整することもでき、アプリケーションを直接作成できる効率的で低レベルのインターフェイスを提供することもできます。OSv[17]、IncludeOS[9]、EbbRT[29]などのユニカーネルは、C標準のランタイムと一般的なPOSIXのようなインターフェースの部分的なサポートと共に、高性能なコンポーネントのバランスを取ろうとしています。問題は、クリーン・スレート・ユニカーネルが、汎用カーネルによって提供される同じ無数のインタフェースとオプションをサポートすることができない(すべきではない)ことです。少なくとも、効率的な経路を放棄したり難読化したりせずに、細かく微調整された実装が、クリーン・スレート・アプローチを魅力的なものにしています。レガシーソフトウェアのサポートが限られているため、既存のアプリケーションをクリーン・スレート・ユニカーネルに移植してサポートすることは容易なことではなく、すぐに「努力に値しない」と判断されてしまうかも知れません。

別の方法として、ストリップダウン・ユニカーネルは、レガシー・カーネル・コードベースの汎用ライブラリとインタフェースを保持することで、ソフトウェアの移植を容易にしようとしています。このプロセスでは、既存のカーネル・コードベースのフォークを作成し、ターゲットのユニカーネルに不要と判断されるコンポーネントを手動で削除します。これはRumpカーネルとも呼ばれています(イギリス南北戦争後の議会からの王党派の悪名高いパージに触発された名前をもじっている)。例えば、RumpRunユニカーネルには、大幅に縮小されたバージョンのNetBSD[16]が含まれています。しかし、どのような統治機関でもそうであるように、幅広い範囲の利益を引き続きサポートしながら、重要なコンポーネントを削除することは問題になる可能性があります。この場合、ツリー外のフォークを作成すると、元のカーネル・コードベース(その貢献者のグローバル・コミュニティ)の基本的な資産が破棄されます。進化するソース・カーネルに加えられた修正や更新は、Rumpカーネルには無償で提供されません。代わりに、既存のソフトウェアをサポートする最新のプラットフォームを引き続き提供するには、Rumpカーネルを定期的に手動で更新しなければなりません。

3. 主な目標と可能なアプローチ

私たちは、ユニカーネルに関する研究とLinuxコミュニティでの経験に基づき、Linuxベースのユニカーネルは実現可能であり、カーネル・ソース・ツリーの一部として存在できると考えています。Linuxベースのユニカーネルは、Linuxの多くの利点を保持しています。つまり、バトルテスト済みのコードベース、大規模なオープンソース・コミュニティ、レガシー・ソフトウェアの大規模なサポートなどを導入しながら、シングル・アドレス空間、小さなメモリ・フットプリント、カスタマイズ可能なカーネル・パスウェイなど、ユニカーネルに利点となっている主要な特性を導入できます。コミュニティはLinuxユニカーネルを拡張して、ユニカーネル研究システムから学んだ多くの技術と教訓を取り入れ、Linuxの性能とセキュリティを軽量な研究用ユニカーネルに近づけることができます。

このビジョンに向けて、Linuxベースのユニカーネルの実現に向けて、以下の目標を掲げています。

  1. ほとんどのアプリケーションとユーザ・ライブラリは、変更せずにユニカーネルに統合できる必要があります。ユニカーネルを構築するには、別のGCCターゲットを選択するだけです。
  2. リング遷移のオーバーヘッドを回避します。カーネル機能を要求するすべてのアプリケーションで発生するオーバーヘッドは、単純なプロシージャ・コールと同等なものでなければなりません。
  3. クロスレイヤー最適化を許可します。コンパイラや開発者は、アプリケーションとカーネルコードを同時に最適化できなければなりません。
  4. Linuxソースコードの変更は最小限にとどめ、上流で受け入れることができるようにし、ユニカーネルを今後のLinuxの不可欠な部分にすることができるようにします。これにより、ユニカーネルは部外者ではなく、誰もがアプリケーションをコンパイルするために選択できるビルドターゲットになることが保証されます。

アプリケーション・コードとカーネル・コードを混在させるという目標を共有するプロジェクトには、次のものがあります。1) カーネルをプロセスとしてユーザー空間で実行できるUser Mode Linux(UML)[10]、2) Linuxカーネル・ライブラリ(LKL)[27]は、カーネルをライブラリとしてパッケージ化し、カーネルが実行される仮想マシンを作成します。そして、3) LibOS[1]は、カーネルネットワークスタックを共有ライブラリとして構築し、ユーザー空間で実行します。これらのアプローチはすべて、いずれかの方法でカーネル・コードを再利用しようとしていますが、最初の2つの目標には対応していません。

リング遷移を回避するための2つのアプローチは、1) Linuxカーネルモジュールとしてアプリケーションをカーネルに統合すること、2) カーネルと共に、変更されていないアプリケーションをリングゼロで実行できるようにすることです[3,23]。これらのアプローチはどちらも、Linuxの全機能を維持しながら、1つ以上のアプリケーションを最適化できるようにします。クロスレイヤー最適化という3番目の目標を実際に満たしていないため、私たちはこれらのアプローチを最終的に拒否しました。また、カーネル・モジュールについては、アプリケーションを書き換える必要があり、これは第1の目標に反します。

私たちは、カーネルを単一のアプリケーションを実行するために静的にリンクされている純粋なユニカーネル・アプローチを選択しました。このアプローチによってのみ、最適化対象のアプリケーションと並行して任意のユーザレベルのアプリケーションを実行できる場合には不可能な、設定時間とリンク時間の最適化を可能にします。

4. ユニカーネルLinux (UKL)

私たちは、ユニカーネルLinux(UKL)の作業用プロトタイプを作成しました。以下では、関連する実装手順、ビルドプロセス、発生したいくつかの初期の課題、初期の性能結果について説明します。

4.1. 実装概要

UKLプロトタイプを作成するためには、

  • ユーザーがLinuxカーネルをUKLとしてコンパイルするかどうかを選択できるように、新しいカーネル構成オプションを追加しました。
  • 最初のユーザ空間プロセスを作成するのではなく、アプリケーション・コードを呼び出すために使用できる未定義のシンボル(#ifdefによって保護された)への呼び出しを追加しました。
  • システムコール用のスタブを持つ小さなUKLライブラリを作成しました。これらのスタブは、通常のインタフェース(つまり、syscall命令)が使用されなくなったため、必要なカーネル機能の呼び出しの詳細を隠します。
  • カーネルにsyscallを作成する代わりに、UKLライブラリへの関数呼び出しを作成するようglibcを変更しました。
  • アプリケーションのELFバイナリに存在するスレッド・ローカル・ストレージ(TLS)セグメントなどの新しいセグメントを定義するようにカーネル・リンカー・スクリプトを変更しました。
  • ネットワーク・インタフェースの初期化など、ユーザレベルのコードで通常行われる初期化を置き換えるために、アプリケーションを起動する前に少量の初期化コードを追加しました。
  • カーネル・リンク段階で、アプリケーションコード、glibc、UKLライブラリを含むように変更し、単一のバイナリを作成しました。

私たちのプロトタイプは、最新バージョンのLinux(v5.0.5)とglibc(v2.28)を使用しています。glibc内のシステムコールを行うソースファイルは別のサブディレクトリにコピーされ、UKLライブラリへのプロシージャ・コールを行うように編集しています。明らかに、ここで変更された行数は、システムコールが行われた回数と同じです。別のサブディレクトリに含まれるglibcの変更により、通常のビルド・プロセスが中断しないようになっています。コードが安定してきたら、別のサブディレクトリを用意する必要はありません。UKLの関数呼び出しは、通常のglibcコードと共存できます。glibcアーカイブの合計サイズは45MBです。

Linuxカーネルに、11行の変更を加え、合計20行を新たに追加してユニカーネルにしました。これらの変更によって通常のLinuxカーネルで邪魔になることはありません。UKL構成オプションをオフにすると通常のLinuxバイナリが作成され、オンにするとUKLバイナリが作成されます。これらのささやかな変更は、上流で受け入れられる可能性が高くなります。

4.2. ビルド・プロセス

UKLのビルド・プロセスは簡単です。

  1. glibcをリンクなしで、オブジェクトファイルのアーカイブにコンパイルする。
  2. アプリケーション・コードをリンクなしで、つまり-cオプションを使用してオブジェクト・ファイルにコンパイルする。
  3. UKLライブラリをオブジェクト・ファイルにコンパイルする。
  4. UKL設定オプションをオンにしてLinuxカーネルをビルドする。上記のように、カーネル・ビルド・プロセスのリンク段階は、以前に作成されたすべてのオブジェクト・ファイルをリンクするようにわずかに修正されています。

最初の3つのステップは、任意の順序で実行できます。最初のステップ(glibcのコンパイル)は、16GB RAMを搭載した4コアのIntel i7ラップトップで2分弱かかりますが、これは一度だけ実行する必要があります。予想通り、初めて実行する場合、4番目のステップに最も時間がかかります。これは単に、使用しているマシンによっては、通常Linuxカーネル全体のビルドに時間が掛かるためです。Linuxカーネルが既にビルドされている場合、4コアIntel i7ラップトップでユニカーネルに単純なTCP Echoサーバーをビルドするには、1分52秒かかります。アプリケーション・コードを変更し、すべての再構築し、QEMU/KVMへのUKLの展開が速いので、デバッグ目的に非常に役立ちます。ユーザー空間で通常の実行可能なELFを構築するのに匹敵します。2分未満のオーバーヘッドでアプリケーションをユニカーネルに構築することができます。

4.3. 初期の課題

いくつかの課題が浮かび上がってきましたが、その解決策をいくつか報告します。

名前空間の問題: memset、memmoveなどのいくつかのルーチンは、Linuxカーネルとglibcの両方に存在し、複数の定義のビルド時にエラーを発生させます。glibcバージョンを抑制することで修正しましたが、よりインテリジェントな解決策を考案する必要があります。例えば、最後のリンク手順を実行した後に、glibcとアプリケーションコードの部分リンクと、カーネルを部分リンクを別々に行うことができるかも知れません。

Malloc: カーネルのvmallocルーチンを介して、UKLライブラリにmallocをマッピングしました。今後は、アプリケーション・コードに対してglibc mallocの豊富な汎用機能を利用できるようにしたいので、このメモリ管理設計を見直す必要があるかも知れません。また、カーネル・レベルのコードがバッファを割り当て、そのバッファを後でアプリケーションが直接使用して解放できるようにしたいと考えています。

原始(Primordial)スレッドのセットアップ: カーネル空間にTLSメモリをセットアップする必要がありましたが、これはglibcが原始スレッドに期待するものだからです。

これらのような大きな設計上の問題は、今後対処する必要があります。

4.4. 初期評価

図1は、Linux上でユーザ空間プロセスとして動作するC言語で記述されたTCP Echoサーバと、ユニカーネルにリンクされた同じTCP Echoサーバの性能を比較したものです。どちらの場合も、サーバはホストマシン上のQEMU/KVM上にVMとしてデプロイされ、クライアントはそのホストマシン上で実行されています。これは明らかにおもちゃのような例ですが、ユニカーネル版のアプリケーションでは、平均レイテンシがユーザ空間アプリケーションの半分、テールレイテンシが41%速くなっていることは励みになります。

私たちのプロトタイプにより、Linuxをユニカーネルに変換することが可能であり、最適化を行わなくてもある程度の性能上の優位性を得ることが可能と強く確信しています。Linuxカーネルとglibcコードベースに必要な変更が限定的であり、それらをアップストリーム化する際の重要な課題は予見されていないことを示す証拠が得られました。この初期のプロトタイプを作成するための(多数の)ショートカットは、どちらのプロジェクトにも大きな変更を加えることなく対処することができます。

4.5. 必要な作業

アプローチをより広く利用できるようにするための作業には、次のようなものがあります。

  1. UKLをGCCターゲットにして、既存のmakefileを任意のアプリケーションで使用できるようにします。
  2. アプリケーションが必要とするデバイスとインタフェースを初期化するためのシンプルなモデルを開発します。
  3. C++コンストラクターのcrt0サポートを追加します。
  4. glibcの完全な初期化コードをカーネルのスタートアップに統合します。
  5. デバイスとカーネル機能のカスタマイズ可能な初期化を追加します。

5. 私たちが目指す場所

このプロトタイプの後、私たちはプロトタイプを改良し、セクション4で説明したオープンな設計と研究上の疑問に答えることを目指しています。Linuxアプリケーションを実行できる安定したユニカーネルができたら、Linuxまたはアプリケーションを影響を最小限に抑えるための一連の最適化を統合することができます。最初に、そして最も明らかなことですが、リンク時間の最適化は、コンパイラー/リンカーがリンク時にオブジェクト・コード全体を見ることができるため、未使用のコードの削除してサイズを縮小したり、特に短い関数のコードのインライン化してレイテンシを改善させたりすることができます。そして、アプリケーション/カーネルの境界を越えても値の範囲が伝播することを利用しています。

第2に、プロファイル主導の最適化を可能にします。これは、静的にリンクされたバイナリ上でうまく機能し、ユニカーネル全体をプロファイル化することで、後続のコンパイラ/リンカの最適化を可能にし、コード・レイアウトやキャッシュ・フットプリントをさらに最適化します。

第3に、ランタイム環境はスケジューリングを制御し、スレッドが再スケジューリングされるかどうかを仮定することができるため、ユーザレベルの同期メカニズムの実装を簡略化し、その結果として高速化が可能になります。

第4に、アプリケーションやライブラリで利用可能な情報を利用して、システムコールラッパーをバイパスし、内部カーネル関数を直接呼び出すことができます。例えば、あるディスクリプタがネットワーク・ソケットに使用されていることが分かった場合、それぞれのルーチンに直接ジャンプして、コードの逆多重化(demultiplexing)を回避します。

現在、Linuxカーネル全体がユニカーネルにリンクされています。長期的な研究目標の1つは、アプリケーションをサポートするために必要な最低限の要件までユニカーネルを取り除くことです。プログラムを分析し、コンパイラ拡張機能とソースコードの注釈を活用して、カーネルの細かいコンパイル時設定で不要なカーネル機能を自動的に取り除くことができるツールの開発を想定しています。プログラマ、またはユーザレベルのコードを分析するツールは、コンパイラーを使用するためにソースコードに表されていない追加の知識を表現できます。例えば、不変パラメータに関する仮定を提供できます(一部のファイル記述子は常にファイル用です)。また、カーネルでのケース処理を簡略化できます。例えば、ネットワーク・トラフィックがTCPに制限されていることを表現することで、カーネル内の様々な場所に注釈を付けて、ソースコードを変更することなく、テストを削除したり、他のケースを処理するための間接呼び出しを行うことができます。

ユニカーネルモデルがLinuxの一部として受け入れられるようになると、私たちの目標は、既存の研究ユニカーネルで達成されるのと同じ種類の豊富な最適化を可能にします。例えば、バッファの場所は指定せず、カーネルが場所を指定できるようにする読み取り用の代替インタフェースを公開することです(例えば、リングバッファやDMAバッファなど)[19]。別の例として、フルスタックの情報セキュリティの側面を実装しないネットワークスタックのフラット化されたバージョンを公開します。プロセスが1つしかない場合、プライバシーは必要なく、単一のリングバッファーで十分であり、真のゼロコピー・ネットワーキングが可能になります。もっと極端な例として、OpenMPのような複雑なランタイムは、現在使用されているヒューリスティックではなく、真にシステムグローバルな情報を利用して、その情報(数、アフィニティ)に基づいて動的にスレッドを作成できます。

6. 終わりに

ユニカーネルに関する研究から、今日使用されている幅広いクラスのアプリケーションで、仮想コンピュータや物理コンピュータを単一のアプリケーションの実行専用にすることができ、ユニカーネルに大きな利点があるという明確な証拠が得られています。Linuxはイノベーションの適応と統合に非常に成功してきました。ユニカーネルがLinuxの優位性を脅かすのではなく、Linuxの次の自然な進化の段階は、ユニカーネルモデルを可能にすることだと私たちは考えています。

この論文では、このプロジェクトの開始時に確信が持てなかった基本的な疑問である、Linuxをユニカーネルに変えることができることを実証しました。さらに、必要な変更は控えめであることを示し、これらの変更が上流で受け入れられる可能性が高い2つの条件、少なくともいくつかのパフォーマンス上の利点を提供するという初期の証拠を集めました。また、この作業にはコミュニティの大きな関心が寄せられているという証拠もあります。11月中旬のビジョンを説明したブログ投稿[6]は、編集者の言葉を借りれば「2018年にnext.redhat.comで最も読まれた記事」でした。

現時点で、Linuxが実行可能な展開モデルとしてユニカーネルを採用できると確信しています。これが達成されれば、一連の自然な最適化がすべて特定しましたが、これがより広範なLinuxコミュニティーが追求できるもので、これにより、根本的な新しい研究の機会が開かれると信じています。商用グレードのユニカーネルが存在することで、これまでユニカーネルの研究者しか利用できなかったハードウェア、システム・ソフトウェア、アプリケーション空間全体の最適化を探ることができるようになり、より幅広い研究コミュニティが可能になります。

私たちが間違っている可能性は十分ありますが、将来的にはユニカーネル・ターゲットがLinuxの最も重要なターゲットになり、リアルタイム環境、HPC、クラウド・アプリケーション、インフラのコンポーネントなどに利点を提供することが期待されると考えます。そうなれば、私たちが共に成長してきたこれまでのカーネル/ユーザーモデルからオペレーティングシステムの主要な使用法が変わるという根本的な変化が起こるでしょう。これは、マルチユーザーの汎用オペレーティング・システムの終わりの始まりかも知れません。もしかしたら、私たちはついにUnixに「U」を戻したのかも知れません。

参考文献

省略

Hacker News

5/26/2020

新IPと新たな通信技術

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

昨年、ITUに「新IP (New IP)」のフレームワークが提案されました。このフレームワークは、通信アーキテクチャのネットワーク中心の見方の復活を思い描いており、ここではアプリケーションの動作がネットワーク管理された制御メカニズムによって和らげられます。

インターネット技術の基本的なアーキテクチャを見直す提案を目にしたのはこれが初めてではありません(例えば、10年ほど前にアメリカの研究コミュニティで「クリーン・スレート」の取り組みがありました)し、これが最後ではないことは間違いありません。しかし、この新IPのフレームワークは、アプリケーションの動作を抑制するという点で非常に規範的(prescriptive)であり、過去30年間の進化の中で、最も基本的な教訓を無視しているように思えます。通信サービスは、もはや計画経済ではなく、最近では従来の市場基盤の経済として運営されており、多様なサービスのためのこの市場は、アプリケーションの動作の多様性で表されます。

この市場基盤の経済が意味することは、最終的には通信分野の将来を形作るもの、提供されるサービスを形作るもの、そしてそのようなサービスを生み出すために使用されるテクノロジーでさえも、消費者の選択の結果であるということです。消費者は往々にして気まぐれで、一過性の流行に惑わされ、保守的であると同時に冒険的でもあります。しかし、消費者市場の健全性についてどう考えようとも、この業界を動かしているのは消費者のお金です。他の消費者向けサービス市場と同様に、消費者が求めるものを手に入れることができるのです。

しかし、それは単純な消費者の嗜好以上のものです。このセクターの経済的性質の変化は、投資家や投資の変化、事業者の変化、セクターに対する集合的期待の変化、これらの期待の表現方法の変化をも意味します。将来の消費者の嗜好を決定するのは、どこかの堅苦しい国際委員会の責任ではありません。「ネットワーク2030のテクノロジーに関するフォーカス・グループ」のような、高尚な肩書きを持つこれらの委員会は、現実と完全に矛盾するそれらの予測を検討する生来の能力によって認められています。同じような委員会に所属していた先人たちはコンピューターのメインフレームを見逃し、パソコン・コンピュータ革命を見落とし、スマートフォンに完全に驚かされました。10年後にネットワークがどのようなものになっていようともそれは明らかです。そうならないことが、この2030フォーカス・グループが想定している新IPを熟考していることです!

私は将来の予知の分野で、特に何か優れた能力があると主張しているわけではありませんし、トライするつもりもありません。しかし、この進化の過程において、近い将来の技術的な種は今日すでに見えています。ここで私がやりたいことは、私が考える決定的に重要な技術的な種は何か、そしてその理由について説明することです。

これは、私のやや恣意的な個人的な選択ですが、今後10年の間にインターネットにおいて重要な役割を果たすと思われる技術です。

インターネットの基盤技術、そしてデジタル通信のより大きな環境の基盤技術は、従来の回線エミュレーションのモデルに取って代わるパケット化の概念です。

IPは、これまでの電話の責任を根本的に変えることを提唱しました。IPアーキテクチャは、受動的なエッジデバイスを備えたアクティブな時間交換ネットワークではなく、ネットワークの内部要素がシンプルにパケットを交換するだけの大部分が受動的なネットワークを提唱しました。サービス応答の機能は、ネットワークのエッジにあるデバイスに押し出すことを意図していました。ネットワークとデバイスのそれぞれの役割は、インターネットへの移行により逆転しました。

しかし、変化は難しく、数十年の間、ネットワークとネットワークサービスの提供に関心を持つ多くの業界関係者は、このようなネットワーク・サービス・モデルの逆転を一変させようと努めてきました。ネットワーク事業者は、パケットベースのペイロードを処理しながら、ネットワークベースのサービス応答を導入しようと懸命に努力しました。単一のネットワーク・プラットフォーム内で、異なるクラスのパケットフローに対する異なるサービス応答をサポートしようとするネットワークベースのサービス品質(QoS)アプローチを開発する取り組みを私たちは目にして来ました。その約20年後、この努力は大失敗(Grand Failure)だったと見なすことができると思います。その後、MPLSでの仮想回線エミュレーションや、最近ではルーズ・ソース・ルーティングのアプローチのバリアント(SR)が登場しました。これらのアプローチは、ネットワーク内のすべてのアクティブな要素に渡って、オーケストレーションを必要とすることが、私にはいつも不思議な印象を与えます。ここでは、トラフィック・セグメント化の基本機能が、イングレス・トラフィック・グルーミングによって、はるかに低いコストで提供できます。しかし、皮肉なことに、より高価なルーターを販売するには、ネットワーク全体に複雑さを分散させることだと思います。私は、これらの技術を新テクノロジー(emerging technologies)として分類することをためらいます。それは、パケット伝送という特徴のないコモディティ・サービスに「付加価値」を付けたいと言う願望により動機付けられているため、多くの点で逆行する手段のように見えるからです。ネットワークベースのサービスを創出しようとするこれらの取り組みが長続きすることは、回線ベースのネットワーク・セグメントというアーキテクチャ概念に固有の価値があるというよりも、コモディティ・ユーティリティとしての役割を受け入れようとするネットワーク事業者の抵抗のレベルの高さを示す証です。

同時に、ネットワークの他の側面でも驚くべき進歩を遂げました。中央集中型のコマンドと制御に依存しない、広く分散したフォールト・トレラント・システムを構築してきました。約30年ほど前からインターネットを静かにサポートしてきたドメイン間ルーティング・プロトコルBGPは、もともと考案された1990年代初頭のネットワークよりも9桁大きい複雑なネットワークを管理するための分散型システムの設計が、ほとんど先見の明のあるものであることに感銘を受けずにはいられません。私たちは、オープンにアクセス可能な新しい種類のネットワークを作り出しました。電話ネットワークのための新しいアプリケーションを開発することは不可能に近いことでしたが、インターネットでは常にそうです。活気に満ちたアプリの世界からデジタル通信の基本に至るまで、ネットワークの世界は絶え間なく変化しており、目まぐるしい速度で新しいテクノロジーが出現しています。

今後数年間で重要な役割を果たす新テクノロジーについて、私たちは何を見ることができるでしょうか? ここでは、最近の技術革新の中から、今後10年間で大きな影響力を発揮するであろう一連の新テクノロジーに分類したものを個人的に選んでみました。

光コヒーレンス

何十年もの間、光の世界ではトーチに相当するものが使用されていました。ケーブルを通過する光があるか、ないかのどちらかでした。この「オンオフ変調」(OOK)という光エンコーディングのシンプルなアプローチは、最大10Gbpsまでの速度をサポートするために継続的に改良されてきましたが、これは決してテクノロジーの偉業ではありません。しかし、その時点では、OOKが使用しているシグナル・プロセスの明らかに厳しい制限にぶつかっていました 。

しかし、ファイバーには、より多くの信号を送るための余裕がまだあります。私たちは今、光コヒーレンスに目を向け、この分野で第2のイノベーションの波を解き放ちました。光コヒーレンスの活用は、他の領域で徹底的に実践されたテクニックの繰り返しです。位相振幅変調を使用して、アナログベースバンド音声回路モデムを調整し、3Khz帯域幅キャリアで動作しながら56Kbpsの信号を生成しました。同様のアプローチが無線の世界でも使用されており、現在では最大200Mbpsのデータ速度をサポートする4Gシステムが登場しています。

このアプローチは、位相振幅と偏光変調の使用に依存しており、理論上のシャノン限界に近いデータ容量を引き出すことができます。波長あたり100Gpbsの光システムは、現在、光市場でコモディティとなっており、400Gシステムが登場しつつあります。今後数年で、カスタム訓練されたデジタル信号処理と組み合わされた高密度位相振幅変調を使用したテラビット光システムが登場する可能性があります。他の光システムと同様に、生産量の増加に伴い、これらのシステムの帯域幅の単位あたりの価格が急落する可能性もあります。今日の世界では、通信容量は豊富なリソースであり、その豊富さがネットワーク・アーキテクチャに新たな視点を与えてくれます。

5G

無線システムはどうなる? 5Gは「新テクノロジー」なのか?

5Gは、4Gと大して変わらないというのは私の考えです。真の変化は、PPPセッションを使った回線トンネリングからネイティブIPパケット転送方式に移行したことであり、それが3Gから4Gへの大きな変更でした。5Gは、4Gとほとんど同じように見えますが、基本的な違いは5Gの無線周波数の上方シフト(upward shift)です。初期の5Gの展開では3.8Ghzのキャリアを使用していますが、意図としては24Ghzから84Ghzのミリ波帯に向かうことになっています。これは、より高いキャリア周波数はより大きな周波数ブロックを割り当てることができるため、無線ネットワークの伝送容量を増やすことができますが、同時に、より高い周波数は短い波長を使用しており、これらのミリメートルサイズの短い波長は、無線よりも光のように振る舞うという点で、矛盾した恩恵です。より高い周波数では、無線信号は建物、壁、木、その他の大きな物体によって容易に遮られます。これを補うためには、同じカバレッジを実現するためにかなり多くの基地局を必要とします。誇大広告を超えて、ミリ波帯5Gサービスの健全で持続可能な経済モデルがあるかどうかは明らかではありません。

これらの理由から、私は、5Gを重要な新テクノロジーのリストの最下位に置くことにします。無線やモバイルサービスは、インターネットにおいて非常に重要なサービスであることに変わりありませんが、5Gは、確立された4Gテクノロジーを超えて、これらのシステムの利用方法に根本的な変化をもたらすものではありません。

IPv6

2020年にIPv6を「新テクノロジー」と見なすのは奇妙な気がします。IPv6の最初の仕様であるRFC1883は、1995年に公開され、25年前の技術になります。しかし、長年の優柔不断と全面的な否定の後、IPv4の枯渇問題がついに導入決定を原動力となり、最近ではインターネットのユーザ・デバイスの4分の1がIPv6を使用しているようです。この数値は、今後も増加の一途を辿るでしょう。

残りの4分の3にどのくらいの時間が掛かるかを言うのは難しいですが、結論はかなり避けられないように見えます。「新(emerging)」の定義が、今後数年間の採用の大幅な増加の1つであるなら、IPv6はすでに非常に高齢であるにもかかわらず、確かにその特徴に適合しているように見えます!

IPv6のみのサービス環境に頼らざるを得ない状況になる前に、特にパケットの断片化に関連して、IPv6拡張ヘッダーに関する進行中の問題に対して、より良い答えを見つけられることを期待しています。

BBR

Googleのボトルネック帯域幅とラウンド・トリップ時間TCP制御アルゴリズム(BBR)は、私の考えでは、TCP自体と同等の重要を持つ革新的な制御アルゴリズムです。このトランスポート・アルゴリズムは、エンド・ホスト、ネットワーク・バッファー、速度の関係を再定義し、エンドシステムが不十分な設計のアクティブ・パケット・スイッチング・エレメントに妨げられることなく、マルチギガビット速度で利用可能なネットワーク容量を効率的に消費できるようにします。

損失ベースの輻輳制御アルゴリズムは、過去にはうまく機能してきましたが、最近では毎秒数百ギガビットのエンドツーエンドの速度を考えると、このような保守的な損失ベースのシステム制御アルゴリズムは現実的ではありません。BBRは、フロー制御と速度管理の両方にまったく新しい視点を導入しており、利用可能なネットワーク容量の公平な配分と同じ速度で流量を安定化させようとします。これは注目すべき技術です。

QUIC

アプリケーションとネットワークの間には、長年に渡って緊張関係がありました。TCPのエンドツーエンドの世界では、ネットワークのリソースは、クライアント自身が決定する方法でアクティブなクライアントのグループで共有されます。これは、積極的にネットワークのリソースを管理し、顧客に決定論的なサービス結果を提供したいと考えるネットワーク事業者にとって常に忌み嫌われていました。これを実現するため、ネットワークでは様々な形態のポリシーベースのレート・ポリサーが一般的に見られます。ここで、パケット・ヘッダーの「シグネチャ」ば、トラフィックを生成しているアプリケーションを示すことができ、そのアプリケーションがポリシー応答を生成します。このような方法では、各IPパケットの内部コンテンツの可視化する必要がありますが、従来のTCPでは一般的でした。

QUICは、UDPパケットの目に見える外側のラッピングを使用し、内側のTCPとコンテンツのペイロードを暗号化するカプセル化の一形態です。このアプローチは、ネットワークやネットワークのポリシー・エンジンからTCPフロー制御パラメーターを隠すだけでなく、データフロー・アルゴリズムの制御を共通のホスト・オペレーティング・システム・プラットフォームから切り離し、各アプリケーションの手に委ねることができます。これにより、アプリケーションの制御が強化され、アプリケーションが実行中のプラットフォームから独立して動作を調整できます。

さらに、オペレーティング・システム・プラットフォームベースのTCPアプリケーションで使用されているデータフロー制御の「すべての人にとって等しく不快な1つのサイズ」モデル要件を取り除きます。QUICを使用すると、ネットワークパスの現在の状態のパラメーター内でアプリケーションの動作を最適化するために、アプリケーション自体がフロー制御動作を調整することができます。

このように。プラットフォームからアプリケーションへのこの制御の移行は今後も続くと思われます。アプリケーションは、より大きな俊敏性と、独自の動作とサービスに対する高いレベルの制御を求めています。基本的なUDP下層を使用することで、ホスト・プラットフォームのTCP実装がバイパスされ、アプリケーションは、アプリケーションの完全な制御下で動作するようになります。

リゾルバーレスDNS

私は本当は、「DNS over HTTPS」(DoH)と言おうと思っていましたが、DoH自体が特に目新しいテクノロジーではないので、この「新テクノロジー」のカテゴリに当てはまらないと思います。ファイアウォールとプライバシーの懸念が存在する限り、ファイアウォールのトンネリングと通信のプライバシーを強化するテクノロジーとしてHTTPSを使用してきたし、HTTPSセッションでIPパケットをトンネリングするソフトウェア・ツールは容易に利用可能で、少なくとも数十年前から存在していました。そこには目新しいものは何もありません。DNSをHTTPに組み込むことは、HTTPSをユニバーサル・トンネリング回路基板として使用するモデルにわずかな変更を加えるだけです。

しかし、HTTPS自体は、HTTPSのセキュア・チャネル部分であるTLS上のプレーンな古いDNSが本来提供できないいくつかの追加機能を提供します。私が言及しているのは、Webの「サーバープッシュ」テクノロジーのことです。例えば、Webページがカスタム・スタイルページを参照して、ページの意図する視覚設定を決定する場合があります。このスタイルページを取得するためにクライアントに別のラウンドのDNS解決と接続確立を実行させるのではなく、サーバーは単にこのリソースを使用するページとともにこのリソースをクライアントにプッシュするだけです。HTTPの観点から見ると、DNSリクエストとレスポンスは他のデータ・オブジェクト・トランザクションのように見え、DNSクエリをトリガーすることなく、DNSレスポンスをプッシュすることは、HTTPの用語で、スタイルシートをプッシュすることとほとんど変わりません。

しかし、インターネットのネーミング・アーキテクチャの観点から見ると、これは大きな意味を持つ深遠な第一歩です。もし、名前が特定のWeb環境のコンテキスト内でのみアクセス可能で、従来のDNSクエリを含む他のツールでは、アクセスできないとしたらどうなりますか? インターネットは、一貫性のある単一の名前空間として定義できます。リソースへの参照、つまり名前を送信することで相互に通信できます。これは、特定の名前を使用して参照するリソースが、同じ名前を使用するときに参照するリソースと同じである場合にのみ意味があります。どのようなアプリケーションが使用され、その名前に対するクエリのコンテキストが何であるかは関係ありませんが、DNS解決の結果は同じです。しかし、コンテンツが解決された名前をクライアントにプッシュする場合、コンテンツが他の名前のコンテキストとはまったく異なる独自のコンテキストと環境を作成するのは簡単です。もはや1つの一貫した名前空間ではなく、多くの断片化された重複する名前空間が存在し、名前の使用法が矛盾する可能性を曖昧にする明確な方法がありません。

多くの新テクノロジーの背後には、スピード、利便性、そして各ユーザに合わせた環境の整備があります。このような観点から、リゾルバーレスDNSはほとんど避けられません。しかし、欠点はインターネットが共通のまとまりを失ってしまうことであり、この特定のテクノロジーがインターネットに良い影響を与えるのか、それとも非常に破壊的な影響をもたらすのかがはっきりしないことです。今後数年で分かることだと思います!

量子ネットワーク

1936年、私たちが現代の最初のプログラム可能なコンピューターを構築するずっと前に、イギリスの数学者はユニバーサルなコンピューティング・マシンの思考実験を考案し、さらに重要なことに、彼は問題を有限時間内に解が「計算可能な」問題と、マシンが停止しない「計算不可能な問題」に分類しました。ある意味では、最初の物理コンピュータが登場する前から、コンピューターでは決して解決できない問題のクラスが存在することを知っていたのです。ピーター・ショアは1994年に同様の偉業を成し遂げ、まだ完成していない量子コンピュータで有限時間内に素因数分解を実行するアルゴリズムを考案しました。この新しい形の機械的処理の能力(および限界)は、そのようなマシンが構築されるずっと前から把握されていました。量子コンピュータは、コンピューティングの世界で、潜在的に破壊的なテクノロジーとして台頭してきています。

また、量子ビット(キュービット)を量子ネットワーク間でやり取りする量子ネットワーキングという関連する新テクノロジーもあります。他の多くの人と同様に、量子ネットワークがデジタル・ネットワークの進化における難解な転換になるのか、それとも将来のデジタルサービスの従来の主流の基盤になるのか、私には検討がつきません。それを言うにはとにかく時期尚早です。

アーキテクチャの進化

なぜ、絶え間なく技術的な進化がまだ見られるのでしょうか?「これでおしまいです。みんなパブに行こう!」と言う準備ができていないのはなぜでしょうか? インターネットの技術プラットフォームを変更し続けなければならないという圧力は、インターネットのアーキテクチャー自体の進化から来ているのではないかと私は考えています。

インターネットの元々のモデルの目的の1つの見方は、クライアントをサービスに接続することでした。今では、各サービスに専用のアクセス・ネットワークを持たせ、クライアントは特定のサービスにアクセスするために特定のネットワークを使用する必要がありますが、1980年代にこれを少し試してみたところ、一般的な反応は恐怖でたじろぎました! そこで私たちは、インターネットをユニバーサル接続ネットワークとして使用しました。すべてのサービスとサーバーがこの共通のネットワークに接続されている限り、クライアントが接続すると、どのようなサービスにもアクセスできるようになりました。

1990年代には、これは画期的な一歩でしたが、ユーザ数が増えるにつれ、サーバーモデルの成長能力を超えており、維持できない状況になってしまいました。人気のあるサービスは、ネットワークのデジタル版ブラックホールに相当するものでした。私たちは別のソリューションを必要とし、コンテンツ配信ネットワーク(CDN)を考え出しました。 CDNは、専用のネットワークサービスを使用して、インターネット上の全ての場所で同等のサービス配信ポイント・セットを維持します。接続されたサービスにアクセスするために、単一のグローバル・ネットワークを使用するのではなく、クライアントが必要とするのは、ローカルの集約CDNアクセス・ポイントに接続するアクセス・ネットワークです。ローカルでアクセス可能なサービスを使用すればするほど、より広範なネットワークを使用する必要がなくなります。

これはテクノロジーにとって何を意味するのだろうか?

1つの含意は、単一の一貫して繋がったインターネットを維持するインセンティブの弱体化です。ユーザーが望むデジタル配信サービスの大部分が、純粋にローカル・アクセスの枠組みによって得られるとしたら、リモート・アクセスのみの少数のサービスにアクセスするために、一般的なグローバル・トランジットのかなり高いコストを誰に負担することになるのでしょうか? ローカルのみのサービスは、グローバルにユニークなインフラ要素へのアクセスを必要とするのでしょうか?

NATは極端な例ですが、ローカル専用のサービスがローカル専用のアドレスでかなり機能しており、ローカル使用名の急増(proliferation)は同様の結論を導き出します。コンテンツ配信ネットワークの台頭に伴い、インターネットの断片化への圧力が高まっていると結論付けることは困難です。しかし、断片化を物理世界のエントロピーと同じように考えるなら、断片化に抵抗するためには、常に努力が必要です。固有の識別子のグローバル・システムを維持するための絶え間ない努力がなければ、私たちはローカル・スコープのみを示すネットワークに向かっているように見えます。

もう1つの含意は、アプリケーションにおける特定のサービスのスコーピングの台頭です。この例は、QUICの最初の展開で見ることができます。QUICは、GoogleのChromeブラウザがGoogle Webサーバーにアクセスする際に、独占的に使用されていました。従来はアプリケーションのための共通サービスとして、トランスポート・プロトコルはオペレーティング・システムに配置され、アプリケーションの中に引き上げられたのです。適合するアプリケーション機能の使用に対するオペレーティング・システム機能の共通セットの使用をサポートしていた古い設計上の考慮事項は、もはや適用されません。より高性能なエンドシステムとより高速なネットワークの導入により、高度にカスタマイズされたアプリケーションを構築することが可能になりました。ブラウザは、以前のオペレーティング・システムのみに関連付けられていた機能の多くを既にサポートしており、多くのアプリケーションがこれに追随しているように見えます。これは重要な考慮事項ではありますが、エンドユーザ体験をより細かく制御したいというだけでなく、各アプリケーションがホストのオペレーティング・システム・プラットフォーム、ネットワークから他のアプリケーションの動作やユーザーとのやり取りを遮断する場合もあります。

インターネットの原動力となるお金が、エンドユーザの習慣や欲望の知識から得られたお金であるなら、確かにGoogle、Amazon、Facebook、Netflix、その他の多くの企業に当てはまるなら、これらのアプリケーションがその知識を第三者に公開するのは愚かなことです。オペレーティング・システムとネットワークによって提供される豊富なサービスセットに依存するアプリケーションの代わりに、偏執狂的アプリケーションが新しいテクノロジ・モデルとして台頭しています。これらの偏執狂的なアプリケーションは、外部からの依存度を最小限に抑えるだけでなく、行動の可視性も最小限に抑えようとします。

生き方としての変化

インターネットの既存のサービスやインフラと競合するという新テクノロジーの圧力は、おそらくインターネットがまだ生きており、次第に陳腐化と無意味さに陥ることからまだかなり離れていることを示す最も心強い兆候です。私たちは今でも、基本的な伝送要素を変更し、基盤となるトランスポート・プロトコルを変更し、名前とアドレスのインフラを変更し、サービス提供のモデルの変更は現在も行われています。

そして、インターネットは決して解決済の問題ではなく、依然としてまだ多くの重要な技術的課題を提起しているということを、私たちが得ることができる最高のシグナルです。

これは、新IPの提案をどこに置いていくのでしょうか?

私の見解では、それは何の役にも立ちません。ユーザーがお金を支払う準備ができていないネットワークに付加価値を付けようと必死になっている中で、ネットワークをもっと役に立たないノブとレバーで飾ろうとする、もう一つのかなり役に立たない努力として、前任者の長いリストと同じ運命を辿ると思います。

光の世界とモバイル分野の取り組みは、通信を豊かで区別のないコモディティに変えつつあり、それを様々な方法で配給したり、不要な装飾を追加したりする取り組みは、まったくの見当違いの努力です。アプリケーションはもはやネットワークによって管理されるものではなくなりました。ECNの失敗が証明しているように、ネットワークとアプリケーション間の協力の形はほとんど残っていません。現在、QUICとBBRで見られるように、アプリケーションは制御メカニズムをネットワークから隠されており、ネットワークの特性について仮定することが少なくなっています。

もし、これがダーウィン的な進化の過程であるなら、進化の注目は現在、私たちのデバイス上のアプリケーションとしてのユーザ空間に存在しているように思います。ネットワークはパケットを運ぶためだけに存在しています。

リーナス・トーバルズ、個人用PCのCPUをIntelから32コアAMD Ryzenに置き換え

Slashdotより

リーナス・トーバルズは本日Linux 5.7 rc7をリリースし、「非常に正常に見える… どの修正も特に怖いものはないようだ。」と述べています。

しかし、それから彼はさらに他のことを付け加えました。

今週、私にとっての最大の興奮は、メインマシンをアップグレードしたことで、約15年ぶりに、デスクトップがIntelベースではなくなったことです。いや、ARMにはまだ切り替えていませんが、今はAMD Threadripper 3970xを使っています。 'allmodconfig'テストビルドは以前よりも3倍速くなりました。今の落ち着いている間はそれほど重要ではありませんが、次のマージウィンドウの間のアップグレーで間違いなく多くに気付くでしょう。

The Registerは書いています。

トーバルズは新しい装置(rig)について、これ以上詳細を明かしませんでしたが、3970xはかなりの獣であり、TSMCの7nm FinFETプロセスで構築され、3.7GHzで32コアと64スレッドを誇り、最大4.5GHzまでバーストする能力を備えます... ThreadripperシリーズにはsTRX4ソケットが必要で、2019年後半からマザーボード上にデビューしたため、トーバルズはおそらくまったく新しいPCを取得したのでしょう

彼が何を実行しているかというと、現在IntelがPC用に設計されたCPUで提供しているよりも多くのコアを備えています。Chipzilla社のハイエンドCoreXシリーズでさえ、18コアでトップになっています。彼のような有名なITプロがキットを採用し、そのパフォーマンスを指摘したことに、AMDは大喜びでしょう。

あるいは、長年のSlashdot読者であるwilliamyfは、「AMDに対する良い支持、Intelに対するPRの打撃」と述べています。

Hacker News