Linked by David Adams on Thu 1st Jul 2010 08:52 UTC
GNU, GPL, Open Source The HURD was meant to be the true kernel at the heart of the GNU operating system. The promise behind the HURD was revolutionary -- a set of daemons on top of a microkernel that was intended to surpass the performance of the monolithic kernels of traditional Unix systems and in doing so, give greater security, freedom and flexibility to the users -- but it has yet to come down to earth.
Thread beginning with comment 432162
To read all comments associated with this story, please click here.
Key Observation
by tchristney on Thu 1st Jul 2010 16:45 UTC
tchristney
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.

Reply Score: 2

RE: Key Observation
by xiaokj on Thu 1st Jul 2010 17:19 in reply to "Key Observation"
xiaokj Member since:
2005-06-30

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.

Reply Parent Score: 2

RE: Key Observation
by Bill Shooter of Bul on Thu 1st Jul 2010 17:34 in reply to "Key Observation"
Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Parent Score: 4

RE: Key Observation
by tony on Thu 1st Jul 2010 18:49 in reply to "Key Observation"
tony Member since:
2005-07-06

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.


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.

Reply Parent Score: 3

RE: Key Observation
by scolabirra on Fri 2nd Jul 2010 09:38 in reply to "Key Observation"
scolabirra Member since:
2008-10-02

Is that NeXT and Apple seemed to make Mach work. Why is that? Simple. ...


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.

Reply Parent Score: 1

RE[2]: Key Observation
by Neolander on Fri 2nd Jul 2010 12:40 in reply to "RE: Key Observation"
Neolander Member since:
2010-03-08

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

Reply Parent Score: 2

RE: Key Observation
by Phucked on Sat 3rd Jul 2010 03:23 in reply to "Key Observation"
Phucked Member since:
2008-09-24

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."

Reply Parent Score: 2