【神アプデ】JSLinuxがついにx86_64に対応！ブラウザで64bit Linuxが動く時代へ

伝説的エンジニアFabrice Bellard氏が開発した、Webブラウザ上で動作するPCエミュレータ「JSLinux」が、ついにx86_64（64bit）アーキテクチャをサポートしました。これまで以上にモダンなソフトウェアの実行や開発検証が、ブラウザ一つで手軽に行えるようになります。

ずっとこれに惹かれているんだけど、何に役立つのかはさっぱり分からなかったんだ。誰か実用的なユースケースを知っている人いる？

残念ながら、64ビットx86エミュレーションレイヤーのソースコードや、ホストされているイメージをコンパイルするのに使った設定は公開されていないみたいだね。もっとオープンソース寄りのものが良ければ、x86_64、riscv64、AArch64アーキテクチャをサポートしているcontainer2wasmをチェックしてみるといいよ：https://github.com/container2wasm/container2wasm

これを起動して、適当なIPからインターネットの25番ポートに勝手につなげられるってこと？うーん。

とんでもないヤツだな！

TinyEmuやJSLinuxはlinux-wasmと比べてどうなんだろう？

"Show HN: Amla Sandbox – AIエージェント用のWASM bashシェルサンドボックス" (2026) より
https://news.ycombinator.com/item?id=46825119 (https://news.ycombinator.com/item?id=46825119) :

c2wやjoelseverin/linux-wasmでvscode-container-wasm-gcc-exampleを動かすにはどうすればいい？

linux-wasmは明らかにc2wより速いよ

"xterm.js API互換でWASMにコンパイルされたGhostty" より https://news.ycombinator.com/item?id=46118267 (https://news.ycombinator.com/item?id=46118267) :

joelseverin/linux-wasmから: https://github.com/joelseverin/linux-wasm (https://github.com/joelseverin/linux-wasm) :

ヒント：WasmにはMMUがないから、LinuxをNOMMU構成でビルドする必要がある

From https://news.ycombinator.com/item?id=46229385 (https://news.ycombinator.com/item?id=46229385) :

pypi:SystemdUnitParserがあるよ。

本題から逸れて申し訳ないけど、Windows 2000のインターフェースが見られるなんて最高だね。それに比べて最近のUIはどれもこれも、地獄から来たのかってくらいひどい代物だよ。

これ（あるいは他のWASM Linuxエンジン）を一番使いたい理由は、ブラウザ内で直接、仮想OSに対してコーディングエージェントを動かすことなんだ。Claude CodeやCodex CLIとかはどれも、Bashや他のLinuxツールを扱えるから最高だよね。ブラウザはおそらく俺たちが持っている最高のサンドボックスだし、WebAssembly版Linuxに対してエージェントのループを回せたら、すごく面白い使い道になると思う。数ヶ月前にv86で遊んでみたけど、エージェントを繋ぐところまではいかなかった。これが仕掛かり中のプロジェクト：https://tools.simonwillison.net/v86 (https://tools.simonwillison.net/v86) － Linuxマシンにコマンドを送るためのテキスト入力があるんだけど、エージェントを繋ぎ込むのにもほぼこれが必要になるはず。そのデモで "cat test.lua" を実行してから "lua test.lua" を試してみて。

興味がある人がいれば。先月、x86_64のJSLinux上でTempleOSを動かすために少し修正を加えてみたんだ：https://ring0.holyc.xyz/ (https://ring0.holyc.xyz/)

自分のカスタムターミナルエミュレータとJavaScriptエンジンを、さらっと披露しちゃうところがたまらないね。

興味本位で、x86_64とx86のAlpine、それからriscv64のBuildrootを使って、自分の素数ベンチマーク[1]を試してみた。環境はどちらもM1 Mac Mini上のChrome。必要なコードがローカルにキャッシュされた状態にするため、2回目の実行結果を載せるよ。

x86_64:

    localhost:~# time gcc -O primes.c -o primes
    real    0m 3.18s
    user    0m 1.30s
    sys     0m 1.47s
    localhost:~# time ./primes
    Starting run
    3713160 primes found in 456995 ms
    245 bytes of code in countPrimes()
    real    7m 37.97s
    user    7m 36.98s
    sys     0m 0.00s
    localhost:~# uname -a
    Linux localhost 6.19.3 #17 PREEMPT_DYNAMIC Mon Mar  9 17:12:35 CET 2026 x86_64 Linux

x86 (32ビット):

    localhost:~# time gcc -O primes.c -o primes
    real    0m 2.08s
    user    0m 1.43s
    sys     0m 0.64s
    localhost:~# time ./primes
    Starting run
    3713160 primes found in 348424 ms
    301 bytes of code in countPrimes()
    real    5m 48.46s
    user    5m 37.55s
    sys     0m 10.86s
    localhost:~# uname -a
    Linux localhost 4.12.0-rc6-g48ec1f0-dirty #21 Fri Aug 4 21:02:28 CEST 2017 i586 Linux

riscv64:

    [root@localhost ~]# time gcc -O primes.c -o primes
    real    0m 2.08s
    user    0m 1.13s
    sys     0m 0.93s
    [root@localhost ~]# time ./primes
    Starting run
    3713160 primes found in 180893 ms
    216 bytes of code in countPrimes()
    real    3m 0.90s
    user    3m 0.89s
    sys     0m 0.00s
    [root@localhost ~]# uname -a
    Linux localhost 4.15.0-00049-ga3b1e7a-dirty #11 Thu Nov 8 20:30:26 CET 2018 riscv64 GNU/Linux

結論：Bellardが始めたQEMUでもそうだけど、RISC-Vはx86よりエミュレートがずっと簡単だね。エミュレーション上で動かすためにコードをビルドするなら、RISC-Vを使うべき。ビルドは速いし、バイナリは小さいし、実行も速い。

注：gccのバージョンがかなり違っていて、x86_64は15.2.0、x86は9.3.0、riscv64は7.3.0だった。

[1] http://hoult..rg/primes.txt (http://hoult..rg/primes.txt)