For a moment I thought someone did a port of Linux to wasm, but this is actually x86_64 Linux in a wasm qemu (with JIT, granted, which I suppose blurs the line). That's probably a lot more practical.
---
I'm stoked about the idea of using this for code review / bug reproduction / tutorials / demos. Obviously nix already gives you the reproducibility side of things, but running on any host system with zero setup and robust sandboxing should really improve its practical usefulness. Native nix doesn't give you "try this software by clicking a link and it works without installing anything", nor " here's some completely untrusted code someone wants you to run, and that's ~fine because it's in a browser tab".
I think it could be made much faster by emulating Linux system calls instead of running a real kernel, and translating x86 binaries to wasm before running (using something like cheerpx).
There's a JIT, so running the same thing more than once makes it faster:
~ # time hello
Hello, world!
real 0m 1.89s
user 0m 0.67s
sys 0m 1.14s
~ # time hello
Hello, world!
real 0m 0.97s
user 0m 0.36s
sys 0m 0.55s
This would to me imply an obvious route of pre-warming the resumed image with your program. Or going all-in and natively compiling to wasm, but that's a much bigger lift.
Just because something "works" doesn't not mean it makes sense to use in the long run. It is incredibly memory inefficient and will cause the user's machine to crash. Not everyone is running the latest ThinkPad or Macbook with 64GB RAM.
Without those considerations, I believe it is complete AI slop.
> It is incredibly memory inefficient and will cause the user's machine to crash. Not everyone is running the latest ThinkPad or Macbook with 64GB RAM.
Thankfully, you don't need that:
> Lastly, we have an upper-bound on the size of the closure we can fetch. The whole closure has to fit in tab memory, which is set to a hard limit of ~1.5GiB as of now and WebAssembly has a hard limit of 4GiB as it is a 32-bit address space.
And it works fine on my 3-year-old phone with 8G of RAM, so I think your complete dismissal of VMs is excessive.
If the binary is running under a real x64 linux kernel running in qemu, wouldn't that imply that the binary is never translated to wasm?
For a moment I thought someone did a port of Linux to wasm, but this is actually x86_64 Linux in a wasm qemu (with JIT, granted, which I suppose blurs the line). That's probably a lot more practical.
---
I'm stoked about the idea of using this for code review / bug reproduction / tutorials / demos. Obviously nix already gives you the reproducibility side of things, but running on any host system with zero setup and robust sandboxing should really improve its practical usefulness. Native nix doesn't give you "try this software by clicking a link and it works without installing anything", nor " here's some completely untrusted code someone wants you to run, and that's ~fine because it's in a browser tab".
I think someone did that here: https://github.com/joelseverin/linux-wasm
The entire site reeks of Claudisms and I doubt that the author even cares or knows what they are doing. The GitHub put me off immediately.
It's quite ridiculous to see such slop here and we are just going to see more of this.
Just because something "works" doesn't not mean it makes sense to use in the long run. It is incredibly memory inefficient and will cause the user's machine to crash. Not everyone is running the latest ThinkPad or Macbook with 64GB RAM.
Without those considerations, I believe it is complete AI slop.
Thankfully, you don't need that:
> Lastly, we have an upper-bound on the size of the closure we can fetch. The whole closure has to fit in tab memory, which is set to a hard limit of ~1.5GiB as of now and WebAssembly has a hard limit of 4GiB as it is a 32-bit address space.
And it works fine on my 3-year-old phone with 8G of RAM, so I think your complete dismissal of VMs is excessive.
Nice ideas but 100% slop