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

1. Pick something small that you know you can finish.

2. Finish it.

3. Feel the rush of actually finish something!

4. Repeat.

Ok, not that easy but that is how I got around to it eventually.

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.

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

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

That's interesting. Thanks for clarifying how it works and pointing to container2wasm and how it can be used. I guess if you had a Cosmopolitan WASM VM runner built into Dockerc or similar that bundled the WASM images with a cross-platform binary with the VM and image?

As someone who's not overly familiar with Docker, how big are these executables in the end?

Edit: This was already answered here https://news.ycombinator.com/item?id=39622184

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.

Great! Thank you for dissolving my doubts.

About Zon, I was just curious if you had any issues with it. I also need to finally start using it in my small projects.

Good luck with Zig!

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

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.

Singularity absolutely produces standalone executables, been building tools this way for years.

How? I've used Apptainer pretty extensively for a couple years and as far as I know the machine where it runs has to have Apptainer installed, even when executing sif files like a normal app.

I stand corrected, yes, you need run-singularity to be installed to execute the image, i completely forgotten.

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.