9 ms·

"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 g

• resonious 2y ago
  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.
    • 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.
• Dalewyn 2y ago
  >But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. So an operating system?
  • klabb3 2y ago
    Yes. Wasm does to my knowledge not have an answer for this, even if some projects patch in their bridge logics. Networking and file systems, and the permission model, is "the rest of the fucking owl". Linux isn't standardized, but at least it's Linux. Without consensus on the fundamental APIs I don't see how we can get to a platform agnostic experience. Even an https call isn't simple: you need TCP and you need to pull root certs from the env, at the very least. Where's the API for that? I hope for a much more near term bright future for WASM: language interop. The lowest common denominator today is C, and doing FFI manually is stone age. If you can leverage WASM for the FFI boundary, perhaps we can build cross language applications that can enjoy the strengths of all libraries, not just those outside of our language silos.
    • cookiengineer 2y ago
      Check out WASI, it's exactly what you are talking about.
  • cookiengineer 2y ago
    Yes and No. Check out the WASI repository. For people not understanding what WASI is, I always tell them it's something like a reference/specification of cross platform syscalls that have to be implemented in WASM VMs. Of course, access to such things always come with assumptions of control and policies that rely on behavioral analysis. So I hope that something similar to host and web application firewall rules will come out of this, similar to how deno does it. [1] https://github.com/WebAssembly/WASI https://github.com/WebAssembly/WASI
• BrouteMinou 2y ago
  I think you meant Java Applets instead of Compile once run everywhere.
  • mrkeen 2y ago
    Right, now it's compile once, don't run on the web.
    • BrouteMinou 2y ago
      Well,for my part it's more: don't even compile, just run somewhere else. Java is cool.
• throwaway7783 2y ago
  You meant Java applets perhaps? Java is still write-once run-anywhere if you stick with its APIs.
• josephg 2y ago
  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 to run it on the browser? Sure! Want to give it r/w access to some particular path? Fine! Or you want to run it "natively", with full access to the host operating system? That can work too! We just ("just") need wasi, and a good set of implementations which support all the different kinds of sandboxing that people want, and allow wasm containers to talk to each other in all the desirable ways. Make no mistake - this is a serious amount of work. But it looks like a very solvable problem. I think the bigger adoption problem will be all the performance you leave on the table by using wasm instead of native code. For all its flaws, docker on linux runs native binaries at native speed. I suspect big companies running big cloud deployments will stick with docker because it runs code faster.
  • danpalmer 2y ago
    This assumes that everyone implements the same set of APIs that work in the same way. More likely, the browser will implement some that make sense there, some browsers will implement more than others, Cloudflare workers will implement a different set, AWS Lambda will implement a different set or have some that don't work the same way... and now you need to write your WASM code to deal with these differing implementations. Unless the API layer is, essentially, a Linux OS or maybe POSIX(?) for Docker, which I doubt it would be as that's a completely different level of abstraction to WASM, I don't have a lot of faith in this being a utopian ideal common API, given that as an industry we've so far failed almost every opportunity to make those common APIs.
    • josephg 2y ago
      True. Its probably worth creating a validation suite for wasi which can check that any given implementation implements all the functions correctly & consistently. Like, I'm imagining a wasm bundle which calls all the APIs it expects in every different configuration and outputs a scorecard showing what works properly and what doesn't. I suspect you're right - unless people are careful, it'll be a jungle out there. Just like javascript is at the moment.
• rr808 2y ago
  ActiveX had this sorted out 25 years ago. Code signing with different levels available for access outside the sandbox controllable by the user.
  • lxgr 2y ago
    And a nice centralized authority that judges the trustworthiness of a given application by staring at a binary extensively?
    • jeremycarter 2y ago
      Sounds good!
    • account42 2y ago
      More like staring at dollar bills. The more bills the more secure the software is.
• 7e 2y ago
  Even containers aren’t really secure. You need a VM boundary.
• okeuro49 2y ago
  > That's what killed the Java write-once, run-anywhere promise. I write Java software on Intel and deploy to an arm device. The promise seems to work for me.
  • account42 2y ago
    Cross compilers have solved this use case for pretty much any language with enough demand. Meanwhile you won't have much luck running Eclipse or any other large Java program on your custom OS or hardware platform if you just port the JRE.
  • yencabulator 2y ago
    That's run-on-the-other-device-I-manage, not run-anywhere. Run-anywhere was used in the meaning of run-by-untrusting-parties, like javascript on the web.
