Comments URL: https://news.ycombinator.com/item?id=40545657

Points: 4

# Comments: 0

Very curious about this. As do many people I struggle to finish projects.

How does one learn this skill?

As for WASM, this is already possible using container2wasm[0] and wasmer[1]'s ability to generate static binaries.

[0]: https://github.com/ktock/container2wasm

[1]: https://wasmer.io/

An alternative is to extract the image to disk but that has quite a bit of overhead.

dockerc allows you to re-use your existing docker images without having to spend time packaging something up.

The applications running from dockerc-generated executables run inside a container so they are guaranteed to be hermetic.

> 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.

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.

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.

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 use case is for distributing software to end users.

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

[0]: https://treehacks.com/

[1]: https://github.com/NilsIrl/dockerc/blob/68b0e6dc40e76c77ad0c...

> Will this run ok on a Mac?

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.

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`.

Enough for the executables to run everywhere. So I'm happy for system libraries to be dynamically linked.

> But do you even want to distribute Windows binaries?

That's what I'm imagining. A windows binary that starts a Linux VM in which the container runs.

> Does this include automagically mounting filesystems?

Yep, inside of the Linux kernel. Here's what PID 1 looks like: https://github.com/NilsIrl/dockerc/blob/non_linux/src/init.z...

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.

[0]: https://developer.apple.com/documentation/virtualization

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.

[0]: https://github.com/shepherdjerred/macos-cross-compiler [1]: https://hub.docker.com/_/python