すごいね。これがOSの未来になるのかな。READMEを読むのがめっちゃ面白い。なんでwasmiを使ったの？wasmtimeじゃなくて。実際にこのOSをVMの中で使ってみようかな。自分のリアクティブGUIライブラリをMunalに移植したい気持ちもある。

もちろん、ループの各ステップはCPUを任意の時間保持することができず、長時間のタスクのためには明示的にyieldしなければならないというデメリットがあります。もっと大きなデメリットは、アプリをたくさん開くほど、各アプリが遅くなることだと思います。10個以上開いたことはないけど、30タブ開いたことはあるから、それぞれが別のプロセスだったら、30倍遅くなるんじゃない？全体のコンピュータが十分に速ければそれでいいけど、動画レンダラーみたいな重いプロセスは明らかに遅くなるよね。1秒から30秒に伸びるだけでも。とはいえ、これは全体のOSを動かすための本当に賢いショートカットだと思う。大したもんだし、ワクワクするね！

ループの各反復はネットワークと入力ドライバーをポーリングし、デスクトップインターフェースを描画し、各アクティブなWASMアプリケーションの1ステップを実行し、GPUフレームバッファをフラッシュします。これは本当に興味深いね。Wasmiを使ってどう実装したのか気になる。コードはここにあるみたいだよ：https://github.com/Askannz/munal-os/blob/2d3d361f67888cb2fe8... 新しいバージョンのWasmi（v0.45+）では、燃料が切れたときにyieldできるように、再開可能な関数呼び出し機能が拡張されたみたいだよ：https://docs.rs/wasmi/latest/wasmi/struct.TypedFunc.html#met... すでにWasmiの燃料メーターを使っているなら、Wasmアプリをステップで実行するためのより効率的で失敗しにくいアプローチかもしれないね。やり方の例はWasmiのWastランナーにあるよ：https://github.com/wasmi-labs/wasmi/blob/019806547aae542d148...

wasmコンポーネントが現実になった後、こういう試みがどんな感じになるのか楽しみだな。ユニカーネルデザインには大きなリスペクトを持ってるし、これは素晴らしい機能が詰まってる。だけど…なんでこんなに重要に感じるのか自分でもわからないけど、wasmが一つの大きなプリコンパイルアプリだけに役立つのではなく、もっと役立ってほしい。今、wasi preview3に向けていろんな作業が進んでいて、同期と非同期のコードが共存できるようにしてる。これが実現すれば、wasmはついにすべての必要な要素を揃えて、あらゆるもののランタイムになれる気がする（ホストオブジェクトのブリッジももっと注目されるといいんだけど、rust web-sysみたいなjsベースのブリッジを超える意図があるのかは不明）。wasmランタイムがもっとダイナミックなサブ環境をホストするために使われることに興味が集まるといいな。一つの素晴らしいプロセスだけでなく、たくさんのプロセスをホストするために。wasmコンポーネントの約束は、標準でポータブル、軽量で、きちんとサンドボックス化されていて、クロスランゲージで構成可能なモジュールを提供すること（下の素晴らしいトークに基づいて）で、もうすぐそこにあるように思えるけど、ユニカーネルのようなアプリケーションで広く使われている現状は、wasmが拡張していくべき分野だと思う。仕様としてではなく（仕様はあるみたい！）、実際に実行可能なものとして、wasmコンポーネントが何に役立つのかを見たい。単なる配布形式ではなく、ランタイムの能力として。コンポーネントとは何か（そしてなぜ） https://youtu.be/y3x4-nQeXxc

すごい！これ、独自のウェブブラウザまであるんだ！デモ動画でHacker Newsが動いてるのが見れるよ。

/愚痴モードオン Xerox PARC以来、数年ごとにバイトコードユーザースペースへの新たな試みが出てくるけど、今のところIBM i、ChromeOS、Androidだけが生き残ってるね。主にオーナーたちが「自分のやり方か、さもなくば去れ」って態度を持ってるおかげで、管理者もチームを支えるのに時間がかかっても構わないって感じ。/愚痴モードオフ とにかく、このプロジェクトに幸運を祈るよ、かっこいいね。

協調スケジューリングを除けば、Spectreがセキュリティモデルを壊してると思うし、仮想メモリなしで効率的に動くとは思えない。memory.growはどう実装するの？10 kB増やしたいときに、別のアプリが邪魔してたら、アプリ全体のメモリをmemmoveしなきゃいけないの？それって可能なの？それでも、すごく印象的なプロジェクトだね！

クライアントOSだなんて信じられない！このデザインはサーバーサイドで即座に使えると思う。カーネルを小さくして、実行しているもの以外のライブラリやアプリケーションを排除することで、セキュリティ境界をかなり減らせるからね。例えば、キー/バリューストアはこうやって動かすのにぴったりだと思う。このIOモデルで decentなネットワークパフォーマンスを達成するのは可能なの？ほとんどのプログラムでWASMをホスティングするときに必要なコピーを減らすために、メモリで何かトリックを使える？

ちょっと聞きたいんだけど、「The Birth and Death of Javascript」っていうPycon 2014のトークに影響を受けたことある？ https://www.destroyallsoftware.com/talks/the-birth-and-death... そのトークでは、オペレーティングシステムがasm.js（wasmの前身）サンドボックスを仮想メモリ保護の代わりに使う未来の仮定について話してるんだ。あれはすごくクールなアイデアだと思ってたし、君のデザインにも大事な部分みたいだね。

これは本当にインスピレーションを与えてくれるし、クールだね。頭の中にこういう概念がたくさん浮かんでるけど、必要な能力や実行力が足りなかったんだ。きっと他の人もそうだと思う。誰かがそれを実行しているのを見るのはすごくクールだね。こういう孤立したアプリケーションを持つオペレーティングシステムが、何らかの証明を提供できるのか気になるな。ユーザーに敵対的でない方法でそれを実現するのは可能なのかな？私が夢見るユースケースはオンライン競技ゲームなんだ。大多数のユーザーが公平なコミュニティのためにソフトウェアの自由を犠牲にする状況だよね。コンソールは他のユーザーが公平に参加していることを保証するためのロックダウンされた方法だったけど、チーターが進化するにつれてそれはどんどん少なくなってきてる。これを解決するには、ソフトウェアやハードウェアへのアクセスをロックダウンする必要があると思う。ゲーム理論の観点からは、他のアプローチが見えないんだ。「カーネルレベルのアンチチート」っていうのが出てくるけど、誰に聞くかによってはルートキットとも呼ばれるよね。だから、こういうレベルでの仮想化が、ソフトウェアの自由やユーザーのプライバシー、セキュリティを保ちながら解決策の一部になれるのか、ちょっと気になるな。