Is this just wrapping ancient POSIX APIs, generally regarded as awful, in WASM? If so, that’s kind of sad, i.e. we’ll have to live with these APIs for another few decades.
That was my reaction as well. With WASM, we have a rare opportunity to build a platform that breaks legacy and provides clean abstractions that weren’t designed for single-core minicomputers, so let’s take advantage of this by directly porting the worst ideas from that world. Oh, and let’s make absolutely share that we don’t think about security at all when we do it. No thanks.
Yes, this is the “Worse is Better” to the Bytecode Alliance’s “The Right Thing”.
They are faster to the market, but also I feel like everybody whose problem looks like “I want to run legacy Linux applications in a lightweight sandbox without source modifications” is already well-served by the container ecosystem.
This is not a Bytecode alliance protocol, so it’s just low quality fragmentation on their part. No one else is going to support it. Also, that company is generally malicious.
I disagree. It’s exactly the kind of poorly designed nonsense that solves immediate problems (how do I run this program that assumes a Linux host in a WASM environment without any porting) and creates massive amounts of technical debt along the way that usually succeeds in the market.
As a previous insider, I assure you companies are not very interested in running stuff in wasm. The only interest that existed (back then at least) was from the cryptocurrency hype which has since died. This stuff adds so much tech complexity which no sane person would choose over running containers.
Also, this implementation in particular is written by a guy with no programming/engineering background (look him up) so this technical debt you say may pile up too fast. Company’s a clown show.
Yes but now we can add several more layers of indirection (:
(For real though, the idea is that you compile once to wasm and now it runs anywhere with a wasm runtime. Wasm itself doesn’t have these POSIX-y sharp edges so you couldn’t generally just crosscompile arbitrary tools that expect to be able to do things like fork. This is a feature and not a bug, given the tax such features impose on their environments, but now this project would like to pull Wasm back down into the crab bucket.)
I assumed no connection between “crab bucket” and Rust was intended, given that (1) the metaphor seems to imply that the crab bucket is a bad place to be and (2) Bytecode Alliance seems to be better-regarded.
Is this just wrapping ancient POSIX APIs, generally regarded as awful, in WASM? If so, that’s kind of sad, i.e. we’ll have to live with these APIs for another few decades.
That was my reaction as well. With WASM, we have a rare opportunity to build a platform that breaks legacy and provides clean abstractions that weren’t designed for single-core minicomputers, so let’s take advantage of this by directly porting the worst ideas from that world. Oh, and let’s make absolutely share that we don’t think about security at all when we do it. No thanks.
Yes, this is the “Worse is Better” to the Bytecode Alliance’s “The Right Thing”.
They are faster to the market, but also I feel like everybody whose problem looks like “I want to run legacy Linux applications in a lightweight sandbox without source modifications” is already well-served by the container ecosystem.
Yeah it’s a misguided attempt to make containers from scratch.
This is not a Bytecode alliance protocol, so it’s just low quality fragmentation on their part. No one else is going to support it. Also, that company is generally malicious.
I disagree. It’s exactly the kind of poorly designed nonsense that solves immediate problems (how do I run this program that assumes a Linux host in a WASM environment without any porting) and creates massive amounts of technical debt along the way that usually succeeds in the market.
As a previous insider, I assure you companies are not very interested in running stuff in wasm. The only interest that existed (back then at least) was from the cryptocurrency hype which has since died. This stuff adds so much tech complexity which no sane person would choose over running containers.
Also, this implementation in particular is written by a guy with no programming/engineering background (look him up) so this technical debt you say may pile up too fast. Company’s a clown show.
I am especially saddened by inclusion of proc_fork. Have we learned nothing?
I don’t understand. Isn’t this what the operating system does already?
Yes but now we can add several more layers of indirection (:
(For real though, the idea is that you compile once to wasm and now it runs anywhere with a wasm runtime. Wasm itself doesn’t have these POSIX-y sharp edges so you couldn’t generally just crosscompile arbitrary tools that expect to be able to do things like
fork. This is a feature and not a bug, given the tax such features impose on their environments, but now this project would like to pull Wasm back down into the crab bucket.)Given that both Wasmer and Bytecode Alliance’s Wasmtime use Rust, this seems an unfortunate metaphor. :-)
Oh my goodness, that wasn’t even intentional :D
I assumed no connection between “crab bucket” and Rust was intended, given that (1) the metaphor seems to imply that the crab bucket is a bad place to be and (2) Bytecode Alliance seems to be better-regarded.