Slashdot Mirror
Hurd/L4 Developer Marcus Brinkmann Interviewed
wikinerd writes "A few years ago when the GNU OS was almost complete, the kernel was the last missing piece, and most distributors combined GNU with the Linux kernel. But the GNU developers continued their efforts and unveiled the Hurd in 1990s, which is currently a functioning prototype. After the Mach microkernel was considered insufficient, some developers decided to start a new project porting the Hurd on the more advanced L4 microkernel using cutting-edge operating system design, thus creating the Hurd/L4. Last February one of the main developers, Marcus Brinkmann, completed the process initialization code and showed a screenshot of the first program executed on Hurd/L4 saying 'The dinner is prepared!' Now he has granted an interview about Hurd/L4, explaining the advantages of microkernels, the Hurd/L4 architecture, the project's goals and how he started the Debian port to Hurd."
That's the difference between OSS and proprietary companies. They can focus like a laser on what they want to develop and leave a lot of the infrastructural heavy lifting to those hippy anarchists in the open source scene.
It's win-win for them, because they get the benefit of a lot of what these groups produce, and often can improve upon it (BSD --> OSX). It's like having an unpaid R&D dept. working for you 24/7.
Is it just loss of interest after Linux became popular?
That, and I also seem to recall that they faced a choice: write a quick and dirty monolithic kernel, or write a much more complex (but theoretically more advanced, secure, robust, etc.) set of servers running on top of a microkernel. Linux came onto the scene and provided the former, so the GNU kernel folks decided to work on the latter. The latter, of course, being HURD.
That's my simplistic take on things from what I've read in the past, anyway.
It's theoretically going to be much better. Revolutionarily so in fact. This is a deliberate design decision since the rise of linux: loads of experimental, potential "next big thing" ideas are going into hurd. Linux works, so hurd is trying to make something that's much better, rather than slapping together a working kernel and worrying about the architecture later which is what linux does.
I am trolling
Think of it more like OS research. Lessons learned from HURD can be applied to *BSD and Linux. Some already have.
Almost everyone who has started with a "pure" microkernel design has eventually moved away from it for performance and other reasons.
Many of the problems HURD was trying to address have either become irrelevant, determined to be non-issues, or have been solved. (The same can be said of things like IA64 or SPARC).
There are still interesting ideas in HURD that deserve research. However if they intend to challenge the enormous momentum behind *BSD and Linux, HURD is going to have to offer some truly astounding functionality / killer app or few people are going to use it.
"It's theoretically going to be much better."
This is why so many projects fail. They try too hard to create a mythical overdesigned piece of software that "works in theory" rather than create something that works and then improve it from there.
This is why so many projects fail. They try too hard to create a mythical overdesigned piece of software that "works in theory" rather than create something that works and then improve it from there.
Ah, the grand old dispute between academics and business people. Linux wouldn't have existed without some quite theoretic early approaches (Babbage, Turing, von Neumann). After all - who cared about the early computers like Babbage's analytical engine? An abacus would be much faster for all relevant computations!
Without theoretic deep-dives like HURD, we would never know if microkernels are a possibility or not. Because it hasn't been proved to work yet. The HURD theorists suggest that microkernels are better than monolithic kernels. Let them explore it, make prototypes, and then someone will make a working kernel to play Duke Nukem Forever on.
Remember: a lot of research just discovers uselessness. It is important to know what's useless, so no-one have to take that path.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
Many of the posts above say Hurd is a waste of time. I suspect the Hurd team just enjoys hacking. I really don't think they care if its a "waste" of time. They just love what they do. I think it's awesome to be so dedicated to your craft. Even if the Hurd never works... I bet they will still look back on the whole experience as something pretty cool.
My own personal experience: I worked on an 8 month student project that in many ways failed in the end. But I would never consider that a waste of time. I learned so much and had a blast doing it.
-bdb
The Linux kernel works because it fills a need, and because it fills a need, lots of people will want to work on it.
The Hurd is more researchy and hence doesn't fullfill anyone's needs exactly, and yes, to the extent that Linux does fit them, then there are less people working on Hurd.
In my experience, a program that fills 90% of the need for 10% of the effort will nearly always win out, even if the extra 10% costs another 90%. The Linux kernel was a quick hack (and I don't mean that in a bad way), whereas Hurd was trying for perfection...
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"having adminned variously HP-UX, AIX, Irix, and Solaris boxes, one of the first things I did on a machine was install the gnu toolset. The proprietary stuff was years behind (Solaris was probably the worst) and getting almost anything modern to compile with them was a real bitch.
I am obviously not as well versed in operating system design as you are, but it seems what you are posing is merely an impedence mismatch in programming models.
For programs that want IPC to work like a subroutine, blocking atomically, then yes implementing it as async IO in the kernel is a mismatch. But what about the reverse case? Are there not any examples of programs which would be better suited to queue and recieve IPC responses asynchronously? If you make IPC atomic this case is simply not possible. Whereas if you start with an asynchronous implementation, you can always optimize a fast path, with a blocking function like MsgSendAndRecieve(). Am I wrong?
It's 10 PM. Do you know if you're un-American?
This is a classic logic fallacy in that you pick and choose the factors that support your argument. The PC didn't win because it was more "open." It won because it was cheaper than the $2000+ priced Macintosh, fueled by commodity PC-clones (remember the phrase "PC-compatible"?) that competed with each other and brought prices down each year.