To containerize darwin binaries?

This is not an alternative to remotely connecting to a VM to control Linux containers (which DfM is)

And what is the benefit of that? Who would use that and for what? Containers solved deployment, and software distribution problems related to diversity of runtime environments on linux. It also has some security benefits, but their adoption was successful because it solved real world everyday problems. It eventually allowed better utilization of servers.

They did not have such success on windows, despite Windows also having a container subsystem, as windows servers already did this with IIS web app containerization.

On MacOS desktop software distribution is largely a solved problem since ages. On MacOS/Darwin servers... are there such in industrial use apart from some research installations?

> Who would use that and for what?

I believe this project can be useful for CI and testing scenarios.

> On MacOS desktop software distribution is largely a solved problem since ages

Are you talking about App Store? Or Homebrew? Or MacPorts? Or... Wait, isn't this too many tools for a problem that was solved?

So why don’t they run a Darwin VM that doesn’t need SIP and control it in the same manner?

Docker For Max marshals filesystem events over a VM host/guest boundary which can grind the most powerful computers to a halt if you’re sharing directories between the host and guest. For example, at my last company we developed Python apps and ran them in Docker for Mac containers by mounting the source code directory into the containers (so we wouldn’t need a build step) but as our project grew the filesystem event marshaling became exponentially slower until we eschewed Docker from our dev iteration loop entirely (the fidelity benefits weren’t worth the performance hit). Note: there are lots of projects and hacks that claim to solve this problem but none made an ounce of difference.

The alternative is to use a performant file sharing system through the VM isolation. Some people use NFS, I personally use VMware Fusion + vmhgfs.

Sure it does not attempt to map fsevents<->inotify 1:1 but honestly I can live with that limitation given that it's a 10x performance increase compared to the DfM kitchensink.

I do go native darwin when I can / it makes sense.

Is that something you can configure in DfM or are you saying you sort of roll your own DfM alternative? Also, what does "VM isolation" mean here? How is NFS or VMware Fusion more "isolated" than DfM?

> Is that something you can configure in DfM

No

> or are you saying you sort of roll your own DfM alternative?

Yes, I set up a NixOS VM and use DOCKER_HOST=ssh://docker@<ip>

If you want to have it easy you can roll with lima/colima (but I found the fs sharing slower than vmhgfs)

> Also, what does "VM isolation" mean here?

The host/guest boundary. The guest is just like any another, remote machine. DsM adds smoke and mirrors to make it look like guest and host are one.

> How is NFS or VMware Fusion more "isolated" than DfM?

It's not, both are VMs and need a way to expose the host fs to the guest, NFS or vmhgfs are a means to that.

Understood. Thanks for the explanation/clarification!

> until we eschewed Docker from our dev iteration loop entirely

Can you say anything more about what you did instead, and how it ended up working out?

We used native MacOS processes and it worked out fine. In practice I don't recall any bugs due to different behavior between our dev environment (MacOS) and our production environment (Linux) and we saved a ton of time during development. Docker just wasn't worth it. This worked for us because our app didn't depend on any platform specific behavior.

Of course, if you are using Go or some other language with a fast, static cross-compilation step, you don't need to mount a source code volume into your container, you can just rebuild the whole container image or rebuild on the host and `docker cp` the new binary onto the target container.

Docker Desktop for macOS does full-blown hardware virtualization, which is just silly.

This should have faster file access than Docker Desktop. For large projects, disabling SIP may be worth the increase in performance.

Docker Desktop runs an entire second kernel in a VM.