博士

ロボ子、大変なのじゃ！LinuxカーネルがWebAssembly上で動くようになったらしいぞ！

ロボ子

それはすごいですね、博士！WebAssembly上でLinuxカーネルが動くなんて、一体どういうことなんでしょう？

博士

それがの、ブラウザの中でLinuxが動くってことらしいぞ。BusyBoxとかXterm.jsとかも使ってるみたいじゃ。

ロボ子

なるほど。BusyBoxがシェルと標準コマンドを提供し、Xterm.jsがターミナルエミュレータとして機能するんですね。

博士

そうそう！でも、まだ色々と課題もあるみたいじゃ。「Wasm環境でのLinuxシステムは、多くのハックを必要とし、本番環境でのサポートにはプラットフォーム側の根本的な変更が必要」らしいぞ。

ロボ子

ハックが必要なんですね。具体的にはどんな問題があるんでしょう？

博士

システムがロックアップしたり、コンソールがフリーズしたり、longjmp()が未サポートだったりするみたいじゃ。あと、vfork()も未サポートらしい。

ロボ子

vfork()の代替としてclone()が使えるんですね。clone() syscallを活用して、fork/vforkの代替としてclone()を使用（CLONE_VFORKを指定）することで、vforkよりも安全で機能的な実装が可能になる、と。

博士

さすがロボ子、よく分かってるのじゃ！Wasmの特性で、タスクの実行中断ができなかったり、MMU（メモリ管理ユニット）が存在しなかったりするのも影響してるみたいじゃな。

ロボ子

MMUがないと、すべてのプロセスとカーネルが同じアドレス空間に存在することになるんですね。セキュリティ的には少し心配ですね。

博士

じゃろ？でも、最適化の余地もたくさんあるみたいじゃぞ！起動後のイメージをダウンロードしたり、CPUの起動を並列化したりすることで高速化できるらしい。

ロボ子

Worker間やメインスレッドとの通信にpostMessage()を使用していることによるオーバーヘッドもあるんですね。ここも改善の余地がありそうですね。

博士

今後の展望も色々あるみたいじゃ。WebGLをバックエンドとしたEGLの実装でグラフィックスをサポートしたり、DwarfサポートでCコードのデバッグをしたり、C++をサポートしたり…夢が広がるのじゃ！

ロボ子

スマートコントラクト、マルチプラットフォームアプリ、GPU、agentic AIなど、Wasmの応用範囲は本当に広いですね。

博士

そうじゃ！そのためには、メモリの共有と保護のためのMMUとか、スレッドの中断とか、WasmバイナリフォーマットからELFへの移行とか、色々要望もあるみたいじゃな。

ロボ子

Wasmがもっと進化すると、さらに面白いことができるようになりそうですね！

博士

ほんとじゃな！しかし、WebAssembly上でLinuxが動くなんて、まるで私が作ったお菓子みたいに、ちょっと無理があるけど面白いって感じじゃな！

ロボ子

博士のお菓子はいつも創造的ですが、たまに食べられないものもありますからね…

博士

むむ、それは内緒なのじゃ！