To read all comments associated with this story, please click here.
I think the key point is more likely that kernel development follows the "release early, release often" mantra _most_ closely compared to other projects. This is because a semi-working kernel allows people to work the problem out as they run into the stubs. If your kernel simply just does not have enough to run a web browser with, then people cannot even casually use it long enough to bother working on it.
NeXT made mach work, because they had a product to sell based off of it, and because they didn't have a set of pre-conceived notions of design purity.
But, Linux did not have any corporate backing, until it was already working pretty well on single CPU x86 systems. Hurd has never reached that point.
A key point is also that Linux has had significant corporate backing, with paid engineers working full time on various parts since their employers have an itch to scratch. AFAIK, HURD has never enjoyed such an arrangement.
As others have said, the wild success of Linux was what attracted corporate support, not what created the wild success. And Linux was never perfect, but they did release, and added more and more features. It went from fragile hobby to being a factor in Sun's demise pretty quickly.
It's not so simple: the apple's kernel is XNU which is an hybrid kernel and not a pure microkernel. In fact, it has Mach as core, and a BSD system as only daemon for everything else. So the limitations due to the Mach microkernel (slow IPC) don't penalize the performances too much.
However in a system like Hurd, where each OS task is handled by a separated daemon, these limitations are really an issue.
Microkernels do not need to be slow. Look at those computer they sell today, which take 1 minute to boot while running on hardware millions of times faster than the ones which could boot in 15 seconds some years ago.
Compared to that, what are a few microseconds spent on IPC worth ?
Edited 2010-07-02 12:42 UTC
From RoughlyDrafted
"Once again, just for good measure: Mac OS X is not based on a microkernel architecture, and has never used Mach as a microkernel. Apple's XNU kernel is larger than many monolithic kernels, and does not suffer from the intractable performance failure the world associates with Mach microkernel research.
Apple has incorporated progress the Mach project made in development of Mach 3.0, but nothing changed: Mac OS X still does not have a microkernel architecture. Its XNU kernel is not implemented as a microkernel. Apple does not use Mach as a microkernel.
XNU incorporates many technologies from Mach which makes it different than traditional fat kernels such as BSD or Linux. The microkernel myth confuses the facts by associating [anything related to Mach] with [the failure of the Mach microkernel project], which sought to remove BSD from Mach. Since Mac OS X's version of Mach is full of BSD, this false association is rooted in either ignorance or FUD (or both), depending on who is reweaving the myth.
So there you have it: the Mac OS X Microkernel Myth falls apart on the simple discovery that Mac OS X has no microkernel."





Member since:
2005-09-21
Is that NeXT and Apple seemed to make Mach work. Why is that? Simple. Developing a kernel is frustrating, difficult work (although I suspect for the right person the rewards can be high). If it is your job (as opposed to your hobby), then the expectation that you will grind through and make it work is much, much higher. Maintaining momentum with a hurd of volunteers working part time is much harder than it is when a project has money behind it.
A key point is also that Linux has had significant corporate backing, with paid engineers working full time on various parts since their employers have an itch to scratch. AFAIK, HURD has never enjoyed such an arrangement.