Overall I am impressed with the PureDarwin project and have enjoyed conducting my research around it. They have achieved a lot, considering that the project is funded by community donations and run by volunteers. It definitely isn’t a production-ready system, but for developers it has the potential to come in very useful.
The PureDarwin team have been able to successfully install MacPorts in PureDarwin, allowing many software packages such as Apache HTTPd, Git and even XFCE to be installed. Unfortunately this is non-trivial to achieve without strong networking support, but it shows the potential use cases of PureDarwin.
The problem with Darwin is that you’re always confined to Apple’s whim; the company has a history of delaying Darwin code dumps after new macOS releases for a long time, not including any ARM/iOS code for almost a decade, and the releases themselves don’t really have a commit history and comments – they’re just big code dumps.
I guess Darwin is interesting from an enthusiasts’ perspective, but as far as Apple goes, they don’t really seem to care all that much about it, other than scoring the occasional good press.
Is there anything in Darwin that isn’t in the BSDs?
Mach Ports?
Launchd/launchctl?
I can’t see anybody getting so excited about either to want to run Darwin in places Linux or BSD usually runs.
Well, it is a hybrid microkernel design, which is pretty exciting in and of itself. It comes with some pretty nice security and stability advantages.
One driver/kext acting up won’t crash the whole system. One compromised subsystem will not compromise the whole system, etc.
This is completely false. Kexts run in supervisor mode as part of the kernel with no memory isolation and any bad behavior in one is very likely to cause a kernel panic (and in fact bad kexts are pretty notorious for causing them).
It still aspires to the modular design of micro-kernels, though.
In any case, kexts have been given the death sentence at WWDC 2019, with the presentation of Apple’s roadmap to move all drivers to userspace.
I mean sure, I think hybrid microkernels like xnu are in general are a very good approach to kernel design. It’s just that people see microkernel in the name and automatically assume they have all the same runtime benefits when generally speaking they have virtually none of them. Most of the advantages are abstract in nature and mainly apply to the development cycle. At runtime they behave (for the most part) exactly like any monolithic kernel would, at least the parts that are performance critical (which is kind of the point of hybrids – perform like a monolithic kernel for the bits where performance matters the most).
Apple will never want to regularly update it. People would stop buying their devices if they could use an open source version of macos on computers where macos was no longer supported.
The way I see it, it’s a missed opportunity, because that’s a market I’d like to tackle with support, but then again I don’t like to price gouge people like they do.
But Darwin is not an open source version of macos. it is an open source version of the CORE of macos. And as you can see from the PureDarwin project in this article it is pretty much unsuitable for regular users even with all the work this project put into it