Hurd/L4 Developer Marcus Brinkmann Interviewed 327
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."
The continued splintering of OSS (Score:4, Insightful)
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.
Re:The continued splintering of OSS (Score:4, Insightful)
You just don't see this in the proprietary companies. Sure, they compete with each other, but within the companies themselves there's much tighter integration.
I think this has the tendency to make OSS be sort of the breeding ground for the real innovations in tech, but largely unable to provide the sort of polish that proprietary companies can. I also think it's a large part of what keeps projects like Linux, Unix, etc. from really breaking through in areas like the desktop.
It's not necessarily a bad thing, but I think to dismiss it is a mistake.
Re:The continued splintering of OSS (Score:4, Insightful)
Re:GNU (Score:3, Insightful)
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.
My advice to the Hurd herd. (Score:1, Insightful)
*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.
Re:And how long have they been working on this? (Score:5, Insightful)
Re:And how long have they been working on this? (Score:4, Insightful)
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.
Focus-Academia. (Score:1, Insightful)
And hence academic research. Like Xerox Parc.
Re:And how long have they been working on this? (Score:5, Insightful)
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.
But Unix is 30+ years old. (Score:2, Insightful)
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.
Re:When are they gonna let this go (Score:1, Insightful)
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
Re:DNF (Score:3, Insightful)
Re:GNU (Score:3, Insightful)
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.
Re:And how long have they been working on this? (Score:4, Insightful)
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.
Re:GNU (Score:3, Insightful)
If that is not enough, complain to Lucent [mailto] with a clear explanation of why the LPL is not good enough for you.
Please, good people, RTFA! (Score:2, Insightful)
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.
slashdot is missing the point... (Score:5, Insightful)
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
No infighting in companies? (Score:3, Insightful)
Who do you work for and where can I send my resume?
Re:But Unix is 30+ years old. (Score:3, Insightful)
Unless it remains vaporware the entire time.
Linux knows where it's going, but the horizons surrounding the Hurd are very fuzzy indeed. It will take time.
Until they actually release an OS, all this discussion is pretty much theoretical. The horizons are fuzzy because we can't actually run the damned thing to refine it.
Re:And how long have they been working on this? (Score:3, Insightful)
I strongly agree with the OP. Even if HURD never competes with Linux, it's still important as a research project.
Re:GNU (Score:4, Insightful)
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...
Re:My advice to the Hurd herd. (Score:1, Insightful)
Every damn time, 50 000 slashdotters has to point out what a waste of time the Hurd is, can't you just shut up for once?
The Hurd developers doesn't deserve all this crap, if it weren't for all of you pessimistic trolls the project would probably have attracted alot more developers.
I don't understand why all of you are trying so hard to ruin their effort?
Re:GNU (Score:2, Insightful)
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.
uh... wrong (Score:5, Insightful)
Re:GNU (Score:3, Insightful)
There are no shortage of people who would disagree with you about Microkernels. You also neglect mention that they are incredibly slow.
Re:GNU (Score:3, Insightful)
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.
Re:Themicrokernels that work - VM and QNX (Score:4, Insightful)
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?
Re:You are missing the point. (Score:3, Insightful)
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.
Re:My advice to the Hurd herd. (Score:1, Insightful)
Then he should do it. Til then, it's useless bits. I'm tired of hearing what hurd could do, I want to see what it does
Re:GNU (Score:2, Insightful)
Price! (Score:4, Insightful)
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.