MetaでカスタムXR OSを構築することに対するJohn Carmackの反対主張

• John CarmackはMetaのカスタムXR OS開発に反対の立場を表明
• 彼は独自OSの開発が複雑性とリスクの増大につながることを強調
• 既存プラットフォームの活用が開発効率とリソースの最適活用により効果的だと主張
• Carmackは市場での迅速なイノベーションと対応のため、標準OSベースの戦略を推奨
• 彼は不要な技術的分裂と断片化を避ける必要性を強調

---

John CarmackによるMetaカスタムXR OS反対の論拠

背景

• John Carmackは、Metaが独自にカスタムXR（拡張現実）OSを開発する案に対して否定的な見解を持っているとされる
• XR OSは、AR/VRなどの拡張現実デバイスで動作するオペレーティングシステムを意味する

主な主張の要約

• Carmackは、すでに市場に存在するプラットフォーム（Android、Windowsなど）の上で開発すれば、開発速度とイノベーションがさらに加速すると述べている
• カスタムOSの開発は、複雑性の増加、バグ発生リスク、長期的な保守負担など、さまざまな問題を伴う
• 独自プラットフォームの構築にリソースを投入すると、既存エコシステムの標準化されたツールと技術を活用する利点が犠牲になる
• 新技術やユーザー要求の変化により迅速に対応するには、既存OSを積極的に活用する戦略が効果的である
• カスタムOSは、開発者と消費者の双方に互換性の問題と学習コストを生じさせる可能性がある

結論

• Carmackは、長期的に技術とサービスの断片化を防ぎ、拡張性と活用性を最大化するため、カスタムXR OS開発よりも既存プラットフォームを活用する戦略を好んでいる

[GN⁺]

Hacker Newsの意見

• Metaで働くことの問題は、自分が成果を出すほど、かえって世界をより悪くする手助けをしてしまうことだ……本当の英雄は金と効率を無駄にする人たちなんじゃないかと思う<br>実力があるなら、別の場所でキャリアを積むことを勧める
  • ソフトウェアエンジニアが人類に奉仕できる最高の方法の一つは、MetaやTikTokのような会社に入って、できるだけ長く仕事ができないふりをすることだ
  • 私はFacebookと関連サービスはブロックするし、zstdは使うつもりだ<br>世の中は白黒論理ではない
  • それは単純化しすぎた見方だ<br>Metaの中核事業をどう思うにせよ、この会社はさまざまなオープンソースプロジェクトやVR、データセンター技術など、ソーシャルメディアと大きく関係のないR&Dにも多くのエンジニアを雇っている<br>関心のある分野の研究で給料をもらう道としては、もっとひどい選択肢もあると思う
  • かなり悲観的な意見ではあるが、これまでのデータを見ると反論しづらい
  • でも実際、これはすべての大企業、いやすべての上場企業にも当てはまる話ではないかと思う<br>創業者には当初ほかの目標があったとしても、時間が経つにつれて結局は利益だけが目的になり、たいてい利益は悪いことに集中するほどずっと大きくなる<br>これはシステム的な問題だ
• 私はいろいろな低レベルソフトウェアやBSP、ほぼOS全体まで作ってきたが、今どきOSを自作しない本当の理由はシリコンベンダーにある

以前はドライバを自分で書けるよう詳細な仕様を渡してくれたが、今では曖昧な説明に加えて品質の低いLinuxドライバだけを投げてくる 怠慢もあるが、複雑さが増したことも理由だ 現代のハードウェアはあまりに複雑で、全体を文書化するだけでも長い時間がかかるし、自分でドライバを書くならなおさら時間がかかる

• Intelは今でもきちんとした文書を出している<br>高速NIC向けに非常に詳細な文書が公開されており、実際 e810 100Gbイーサネットカードのような製品では、公式の2750ページのデータシートだけでドライバをゼロから書ける<br>ほかのベンダーは、(1) 無視するか、(2) NDAを要求するか、(3) お粗末なLinux/FreeBSDドライバの文書だけを見せてくる<br>NVMe SSDのようなほかのハードウェアの状況はよく分からない
• 私も最近、趣味OSで「ソフトリブート」ボタンをサポートしようとして本当に苦労した末に諦めた（GCPでのリブート速度を上げたかった）<br>OS Dev WikiのガイドやLinuxとFreeBSDのソースまで全部読んだが、まったく進展がなかった<br>WindowsでもLinuxでも再起動時に使う機能だ<br>何日も無駄にして結局断念した<br>OS開発者は本当に別種の人間で、たいてい経済的な圧力を受けていないように見える
• 「現代のハードウェアは複雑すぎて文書化が難しい」という話はよく聞くが、全部言い訳だと思う<br>チームには新しい社員のトレーニングも必要だし、テスト管理も必要なのだから、本来複雑であればあるほど、より詳細に文書化すべきだ

つまり、シリコンベンダーの弁解には納得できない

• 今どき本気でOSを自作するつもりなら、ハードウェアに対して非常に強い統制を持つか、OSに servant Linux インスタンスを組み込むしかない気がする

