4 ms·

This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.

gchamonlive 2y ago
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)
- hardwaresofton 2y ago
  Yes, but note the difficulty of building a specialized I/O or drivers for controlling access in a virtual machine versus the WASI model. Also, startup times are generally better w/ availability of general metering (fuel/epochs) for example. The features of Wasm versus a virtual machine are similar but there are definitely unique benefits to Wasm. The closer comparison is probably the JVM -- but with support for many more languages (the list is growing, with upstream support commonplace).
  - pjmlp 2y ago
    https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/IBM_i#TIMI https://en.m.wikipedia.org/wiki/IBM_i#TIMI Really this is only new for those that weren't around, many other examples, even older available.
    - hardwaresofton 2y ago
      Except developers have consistently chosen not to embed the JVM, CLR, or IBMi. wasmtime (the current reference runtime implementation) is much more embeddable than these other options were/are, and is trivially embeddable in many languages today, with good performance. On top of being an option, it is being used, and WebAssembly is spreading cross-language, farther than the alternatives ever reached. These things may look the same, but just like ssh/scp and dropbox, they're not the same once you zoom/dig in to what's different this time.
      - pjmlp 2y ago
        As if developers are consistently chosing to embedd WASM, just wait after the hype cycle dies. What we have now is lots of hype, mostly by folks clueless of their history, in the venture to sell their cool startup idea based on WASM.
        hardwaresofton 2y ago
        > As if developers are consistently chosing to embedd WASM, just wait after the hype cycle dies. > > What we have now is lots of hype, mostly by folks clueless of their history, in the venture to sell their cool startup idea based on WASM. I don't think there's much of a hype cycle -- most of the air has been sucked out of the room by AI. There aren't actually that many Wasm startups, but there are companies leveraging it to great success, and some of these cases are known. There is also the usefulness of Wasm as a target, and that is growing -- languages are choosing to build in the ability to generate wasm bytecode, just as they might support a new architecture. That's the most important part that other solutions seemingly never achieved. The ecosystem is aiming for a least-changes-necessary approach -- integrating in a way that workflows and existing code does not have to change. This is a recipe for success. I think it's a docker-shaped adoption curve -- most people may not think it is useful now, but it will silently and usefully be everywhere later. At some point, it will be trivial to ship a small WASM binary inside (or independent of) a container, and that will be much more desirable than building a container. The artifact will be smaller, more self-describing, work with language tooling (i.e. a world without Dockerfiles), etc.
        afiori 2y ago
        I believe that the two most likely futures for the wasm-as-puglin-engine are mod in games and applications with a generic extension interface. IMO in games developers would prefer something with a reasonable repl like lua or javascript (as a game is already assumed to be heavy if the mods are not performance critical running a V8 should not be a problem) for extensions in generic complex applications (things like, VSCode, Blender, Excel, etc.) I would posit that the wasm sandbox could be a really good way to enable granular-permission secure extenstion.
- p12tic 2y ago
  One can use something like https://github.com/google/gvisor 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 though uname says weird things about the kernel container is running in: $ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash root@7862d7c432b4:/# ls /app bin home lib32 mnt run tmp vmlinuz.old boot initrd.img lib64 opt sbin usr dev initrd.img.old lost+found proc srv var etc lib media root sys vmlinuz root@7862d7c432b4:/# uname -a Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux Gvisor let's one have strong sandbox without resorting to WASM.
  - yencabulator 2y ago
    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-jobs-and-second-generation-execution-environment-ga 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.
Capricorn2481 2y ago
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?
- tyingq 2y ago
  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/ 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-workers-works/ https://developers.cloudflare.com/workers/reference/how-work... It does currently present a lot of restrictions as compared to what you could do in a container. But it's good enough to run lots of real world stuff today.
  - pjmlp 2y ago
    Even closer WebLogic, WebSphere, JBoss, Glassfish in 2002, but now instead of a EAR file, it is a WASM one.
  - gedw99 2y ago
    I run my golang on car workers. It does not work with wasi. I just use a simple driver: https://github.com/syumai/workers 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.
- hardwaresofton 2y ago
  > 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 distribute functionality from other languages, with high performance and fast startup. The artifact is minimal (like a static/dynamic library, depending on how much you've included), and if your language has a way to run WASM, you have a way to tap into that specialized computation.
afiori 2y ago
The idea with wasi containers is that you could spin up a container with only the interfaces it needs.

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)

