
Thread beginning with comment 432195
To view parent comment, click here.
Member since:

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