10 ms·

>WASM vs a container runtime isn't a meaningful comparison because they're at different layers of the stack. It's not just comparing pure WASM (bytecode) but t

by jasode 3y ago

>WASM vs a container runtime isn't a meaningful comparison because they're at different layers of the stack. It's not just comparing pure WASM (bytecode) but the WASM+WASI (runtime) which is what this article's WasmEdge (runtime) is about. It's a meaningful comparison when the original creator of Docker containers also compared them: >Solomon Hykes / @shykes@hachyderm.io @solomonstre >If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! -- from 2019-03-27t20:39:47 https://twitter.com/solomonstre/status/1111004913222324225 https://twitter.com/solomonstre/status/1111004913222324225

jmillikin 3y ago
> It's not just comparing pure WASM (bytecode) but the WASM+WASI (runtime) WASI isn't a runtime, and it's not a packaging format. It's a standard ABI for a POSIX-like syscall interface, which is useful[0] but doesn't substitute for or relate to container runtimes. You still need a syscall shim to provide the WASI implementation, and you need a WASM VM to run it. > It's a meaningful comparison when the original creator of Docker > containers also compared them: I've seen that quote before and I think it's nonsense. Docker container images are architecture-specific, and it took years before their distribution protocol supported specifying the architecture. If the existence of an architecture-agnostic bytecode would have avoided the need for Docker, then the JVM would have filled that niche perfectly. And if you look at the Docker code, the vast majority is about configuring the runtime environment of the container (networking, bind-mounts, logging) and persisting that state across reboots. There is no syscall shimming like in gVisor or a WASI implementation, it's all about setting up a chroot and then calling `exec()`. If WASM had existed in 2008, maybe the Docker folks would have enabled it as an entry-point format, but you'd still need a way to ship all the other stuff that goes along with the main binary. It's baffling that people feel the need to fabricate ways for WASM/WASI to be important, when the projects themselves are already so interesting. Architecture-agnostic plugins! A clean slate for a capability-based syscall ABI! A genuine chance at running unmodified userland programs in memory-safe sandboxes! Get excited about that, not about someone poorly re-implementing AWS Lambda. [0] Maybe one day most small shell tools will be in WASM+WASI, and the typical Linux distribution will have relatively little native code installed by default.

by jasode 3y ago

jmillikin 3y ago

> It's not just comparing pure WASM (bytecode) but the WASM+WASI (runtime) WASI isn't a runtime, and it's not a packaging format. It's a standard ABI for a POSIX-like syscall interface, which is useful[0] but doesn't substitute for or relate to container runtimes. You still need a syscall shim to provide the WASI implementation, and you need a WASM VM to run it. > It's a meaningful comparison when the original creator of Docker > containers also compared them: I've seen that quote before and I think it's nonsense. Docker container images are architecture-specific, and it took years before their distribution protocol supported specifying the architecture. If the existence of an architecture-agnostic bytecode would have avoided the need for Docker, then the JVM would have filled that niche perfectly. And if you look at the Docker code, the vast majority is about configuring the runtime environment of the container (networking, bind-mounts, logging) and persisting that state across reboots. There is no syscall shimming like in gVisor or a WASI implementation, it's all about setting up a chroot and then calling `exec()`. If WASM had existed in 2008, maybe the Docker folks would have enabled it as an entry-point format, but you'd still need a way to ship all the other stuff that goes along with the main binary. It's baffling that people feel the need to fabricate ways for WASM/WASI to be important, when the projects themselves are already so interesting. Architecture-agnostic plugins! A clean slate for a capability-based syscall ABI! A genuine chance at running unmodified userland programs in memory-safe sandboxes! Get excited about that, not about someone poorly re-implementing AWS Lambda. [0] Maybe one day most small shell tools will be in WASM+WASI, and the typical Linux distribution will have relatively little native code installed by default.