Slashdot Mirror

← Back to Stories (view on slashdot.org)

KernelTrap Talks WIth GNU/Hurd Developer Neal Walfield

Posted by timothy on from the hird-about-this-one-yet dept.

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

14 of 218 comments (clear)

  1. Using the HURD in production by Walter+Bell · · Score: 5, Interesting

    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

  2. Re:microkernel == too slow on x86 by selectspec · · Score: 3, Interesting

    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.

    --

    Someone you trust is one of us.

  3. HURD vs Plan9 by line-bundle · · Score: 2, Interesting

    I have been looking at plan9 from bell labs recently. Has anyone here used both hurd and plan9 enough to give advantages of each?

    1. Re:HURD vs Plan9 by spitzak · · Score: 3, Interesting
      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?

  4. The HURD could be in public use today by Jack+Wagner · · Score: 5, Interesting
    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

    --


    Wagner LLC Consulting Co. - Getting it right the first time
  5. Re:Not much new stuff by Anonymous Coward · · Score: 0, Interesting
    This would imply that the public authentication server is hackable also in a way that authentication tokens can be had illegally.
    No, it's more like a public key system. You can get issued keys from anyone you like but only certain keys issued are useful.

    I think all he meant was that in Linux I can write software that will let people run programs under me. I could (I have) wrote a system ontop of that so that I might adminstrate my processes and try to lock-down what people can do. I don't give them a command line - I just let them use my web groupware software. It's no biggie.

  6. Re:Hurd Speed by Ivan+Raikov · · Score: 2, Interesting

    I believe QNX has a philosophy similar to the Hurd -- most of the traditional OS facilities there are moved in user space. Nevertheless, QNX is a leading hard real-time operating system with a very small footprint and elegant architecture.

    Which makes me really excited about implementing real-time software in Hurd.

    --
    Bush Lies Watch
  7. Re:Why???? by Anonymous Coward · · Score: 1, Interesting

    1) A debian port exists for HURD. Actually, Linux is not all GPL since Linus allows binary drivers into Linux. HURD, OTOH, forbids them.

    2) As for L4, the article states that Hurd is being ported to L4.

    4) Microkernels, by their design, are inherently more secure than regular kernels since they allow you to do more in user space with less privilege.

    5) QNX is *also* a microkernel. The main problem about QNX is that it's not free software.

    7) Amoebo is also a microkernel, so it should be possible to port it to HURD so that it co-resides with it. As stated in the article, you can have multiple authentification services, device manager, file systems, etc. Just *try* and do that with Linux.

    I think that answers your questions.

  8. To sum things up by Waffle+Iron · · Score: 3, Interesting
    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.

  9. Re:Hurd Speed by jbailey999 · · Score: 2, Interesting

    One of the biggest speed problems we face right now is how expensive fork is. Everytime something forks, all the ports (and send rights) have to be copied from one task to another (Many many RPCs for that). If that's followed by an exec (which then has to clear it) it's quite expensive.

    The solution for that is to use posix_spawn (in the latest posix drafts). This signals that a new task can be setup cheaply. Hopefully when bash, make, and gcc use that, we'll see a huge improvement in speed.

    So far raw execution speed seems fine. I don't use X (since mostly my machine just sits and compiles binaries), but even when it's going full tilt, it's quite usable on a PII/233mhz. (Multiple ssh sessions, irc)

  10. Re:Hurd Speed by SerpentMage · · Score: 2, Interesting

    What is interesting to note is that the original design of Windows NT with its servers was abandoned in NT 4.0. And from what I know in XP it does not even exist. While HURD did sound very interesting and many of its concepts sounded good I think speed is still an issue.

    Many people say, computers get faster. Sure I agree, but software gets slower as well. The real question is if the software gets slower faster than the CPU or not? For example while C++ as a GUI is hard to program, C++ gui's are miles faster than any Java GUI. On top of that C++ GUI's are nicer than Java's. Hence why Java has not made it on the desktop.

    Folks sometimes you need the speed!!!!

    --

    "You can't make a race horse of a pig"
    "No," said Samuel, "but you can make very fast pig"
  11. Something I perhaps don't understand... by daveman_1 · · Score: 2, Interesting

    If it is possible to implement the Hurd with any underlying microkernel, isn't it essentially possible to provide Hurd functionality with a macro-kernel as well? Layer your Hurd-servers around the macro-kernel as user space apps, disable much of the macro-kernel functionality, still suffer from not doing stuff in kernel space. This is possible isn't it? Wouldn't this allow for the "enhanced" security model which is at the heart of the Hurd? In other words, why does one have to re-invent the wheel to accomplish what the Hurd does, as well as work along side of existing systems, and not require a "compatibility" layer? The interviewer admits the Hurd suffers from a scalability standpoint. Also, isn't it possible to provide the security contexts the Hurd offers through projects for the Linux kernel, such as what NSA is working on with SE-Linux and SIDs? (known in the article as "tokens to perform specific tasks".) This is perhaps a different solution to the problem, but the result appears to be the same...

    --
    Russian Russian Russian RussianDollSig DollSig DollSig DollSig
  12. Better scaling and less forking by hoggy · · Score: 2, Interesting

    A point I've not seen anyone make is that the Hurd scales better than Linux ever will, and I don't mean in terms of hardware, I mean in terms of development.

    Vast wars already take place about what should or should not be in the Linux kernel. The rate of progress on all of these fronts together is approaching glacial. There is just no easy way for a small team to keep a grip on a monolithic kernel that is being pulled in different directions by different developers. It has taken years for a journaling filesystem to be accepted into the kernel.

    The Hurd neatly sidesteps all of these issues by not requiring any of these things to be in the kernel. Useful functionality like reiserfs and tux can be developed and released without any requirement for them to be "accepted" by any controlling group. At the moment, the only way to do something similar with Linux is to release a patch. This makes Linux much more susceptible to forking.

    In case anyone disagrees with me on the forking issue, consider that Linux already has a very high profile fork: RedHat. RH have been distributing a forked kernel for a long time. Admittedly they only patch the kernel in minor ways, but nonetheless they maintain an alternative version. This is because if their views on what they want out of the OS differ from the kernel admins they have no choice but to fork.

    But a RedHat version of GNU/Hurd could be composed of whatever OS servers they choose without any patching. They could mix and match the kernel distribution in much the same way as they currently mix and match the userspace distribution. Because most of the Hurd kernel *is* a userspace distribution.

  13. Just cause you can doesnt mean you have to by Anonymous Coward · · Score: 0, Interesting

    It would be a trivial task to put several processes into the same memory space for efficiency if you have a microkernel OS.

    I imagine being able to give a driver its own memory space during development would be a boon.