Unfortunately cosmopolitan wouldn't work for dockerc. Cosmopolitan works as long as you only use it but container runtimes require additional features. Also containers contain arbitrary executables so not sure how that would work either...
As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.
I don't expect this to interact with the docker daemon in any way. With networking executables generated by dockerc behave in the same way as a native application running outside a container.
> What about using Zon for deps, instead of a git submodule?
I couldn't find documentation quickly enough (dockerc was initially during a hackathon and was my first time using Zig). I plan to fix this eventually.
dockerc can, the produced executables cannot, at least not without some tweaking.
Even if you path through `/dev/fuse` and `/usr/bin/fusermount3` (using -v) it fails the mount the fuse filesystems with the error message "Operation not permitted".
It might be possible to make it work if it falls back to extracting the container when failing the mount the fuse filesystems.
> Running on Windows/macOS was also the context in which I meant to ask about filesystem mounts.
That's not an issue because the mounts are within the Linux VM. At least as long as you're not trying to implement volumes.
> I understand this is not something that's implemented yet, but I'm wondering about your goals.
Make a better alternative for all the projects that suggest using `docker run` in their READMEs. Something that's easy to setup (re-use existing Dockerfiles) and something that doesn't depend on pre-existing setup from the user (which docker does).
> The much larger hurdle I see for Windows support is that I don't think you can setup virtualization without Admin privileges in the general case. If Hyper-V is not already present and enabled you'll need to install some hypervisor. Even QEMU needs Hyper-V for proper virtualization.
That's good to know. I didn't know that. I guess it will need to use emulation in some cases then.
That's really cool. I didn't know about that. Thanks for sharing.
There's a few things that seem to make it unsuitable for the intended use case of dockerc:
* The container extracts itself which means there is quite a bit of overhead for large images. dockerc-built executables have the same startup time whether the image is 2.2GB or 25MB.
* The executables produced by enroot don't seem suitable for running standalone. At least the example doesn't seem to suggest so.
The main reason Zig was chosen is because the project was started at a hackathon[0] at which there was a prize for "best use of Zig". Beyond that there were also other reasons: 1. I have been wanting to try out Zig 2. It fit the requirement of being a so called "systems language".
However having written it in Zig I have a few retroactive reasons for why Zig was a good choice (if not the best choice):
* The build system allows to make the runtime a dependency of the "compiler". I don't think any other language has that.
* The interoperability with C/systems calls is amazing (in comparison to anything but C/C++)
* The ability to embed files
* Makes it incredibly easy to make static binaries
I've managed to make it work but unfortunately not in a way that produces portable binaries. I just need to figure out how to selectively statically link some of the QEMU dependencies or write a runtime that uses Apple's VirtualizationFramework.
> How do you deal with resource sharing? This starts with just filesystem mounts, but also concerns ports, possibly devices, and probably many other things I'm forgetting. Is this somehow configurable?
I'm not too sure what resources you're talking about in general. Mounts are in a temporary location so they shouldn't conflict. Each container uses 2 when it is running. In terms of ports, you won't be able to have multiple applications using the same port (whether they are built with dockerc or not). As for devices I don't think there's any issues there.
> How does this compare to AppImage? IIRC that also puts everything into a squashfs.
It's very similar to AppImage in spirit. I haven't looked at the AppImage implementation but I suspect a lot of things are similar.
The difference with AppImage is that this makes it trivial to convert existing docker images into something that can run as an executable. It also offers stronger hermeticity guarantees as the application runs inside of a container.
> If a user without CAP_SYS_USER_NS executes one of the binaries built by dockerc, do you handle that gracefully in any way?
It's not something I've paid much attention to. This falls back to the container runtime which currently outputs "clone: Operation not permitted" when ran with `sudo sysctl -w kernel.unprivileged_userns_clone=0`.
> It would make sense that a tool like this would prioritize MacOS/Windows support above all else.
Yep, unfortunately I've not had the time to make it work well on those platforms. I got an initial demo working on MacOS but I'm currently facing the issue that I'm unable to statically compile QEMU on MacOS. I've also started writing a VirtualizationFramework[0] based backend.
> Why would QEMU even necessary? Docker runs fine on Windows.
When docker runs on Windows/MacOS it's actually running the containers in a Linux VM. Containers rely on features provided by the Linux kernel.
> Maybe it's to avoid requiring the user to install Docker?
The main reason to use dockerc is to avoid the user having to install Docker.
> Either way, asking the user to fiddle with Hyper-V settings is bad UX.
Yep I don't think that would be nice. I expect the experience to be transparent to the user.
It will depend heavily on the docker image you're trying to ship. For example with macos-cross-compiler[0] the resulting binary is over 2GB. With python:alpine[1] it's only 25MB.
Because the image isn't copied whether the image is 2GB or 25MB the startup time will be nearly instantaneous for both.
The runtime adds 6-7MB of overhead although I expect that this can be reduced to less than 3MB with some work.
Very curious about this. As do many people I struggle to finish projects.
How does one learn this skill?