26 comments

[ 2.8 ms ] story [ 50.0 ms ] thread
I've always been fascinated by this, but I have never known what it would be useful for. Does anyone know of any practical use cases?
Unfortunately, he didn't attach the source code for the 64-bit x86 emulation layer, or the config used to compile the hosted image.

For a more open-source version, check out container2wasm (which supports x86_64, riscv64, and AArch64 architectures): https://github.com/container2wasm/container2wasm

I can launch this thing and start making arbitrary connections out to port 25 on the internet from some random IP? Hmm.
How do TinyEmu and JSLinux compare to linux-wasm?

From "Show HN: Amla Sandbox – WASM bash shell sandbox for AI agents" (2026) https://news.ycombinator.com/item?id=46825119 :

>>> How to run vscode-container-wasm-gcc-example with c2w, with joelseverin/linux-wasm?

>> linux-wasm is apparently faster than c2w

From "Ghostty compiled to WASM with xterm.js API compatibility" https://news.ycombinator.com/item?id=46118267 :

> From joelseverin/linux-wasm: https://github.com/joelseverin/linux-wasm :

>> Hint: Wasm lacks an MMU, meaning that Linux needs to be built in a NOMMU configuration

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

>> There's a pypi:SystemdUnitParser.

UBY: touchscreen: How to scroll the scrollback
Sorry for the off-topic, but what a bliss to see Windows 2000 interface. And what an absolute abomination from hell pretty much all the modern UIs are.
The thing I most want to use this (or some other WASM Linux engine) for is running a coding agent against a virtual operating system directly in my browser.

Claude Code / Codex CLI / etc are all great because they know how to drive Bash and other Linux tools.

The browser is probably the best sandbox we have. Being able to run an agent loop against a WebAssembly Linux would be a very cool trick.

I had a play with v86 a few months ago but didn't quite get to the point where I hooked up the agent to it - here's my WIP: https://tools.simonwillison.net/v86 - it has a text input you can use to send commands to the Linux machine, which is pretty much what you'd need to wire in an agent too.

In that demo try running "cat test.lua" and then "lua test.lua".

I love how nonchalantly demonstrates his custom terminal emulator and javascript engine.
Out of interest I tried running my Primes benchmark [1] on both the x86_64 and x86 Alpine and the riscv64 Buildroot, both in Chrome on M1 Mac Mini. Both are 2nd run so that all needed code is already cached locally.

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 (i.e. 32 bit):

    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

Conclusion: as seen also in QEMU (also started by Bellard!), RISC-V is a *lot* easier to emulate than x86. If you're building code specifically to run in emulation, use RISC-V: builds faster, smaller code, runs faster.

Note: quite different gcc versions, with x86_64 being 15.2.0, x86 9.3.0, and riscv64 7.3.0.

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

> If you're building code specifically to run in emulation, use RISC-V: builds faster, smaller code, runs faster.

I don't really think this bears out in practice. RISC-V is easy to emulate but this does not make it fast to emulate. Emulation performance is largely dominated by other factors where RISC-V does not uniquely dominate.

x86 is a lot easier to JIT to Arm or RISC-V though, because it has fewer registers.
I've been using the x86_64 Alpine jslinux browser image in Chrome for the last 4 hours - pulling code down via git, building several large packages from source, editing and altering code, and running their test suites. This VM may be 50 times slower than native, but it is rock solid - worked perfectly and is stable. It's simply remarkable.
how can I install a openclaw in the jslinux.
Amazing work by Fabrice Bellard as always. The x86_64 support opens up so many possibilities for running modern Linux distributions in the browser.
I am almost sure it was done so carefully that you can extract it from the abominations which are the whatng cartel web engines with a direct to OS abstraction layer that with only some little amount of work.
Is JSLinux still an interpreter, or does it JIT compile these days?

Or are modern JS JITs so good that this is no longer a relevant distinction, i.e. is the performance of a JITted x86 interpreter effectively equivalent to a JITting x86-to-Javascript translator where the result is then itself JIT interpreted?

There seems to be an issue with DNS. Did I miss something?
I bet Fabrice could write JSAndroid which would provide no lag emulation experience.
Didn’t know this was possible! Isn’t this open source? I’d like to see how it works. I assume this runs on top of pure WebAssembly.