Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM will replace containers

creston.blog

Post reply on HN
Print view View original

331–340 of 371 posts

Re: WASM will replace containers

#331

Post by yencabulator »

josephg wrote: post #95
not2b wrote: post #13

"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…

True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…

> half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime.

This is a serious misunderstanding of how containers work.

Containers make syscalls. The Linux kernel serves them. Linux kernel has features that let one put userspace processes in namespaces where they don't see everything. There is no "routing". There is no "its own filesystem and network", just a namespace where only some of the host filesystems and networks are visible. There is no second implementation of the syscalls in that scenario.

For WASM, someone has to implement the server-side "file I/O over WASI", "network I/O over WASI", and so on. And those APIs are likely going to be somewhat different looking than Linux syscalls, because the whole point is WASM was sandboxing.

Quite far from "pretty easy".

Re: WASM will replace containers

#332

Post by yencabulator »

p12tic wrote: post #167
gchamonlive wrote: post #53

Earlier quoted context omitted.

So basically virtual machines, those we can spin up with lxd or firecracker. Not that they don't have file access, it's just that's finnicky compared to containers (I'm thinking docker/podman)

One can use something like https://github.com/google/gvisor as a container runtime for podman or docker. It's a good hybrid between VMs and containers. The container is put into sort of VM via kvm, but it does not supply a kernel and talks to a fake one. This means that security boundary is almost as strong as VM, but mostly everything will work like in a normal container. E.g. here's I can read host filesystem even…

Meanwhile, Google moved away from gVisor, because they had too much trouble trying to make it look like actual Linux :-(

https://cloud.google.com/blog/products/serverless/cloud-run-...

Between this and WLS1, trying to reimplement all Linux syscalls might not lead to a good experience for running preexisting software.

Re: WASM will replace containers

#333

Post by Capricorn2481 »

pjmlp wrote: post #202
hardwaresofton wrote: post #175

Earlier quoted context omitted.

> I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Yes, this is a key value of WebAssembly compared to other approaches, it is a relatively (compared to a container or a full blown VM) lightweight way to package and…

IronPython alongside C++/CLI on the CLR, everything compiled down to MSIL bytecodes.

I could be wrong, but I can't find anything about how to include your C dependencies with IronPython when you compile. Instead I see that IronPython has limited compatibility with the Python ecosystem because of Python libraries using C.

Contrasted with WASM where you can write in any language and bring the ecosystem with you, since it all compiles down.

Re: WASM will replace containers

#334

Post by milesrout »

int_19h wrote: post #324
milesrout wrote: post #264

Earlier quoted context omitted.

Hardware video decoding has worked perfectly for decades. Sleep worked perfectly until Microsoft decided that device manufacturers should replace sleep with overheating in your bag (a much better sleep mode than, y'know, actual SLEEP). Not sure what "modern UEFI features" means. Whenever something is described as "modern" that screams to me that someone is trying to conflate recentness with quality which is a red fla…

As things are, all browser developers - including Firefox! - disable hardware acceleration on most video cards in their browsers on Linux because it is "too unstable". The result is a 20% difference in battery life between Linux and Windows if you mostly do browsing.

Never experienced this myself, and I have used discrete and integrated graphics cards from a variety of manufacturers.

Meanwhile on Windows I am not exaggerating when I say that every computer I have owned and every peripheral device I have ever used has had serious issues. Wireless headphones randomly disconnect, microphones require frequent unplug-replug cycles, rebooting is often required, reinstalling is common. Mice and keyboards have weird compatibility issues with software drivers. This experience is shared with most people I know that I have discussed it with. People are just used to it.

Maybe it isn't Linux that is the problem. Maybe the problem is that consumer hardware is designed and built on the cheap and is not designed to last, and they get away with it because most people (1) have no idea it could be so much better and (2) have no insight into these issues before buying because they are rarely covered in reviews.

For some reason when this happens on Windows, the hardware is to blame, but when it happens on Linux, Linux is to blame.

Re: WASM will replace containers

#336

Post by tonymet »

My boomeritis flares up when I hear someone trying to sell me on 10x-ing instructions . I think we need a new unit of inefficiency called Matrioschkas . The Swedes call this Torta-på-Torta or a cake in a cake (in a cake..)

Re: WASM will replace containers

#337

Post by gedw99 »

tyingq wrote: post #91
Capricorn2481 wrote: post #73

Earlier quoted context omitted.

I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob. Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?

The closest way to visualize it is probably how cloudflare offers something kind of like a container (if you squint) via it's workers product. https://blog.cloudflare.com/announcing-wasi-on-workers/ I assume the merit for cloudflare is lower overhead cost per worker than if they had done something more like AWS lambda. Explained better than I can, here: https://developers.cloudflare.com/workers/reference/how-work...…

I run my golang on car workers.

It does not work with wasi.

I just use a simple driver:

https://github.com/syumai/workers

Wasi is so painful that I just write all my golang using stdio and have a shim per runtime. Web browser, Cloudflare, server ( with wazero ).

The new go:wasmexport might be useful in go 1.24 but I highly doubt by it.

Re: WASM will replace containers

#338

Post by hardwaresofton »

Capricorn2481 wrote: post #333
pjmlp wrote: post #202

Earlier quoted context omitted.

IronPython alongside C++/CLI on the CLR, everything compiled down to MSIL bytecodes.

I could be wrong, but I can't find anything about how to include your C dependencies with IronPython when you compile. Instead I see that IronPython has limited compatibility with the Python ecosystem because of Python libraries using C. Contrasted with WASM where you can write in any language and bring the ecosystem with you, since it all compiles down.

Fully agree with your point here, but wanted to point out that including C dependencies is actually one of the biggest reasons why Python support is hard for WebAssembly too.

Bolstering your point -- smart-and-hardworking people are working on this, which results in:

https://github.com/bytecodealliance/componentize-py/

which inspired

https://github.com/WebAssembly/component-model/blob/main/des...

with some hard work done to make things work:

https://github.com/dicej/wasi-wheels

It's a fun ecosystem -- the challenge is huge but the work being done is really fundamentally clean/high quality, and the solutions are novel and useful/powerful.

Re: WASM will replace containers

#339

Post by zfg »

algorithmsRcool wrote: post #311
zfg wrote: post #195

Earlier quoted context omitted.

It's doesn't. It's just another compilation target along side x86 and ARM and friends.

Yes, but now you are going through another translation (aka V8) layer in order to get down to x86 or ARM. You just have to hope that the optimizer of this translation layer is at least as smart as what you had before.

How is that worse than JavaScript?

x86 and ARM compilation don't go away. WebAssembly is an additional option.

Post reply on HN