3 ms·

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 contain

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.

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.