Windowsにはバグのようでも一応ドライバがあり、Linuxには無料のバグだらけのドライバがある OSをLinuxハイパーバイザ上のクライアントとして動かし続けてもよいならその道もあるし、そうでないならハードウェアサポート機能を自分のOSへ少しずつ移していくしかない。ただしその速度が、Linux側に新しい依存が増える速度より速くなければならない……

• 特定のOSの種類であれば、Linuxのハードウェアサポートの大半は移植版LKL(https://github.com/lkl/linux)を使い、ハードウェアアクセス用のフックだけ追加すれば簡単に持ってこられると思う

もちろんコアプラットフォーム/チップセット向けのコードは別に書く必要があるが、残りのI/Oデバイスはほぼカバーできる 一般的なモノリシックカーネルより、ユーザーモードドライバをサポートするスタイルのほうがうまく機能しそうだ

• Johnの話は、実際に誰かに作ってほしいと私が思っているシステムをまさに言い表している

「何かまったく新しいコンピュータを作りたいなら、既存ソリューションの重力井戸から抜け出すには、事実上、隠遁した修道士のようなエンジニア集団が必要になる」 思考実験をすると:

• 月の生活費が200ドルの場所を決める
• 住みやすい村を作る（きれいな空気、健康的な食事、良い学校など）— 富豪が支援しても大きな負担にならない程度に
• ソフトウェアやインターネットがほとんどないコンピュータを大量に提供する
• まったく新しいコンピューティングをゼロから作ってみる

鍵は忍耐だ。数十年かかるだろう

• このアイデアは本当に面白い

そういう低い生活費で成り立つ場所がどこなのか気になる でも本気で気になるのは、なぜ今すぐ実現不可能な問題を解こうとするのかという点だ。CPUのようなハードウェアから始めるべきなのか？ 昔Intel出身のエンジニアが言っていたのを覚えている — 現代のISAやCPU uArch、GPUなどを全部学んで完全に作り直すのは、自分で経験して試行錯誤まですべてやるなら、引退する頃になってやっと可能だと

• 10年以上OSを自作しているが、本当に何かを成し遂げたいならやるべきことではない

もちろん楽しくはあるし、時々想像する。いつかものすごい開発者軍団が加わったら、どこまで成長するのかと。（もちろん金にはならないだろうが）

• 正直、これはものすごく格好いいSFコンセプトだ
• MetaにはOS関連でMicrosoftから来た人が多く、この人たちはもともとOSを作ることに強い関心を持っていた

しかしMetaではXRの仕事に回され、当然ながらカスタムOSを作りたがっていた

• John CarmackがMetaでやったことのせいで、今では彼の話を真剣に受け取りにくい

SerenityOSを見るだけでも、WindowsやLinuxより使いやすく一貫性のあるシステムを作ることは十分可能だった 明確なビジョン、推進力、献身のほうが、「トップエンジニア」の雇用や「高品質なコード」よりもずっと重要だ — そういうものがあれば、良いコードと人材はどうせ後からついてくる これがMetaで不可能な理由であり、Linuxが今のような姿である理由でもある 実際の障害は結局ドライバだ。参考: Thirty-Million line問題 — caseymuratori.comブログ

• Oculus買収後に勤務していたが、XROSは中核技術チームにとって本当に厄介で気が散る存在だった

複数の技術スタックにすでに解決すべき問題が山積みだったのに、XROSというアイデアはOculusがFBに完全統合された後に出てきた 私には、FBチーム（あるいは個人）の一部がARVRトレンドに乗りたかっただけのように見えた Carmackは完全に正しく、リオーグ以降は彼の影響力が徐々に弱まり、その悪影響を身をもって感じた

• XROSチームの大半はFB本社ではなく業界から経験者採用された人たちだった（多くはE5/E6レベル）

FBのSWEは技術的適性が合わず、ブートキャンプ出身の人も何人かいたが、うまくいかずすぐ別の部署へ移っていった

• Oculusのオープンソースコミュニティを壊し、コミュニティが資金を集めたプロジェクトをもう一つのMetaの鎖にして個人情報を吸い上げたことに腹が立つ

それでも給料は良かったことを願う

• 私は2002〜2004年ごろMicrosoftで、OS開発者数名がBill GatesのThink Week向けにハッカソンのように書いた内部論文を読んだことがある

.NETベースの上にGCやメモリ管理まで全部自前で載せた完全に新しいOSで、各種ハードウェアで起動もでき、面白い機能もたくさんあった Windowsとの互換性がゼロであることを明確に前提にした設計で、おそらくそれが失敗理由だったのだろう 数人のOS専門家が1か月ほど集中して成し遂げた仕事だったが、本当に面白かった

• Singularityのことだろうか？<br>Wikipediaの説明<br>Microsoft Researchの公式ページ
• Midoriプロジェクトだったと思う<br>実際には何年もかけて100人以上が投入されたMicrosoft Researchの大規模プロジェクトだ<br>ZDNetのMidoriプロジェクト記事
• John CarmackがXROSチームのマネージャーから「チームメンバーの気分を害する」としてHRに通報されたという話があった

実際、私はCarmackの公開コミュニケーションをいつもプロフェッショナルで親切だと感じてきた 私自身も似たようなHRの武器化を経験したことがあるが、こういうことは会社の雰囲気を萎縮させる — 一度でも、誰かが自分の発言を嫌ってHRに訴えられると思ってしまうと、その後は皆が発言に極端に慎重になる

• Carmackが退職前に書いていた社内投稿を追っていたが、資源の浪費に非常に厳しく、ハンドトラッキング機能がしょっちゅう壊れると、数値を根拠にそこを指摘していた

彼のメッセージは常に「Appleはハードウェアを押さえた。だから今や効率的なソフトウェアこそ未来の鍵だ」という観点で、Metaの放漫さは結局組織内の力学のせいだというものだった

• LucovskyはOSをゼロから自作すると言い張るあまり、現場のプロダクトチームが顧客に実際に何かを届けなければならないという現実を見られず、その結果追い出された

彼が残した毒性（本人は深刻さを理解していない）も影響した 似たような振る舞いはGoogleでも繰り返され、そこでも結局追い出され、公式には自発的に辞任したという形で終わった ツイッター参考 1 ツイッター参考 2

• Johnは実際に対面するとかなり率直で鋭いことがある

自分が信念を持てない仕事には過度に批判的になることがあり、その場合はパワーバランスの関係で反論するのも難しい

• Metaは当時、社内の空気が少し妙だった

PSC（業績評価）が重要で、Carmackのような伝説的な人物に自分のプロジェクトを「資源の浪費」と言われると、それが評価に直撃した 「インパクト」はFacebookで「それが会社にどれだけ有用か」を測る重要な軸だった

• Googleでも似たような場面を見たことがある

Distinguished engineerがjuniorエンジニアに、最初は穏やかに、その後はきっぱりと「それは良くないアイデアだからやめるべきだ」と言ったところ、HRが介入したことがあった こうした中で、それ以上時間や労力を注ぎたくなくて、問題をそのまま流したこともある

• GoogleでFlutterチームがFuchsiaを作っていた時期があった

本当に優秀な人材（私が見た中でも最も優秀なエンジニアたち）で、人数も数百人規模と大きかった 技術的には非常に優れていたが、そもそも誰が使うのかについて明確な答えを誰も持っていなかった カーネルだけ新しく作って既存Linuxを置き換えるという目標ならまだ良かったが、逆にOSをカーネル、UI、window managerまで全レイヤー最初から作ろうとしていた 結局、Home HubのようなUIだけの特殊デバイスしか対象にせず、それですら既存製品に比べて、なぜわざわざここまで複雑にOSを変える必要があるのかを示せなかった いまだにFuchsiaが続いていることが、呆れるほど納得できない Googleがリストラを進める中で必須チームの資源を削りながら、こういうプロジェクトには人員を残していたのを見ると、なおさら気が滅入る むしろ、なぜこれを生かしているのか本当に分からない

• 短期的な成果だけを見れば弁明は難しいが、長期的に考えれば新OS開発も妥当だ

Googleは実際に長期投資に関心があり、プロジェクトが対外的に大義名分を示す必要もない むしろ批判する側のほうが不思議に思える。必要なら参加すればよく、そうでなければ無視すればいい 新しいアプリケーションエコシステムの創出はそもそも目標ではなく、最も難しいのは、普段は当然だと見なしている無数の技術をすべて実装しなければならない点だ。大変だが不可能ではない 選択肢が増えることに悪い点はない — ブラウザ市場では多様性が重要だと言いながら、OS市場では独占が構わないとするような矛盾した論理より、より多様なOSがあるほうが良い

• 一部のデバイス（Home Hub）を出発点にして、そこで経験と収益を積み、徐々に拡張していくのが目標だったのだと思う

最初から一気にすべてを置き換えるつもりで始めたわけではないだろう

• Fuchsiaは実際には複数のOSとアプリパッケージが完全なコンテナとして動く新しいパラダイムだと理解していた

私の想像では、Web上でも動き、複数のマシンで一緒に動かすこともできる未来のOSを描いていた 同じマシン上で複数インスタンスを動かし、それぞれを別々のユーザー向けに最適化する方式も期待していた

• 私にはFuchsiaが、Googleが優秀なカーネルエンジニアを競合に行かせないための、一種の消耗戦プロジェクトのように見えた
• Home HubへのFuchsia搭載を無理やり押し通したせいで既存スタックはすぐレガシーになり、その後もスケジュールが遅れ続けても何の成果もなかった

OSを自作するのは格好良く見えたが、プロジェクト全体としてはほかのチームの仕事に悪影響を与えただけのように感じた

• 最近ではLinuxカーネルをバイパスして直接ハードウェアへアクセスするのが簡単になり、多コアCPUも一般的だ

重要なのはコアを分離してスレッドを割り当て、カーネルバイパス技法で直接ハードウェアを制御すること。コア間通信をリングバッファで行えば、ほぼハードウェア最適化に近い性能に加えて、管理・監視・デバッグではLinuxカーネルの利点も活用できる

• /dev/mem を mmap して物理メモリに直接アクセスするように、カーネルバイパスはいつでも可能だ