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".
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.
> we can run a Linux kernel in WebAssembly.
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 thought someone did a port of Linux to wasm
I think someone did that here: https://github.com/joelseverin/linux-wasm
Every damn vibe project: “Catchy hook, descriptive explanation”. Like they’ve all got their own marketing team now.
Seems very cool. I'm wondering what the next step would be for performance here. Trying python as suggested is quite slow so far.
There's a JIT, so running the same thing more than once makes it faster:
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.Ugh cant stand the LLM-isms, cool idea tho, practical? For teaching maybe?
so sick, nice work!
Just looked at this and wondered, how much Claude AI slop went into this project and unsurprisingly a lot of it.
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.
It's a good idea, and the implementation works. Are there actual problems, or are you just complaining that AI was used?
> It's a good idea, and the implementation works.
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.
Have a look at the submissions from that websites. The quantity alone indicates that the author is vibing full steam.
Nice ideas but 100% slop