GNU/Hurd in 2010

What do you think of Minix 3?

It's interesting to look at the advantages they list, and see (1) which are also covered by Linux, (2) which are not covered by Linux but are of questionable usefulness, and (3) which are not covered by Linux and are useful--and then to see if these could be brought to Linux reasonably.

    It's free software, so anybody can use, modify, and
    redistribute it under the terms of the ?GNU General
    Public License (GPL).

Linux already has this covered.

    It's compatible as it provides a familiar
    programming and user environment. For all intents
    and purposes, the Hurd provides the same facilities
    as a modern Unix-like kernel. The Hurd uses the GNU
    C Library, whose development closely tracks
    standards such as ANSI/ISO, BSD, POSIX, Single Unix,
    SVID, and X/Open.

Linux has this covered.

    Unlike other popular kernel software, the Hurd has
    an object-oriented structure that allows it to
    evolve without compromising its design. This
    structure will help the Hurd undergo major redesign
    and modifications without having to be entirely
    rewritten.

Not covered by Linux. I wonder if this is actually useful, though. In my experience when something needs to undergo a major redesign in an operating system, it tends to be a whole subsystem that needs the redesign--so even if it were object oriented, you'd be redoing the design of all the objects for that subsystem. Sure, you would be able to keep, hopefully, the same interfaces to other subsystems--but you don't need object oriented design for that.

For example, in the filesystem area, I believe modern monolithic kernels have well-defined interfaces between the filesystem subsystem and the rest of the kernel, so major redesign of the filesystem subsystem could be done without affecting the rest of the kernel. Within the filesystem submodule, they have well-defined interfaces between the generic filesystem code and the code that implements specific filesystems, again allowing for major redesign within the filesystem subsystem or the code for specific filesystems without affecting too much other code.

    The Hurd is built in a very modular fashion. Other
    Unix-like kernels (Linux, for example) are also
    modular in that they allow loading (and unloading)
    some components as kernel modules, but the Hurd goes
    one step further in that most of the components that
    constitute the whole kernel are running as separate
    user-space processes and are thus using different
    address spaces that are isolated from each other.
    This is a multi-server design based on a
    microkernel. It is not possible that a faulty memory
    dereference inside the TCP/IP stack can bring down
    the whole kernel, and thus the whole system, which
    is a real problem in a monolothic Unix kernel
    architecture.

    One advantage of the Hurd's separation of
    kernel-like functionality into separate components
    (servers) is that these can be constructed using
    different programming languages -- a feature that is
    not easily possible in a monolithic kernel.
    Essentially, only an interface from the programming
    environment to the RPC mechanism is required. (We
    have a project proposal for this, if you're
    interested.)

Linux does not have this covered. This is where it gets interesting. After all, even on a monolithic system like Linux, people have pushed some code to user space. A good example is FUSE. That's a kernel module that provides a bridge between the kernel filesystem code and user space code for specific filesystems.

I don't see any reason this could not be done for other things now in the kernel, such as the TCP/IP stack.

This would introduce performance problems, due to overhead of communicating between the user mode components and the kernel components, or between different user mode components, but microkernels like Hurd also suffer from that overhead.

To put it more succinctly, if you want a microkernel you don't necessarily have to start with a microkernel like Hurd is doing. Why not start monolithic with Linux and add microkernel aspects? It would be an interesting project to make a microkernel via a series of mutations of Linux.

It might be possible that way to end up with a kernel where you can choose whether each subsystem is handled in the traditional monolithic way, or bridged out to user-mode code, or both. You can then pick where on the performance vs. security spectrum you need to be for each aspect of your system, tailoring it to your particular requirements. That would be pretty cool--sounds like a fun project.

    The Hurd is an attractive platform for learning how
    to become a kernel hacker or for implementing new
    ideas in kernel technology. Every part of the system
    is designed to be easily modified and extended.

Hurd has the advantage here. Even a microkernel evolved out of Linux as I described above would probably be uglier to learn from.

However, I'm not sure this is important enough. There are systems designed for learning operating systems hacking, such as Minix. A potential new kernel hacker could learn on one of those, and then switch to Linux pretty easily.

    It is possible to develop and test new Hurd kernel
    components without rebooting the machine. Running
    your own kernel components doesn't interfere with
    other users, and so no special system privileges are
    required. The mechanism for kernel extensions is
    secure by design: it is impossible to impose your
    changes upon other users unless they authorize them
    or you are the system administrator.

Advantage Hurd. I question the usefulness. This would have been important in the time sharing days. Now we're for the most part the only user on our system--there's no one our changes could be imposed on! Also, if a microkernel-like Linux kernel were developed as described earlier, it would gain some of this automatically.

TL;DR version: most Hurd advantages over Linux either are in areas that aren't really important to most people, and for those that do matter it looks like they could be added to Linux.

An academically flawless OS, yet no programmer's nirvana on the other end.

The only reason GNU/Hurd is still a popular subject of discussion is its historical fame. There is no concrete reasoning behind this project anymore as to why it may find adoption. It is not easy to write operating systems in the first place. Adoption is even harder today because the subject is very well explored and the solution has become a commodity.