hardwaresofton 2y ago
Yes, but note the difficulty of building a specialized I/O or drivers for controlling access in a virtual machine versus the WASI model. Also, startup times are generally better w/ availability of general metering (fuel/epochs) for example. The features of Wasm versus a virtual machine are similar but there are definitely unique benefits to Wasm. The closer comparison is probably the JVM -- but with support for many more languages (the list is growing, with upstream support commonplace).
- pjmlp 2y ago
  https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_JVM_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/List_of_CLI_languages https://en.m.wikipedia.org/wiki/IBM_i#TIMI https://en.m.wikipedia.org/wiki/IBM_i#TIMI Really this is only new for those that weren't around, many other examples, even older available.
  - hardwaresofton 2y ago
    Except developers have consistently chosen not to embed the JVM, CLR, or IBMi. wasmtime (the current reference runtime implementation) is much more embeddable than these other options were/are, and is trivially embeddable in many languages today, with good performance. On top of being an option, it is being used, and WebAssembly is spreading cross-language, farther than the alternatives ever reached. These things may look the same, but just like ssh/scp and dropbox, they're not the same once you zoom/dig in to what's different this time.
    - pjmlp 2y ago
      As if developers are consistently chosing to embedd WASM, just wait after the hype cycle dies. What we have now is lots of hype, mostly by folks clueless of their history, in the venture to sell their cool startup idea based on WASM.
      - hardwaresofton 2y ago
        > As if developers are consistently chosing to embedd WASM, just wait after the hype cycle dies. > > What we have now is lots of hype, mostly by folks clueless of their history, in the venture to sell their cool startup idea based on WASM. I don't think there's much of a hype cycle -- most of the air has been sucked out of the room by AI. There aren't actually that many Wasm startups, but there are companies leveraging it to great success, and some of these cases are known. There is also the usefulness of Wasm as a target, and that is growing -- languages are choosing to build in the ability to generate wasm bytecode, just as they might support a new architecture. That's the most important part that other solutions seemingly never achieved. The ecosystem is aiming for a least-changes-necessary approach -- integrating in a way that workflows and existing code does not have to change. This is a recipe for success. I think it's a docker-shaped adoption curve -- most people may not think it is useful now, but it will silently and usefully be everywhere later. At some point, it will be trivial to ship a small WASM binary inside (or independent of) a container, and that will be much more desirable than building a container. The artifact will be smaller, more self-describing, work with language tooling (i.e. a world without Dockerfiles), etc.
      - afiori 2y ago
        I believe that the two most likely futures for the wasm-as-puglin-engine are mod in games and applications with a generic extension interface. IMO in games developers would prefer something with a reasonable repl like lua or javascript (as a game is already assumed to be heavy if the mods are not performance critical running a V8 should not be a problem) for extensions in generic complex applications (things like, VSCode, Blender, Excel, etc.) I would posit that the wasm sandbox could be a really good way to enable granular-permission secure extenstion.
p12tic 2y ago
One can use something like https://github.com/google/gvisor 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 though uname says weird things about the kernel container is running in: $ sudo podman run -it --runtime=/usr/bin/runsc_wrap -v /:/app debian:bookworm /bin/bash root@7862d7c432b4:/# ls /app bin home lib32 mnt run tmp vmlinuz.old boot initrd.img lib64 opt sbin usr dev initrd.img.old lost+found proc srv var etc lib media root sys vmlinuz root@7862d7c432b4:/# uname -a Linux 7862d7c432b4 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016 x86_64 GNU/Linux Gvisor let's one have strong sandbox without resorting to WASM.
- yencabulator 2y ago
  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-jobs-and-second-generation-execution-environment-ga 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.

Capricorn2481 2y ago

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?

tyingq 2y ago
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/ 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-workers-works/ https://developers.cloudflare.com/workers/reference/how-work... It does currently present a lot of restrictions as compared to what you could do in a container. But it's good enough to run lots of real world stuff today.
- pjmlp 2y ago
  Even closer WebLogic, WebSphere, JBoss, Glassfish in 2002, but now instead of a EAR file, it is a WASM one.
- gedw99 2y ago
  I run my golang on car workers. It does not work with wasi. I just use a simple driver: https://github.com/syumai/workers 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.
hardwaresofton 2y ago
> 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 distribute functionality from other languages, with high performance and fast startup. The artifact is minimal (like a static/dynamic library, depending on how much you've included), and if your language has a way to run WASM, you have a way to tap into that specialized computation.

afiori 2y ago

The idea with wasi containers is that you could spin up a container with only the interfaces it needs.