This is really great.<p>I have been trying to get my docker to be more distributable. Right now it's just a simple python script in a python env inside a docker container inside a QEMU container to automate a click and then netcat something.<p>Pretty sweet. It's only like 20GB, so pretty lightweight by modern standards.
I absolutely love how we are going full circle to portable executable binaries but with embedded OS. Taking the whole "it works on my machine" to a whole new level of troubleshooting hell.<p>Awesome project though.
In the past I've used and recommended nix-bundle¹ or its first-party counterpart `nix bundle`² for this. That lets you skip the step of managing the creation of the Docker image, which is nice.<p>I suppose dockerc could be convenient when you already have a Docker image on hand, especially if it was a PITA to create or its creation is a lost art.<p>Besides fat executables, `nix bundle` also lets you create Docker images, AppImages, and images/executables in a few other formats.<p>--<p>1: <a href="https://github.com/matthewbauer/nix-bundle">https://github.com/matthewbauer/nix-bundle</a><p>2: <a href="https://nixos.org/manual/nix/unstable/command-ref/new-cli/nix3-bundle.html" rel="nofollow">https://nixos.org/manual/nix/unstable/command-ref/new-cli/ni...</a>
The Reddit screenshot is hilarious. But it reflects my feelings whenever I want to install a product made by many of these self-proclaimed "open source" companies that bend over backwards to make it almost impossible to install the open version (...and often to discover the crucial features are missing anyway).
There is some great cosmic irony here. A section about never needing to build, install, etc… just give me an executable. Followed immediately with an incantation for zig to build this project
Nice idea! How does this actually work? I'm guessing it's wrapping a custom loader + docker + the image into an executable binary - or something like that?
This is awesome Nils! So happy to see the progress on the project since we chatted on the AGI house :) (I'm Syrus, from Wasmer)<p>dockerc works by using: Zig + crun + squashfs/overlayfs. Nils (the author) posted a bit more in this thread for anyone interested: <a href="https://news.ycombinator.com/item?id=39621573">https://news.ycombinator.com/item?id=39621573</a>
You'll still need different ones for different architectures...<p>At this point you might as well compile statically and include a virtual filesystem. Pretty much what Sun created in the 90s..
Let me start by saying this looks like a fun project to work on and, honestly, that's reason enough for doing it.<p>As a solution to the problem of app distribution, I do have some concerns, though:<p>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?<p>How does this compare to AppImage? IIRC that also puts everything into a squashfs.<p>If a user without CAP_SYS_USER_NS executes one of the binaries built by dockerc, do you handle that gracefully in any way?
What about Cosmopolitan and WASM? ;)<p>Cosmopolitan libc allows compiling of a single binary that runs on multiple OS platforms without modification – maybe Dockerc could use this to create a more universally portable container binary?<p>WASM binaries could run in the browser, or another WASM VM, including securely sandboxed environments that spin up fast.<p>I understand that newer Docker builds can use WASM under the hood so WASM in WASM would be funny, it seems if that were the case, maybe extracting the WASM with a more thin wrapper would be better?
OK that's a cool idea. I did try the example in the README but I get an error right away (Ubuntu 22.04)<p>-----<p>$ ./dockerc --image docker://oven/bun --output bun<p>FATA[0000] Error loading trust policy: open /etc/containers/policy.json: no such file or directory
⨯ open CAS: validate: read oci-layout: invalid image detected
Cannot stat source directory "/tmp/dockerc-fbObho/bundle" because No such file or directory
error: FileNotFound<p>-----<p>Btw does this also solve the last line in the original user's complaints?
It's interesting. According to the source code, it uses FUSE to mount the container's internal filesystem. This means that the compiled binary will either need root privileges to run, or the user must have configured FUSE to allow non-root mounting. Not ideal, but there's not much of an alternative either.
This is incredibly cool!<p>Currently using docker as a way to easily distribute and run an open project[1], this would be great to use on top of docker<p>Will this run ok on a Mac? (I see the feature is pending, any tests done yet?)<p>[1] <a href="https://github.com/nicobrenner/commandjobs">https://github.com/nicobrenner/commandjobs</a>
I think a straightforward way to achieve this would be to place a Docker image as a binary directly into a statically compiled podman (<a href="https://github.com/mgoltzsche/podman-static">https://github.com/mgoltzsche/podman-static</a>).
This can be useful for certain people, but I am surprised the documentation (there is just the Readme) doesn't mention what happens when you already have a docker daemon- esp. what happens to all the networking/firewall tricks docker is using. I see potential for quite a number of operational issues.<p>Nice to see Zig in action, btw.
What about using Zon for deps, instead of a git submodule? Just curious if the author tried it, I honestly didn't have time to use Zon deps yet
Very cool project! Can’t wait to see its future development.<p>I’m glad that I know the author. He won 2 tracks of this year’s Stanford TreeHacks with it:)
This sounds really cool, but, doesn't work for me, on version 0.2.1:<p><pre><code> $ ./dockerc --image docker://docker.io/pivotalrabbitmq/perf-test --output yourmom
$ ./yourmom
2024-03-07T03:10:54.145333Z: chown `/dev/pts/0`: Invalid argument</code></pre>
Have we come full circle? Docker was made to create a stable environment for an executable to be run in. Now we're making executables out of the stable environment... should we run that executable in a docker image too?
Damn I would really love to distribute ArchiveBox this way, been looking for a solution that does this for years. Crossing my fingers for arm64/macoOS support someday!
Ahhh, this is one of those situation where "you can does not mean you should". One does this likely because he want to distribute the binary, but turning whatever inside a docker container in a gigantic blob can gives more trouble down the road.
Same thing as Apptainer/Singularity? Or a different approach?<p>I always remember having issues using the Singularity outputs for anything that needed to interact with the filesystem.
Enroot can do something similar: <a href="https://github.com/NVIDIA/enroot/blob/v3.4.1/doc/cmd/bundle.md">https://github.com/NVIDIA/enroot/blob/v3.4.1/doc/cmd/bundle....</a>
The README indicates that this tool will only support Windows and MacOS through emulation. I find that odd.<p>Let's face it, if you're using Linux, you're comfortable typing some stuff into the terminal to install software. Or if you aren't comfortable with it yet, you will be soon. That's just the reality of using Linux. Even ignoring that, snap and flatpak apps provide a generally awful user experience, and I fail to see how this tool would do a better job.<p>That leaves Windows and MacOS users as the primary audience for software packaged using a tool like this. It would make sense that a tool like this would prioritize MacOS/Windows support above all else. Even the angry redditeur shown in the README clearly mentions .EXE files.<p>Why would QEMU even necessary? Docker runs fine on Windows. Maybe it's to avoid requiring the user to install Docker? Either way, asking the user to fiddle with Hyper-V settings is bad UX.