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 432147
To read all comments associated with this story, please click here.
Lesson zero: working software, now
by wirespot on Thu 1st Jul 2010 13:56 UTC
wirespot
Member since:
2006-06-21

This is one of the best ways I've heard it put about why GNU/Linux was such a good match, and why FOSS continues to grow exponentially to this day:

The model that grew around Linux gave everybody the chance to take part and make a difference. You could do anything with GNU/Linux. If you couldn't write code you could write documentation, host web sites, make friends or sell t-shirts. Linux was different because everyone and anyone could become involved, and "the most important design issue is that Linux is supposed to be fun" - Linus Torvalds.


(As a side note, here's an idea for an image evoked by that quote, an image I wish I could draw: a huge and horrible hacked together machine, yet functional, with FOSS written on it and people all over it, hammering and working on it, and a guy filling the tank from a canister labeled "Fun". Linus really nailed it. FOSS has and will always have fun as a core design principle and will be powered by it.)

Back to the topic: In 1997, Eric S. Raymond said: "Release early, release often. And listen to your customers." Linus did that (instinctively, years before ESR said it.). The result is above. The FSF did not.

They had a chance, with BSD 4.4-Lite, but didn't take it (granted, Mach seemed like the best choice at the time; it is only in hindsight that the choice appears wrong). Then again, they tried so many microkernels across the years and none of them worked as well as they'd have hoped. That says something about the microkernel vs monolithic debate; microkernels may be, in theory, more advanced in some aspects, but in real life their developments poses problems which cannot be handled by the HURD team's limited resources.

And so it has come to pass that HURD is nowadays a classical example of a software project that always chases moving targets. "Perfect design"? There's no such thing.

Research is fine and all, but at some point you have to come out of the lab with something that (1) works and (2) is needed. HURD doesn't fulfill either of these requirements.

Edited 2010-07-01 14:04 UTC

Reply Score: 8

earksiinni Member since:
2009-03-27

We shall see what is needed in the end.

Reply Parent Score: 1

Neolander Member since:
2010-03-08

Then again, they tried so many microkernels across the years and none of them worked as well as they'd have hoped. That says something about the microkernel vs monolithic debate; microkernels may be, in theory, more advanced in some aspects, but in real life their developments poses problems which cannot be handled by the HURD team's limited resources.

Minix 3 exists as the living proof of the contrary.
It's developed by a small team, it's a microkernel (heck, it's one of those which take the microkernel approach in the most extreme way), yet it actually works on a lot of computers and can already run a nice pack of UNIX software.

Microkernel programming is really just a way of thinking, although you can make this way as twisted as you like. In my opinion, the "all process are created equal" rule must be respected, which means that scheduler, clock driver, vmem manager, and all other services that can instantly put the system to a grinding halt should be left in the kernel... but that's another story.

Getting back to hurd, I think the only lesson which can take from that is that the Hurd team is incompetent. They are over-ambitious, as if they somehow suffered from second system effect without having ever created a single working product. And like the Windows NT team one of the sole people who applied the notion of feature bloat to kernel design.

Many kernel projects have died before because of uncontrolled development. Copland is another famous example. The major problem with OS design is that it requires extremely good management. Some are up to that, some are not, but it always have been a sore spot for open source software, generally started and made solely by developers who know nothing about that.

Edited 2010-07-01 20:26 UTC

Reply Parent Score: 6

google_ninja Member since:
2006-02-05

Back to the topic: In 1997, Eric S. Raymond said: "Release early, release often. And listen to your customers." Linus did that (instinctively, years before ESR said it.). The result is above. The FSF did not.


I really wish people would stop giving esr credit for that. He was just the first guy who wrote it down in a public place, and he only really covered one side of it. In 1997, Kent Beck was in the middle of writing Extreme Programming (which takes a more holistic approach to quick release cycles then ESR did), which was itself a codifying of what the smalltalk guys were doing years before that.

Reply Parent Score: 1