さらに議論があるリンク: Redditの議論: https://www.reddit.com/r/linux/comments/1qw4r71/microsofts_n... プロジェクトリーダーのJames Morrisがsocial.kernel.orgで発表: https://social.kernel.org/notice/B2xBkzWsBX0NerohSC

彼らはCopilotを通して実行し、問題なしと判断されました。

依存関係を監査するのに合理的な時間はどれくらいでしょうか？

grep 'name = ' ms-litebox-Cargo.lock | wc -l 238 編集: grep 'name = ' ms-litebox-Cargo.lock | sort -u | wc -l 221

依存関係が238個もあるね（同じクレートの複数バージョンも含めて）。* その多くは同じ人たちが管理しているクレートのファミリーに属してる（例えば、rust-crypto、windows、rand、regexなど）。* ほとんどは自分が知ってる人気のクレートだよ。* いくつかは古いコンパイラバージョンをサポートするためだけに必要で、MSRVが上がれば削除できるから、見た目ほど悪くはないよ。

Microsoftのことを考えると、彼らがそう言っても証拠を求めるね。

これはWindowsの代わりになるものじゃないし、GUIデスクトップOSでもないよね。これに関わってる人たちが、今のWindowsデスクトップUXに関わってるとは思えないな。

WindowsのUIはバグが多くて一貫性がない。カーネルや低レベルの部分は実際にはすごく安定してていい感じ。

マイクロソフトはセキュリティやプライバシーに関してあまり良い実績がないからね。もしかしたらうまくいくかもしれないけど、どこかで痛い目に遭う可能性は高いと思う。でも、オープンソースっていうのはいいことだよね。人々はそのコードを使ってもっと良いものを作ったり（例えばAIを取り除いたり）、全く関係ないプロジェクトに使ったりできるから。これを悪いこととは思えないな。クソ企業に対しても、良いことをしたらちゃんと評価するよ。

マイクロソフトは10万人以上のエンジニアを雇ってるんだ。だから、彼らが作るものが全部悪いなんて思わない方がいいよ。Windowsのバグが原因でね。

Windowsは結局、もっと複雑だし、オープンソースじゃないからね。Linuxエコシステムも基盤になってるし、マイクロソフトから来たとしても、エンジニアリング文化はWindowsや特に彼らのオンラインプラットフォームとは違うと思うよ（あれはWindowsよりもひどいと思うけど！）。

MSRはちょっと独立した組織だから、他のMSRプロジェクトを基に予測するべきだよ。

うん、私も同じ感じだった。「わあ、彼らのビジネスの面白い一面だな、公共や学術図書館向けのオペレーティングシステムがあるなんて！」って思った。

そうじゃないの？「ライブラリOS」をリンクすれば、スーパーバイザーで実行する時にOSはもう必要ないんじゃないかな。

私も！正直言って、これにノスタルジーを感じてたんだよね： https://en.wikipedia.org/wiki/Dynix_(software)

モバイルプラットフォームのサンドボックスは、OSベンダーにアプリや機能に対する独占を強制する特別な立場を与える。Appleはそれを積極的に強制してるけど、Googleは今のところ渋々って感じ。これによって、ユーザーがシステムを完全にコントロールすることができなくなる。Appleは直接ロックダウンすることでそれを実現してるけど、Googleはデバイスを所有していることに対して認証で罰を与える。もっと良い方法があるはずだと思う。Linuxのflatpakはここでは合理的なアプローチだと思うけど、実行があまり良くないかもしれない。基本的な信頼できるツールのセットがあって、何でもできるようにしたいし、GUIプログラムのようなあまり信頼できないツールは、ファイルシステムへのアクセスが制限されたサンドボックスで実行したい。

UWPと、Appstoreを通じたWin32のMSIX。企業向けにはIntuneを使ったサンドボックス設定もあるよ。

コンテナがあって、そのユーザーの一つがWindows Sandboxだね。- https://learn.microsoft.com/en-us/windows/security/applicati...

「Windowsでアプリを実行するのがますます不安になってきた。平均的なLinuxディストリビューションがそれほど良いわけではないけど、セキュリティの面ではLinuxがWindowsよりも圧倒的に優れているから、いつでもLinuxでアプリを実行することにためらいはない。」

https://en.wikipedia.org/wiki/Operating_system#Library

これは、例えばWineのようなライブラリ形式のOSだと思う。説明からすると、実際のOS上でプログラムを実行できて、実際のシステムに対して簡略化されたAPIを見せることで攻撃面を減らすことができるみたいだね。

これは、OSの代わりにリンクされるライブラリなんだ。だから、OSが提供するインターフェース（syscallsやioctls、SMCメソッドなど）がアプリケーションに直接リンク/コンパイルされて、アプリケーションの「外部インターフェース」が別のものになる。これがほとんどのユニカーネルの動作方式で、「OS」がアプリケーションのアドレス空間に直接リンクされて、「外部インターフェース」がハードウェアアクセスやハイパーコールになる。Wineも一種の「ライブラリOS」と言えるね（ただし、ユーザーランドライブラリをたくさん再実装しているので、最も厳密な定義よりも深いけど）。だから、例えばこのプロジェクトを使えば、Linuxアプリケーションのコードベースを取り、LiteBoxにリンクして再コンパイルし、SEV-SNP上で実行できる。あるいは、OP-TEE TAを取り、LiteBoxにリンクしてLinux上で実行することもできる。ここで注目すべきは、インターフェースを中間表現に切り詰めて、サンドボックス化できるようにしようとしている点だね。つまり、従来のカーネルの能力システムのように何百ものPOSIX syscallsを監査して制限するのではなく、その中で凝縮されたほんの数個のプリミティブへのアクセスを制御できるはずなんだ。

これについての私の理解は、サンドボックスみたいなもので、プログラムがその中で動くための共通インターフェースを提供するけど、プログラムがOSに直接アクセスするのは避けるってこと。明確じゃないのは、独自の共通ABIを使ってるのか、ホストOSのものを使ってるのかってところ。なぜか分からないけど、プロジェクトの説明から少しだけ、これは別の雰囲気のコーディングプロジェクトだという気がする。

ライブラリOSは、カーネルモードへのsyscallを通じてアクセスされる別のプログラムではなく、プログラムに直接リンクされるOSだよ。ほぼ「ユニカーネル」と同じだけど、最近の用語だね。基本的には、プログラムがハイパーバイザーのVM上で直接動くことを可能にするけど、これもLinux/Windows/BSDプロセスとして実行される。

人々は、Rustで書くことが正しいことを意味すると思ってるみたいだね。

まあ、今や多くの企業がOKRを達成するためにAIを使うことを求めてるから、こうなるのは当然だよね。特にAIツールを売ってるところはさ。

極めてシンプルな変更には、明示的なユニットテストは必要ないよ。コパイロットはあまり使ってないんだけど、みんなが悪いって言うからさ。一般的に、こういうエスケープハッチを追加しても、LLMがそれを使うタイミングについての厳密な要件がないと、ほとんどの場合直感的にそのルールに従わないんだよね。