“The Hurd currently runs only on the Mach microkernel, but there is work to port it to the newer L4 microkernel. This article has the details about the current status of the Hurd/L4 port. It is primarily written for people familiar with Hurd/Mach, but who do not know L4.” KernelTrap has the details.
Status of the Hurd Port to the L4 Microkernel
2002-07-29 OS News 11 Comments
I keep waiting for the announcement from the hurd team. The announcement where they admit that the hurd project was just a joke and they will no longer put out fruitless announcements such as this. I still don’t get what sets the hurd project apart from the Linux kernel project. They seem to have the same goals and yet Linux is so much farther ahead.
My 2 cents.
I really think they’re doing some cool stuff with Hurd. Ditching mach is definitely a good thing, it’s massively ancient and bloated. The L4 series has always looked cool (at least on paper) and seems to offer some sort of way to do the microkernel thing of physically splitting tasks (vs logically as in a monolithic kernel).
I’m very much looking forward to seeing how well Hurd will perform, esp vs Linux for low level task type stuff.
Why is L4 superior to Mach? How compatible are the two and would it realistic to speculate that Apple may some day use L4 in OSX, or do their modifications to Mach make this unnecessary? My general understanding is that microkernel architecture is generally more robust than monolithic designs, but at the cost of some performance. Given that L4 consists of less code than most other Microkernel systems, is its performance (overhead) comparable to a monolithic kernel like Linux?
“Why is L4 superior to Mach? How compatible are the two and would it realistic to speculate that Apple may some day use L4 in OSX, or do their modifications to Mach make this unnecessary? ”
Most of CMU’s MACH Team joined NeXT hence Appe some years ago.
MacOS X ‘s Mach is highy modified has its been greatly integarted with BSD (read http://www.osnews.com/story.php?news_id=1246). Appe could switch but it woud be costly for them to do so.
Big huge paper with some numbers in the middle.
Apparently they ported Linux to L4 and compared it to standard Linux and MKLinux. So a cursory head to head comparison between a mach ported and l4 ported linux kernel.
its useful to note that the paper brian cited is for a monolithic port of linux with a modified user-level task structure. for a multi-server operating system, like the Hurd, the numbers could be very different. (i assume for the better)
My general understanding is that microkernel architecture is generally more robust than monolithic designs, but at the cost of some performance.
this is basically true, with a microkernel such as L4 you sacrifice typically 5% of your speed (which if youve got a 1GHz means very little) and gain the ability to run-time modify your system in a number of ways, increasing usability, flexibility and redundancy. for example: most microkernel projects are looking into persistence which means if your computer crashes it will boot up to the exact state it was at the last checkpoint – you’ll only loose about 5 mins of work…
OSX is about as much a microkernel is NT is now, plus its dependance on the aging Mach means it is obsolete many times over. for more recent OS ideas look at L4 http://l4ka.org and Exokernel http://www.pdos.lcs.mit.edu/exo.html
Glad to see they’ve actually started to work on it. There have been discussions about this for well over a year, and I didn’t think anyone was going to actually start doing it. I tried out the hurd a few times. It’s incredibly slow. It will be interesting to see if this performs better.
Just glanced at that a bit. Looks interesting, but seems like a malicious virus writer or hacker could make the system behave badly.
> I still don’t get what sets the hurd project apart
> from the Linux kernel project.
Being based on a microkernel?
But I have to admit that, with the success and momentum behind Linux, it seems a bit silly to make efforts for something that would not be much more than “yet another kernel”. Technical merit has seldom earned a system lasting fame in its own (see Be, NextStep, Amiga, OS/2).
I keep waiting for the announcement from the Linux team. The announcement where they admit that the Linux project was just a joke and they will no longer put out fruitless announcements such as this. I still don’t get what sets the Linux project apart from the NT project. They seem to have the same goals and yet NT is so much farther ahead.
You could have said that in 1995. And you know what? You would have been right. But that would have been missing the point.
The UNIX philosophy has always been KISS (Keep It Simple, Stupid). Every single task has a separate program; you use fetchmail to get your mail, mail to read it, and sendmail to send mail, instead of one big program (and an smtp server). With the exception of Emacs, everything in GNU follows that philosophy. Changing the kernel to a microkernel architecture will make the kernel follow it, too. Switching to a uKernel architecture also speeds things up a bit, makes it possible to essentially hot-reload the kernel, and makes much easier to explore radically new concepts in OS design; you can keep the uKernel and just layer new servers on top (for example a new filesystem server for database FSes), while keeping the servers that don’t need to be replaced (networking). It’s no accident that BeOS uses a uKernel architecture.
Also importantly, RMS loves freedom. The Linux kernel is not as free as he would like, and for bad reason. Linus only GPLed the kernel, he says, because that would insure its wider popularity; and as it is, he uses proprietary BitKeeper for version control. RMS badly wants to offer a kernel that is free for philosophical instead of practical reasons, and he also wants to offer a full GNU System – how he’ll love it when people can use Debian GNU, with no trace of Linux in the system.
Whatever you think of RMS’ motives, though, the microkernel architecture, or rather nanokernel (now that they’re using L4), is better. Already, half of Debian’s archives (admittedly, many of those packages are arch-neutral) are available for the Hurd in sid; by the time the Gnu System 1.0 is released, every package should be available.
Linus only GPLed the kernel, he says, because that would insure its wider popularity; and as it is, he uses proprietary BitKeeper for version control
Only parts of the kernel project uses BitKeeper. And if the change wasn’t made, 2.5 wouldn’t be anyway right now. BitKeeper keeps Linus much more productive, and if RMS was Linus to give freedom to its developers to use a Free Software, he should create an initiative to make something as good or better than BitKeeper.
I respect RMS’s Free Software philosophy, even though I don’t believe in it. But I wish RMS would instead be more pragmatic in stuff like this.
Anyway, I would support this over Linux if it doesn’t break binary compatiblity with drivers depending on the kernel every sub-major release.