This is all fine and dandy, but where are the native Darwin Jails Apple? Still scared that people will filling whole rooms of Mac Minis if you allow them to have multiple macOS containers and not only up to two fat VMs per machine?

▲

cedws 5 days ago | parent | next [-]

Darwin namespaces would be much more interesting and we are in dire need of them in the current security landscape.

I don’t really understand the hype for Apple’s Containerization, it’s just another container runtime alongside many others. It’s not really any better than OrbStack - in fact it’s worse.

	▲	RationPhantoms 5 days ago \| parent \| next [-]
		Thank you for answering that question because I adore OrbStack and didn't find much difference.
	▲	whimblepop 5 days ago \| parent \| prev \| next [-]
		When Apple Sherlocks something, aren't their implementations usually worse? Typically the thing being Sherlock'd is very mature and featureful, and Apple's implementation is much less capable and has undergone much less user testing, at least at the outset.
	▲	gyoridavid 5 days ago \| parent \| prev [-]
		+1 I'd love to have network namespaces

▲

5 days ago | parent | prev | next [-]

[deleted]

▲

jorisw 5 days ago | parent | prev | next [-]

[Replied to wrong comment]

	▲	qalmakka 5 days ago \| parent [-]
		That's totally unrelated to what I wrote

▲

tonymet 5 days ago | parent | prev | next [-]

You would want a layer above darwin, e.g. Foundation, Appkit -- all the stuff that runs the full MacOS. but good idea overall

▲

adastra22 5 days ago | parent | prev [-]

sandbox profiles?

▲

qalmakka 5 days ago | parent [-]

macOS sandboxing is deliberately limited just enough to prevent anyone from truly implement Darwin-on-Darwin containers. People have been discussing about this for a while, see https://github.com/apple/container/discussions/611

In general I understand the rationale behind Apple's decision. They sell hardware, and there's real demand for macOS on servers to run build jobs and other Mac-only tools. Giving you the ability to run multiple containers on a single Mac would end up turning a 10 Mac Mini order into a 2 Mac Minis order for most people. Rest assured, even if it would be technically possible they'd find a way to cap it somehow via the EULA or whatever

▲

coldtea 5 days ago | parent | next [-]

I doubt this insignificant statistically speaking market (compared to the overall units they move) is what prevents them.

	▲	inejge 5 days ago \| parent [-]
		Domino theory as applied to business, plus one should never underestimate the lengths to which a company will go to wring the last ounce of profit from a market.

▲

larodi 5 days ago | parent | prev [-]

and how is this, having containers run hardware one owns, a bad or even shameful idea, given people do it and want to do it with their hardware all the time?

	▲	qalmakka 5 days ago \| parent [-]
		> aving containers run hardware one owns, a bad or even shameful idea what? it isn't, it's absolutely a right you surely have. The problem is that a. Apple forces people to buy Macs to build, notarise and deploy iOS and macOS apps b. Apple refuses to implement jails which is something that every OS, including Windows, has nowadays c. Apple only allows you to have 2 VMs - full, fat, with GUI - on each Mac computer, running at once c. Jails/Containers would allow you to easily deploy multiple jobs, which would allow you to have N jobs in parallel, which would mean you'd need way less Mac Studios/Mini in your local CI