[NilsIRL]

> It would make sense that a tool like this would prioritize MacOS/Windows support above all else.

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

[ryukoposting]

I'm aware of the WSL dependency for the Windows version of Docker - I dealt with it 5 days a week for 4 years before I switched to Ubuntu as my work OS this January. When I said "Docker runs fine on Windows," I meant that Microsoft already ships the necessary runtime to host a Docker container.

I can't comment on MacOS as I haven't used it regularly in several years, and even then I only used Docker briefly on MacOS.

I can see how this approach would result in reliably cross-platform applications, but it immediately raises a couple of concerns: binary size, and interoperability with the underlying OS.

Docker on its own can already be very large. Shoving it inside of QEMU adds even more largeness. Are binary sizes a priority at all? If so, how do you plan to keep them reasonably compact?

I'll assume that user-facing software is the main target for this tool, which means that GUI support is really important. By hosting an application inside of QEMU and Docker, you create a very long and complicated path that stuff must travel through in order for a dockerc'd GUI application to interact with other programs. It's pretty easy to plumb an X server into WSL, but there are limitations when you get into more nuanced interactions with the rest of the machine (ex: clicking and dragging files into the window). Docker adds yet another layer that could cause trouble.

I wish you luck. I tried to make a similar tool for a game engine a while back, and it was absolutely hellish.

[Cu3PO42]

> 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/MacOS it's actually running the containers in a Linux VM.

True on macOS, but only partially true for Windows. There are actual Windows containers, running natively on Windows and runnihng Windows inside the containers.

But do you even want to distribute Windows binaries? Or are you looking for a way to transparently ship a Linux binary to Windows users?

> Yep I don't think that would be nice. I expect the experience to be transparent to the user.

Does this include automagically mounting filesystems?

[NilsIRL]

> 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://github.com/NilsIrl/dockerc/blob/non_linux/src/init.z...