Show HN: dockerc – Docker image to static executable "compiler" • Hacker News Board

Re: Show HN: dockerc – Docker image to static executable "compiler"

#31

Post by Cu3PO42 » Wed, Mar 06, 2024, 10:48 PM UTC

NilsIRL wrote: post #26

Cu3PO42 wrote: post #24

Earlier quoted context omitted.

> 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. How static are we talking here? There's no reasonable way to not link dynamically against libSystem. Then again, that's obviously present on all Macs, so shouldn't be an issue. > When docker runs on Windows/Ma…

> How static are we talking here? 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://gi…

Hey, I appreciate the reply!

> A windows binary that starts a Linux VM in which the container runs.

I'm afraid my wording was somewhat ambiguous here. I meant to ask "do you aim to wrap Windows apps in a single Windows binary", but I suppose you answered my question anyway. You want to distribute Linux applications to Windows users.

Running on Windows/macOS was also the context in which I meant to ask about filesystem mounts. I understand this is not something that's implemented yet, but I'm wondering about your goals. Things obviously get much trickier than they are on Linux. On Windows I'd probably include a Plan9 server for file sharing.

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.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#32

Post by KomoD » Wed, Mar 06, 2024, 10:49 PM UTC

Okay, that is interesting and cool, though I assume the binaries will be pretty large

Re: Show HN: dockerc – Docker image to static executable "compiler"

#33

Post by 39 » Wed, Mar 06, 2024, 10:52 PM UTC

KomoD wrote: post #32

Okay, that is interesting and cool, though I assume the binaries will be pretty large

Only if you don’t use multistage builds

Re: Show HN: dockerc – Docker image to static executable "compiler"

#34

Post by tekknolagi » Wed, Mar 06, 2024, 10:56 PM UTC

Alifatisk wrote: post #10

So what does this mean? That I can finally ship portable Ruby executable without requiring the end user to install Ruby?

You should also be able to do that with Cosmopolitan/APE.

Re: Show HN: dockerc – Docker image to static executable "compiler"

#35

Post by oasisaimlessly » Wed, Mar 06, 2024, 11:10 PM UTC

pvg wrote: post #28

k8svet wrote: post #17

Folks will literally shove a container runtime, FUSE, and operating system image into a binary to avoid going to thera... learning Nix.

Omit internet tropes. Please don't post shallow dismissals, especially of other people's work. https://news.ycombinator.com/newsguidelines.html

[flagged]

Re: Show HN: dockerc – Docker image to static executable "compiler"

#36

Post by NilsIRL » Wed, Mar 06, 2024, 11:57 PM UTC

Cu3PO42 wrote: post #29

Let me start by saying this looks like a fun project to work on and, honestly, that's reason enough for doing it. As a solution to the problem of app distribution, I do have some concerns, though: 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? How does this compare t…

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