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 the device drivers, stupid!*
*The Hurd will go the way of other exotic and unused operating systems if these people continue to sit in their little dream castles and plan for world domination. It's like trying to row a Viking longboat without oars, trying to grill meat without a fork, or more to the taste of our slashdot crowd, trying to masturbate with one's hands tied behind one's back.
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.
"My own experience shows that most people will not be convinced that an alternative is better until you show them."
And hence academic research. Like Xerox Parc.
"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.
2. "unveiled the Hurd in 1990s, which is currently a functioning prototype" -- so, ~15 years (fifteen years!) later, it's still a "functioning" prototype!?
Operating systems develop slowly in their core design and philosophy, and that's no bad thing.
Linux literally exploded into existence, but its design is 80% identical to that of original Unixes so it enjoyed the immense benefits of inherent architectural stability. Linux knows where it's going, but the horizons surrounding the Hurd are very fuzzy indeed. It will take time.
Debian/HURD was "delivered" years ago, but due to limitations of Mach, was underwhelming. It was and is a fully functional OS, though. This new article is "We've gotten rid of our ancient Mach stuff and have ported to L4 which sucks less".
:-)
Theoretically, HURD servers could be ported to a cut down and modified for efficient message passing linux, even, though I don't think anyone has bothered to date.
But lessons from HURD design have been applied to various aspects of linux. The project is not a waste of time. Linux still doesn't have comparably powerful filesystems to HURD (or Plan9 or even AmigaOS...), though unionfs is slowly getting there. Without those that went before, linux would likely have made all the mistakes they made.
And hey, GRUB was written to suppot HURD needs, primarily. If it hadn't been for that, we'd all still be stuck with LILO
Fire up your Project Xanadu browser and check out the link on Hurd and DNF!!
take a look at the source of gnu-core-utils some day... I did it, and I'm still recovering from the trauma. And gcc and other gnu "tools" are not better.
Uhm... you're saying that the gnu tools and projects should be assessed by their coding style? Who cares what the "unix philosophy" of coding style is? The tools should obviously be assessed by how they work and mimic the original tools - and as far as I know, they are "up there" with the commercial unices. Gcc is far better than any compiler from the old days of unix.
And how do you know, by the way, how the commercial unices are coded?
Remember: GNU's not unix. It's GNU. It works. Pretty up the source if you'd like to, no-one cares.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
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
The Plan 9 license is "OSI approved(Open Source), and accepted by FSF and RMS as Free Software; what more do you want?
If that is not enough, complain to Lucent with a clear explanation of why the LPL is not good enough for you.
"When in doubt, use brute force." Ken Thompson
GNU/Hurd is still developed, because it has interesting capabilities, capabilities Linux will never have. IMHO, Hurd is the kernel of the future.
Btw, Hurd will be compatible with a lot of linux' device drivers (i heard all linux 2.0 device drivers were ported, but I could be mistaken) , and imho, device drivers aren't the main job of kernel developers, but of hardware makers. That is a bit unrealistic at this time, though, but it should be.
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
There's no infighting where you work?
Who do you work for and where can I send my resume?
I rarely criticize things I don't care about.
I strongly agree with the OP. Even if HURD never competes with Linux, it's still important as a research project.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
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!"GNU and LInux are interesting for sociological/political reasons. they are not scientifically interesting.
Amen to that.
Happily the science of operating systems isn't very interesting anymore so this is no great loss. Political and economic reasons are of much greater importance, and this is where Linux shines.
Anyone who generalizes about slashdotters is a typical slashdotter.
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.
"but theoretically more advanced, secure, robust, etc.) set of servers running on top of a microkernel."
There are no shortage of people who would disagree with you about Microkernels. You also neglect mention that they are incredibly slow.
Use GNU code for religious reasons but don't use it if you've got work to do or care about using good tools.
The one bit of GNU code that really bugs me: Emacs
I have to admit, I found this to be an odd way of putting things.
Now, you may not be a fan of emacs, but first stating that you shouldn't use GNU code to get things done, and then holding up Emacs as an example, is ignorant at best. I am not personally a fan of Emacs, having discovered vi first, but I still can appreciate the power, flexibility, and usefulness of it.
A friend of mine is big an emacs fan. He uses it for text editing, e-mail, news reading, and coding. He's probably one of the top two or three coders I've ever met in my life. The guy is an absolute wiz. He's easily as productive as two or three normal programmers. And I've seen him do things in Emacs that nearly blows my mind.
You ask what Emacs is? It's probably the most flexible, powerful, and extensible text editor ever created. Although I dislike the implementation, the design theory behind it is beautiful, and has been successfully used by numerous other applications (build a small, fast kernel, or engine, that does implements the core functionality of your program, and build the rest in an extension/scripting language).
Also, a number of your other complaints and comparisons are marginally valid, at best. For example, comparing the Bourne Shell to bash is like comparing the old, original vi, to vim. Both vim and bash are much larger with respect to codebase and resource use, and both likely have more bugs. But they both also offer an immensely great level of functionality. (Although, in fact, both original Bourne shell and original vi have bugs ("features"), which have often been standardized despite their inconsistency.)
If you really want to stay stuck 10+ years in the past, with ancient (but possibly less buggy) software, that's cool. You have that choice.
Me, though. . . I'm looking over that hill there, wondering what we're going to see next.
Topher
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?
GNU's not unix, its an inferior work-alike that serves no purpose.
Serves no purpose? That's funny. Currently, it serves a lot of my needs. I believe that the purpose of the tools is to serve user's needs, but I might be mistaken. Enlighten me.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
Apparently it makes you act like a cock on internet forums.
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.