3 ms·
There was a period of time in the '80s when it was widely assumed by the software cognescenti that microkernels were the future. A lot of companies were experim
by mwfunk 11y ago
There was a period of time in the '80s when it was widely assumed by the software cognescenti that microkernels were the future. A lot of companies were experimenting with them. A lot of these experimental OSes were based on Mach. GNU Hurd has always been based on Mach. This makes sense because it began development in 1990, and at the time that might've seemed like both a forward thinking and sensible thing to do.
NeXTStep was based on a Mach+BSD kernel, which at the time would've been an obvious thing to do if your goal was to create a modernized Unix system with all the latest cutting-edge (in the mid-80s!) technologies available.
That kernel lives on in OS X and its descendants. It was always built as a monolithic kernel, AFAIK. It just differed from a traditional BSD kernel in that the lowest layers (VM, process, thread, and scheduler stuff) were replaced by the Mach microkernel. I believe that this kind of monolithic Mach+BSD arrangement was a pretty common thing to do when developing a Mach-based Unix implementation.
From the outside it's almost indistinguishable from a BSD kernel. So why not just use an ordinary BSD kernel? Because it future-proofs the design. It gives you an easy path to gradually moving kernel-space services out of the core kernel and into separate address spaces, as microkernel technology improves and it becomes practical to do so. Of course, that never really happened, but it was a very logical choice at the time.
There were other benefits to Mach- you also got multithreading (this was a big deal, mid-80s remember), as well as Mach IPC. Mach IPC has its pros and cons, but just being able to have user and kernel services communicate via arbitrarily defined protocols rather than having to constantly add new system calls is very convenient.
That's pretty much it. This system has been around for > 30 years now, and even though it never turned into a true microkernel system, there probably was never much of a reason to de-Machify it either. It would be a ton of work and you wouldn't gain anything. It's not that Mach is so awesome (although it has some niceties), it's more that there's a lot of momentum there, and you wouldn't really gain anything by rewriting all that code.
As for why Linux distributions don't use it, the same reasons apply. It'd be too much work for relatively little benefit. It made sense to base your cutting edge kernel on Mach in 1985, not so much 30 years later. It doesn't make sense for OS X to stop using it for the reasons given above, but it also doesn't make much sense for anyone who isn't already using it to base new stuff on top of it today.