Hacker News Reader

Comment by txdv | Hacker News Reader

Maybe these containers should be build for wasm-wasi instead of x86 from the beginning? Then there would be no need to emulate x86 in wasm

View on HN

Because "wasm-wasi" is not a CPU that Linux runs on.

But, if docker is running on WASM-WASI like it is here, maybe it's possible to do a full build toolchain as well?

Docker is not running on wasm. There's a wasm app, that is a x86_64 CPU emulator, used to run a Linux VM, on top of which anything can run. Including existing Docker images for x86_64.

Sure, fine, if an largely-compliant OCI runtime is running in a wasm-wasi context, then I see no reason you couldn't stub out syscalls to reduce dependence on linux-kernel syscalls, and gradually replace the kernel with a minimal set of stub syscalls that make sense, sort of like how gvisor has implemented 200+ linux syscalls in GO and presents an alternative OCI runtime for docker containers.

Gradually reduce dependence on an emulated linux-kernel in favour of an alternative lightweight POSIX implementation that runs in pure WASM. This is something that is already done with other OCI runtimes like sysbox and gvisor.

Why is that relevant? txdv was suggesting to ditch Linux, so what CPUs Linux supports is not relevant.

If you ditch Linux, you now have to write a kernel, not an application.

There is support in Docker to run wasm-wasi binaries directly (see: https://wasmlabs.dev/articles/docker-without-containers/). The downside compared to OP's approach is that whatever you're running has to have already been compiled to wasm-wasi. The upside would be much faster execution time (no emulation overhead for x86).

Reply on news.ycombinator.com