KernelTrap Talks WIth GNU/Hurd Developer Neal Walfield

An Anonymous Coward writes: "One of the GNU/Hurd developers, Neal Walfield, was recently interviewed by KernelTrap. Nice read."

Comments

Using the HURD in production

[Walter Bell]

My employer likes to stay on the leading edge in the operating systems field, and makes it a point to try to integrate up-and-coming technologies into our server farms. It should come as no surprise, then, that our team does use a HURD machine as a file/web/application server.

The HURD machine has been surprisingly stable since we set it up last year. We may have had a few instances where it would get into an undesirable state and need rebooting, but by and large its downtime has been attributable to hardware upgrades and power interruptions. Its integrated userspace/kernel space has provoked us to write some very interesting programs on that box that we would not have been able to create with an ordinary UNIX or clone.

What's interesting about the HURD is that, despite its departures from many UNIX conventions, its developers are striving to form a clean upgrade path from Linux to HURD. Likewise, many HURD features (like POSIX b.1 capabilities) have made it into Linux in recent years. It's too early to tell, but perhaps the future holds a merging of Linux with HURD in a couple of years.

~wally

Re:microkernel == too slow on x86

[selectspec]

Let's be frank. It's too damn slow on any CPU. I think Mach (and Hurd) are really great projects, but they appear to be fundementally flawed (messaging+context-switch). I'm very disappointed that the interviewer didn't go into any details on the well-known problems associated with micro-kernel design. Also, I've never heard a really good comparison of the micro-kernel approach vs. the monolithic design with loadable modules (I'm sure there is one; I just haven't heard it). I'd really like to hear the Hurd developer's comments on these issues.

The HURD could be in public use today

[Jack Wagner]

When I was doing some contractor work for a huge *nix shop (think purple)I met a fellow who told me an interesting tale. It seems this huge *nix company (think purple) had actually spent a week with RMS and some of the HURD developers to talk with them about using the base code from the HURD for a project they were kicking about. The company would have been willing to give back some of the code, under a community type BSD license, which would have brought the HURD up to a Version 1.0 level. Now bear in mind I got this story second hand but the guy who told me was a very reputable source who had been part of the compiler team for years there. He let it slip out while we were discussing the flaws in the BSD threading model and once the cat was out of the bag he spilled his guts.

Anyways, the long and the short of it was that RMS threw a giant hissy fit about the license so they never did business together. It seems that RMS can't see the forrest for the trees sometimes. Instead of giving the community a rock-n-roll new kernel, he decided to cut off his nose to spite his face.

Yours,
-Jack

To sum things up

[Waffle Iron]

The main points from the interview seemed to be:

The HURD isn't popular yet because

• It's still slow
• It's still buggy
• It's POSIX compliant in theory, but not as used by the real world
• Hardly anyone is working on it
• There hasn't been an official release in 4 years (that's 83 years in Internet time)
• There is no prospect of a date for any further official releases

OTOH, the HURD is cool because:

• It's a microkernel
• It has granular security

Except for the last three bad points, the HURD sounds alot like the Windows NT kernel. In fact, the biggest difference could be bad point #4 (since #5 and #6 flow from #4).

Maybe instead of reinventing the wheel, they should just use the NT kernel with the GNU runtime tools and release GNU/NT.

Re:HURD vs Plan9

[spitzak]

Actually I think Plan9 is a very good idea, and may be a much better aproach to making a microkernel. You could consider Plan 9 to be doing "message passing" but the set of messages is limited (to 17, I think). Ie there is a "read" and a "write" and a "walk" and several others. Each of these "messages" has a very fixed set of arguments, ie some have a big block of memory that needs to be sent to the message reciever, some the other way around, some return a new message pipe, etc. Since there is this limited set of types of messages they can be each hand-coded for maximum efficiency.

This limited set of "messages" also makes it trivial to insert filters between components. In Mach I believe any kind of filter will have to interpret the entire message description structure, right?