Slashdot Mirror
Dr. Dobbs' Journal On Hurd
wiredog pointed out an article that's currently running in Dr. Dobbs that talks about Hurd [?] , what it is, and what it is meant to do, as well as what's cool about it. The article starts off slow, but then gets into some good info.
The HURD is an ambitious project which has had a rocky history, but there remains several black marks against it which seem to me to be fundamental flaws which are inherent to what it is and what it wants to do.
Firstly there is the fact that it is based upon an implementation of the Mach microkernel, which has been the favourite of OS courses but which has been shown to be rediculously inefficient in real world situations where performance rather than elegence is a major factor. You need to have a fast kernel in any case, and Mach just can't cut it. If the HURD is to succeed it needs to move onto using a more serious architecture rather than some ivory tower toy kernel.
Secondly, the current implementation of its server system is prone to an inordinate amount of deadlocks and race conditions under heavy loads, partly due to the Mach kernel, partly due to some sloppy coding in some of the IPC code. This means that whilst the HURD is fine for the casual home user, under heavy loads (such as running a webserver), you are likely to get a lot of system lag or even freezing.
Until these serious flaws are sorted out, the HURD is still in the "hobbyist" category rather than the "real world" one. It's nice to study, but it needs to have a lot more work before it's ready for heavy use.
f so why would I use Hurd, If i stick with Linux (a product that works in the here and now) I will eventually get all the advantages that they are talking about anyways.
Kernel modules are not at all the same thing as microkernel. For example, imagine a system where I (as a non-root user) can load modules at will. You canm do the same. My modules don't affect you and vice versa, so there is not a security problem. Thus, we can each load a different 'module' with different semantics to make a remote FTP site look like a mount point, and both of us will be happily unaffected by the other's choices.
That is not to say that Linux won't still have it's place. One of the trade-offs in a microkernel design is that 'system calls', which are implemented as IPC, tend to have a higher overhead. Linux will tend to run faster because of that. Also, some of the more interesting Linux kernel code may end up in a thin wrapper to serve as a HURD daemon and vice versa.
That's one of the big advantages of Free Software, good and useful code get's re-used.
It wasn't until Microsoft pulled Raschid and other critical researchers out of CMU, and IBM's WorkPlaceOS project failed that the "glow" came off.
At present, Hurd only runs on IA-32, but that hearkens back to the "immense aura of failure" surrounding Mach. Mach has only seen limited maintenance over the last few year.
If you have no compiler and no other such tools, you can't build the kernel, you can't run the kernel, you can't use the kernel.
No, they got the order straight.
The problem isn't with RMS trying to steal the glory from Linus for building a kernel; it's not with Linus stealing the glory from RMS when he built a kernel using the tools RMS helped build.
The problem is with the ingrates down the line that don't give credit where it's due.
It is fair to say that just about everything at the layer sitting on top of the Linux kernel "comes from GNU." Between GLIBC (whether version 1 or 2), GCC, and BINUTILS, the layers that make Linux useful all do come from FSF efforts. It certainly does look less than graceful when RMS "demands credit;" that doesn't mean it's an outrageous state of affairs for him to think he can expect some credit.
And the notion that Hurd is the all important be-all end-all project of the FSF is pretty silly; the people that want to participate are participating, and it is not evident that the FSF is spending big bucks or otherwise big efforts into its development...
If you're not part of the solution, you're part of the precipitate.
I disagree. The point about how there is no simple way to add new features into the kernel is a crock:
I am not a kernel hacker, but according to Linus' essay in Open Sources , the kernel design is quite modular, thank you.
As a user of the kernel, I understand the use of modules and this seems to be a modular way to add features. AFAIK, the module feature of Linux is and interface.
Bottom line: how accurate is this article?
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
"Fat, drunk, and stupid is no way to go through life."
"You're gonna need a bigger boat." - Chief Brody
When I first heard of HURD back in, what, 1992 or 1993, I thought it sounded like a great idea. But now it's the better part of a decade later and the thing still isn't out of ALHPA testing!
I'll stick with Linux, thanks...
I was thinking of the immortal words of Socrates, who said, "I drank what?"
Life is a tale told by an idiot, full of sound and fury, signifying nothing.
William Shakespeare
A heartwarming sentiment, but not all was roses for GNU/Stallman:
Clearly he was feeling smothered by the relationship, and expressed his discomfort in his code. If he couldn't control his love in real life, he could at least manipulate the code-surrogate he created to show his true feelings.
Torn up by losing the love of his life, GNU/Stallman destroyed 90% of the kernel code in a drunken fit of despair-driven rage. Thereafter he insisted on a complete redesign, being unable to cope with any reminders of this tragic romance.
And that's why we run Linux.
--------
One place to read the debate is here.
The quote from Linus you are likely remembering is this:
However, Linus had some other points as well, like multi-threaded filesystems on a microkernel being a hack:
My perception is that Linus' view at the time of this exchange was that Microkernels have a theoretically superior design but monolithic kernels have a practically better design. I don't know if Linus' views on this has changed in the nine year interval since this debate.
have a day,
-l
While I'm not the final expert on these matters, I suspect that the opposite of what you suggest is true. CISC machines tend to be much better at context switches. It does depend on the machine... but the VAX (about as CISC as you can get) could task-switch in a handful of cycles, while some RISC machines take hundreds.
RISC machines are in general really fast at big monolithic tasks, like number crunching, not at task-switching. So if you go to a microkernel that needs to do a lot of context switches, RISC performance will probably be bad.
If the microkernel had better message-passing within it (I'm told Chorus is good at this), then the frequent task switching becomes unnecessary and performance improves. But Mach got it wrong.
I think that there is a little bit of a difference. The loadable modules that Linux uses right now are primarily device driver style modules, and are loaded into kernel-space when they load. What the article is talking about is the inability right now under Linux to add significant system-level features (the example given was networking stacks) outside of kernel space. So there is not a way to extend the kernel in Linux without directly fooling with kernel code, one way or another. This hurts the maintainability of the system, as the amount of stuff lying around inside the kernel grows and grows. Additionally, the monolithic style (according to the writer) lacks a nice strong abstraction barrier that makes it possible to alter components individually without breaking something in the system. If the line between where things like basic kernel services and things like device interactions or networking is not clear in the code, than the odds are that if you alter one of them, you're going to end up having to alter them all. In an ideal world, the layer of abstraction insulates the rest of the system from changes. You want to rip out the old memory management code entire and put in a new one? Great. As long as you provide the same interface (API calls & c.), nothing else should need to be altered. This is of, of course, an ideal situation. Systems that are designed that well are few and far between, but in general a little extra abstraction is going to save you maintenance headaches in the long run, which can be very important on a system like Linux, which is going to go through multiple iterations and have significant modification done to it on a semi-regular basis. Generally, this is a long term problem and not an immediate one. No one is going to complain next week that non-modularity is ruining their life (okay, the guy who wrote the article), but in 5 years, when the code base has swollen more, and when advances in hardware make the performance ding due to using a more modular solution less noticable, than there may be some harried kernel hackers bemoaning the complexity (and ugliness) of a system that has grown without good abstraction and without a good non-kernel space module system.
"Sweet creeping zombie Jesus!"
You wrote: HURD would have been a really cool system, if Richard Stalman had got his priorities right in the first place and written the GNU Kernel before he wrote all the system tools! No, GNU did it the other way around, and now they spend what, 5 years? righting a kernel?!
Writing the kernel with what? Using a non-free editor, a non-free compiler, a non-free libc and other non-free tools? Would that be regarded as "free" by anyone?
I don't know if RMS is involved personally at all in the Hurd effort today (I would be happy if he was). I don't see why people attack him... The GNU Hurd is a perfectly "legal" and quite interesting free Unix project. I find it hard to believe that it's supposed to be a form of "revenge" on the success of the Linux kernel. I think it's rather a separate effort to supply a highly modular and portable Unix kernel. I don't know if the Hurd is supposed to do the same kind of impact as the Linux kernel did (is doing).
Another thing: I don't see how the GNU project can "steal" glory from the success of Linux since the success of Linux is dependent on the GNU project which provides the tools and the license. Calling the running Linux system (kernel and user applications etc.) "GNU/Linux" is the least people could do.
It's 11pm, do you know what your deamons are up to?
> Starting the HURD just seems more like sour-grapes on the part of Stalman to be honest. When he realised how popular Linux and Linus were becoming, he decided to try and steal their thunder.
l
Ah, there's nothing like the smell of revisionist bullshit in the afternoon.
http://www.gnu.org/gnu/initial-announcement.htm
Announced in 1983.
How exactly does that square with your little theory when Linus didn't post the first Linux sources until around 1991 (v0.02)?
Mike.
Tales from behind the Lagom Curtain
When/how did microsoft show that microkernels dont work ?
Have you ever heard of QNX, its a microkernel, it works.
I read that the drawbacks to microkernels is that they are a bit slower due to less code operating in privilidged mode. But microkernels are more scaleable i think.
(i am not an expert)
Linux demonstrated years ago the Monoliths work. MS showed Microkernels don't.
Care to elaborate? Actually there was nothing wrong with the NT microkernel design originally. 3.51 was fast and I believe fairly stable. As far as I can tell the instability came from the UI which has been allowed to contaminate the architecture.
Linux has indeed shown that Monolithic kernels can work well, but there are too many who believe that Linux is the peak of OS design and that it can't be beat, so what's the point in even trying?.
Well in n number of years, we'll all be talking on kuro5hin about the days when Linux was a really good OS for the hardware of it's day and wasn't slashdot great before IBM bought VA. In other words don't stop looking just because what you've got works.
Never attribute to malice that which can be adequately explained by stupidity.
That's a valuable quote. It's a real objection to the way microkernels are usually done. It's not really a problem with microkernels, though. It's a problem with processes as a primitive.
Most operating systems today have the "process" as a primitive. A "process" is a collection of address spaces, some kernel state, and one or more "threads". Interprocess communication typically looks like an I/O operation. When process A "calls" process B, process B sees something that looks like an I/O completion and has to find a thread to service it. One thread in B is enough to make it work; many are required to make it work fast. Allocating and managing those threads adds another level of scheduling complexity to service tasks.
The problem comes from the fact that what you want is a subroutine call between processes, but all you usually get is an I/O operation. If the kernel offered a safe way for a thread in one process to call into another process, the problem Linus points out would go away.
A better way to think about this is to think of "objects" rather than "processes". Think of the CORBA object model, but with all the objects in different address spaces on one machine. All that's needed is a way for a thread in one address space to call through some kind of call gate into another address space. The operation required looks like a system call, or a Multics ring crossing, except that it's between peers. The L4 crowd has been getting close to this, and if they ever do L5, they'll probably do it.
x86 hardware almost supports this; if you abuse the segmentation and "task gate" hardware enough, you can get it to support inter-address-space calls without going through the kernel. Maybe. Sort of. It's not quite the right tool for the job. The latest SPARC CPUs are supposed to have hardware support for this, put in for the Spring project.
That's the direction microkernels ought to go. The end result would be a system that works like CORBA/DCOM/etc objects, but much faster and safer. Current implementations of "big object" systems either turn off protection or run slow.
Which isn't the average user. It's an interest piece for geeks. Period. It dosn't pretend to be anything else. The article ITSELF claims that Linux is fully functional now and the HURD isn't.
So, everyone out there saying " HURD sucks," why yes, you are right, it does and the article even says so.
"Linux can do anything the HURD can do and do it faster," why yes, you are right, * and the article even says so.*
But the article dosn't concern people who are interested in the current functionality of the OS's, it concerns people who are interested in *thinking about* how OS's work. More specifically it mainly addresses people who actually write and/or maintain kernel code because that's what they LIKE to do.
If you don't think about kernel architecture and kernel code and just want to boot the system and see what sort of fps you can get in Quake this article wasn't intended for you.
The article brings up some good and intruiging POINTS about kernels, which is the POINT of the article.
I have some of my own ideas about the issues involved which the article prodded me into thinking about some more, so it is also a *successful* article.
The modularity of micro kernel code certainly has some advantages, but from a kernel coders point of view a monolithic kernel's code can be made just as modular with a clear interface between modules. If it is not done that way at present that is the fault of the coders, not the architecture.
Ok, the Linux kernal code grows and grows, but not all aspects of the code are COMPILED into the user's actual kernel. In this sense the kernal already has modularity of sorts to the end user. If you don't have a USB port you don't compile USB support into the kernel in the first place.
The key advantage of the micro kernel brand of modularity is that you can add or remove USB support * without recompiling.* This will be of primary advantage to the system *maintainer.*
When does a Linux box go down? When you have to modify some core function of the kernel that requires a complete recompile usually. With a micro kernel you upgrade from USB to USB2 by pulling one module and plugging in another. Done. No reboot.
The downside, as we all know, is system performance takes a hit from the resulting extra overhead to support communications between modules.
But look, Moore's law remains in effect. A few months ago IBM announced they had enough stuff in development in the lab * right now * to keep Moore's law in effect for at LEAST the next ten years. Think about that, and that dosn't take any new, currently unknown and undeveloped technology into account.
* What is known technology, right now, will keep Moore's law in effect for the next decade.*
In a year and half that 1.2 gig AMD is going to be a 2.5 gig something or other, and it will be CHEAPER than current boxes. In 3 years it will be 5g and cheaper yet.
So what are we going to use all that added power for? To get 400 fps in Quake instead of 200?
No, I'll TELL you what we're going to use it for, (because that's the kind of swell guy I am), we're going to use to run abstraction layers to the entire software architechture to make end use and system maintainability easier, THAT'S what we're going to use it for.
Will benchmarks for a micro kernal be slower than benchmarks for a monolithic kernel? Yep, sure will, BUT. . .
They'll BOTH be faster than human perception, just as vi appears to run equally fast to the human user on a 486 and a PIII 900.
And APPARENT speed is all that matters people.
Is the day of the micro kernel here? No, and the article itself says so.
Is it coming? You bet it is.
Maybe not today. Maybe not tomorrow, but soon, and for the rest of your life.
If so why would I use Hurd, If i stick with Linux
(a product that works in the here and now) I will eventually get all the advantages that they are talking about anyways.
I am not a kernal hacker....So I admit I do not understand all the issues here, but I do not see any reason to jump.
Yes I can not spell...Wait....for a second there I almost cared.
Apologies for the appalling pun. But its relevant. The thing that leapt out of the article for me was 'Hey, this would be great for portable devices'. Write a translator for Bluetooth gear, instant wireless networking. Write another for GSM WAP cellular stack communication.. instant wireless productivity connections. Don't have a filesystem? Chuck it. Added an IRdA port to your device? Plugin a new service and off you go. This would rock.
Obviously this depends on the general overhead for the microkernel itself, and the resources available, but its a nice idea. A fully tailored OS is a necessity on things that are 'thin-clients'. Sounds like an option.
http://twitter.com/onion2k
Building 2 is part of a complex at the intersection of Massachusetts Avenue (Route 2A) and Memorial Drive. As you cross the Charles River from Boston on Mass Ave, it is the first set of buildings on your right. A map is at http://whereis.mit.edu/bin/map?state=0&pri.x=325&p ri.y=137. I don't
know where the best parking is, since I walk...