• dathinab 2y ago
  > That's what killed the Java It's a similar but quite different solution. Java - was designed with a lot of tight system integration foremost, sand boxing being secondary - a ton of the sandbox enforcement where checks run in the same VM/code as the code they where supposed to sandbox, like you Java byte code decided if Java byte code should be able to access file IO etc. - Java Applets are, at lest for somewhat more modern standard, a complete security nightmare _in their fundamental design_, not just practically due to a long history of failure. - a lot of the security design was Java focused, but the bytecode wasn't limited to only representing possible Java code - Java "sandboxing" targeted a very different use-case/context the "WASM replace containers" blog is speaking about, mainly the blog is about (maybe micro-) servies while Java sandboxing was a lot about desktop application. I.e. more comparable with flatpack and their sandboxing is also (sadly) more about compatibility then security (snap does that better, but has other issues). And especially the last point one is one to really important as we are not speaking about WASM replacing sandboxing e.g. for dev tools and similar but sandboxing for deployment of micro services written with it in mind. In such context 1. you (should))always run semi trusted code, not untrusted code 2. when giving access to other resources (e.g. file system) it's often in a context where you normally don't need any form of dynamic access management (like you need on a desktop) which means _all the tech underlying to containers can be used with WASI_. Like there is no reason not to still use cgroups, dropping privileges and co integrated in your WASI VM in the same way docker and co uses them. 3. (I kinda thing) there is a (subtle/very slow) trend to not rely only on container isolation but e.g. have a firecracker micro vm run multiple closely coupled containers (a pod/side care container) but place not closely coupled containers in different micro VMs. The true challenge isn't WASI, but that it's competing with docker->kubernets where docker is "one thing fit's all (badly)" solution which can not only run your services but can also run all kind of dev tooling, legacy applications etc. without requiring any changes to them and can (badly but often good enough) simulate your deployment locally with compose. Then to make the competition hard kubernets has been become somewhat of a "standard" interface to deployment, especially in the cloud, this might suck, but also mean you use OIC images both locally in in production. And that is what the WASI for service sandboxing use-case is competing with OIC images and software running them, nut just docker.
  • yencabulator 2y ago
• paul_h 2y ago
  Java's SecurityManager was cool at the start, but over the years there was a steady series of ways to side step it. And now Oracle are wholly deleting it in JDK 25 - https://openjdk.org/jeps/486 https://openjdk.org/jeps/486. It was a stand out feature IMO, and I'll miss it.
• lmm 2y ago
  Java write once run anywhere is fine. Java people don't generally bother with containers because there's no point, the JVM already solves the same problem.
  • bzzzt 2y ago
    Almost all modern Java frameworks specifically target Docker containers in the cloud.
    • afiori 2y ago
      To be fair it is in part due to containers being a really nice way to deploy languages with fat-runtimes.
      • account42 2y ago
        Those fat runtimes are part of the portability lie. Runs everywere ... where the runtime is installed. You can make the same argument for any compiled language if you call QEMU your runtime. And this isn't just theoretical. Games written in compiled languages know to bundle all their dependencies. Games written in Java often expect you to have a JRE. And more often than not "a JRE" means the official Sun JRE (maybe even a specific version range) because too many Java applications use non-portable interfaces.
        • lmm 2y ago
          > You can make the same argument for any compiled language if you call QEMU your runtime. Only if you ship a QEMU-compatible image, and I don't think anyone does. The usability and integration with the host system is too poor. > Games written in compiled languages know to bundle all their dependencies. Games written in Java often expect you to have a JRE. You can't get away from having to have some interface between the host system and the program, but so far the JVM is the least bad one. When laptops started shipping with ARM processors, both docker images and games that had compiled in their dependencies broke, while programs that were shipped as JARs worked fine.
  • 2y ago
• rollcat 2y ago
  > But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. [...] Maybe put the whole thing into a container? Since this is an emerging ecosystem, why not take a different spin on security, and instead try e.g. capabilities? Instead of opening a connection to the DB, or a listening socket, you get FDs from your runtime. Instead of a path where you can read/write files, such as assets or local cache, you get a directory FD from openat (not sure right now if that could be bypassed with "..", but you get the idea). Bonus: you can get hot code reloading for very cheap.
• guappa 2y ago
  I don't think it was killed by security, since nobody cares about security. At most companies care about pretending to do security.