Discussion
JSLinux
petcat: 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?
maxloh: My college professor used it to teach us the Linux command lineWe have Windows PCs in the classroom.
varun_ch: Maybe if you’ve got some ancient software that’s missing source code and only runs with X Y and Z conditions, you could continue to offer it on the web and build around it like that? Not sure if that would be practical at all, but could be interesting
maxloh: 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
zamadatix: https://github.com/copy/v86 might be a more 1:1 fully open sourced alternative.
wolttam: I can launch this thing and start making arbitrary connections out to port 25 on the internet from some random IP? Hmm.
westurner: 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 c2wFrom "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 configurationFrom https://news.ycombinator.com/item?id=46229385 :>> There's a pypi:SystemdUnitParser.
AlecMurphy: If anyone is interested, I made some modifications last month to get TempleOS running on the x86_64 JSLinux: https://ring0.holyc.xyz/
simonw: 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".
d_philla: Check out Jeff Lindsay's Apptron (https://github.com/tractordev/apptron), comes very close to this, and is some great tech all on its own.
redleader55: Agentic workloads create and then run code. You don't want to just run that code in a "normal" environment like a container, or even a very well protected VM. There are other options, ofc - eg. gvisor, crossvm, firecracker, etc, but this one is uncommon enough to have a small number of attackers trying to hack it.
srdjanr: What's wrong with a well protected VM? Especially compared to something where the security selling point is "no one uses it" (according to your argument; I don't know how secure this actually is)
g947o: Nothing, but "there are already working options" does not necessarily mean we shouldn't try new (and sometimes weird) things
maxloh: Not really. x86_64 is not supported yet: https://github.com/copy/v86/issues/133
zamadatix: Sure, but JSLinux supports a lot more than CLI Linux userspace on x86-64. E.g. compare to complete lack of graphical interface https://github.com/container2wasm/container2wasm/issues/196
