If all goes well, Debian might be adding another port for 7.0 ("Wheezy"): GNU/Hurd. According to the most recent Hurd news, there's now "a real plan to release a Hurd variant" of Debian with Wheezy. It's not a definite, but the Hurd team is buckling down and trying to get Hurd into shape.
Samuel Thibault has created Debian GNU/Hurd CDs with a GUI installer for those who are interested. There's also work going on in the form of a Google Summer of Code (GSoC) project by Jérémie Koenig to improve Java on Hurd by porting OpenJDK, and create low-level Java bindings, which is also helping to improve Hurd for other applications that are being ported to it.
One might wonder why there's a renewed interest in Hurd. Linux
has now been around for nearly 20 years — an impressive run in terms
of longevity, especially considering all of the success that Linux has
enjoyed. But Linux might not have happened at all if GNU Hurd had been ready when Linus Torvalds started working on Linux. Despite the fact that Hurd predates Linux, the official kernel for GNU has never really been widely used or enjoyed more than a small fraction of the developer interest of Linux.
But in a world where even Duke Nukem Forever is finally completed, it makes sense to keep trying with Hurd, too — if for radically different reasons. Why are people still working on Hurd? I emailed Koenig and the Hurd maintainers list to find out what their motivation is.
In a response from the maintainers (Thibault, Arne Babenhauserheide, and Thomas Schwinge), the first reason given is that Hurd provides better support for GNU's Freedom 0 (The freedom to run the program for any purpose) "by giving users and programs as much control over their computing environment as possible." According to the maintainers, Hurd gives users more control over their system thanks to the translator architecture.
Understanding GNU Hurd and translators
GNU Hurd is a set of servers (translators) that run on top of the Mach
microkernel. Mach handles fewer things than the Linux kernel — it
mostly deals with memory management, inter-process communication, and task switching. In short, say the maintainers, "GNU Mach implements what is necessary to delegate all the rest to specialized and separated user-space translators." Mach also includes device drivers taken from Linux, but most are from the Linux 2.0 series. The maintainers say that a new driver framework is being developed that will allow embedding current drivers from Linux into user-space processes. Once complete, they say that this will reduce GNU Mach to providing only "basic hardware access abstractions, like forwarding IRQ events to the corresponding user-space processes."
Why are they called translators? Because they "translate" from one
representation of data into another — such as blocks stored on a hard
disk into a directory and file hierarchy. The maintainers say that Hurd
translators are similar to Linux's FUSE (filesystem in user space),
but they do not go through the kernel and have broader applications:
It thus looks more like gvfs, except that it's transparent for *all* applications in the system that are using the glibc/POSIX interfaces, including mere shells of course.
And this not only applies to file access, the same basic architecture also allows for setting up a VPN connection, for example, and make user-space applications use it without the need for administration rights (for altering the system's routing table, for example), or things like libsocks, since it's already meant to be pluggable from the glibc itself.
For some users the modularity of GNU Hurd may be a major advantage. The maintainers say that Hurd's translators provide more powerful features "that users have actually always wanted but never dared ask their administrator." The concepts of Hurd translators are interesting, but right now the list of translators is fairly small and there's little functionality that one wouldn't be able to get on Linux.
But functionality isn't everything. There's also the appeal of the
challenge of Hurd and learning in the process. The maintainers say that
learning and solving problems to get Hurd up and running "are indeed
a big part of the current maintainers' motivation." For example,
they say it has required getting involved with glibc "which proved to be useful to them in other contexts." Schwinge says that working on Hurd and "exposure and investigation of glibc," helped him to be accepted into CodeSourcery's apprentice program and to land a part-time job with the company while finishing his university studies. Thibault says that work with Hurd helped with his research and to land a position with XenSource.
The maintainers say that it's also fun to hack Hurd. "Debugging the TCP/IP stack can be done simply by running GDB on the pfinet translator (which handles the standard socket interface, and translates it to/from Ethernet frames)." They say it's easier to work on a translator for GNU Hurd than working inside the Linux kernel. "A translator can actually contain a complete TCP/IP stack implementation, and just be used as a container to debug and profile it."
Finally, for developers who want to have a direct impact, Hurd offers opportunities that Linux doesn't. "There are still some interesting tasks to achieve in the GNU Hurd, while contributing anything but drivers to the Linux kernel has become extremely challenging."
Potential aside, GNU/Hurd is still not quite ready for widespread
deployment. However, the maintainers say that it's
reached the point of being "stable enough to be used
day-to-day." Now they say it's time to improve application
availability and support, and to provide Hurd to more users and developers by making it a full port of Debian.
There's still much to be done before Hurd is even up to par with the
Debian GNU/kFreeBSD port, much less Linux. So far, more than half of the
packages in the Debian archive (68%) have compiled successfully on Hurd, but many do not. Java, as already noted, is a problem. However, Hurd also fails to build or has problems with git, GNU Emacs, Screen, Wine, PulseAudio, and many others.
Koenig's work, if successful, will not only provide Hurd with a Java
implementation, but also some system interfaces that are required by
OpenJDK but not available yet in Hurd. Koenig says that he's working on
bringing Hurd's signal delivery code (in glibc) up to par with respect to
POSIX threads. He also says that he's adding features needed for Unix
sockets and other features needed by OpenJDK that are not present in Hurd. "OpenJDK is not very friendly from a porter's point of view; there are many places where the code assumes we're either on Solaris, Linux or Windows."
There's plenty of room for contributors, too. Koenig says that the Hurd team consists of "about a dozen people with various degrees of involvement," and the maintainers say that they're happy to see new developers. Instructions on getting started are included on the Hurd wiki, and there is even an option of getting shell access to a system running GNU/Hurd already.
Note that installing and running Debian GNU/Hurd at this time is for those who are not only adventurous, but also with a great deal of time to kill. Thibault has provided an image with the Debian GUI installer that will install a Debian GNU/Hurd distribution, but it's very slow and is unlikely to work on a large swath of real hardware. The image still uses Linux 2.0-era network drivers, so it's not likely to work on many newer machines. That is being worked on, however. The Hurd folks are working on using Device Driver Environment (DDE) work to reuse current Linux drivers on Hurd. DDE is a universal interface for drivers that is meant to allow using drivers for other systems (like Linux) on systems without a lot of native drivers.
Instructions are provided for booting it under KVM, but running the install under KVM takes hours even on a relatively fast system. It took about five hours to run through the installation once, with a minimal package set, on a Core i7 system with 1GB of RAM given over to the virtual machine running Hurd. According to Koenig, this is due to a KVM bug that causes a performance issue for Hurd on recent kernels. Thibault says that he's building an image that will have DMA enabled to work around this KVM PIO performance issue.
Once installed, it can be fairly slow — and users may run into problems, though some are possibly due to the distribution being based on Debian Sid than being caused by Hurd. For example, I ran into a number of problems trying to install packages, but it was unclear whether the problems lie with Hurd or with Sid.
Is GNU/Hurd going to challenge Linux anytime soon? It doesn't seem likely. But the effort to provide a full-blown port for Debian 7.0 seems to be going well so far. In the process, the folks working on Hurd may continue to uncover bugs and improve software that's common to both systems, and provide an interesting alternative for developers who want to dig deeper into system development.
to post comments)