I think it's an OK argument given that most people run (and have been running with no alternative until very recently) docker in such a way that there's a trivial privesc to root. In general it seems like docker users are, overall, willing to take that tradeoff.

What exactly attack vectors you think are possible against macOS without SIP but not possible against Linux?

macOS had granular directory permissions way back when it was NeXTSTEP, long before SIP was introduced. Where are you suggesting they disappeared to?

I'd like to digress to your "Encouraged more forcefully" phrasing which is quite interesting if you think about it. In my view, it would mean something like pervasive dialog box ala EULA, some UI hoops you need to resolve, alike going with local account on installation.

In reality they done basically everything to force users to use secure boot. If they disabled normal boot altogether, OS adoption would suffer heavily. They could've obscured that option, but it would be found out, and enterprise users would be pissed at them because they didn't gave them a provisionable way while the way exists. So it came down to normal variables in installer registry.

However modifying, e.g making users "hack" the ISO is really as forceful as it gets without market loss.

Note: There may be more normal way today than modifying the registry of ISO, I installed 11 once when it came out.

Nope, that PR was an attempt to upstream my changes: https://github.com/macOScontainers/containerd/commits/macos

Vanilla containerd cannot mount anything on macos.

> If you really want good adoption, you’ll have to figure out a way for devs to try it out without first having to disable SIP.

I can't stress enough how I also would like it to work with SIP enabled!

Sounds like if Apple wants developers who wants to use containers natively, they need to address the problem of not being able to offer this feature without disabling SIP.

No matter what you or I think about what's needed for adoption, technical problems get in the way of the tool working with SIP, so seems it's in Apple's ball court really.

In corporate managed laptops it may not be an option to disable SIP.

To containerize darwin binaries?

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

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.

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.

> And that’s a good thing?

That's a technical limitation.

If you're talking about desktop use, not really. All the software in a default Fedora desktop install, runs as unconfined by SELinux policies.

Where SELinux really shines is in server installs.

I think you're probably @totallywrong

Can you please expand on this? It wasn't my understanding at all.

A decade ago SIP didn't exist at all. I thought disabling SIP just put us back to how things were in Yosemite. What changed?