Interesting, to use docker as way to package and run wasm stuff. Actually makes sense from the point of view that it's yet another thing that needs networking, security, etc. Why reinvent all that when we already have docker, docker-compose, kubernetes, etc. as an API to drive all of that. It doesn't matter if underneath it uses wasmer instead of whatever kernel containerization is used for docker, or both. It's just another process that launches.
And it kind of solves cross platform distribution since unlike docker images, these should run pretty much on any cpu architecture (as long as it has a wasm runtime).
Give me an open source version of this program that runs in CLI and we’ll talk. I think it’s insane that a dev tool in this (low level) category and with this level of popularity is not only closed source but also GUI. I can’t think of any other major tool with those characteristics.
I’m on the fence about WASM. The capabilities are impressive, but webpacked JS already nips at the paradigm we had where users could see a legible version of website code running on their computer and WASM makes the problem worse.
What you are saying is that de daemon isn't a separate service but only runs as part of the GUI. Also on *nix the Docker CLI talks to the daemon. The difference is how the daemon is hosted.
Only on Mac and windows since they require a Linux VM. On (Ubuntu 22.04 lts server for example) you can still just apt-get install docker.io, add your user to the docker group and call it a day.
This works because most container runtimes are self-contained Go binaries. Haven't used the wasm runtime yet, so not sure if that is true for this runtime as well.
If one wants to use exactly the same command line, then one could compile https://github.com/second-state/runwasi, and place the compiled shim in the correct path.
The difference vs deislabs shims you linked or vs the containerd/runwasi (formerly deislabs/runwasi) is the exact wasm runtime used.
secondstate (that Docker Desktop includes) uses WasmEdge, containerd/runwasi uses wasmtime, and deislabs/containerd-wasm-shims uses Fermyon Spin or SpiderLighting depending on which shim you use.
Podman also has an open-source GUI project called Podman Desktop going on, in addition to their CLI: https://podman-desktop.io/
Oh and in the same space there is Rancher Desktop as well (which has the excellent K3s under the hood): https://rancherdesktop.io/
Personally, I'll probably keep using Docker Desktop on some platforms anyways as long as there won't be licensing issues, because it's just so boring and (mostly) stable at this point.
> docker desktop is pretty dead now that it's got restrictive licensing etc...
It would probably be nice to hear more about why you think this is! I've certainly heard of some having to move away from Docker Desktop.
However, at the scale where you need a license (250 employees or 10 million $ in annual revenue) it's not quite as big of an issue, especially at their current pricing per seat: https://www.docker.com/pricing/
> stick to standard open source tools like Colima etc...
A large market share of the Docker Desktop installs are Windows in particular (since it's "the one way" how most install Docker nowadays, as opposed to not really needing a GUI or the supporting tools on Linux).
Regardless, it's nice to see reputable orgs behind the open source projects as well, which gives a bit more credence to their chances of surviving for the years to come.
That said, the current options are pretty low level (i.e. trying to get nerdctl running), versus the developer experience that many are familiar with.
I don't doubt that it will have some effect on Docker's market share, but saying that "Docker Desktop is pretty dead now" is perhaps getting ahead of oneself.
If anything, Podman and Rancher will have more influence in the near term, because they're (more) fully fledged and can be used today, instead of relying on software that's still very much in early active development and might have plenty of breaking changes. Not that their desktop offerings are there yet, either.
I haven't messed with WASM yet but I do love the idea of being able to build something that targets wasm/wasi with Docker like I'm already doing today and still package all of its dependencies into a single Docker image.
I also love the fact that code that targets wasm can run in a browser or on the machine in an isolate without hard forking.
Re: TUF, Sigstore, W3C DIDs, CT Certificate Transparency logs, W3C Web Bundles; and reinventing the signed artifact wheel:
https://news.ycombinator.com/item?id=30682329 ("Podman can transfer container images without a registry")
Just because something existed before something else doesn't mean a competitor can't spring up and have more momentum. It feels like the JVM is massively falling behind and it loses out massively on things like memory efficiency.
"NestedVM provides binary translation for Java Bytecode. This is done by having GCC compile to a MIPS binary which is then translated to a Java class file. Hence any application written in C, C++, Fortran, or any other language supported by GCC can be run in 100% pure Java with no source changes."
VOC transpiles Python to Java bytecode. Py2many transpiles Python to many languages but not yet Java.
Apache Arrow can do IPC to share memory references to structs with schema without modification between many languages now; including JS and WASM. https://arrow.apache.org/
Browsers could run WASM containers, too. How does the browser sandbox+ WASM runtime sandbox (that lacks WASI) compare to the security features of Linux containers?
Are there relative performance benchmarks that help estimate the overhead of the WASM-recompilation and runtime? How much slower is it to run the same operations with the same code in a runtime with WASI support?
Are there cgroups and other container features for WASM applications?
Is there any way to tell whether an unsigned WASM bundle is taking 110% of CPU in a browser tab process?
Do browser tabs yet use cgroups functionality to limit resource exhaustion risks?
Should we be as confident in unsigned WASM in a WASM runtime as with TUF-signed containers?
28 comments
[ 2.8 ms ] story [ 75.7 ms ] threadAnd it kind of solves cross platform distribution since unlike docker images, these should run pretty much on any cpu architecture (as long as it has a wasm runtime).
That post links to the announcement in Docker's blog, which links to the link of op.
I’m on the fence about WASM. The capabilities are impressive, but webpacked JS already nips at the paradigm we had where users could see a legible version of website code running on their computer and WASM makes the problem worse.
Once this GUI app is running, you can interact with it via CLI.
It seems like it may still be possible, albeit a bit more fiddly work: https://medium.com/crowdbotics/a-complete-one-by-one-guide-t...
If you just want to replace the desktop management portion you can look into https://podman-desktop.io/ Or even https://multipass.run/
Both will get you to a docker host from the desktop.
In your VM or WSL instance that's running Docker, get the shim from here: https://github.com/deislabs/containerd-wasm-shims (You might need to build it yourself)
Then specify the --runtime and --platform arguments like instructed in the doc, but with a slight modification:
This works because most container runtimes are self-contained Go binaries. Haven't used the wasm runtime yet, so not sure if that is true for this runtime as well.The difference vs deislabs shims you linked or vs the containerd/runwasi (formerly deislabs/runwasi) is the exact wasm runtime used.
secondstate (that Docker Desktop includes) uses WasmEdge, containerd/runwasi uses wasmtime, and deislabs/containerd-wasm-shims uses Fermyon Spin or SpiderLighting depending on which shim you use.
Oh and in the same space there is Rancher Desktop as well (which has the excellent K3s under the hood): https://rancherdesktop.io/
Personally, I'll probably keep using Docker Desktop on some platforms anyways as long as there won't be licensing issues, because it's just so boring and (mostly) stable at this point.
It would probably be nice to hear more about why you think this is! I've certainly heard of some having to move away from Docker Desktop.
However, at the scale where you need a license (250 employees or 10 million $ in annual revenue) it's not quite as big of an issue, especially at their current pricing per seat: https://www.docker.com/pricing/
> stick to standard open source tools like Colima etc...
Sticking to open source is a great idea!
I think mentioning that Colima runs on macOS and Linux only at the moment is also a good idea: https://github.com/abiosoft/colima
A large market share of the Docker Desktop installs are Windows in particular (since it's "the one way" how most install Docker nowadays, as opposed to not really needing a GUI or the supporting tools on Linux).
In another comment I mentioned Podman Desktop as a mostly viable alternative: https://github.com/containers/podman-desktop
Then there's also Rancher Desktop as well: https://github.com/rancher-sandbox/rancher-desktop
Regardless, it's nice to see reputable orgs behind the open source projects as well, which gives a bit more credence to their chances of surviving for the years to come.
I expect Docker Desktop to lose relevance for Windows workloads as soon as containderd on Windows reaches feature parity with its Linux version.
That said, the current options are pretty low level (i.e. trying to get nerdctl running), versus the developer experience that many are familiar with.
I don't doubt that it will have some effect on Docker's market share, but saying that "Docker Desktop is pretty dead now" is perhaps getting ahead of oneself.
If anything, Podman and Rancher will have more influence in the near term, because they're (more) fully fledged and can be used today, instead of relying on software that's still very much in early active development and might have plenty of breaking changes. Not that their desktop offerings are there yet, either.
I haven't messed with WASM yet but I do love the idea of being able to build something that targets wasm/wasi with Docker like I'm already doing today and still package all of its dependencies into a single Docker image.
I also love the fact that code that targets wasm can run in a browser or on the machine in an isolate without hard forking.
How is WASM distinct from an unsigned binary blob?
https://docs.oracle.com/javase/7/docs/technotes/tools/window...
Re: TUF, Sigstore, W3C DIDs, CT Certificate Transparency logs, W3C Web Bundles; and reinventing the signed artifact wheel: https://news.ycombinator.com/item?id=30682329 ("Podman can transfer container images without a registry")
From "HTTP Messages Signatures" (~SXG) https://news.ycombinator.com/item?id=29281449 :
> blockcerts/cert-verifier-js ?
blockchain-certificates/cert-verifier-js: https://github.com/blockchain-certificates/cert-verifier-js
Just because something existed before something else doesn't mean a competitor can't spring up and have more momentum. It feels like the JVM is massively falling behind and it loses out massively on things like memory efficiency.
"NestedVM provides binary translation for Java Bytecode. This is done by having GCC compile to a MIPS binary which is then translated to a Java class file. Hence any application written in C, C++, Fortran, or any other language supported by GCC can be run in 100% pure Java with no source changes."
With greetings from 2006, http://nestedvm.ibex.org/
VOC transpiles Python to Java bytecode. Py2many transpiles Python to many languages but not yet Java.
Apache Arrow can do IPC to share memory references to structs with schema without modification between many languages now; including JS and WASM. https://arrow.apache.org/
FWIU Service Workers and Task Workers and Web Locks are the browser APIs available for concurrency in browsers and thus WASM. https://github.com/jupyterlab/jupyterlab/issues/1639#issueco...
"WebVM" https://news.ycombinator.com/item?id=30168491 :
> Is WebVM a potential solution to "JupyterLite doesn't have a bash/zsh shell"? [Or Git; though there's already isomorphic-git in JS]
"WebGPU" https://news.ycombinator.com/item?id=30601415
Emscripten-compiled WASM can be packaged with ~conda packages and built and hosted by emscripten-forge ( which works like conda-forge, which has Python, R, Julia, Rust) to be imported from JS and WASM. Here's the picomamba recipe.yml on emscripten-forge: https://github.com/emscripten-forge/recipes/blob/main/recipe... and for CPython: https://github.com/emscripten-forge/recipes/blob/main/recipe...
Browsers could run WASM containers, too. How does the browser sandbox+ WASM runtime sandbox (that lacks WASI) compare to the security features of Linux containers?
How do the docstrings look after transpilation?
Are there cgroups and other container features for WASM applications?
Is there any way to tell whether an unsigned WASM bundle is taking 110% of CPU in a browser tab process?
Do browser tabs yet use cgroups functionality to limit resource exhaustion risks?
Should we be as confident in unsigned WASM in a WASM runtime as with TUF-signed containers?