NilsIRL

> I did this before I learned how to finish projects

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

How does one learn this skill?

I moved zig-clap to zon. Was alright. I appreciate that absence of a package registry.

I thought it was an acceptable trade-off given that AppImage has the same limitation.

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

don't give me ideas ;) (yes)

They have the same goal but achieve it differently.

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.

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.

I hadn't heard of Apptainer/Singularity before but it doesn't seem to provide the ability to create standalone executables.

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

Yeah, I don't think this makes that much sense for internal distribution. Especially if you use kubernetes.

The use case is for distributing software to end users.