Have You Hurd

When Free Software Foundation founder Richard Stallman launched the GNU project in 1983, his goal was to produce a complete operating system that satisfied his vision of Free software. Stallman (and other developers within the GNU community) started by building developer tools, such as the GCC compiler, and moved on to create program libraries, a command shell, text editors, and several end-user applications. By the late 1980s, one important piece was still missing: a suitable kernel.

The project had already survived a failed kernel development project in the mid-1980s, based around the TRIX kernel. In 1987, Stallman suggested a new effort to incorporate a kernel based on the Mach microkernel, which was originally developed at Carnegie Mellon University. This new microkernel system would come to be known as Hurd [1]. (See the box "Why the Spelling? Why the Name?")

The choice of a microkernel system was consistent with the opinions of many experts at the time, who saw benefit in limiting the kernel to essential functions like memory management and scheduling, while delegating other services to surrounding processes operating in user space.

Linux users might remember a debate about the relative merits of a microkernel versus a monolithic kernel in the heated exchange between Linus Torvalds and Andy Tanenbaum in 1992 [2]. Most modern operating systems, including Linux, are monolithic – that is, as Tanenbaum explained, "the whole operating system is a single a.out file that runs in 'kernel mode.' This binary contains the process management, memory management, file system and the rest." By contrast, with a microkernel, "most of the OS runs as separate processes, mostly outside the kernel. They communicate by message passing. The kernel's job is to handle the message passing, interrupt handling, low-level process management, and possibly the I/O."

A microkernel limits the complexity the kernel, offering a more object-oriented approach to the design. Also, if one of the surrounding services crashes, it doesn't bring down the whole system. Computer scientists in the 1980s viewed microkernels as the future, but Linus's monolithic Linux kernel soon overshadowed Tanenbaum's own Minix, and Hurd never did grow stable or usable enough to become the centerpiece for the ever-sprawling GNU software system. Within a few years, most users within the Free Software community had drifted to systems centered around Linux or one of the BSD Unix flavors. (See the "Monolithic Blowback" box.)

But a loyal team of developers continued to work on Hurd, and Richard Stallman, who has never exactly gelled with the Linux kernel development community, has continued to remind the world that the Hurd exists as a Free software alternative. Although almost no one uses the Hurd on an actual production server or desktop system, the project has recently experienced a resurgence of interest with the recent arrival of Debian GNU/Hurd 2013 ("wheezy"), a variant of the Hurd grounded in Debian technologies [3] [4].

More on the Hurd

Today, pure microkernels have all but disappeared from modern computers, although some modern systems are so-called hybrid kernels [6], in which some device drivers remain in the kernel, but the file server and other services run in user space. (Examples of hybrid kernels include Windows 8; Haiku, the free-licensed re-creation of BeOS [7]; and Dragonfly BSD [8]  – as well as the Hurd itself.)

A number of variations on the Hurd, including ones based on the Arch and Gentoo distributions have come and gone, but, aside from Tanenbaum's own Minix [2], Debian GNU/Hurd is one of the few Unix-like hybrid microkernels still in active development, and probably the most accessible system for modern users who want to get a sense of how microkernels work. This experience is useful not so much to decide which side of the old debate is right, but to see the theory in practice and to broaden your knowledge of kernels in general. Technically, Debian GNU/Hurd consists of a GNU Mach microkernel [9] and the Hurd servers (daemons), through which the kernel communicates with the rest of the operating system.

The servers reside in user space, which minimizes the portion of the system that must operate from within kernel space. The Hurd uses the DDE Toolkit [10] to access Linux 2.6.32 drivers from user space. The Mach microkernel also includes some Linux drivers, although they date from the Linux 2.0 era and are of limited value for today's systems. (These borrowings mean you might have more success installing on a system that is five years old, rather than a brand new computer.)

Installation and Navigation

Debian GNU/Hurd is available in the same images as other Debian operating systems, including DVD, CD, and netinstall – a minimal image that downloads most of the installation from the online repositories [12]. For some reason, all of the netinstall images that were posted in May 2013 failed once they start to download from online repositories, so you are probably best off installing from the DVD and ignoring the invitation to connect to a repository. Once you login to the system, you can then upgrade without difficulty.

A more reliable, if slower, option is the virtual image in the repository for KVM and Qemu (Figure 1). This image works best when converted for use in VirtualBox with the command:

Figure 1: A graphical install from VirtualBox is just one of the options for installing Debian GNU/Hurd.

/usr/bin/VBoxManage convertfromraw debian-hurd.img debian-hurd.vdi --format vdi

Help for installation is spotty. The help mailing list has little to no traffic [13], so try the main debian-hurd list instead [14]. You may find some information around the general GNU Hurd page [15], but check it against the Debian GNU/Hurd pages instead of assuming it is applicable. Your best resources for installation are the README.txt and YES_REALLY_README.txt files in the Hurd repository. These files will give you basic instructions about configuring the system and running the Hurd virtually, as well as providing additional links to guide your exploration. If you are not familiar with Debian, you may also need to search through the general Debian information, most of which will be applicable to Debian Hurd. Some information is lacking altogether, in particular hardware support. At other times, you are left to infer basic facts for yourself – including that only the ext2 filesystem is currently supported, and that, just because packages for the Gnome desktop environment can be installed does not mean that anything more than a basic window manager can actually be run with ease.

After you overcome such difficulties, boot into the system. If you have installed from a virtual image, log in as root (Figure 2), leaving the password blank. Even though the Debian Installer asks you to add an everyday user, your installation is for experimenting only, so security is not a concern – although you might want to create an ordinary user later.

Figure 2: The Hurd virtual images default to logging in as root.

Entering startx opens Debian Hurd's IceWM window manager, a primitive but functional graphic interface (Figure 3). Aside from a few additions, the desktop applications are identical to those in other versions of Debian, although many are as much as a year behind in versions and may not have been as thoroughly tested as their GNU/Linux equivalents. The Bash shell differs only in a few commands (see below). The apt-get packaging system differs only in the repositories to which it points and the fact that only about 78% of Debian packages have been configured so far for Debian GNU/Hurd [11]. Other standard bits of Debian technology, such as dpkg-reconfigure, are also available. The similarity of the system to Debian versions of GNU/Linux is a reminder that, aside from the kernel, both operating systems share a common set of utilities and applications. But, if you're looking for differences, the most interesting things about the Hurd are visible at the command line.

Figure 3: Debian GNU/Hurd's graphic interface includes many familiar Free software applications, although some are as much as a year out of date.

Exploring Translators

You often hear that, in Linux, everything is a file including device files to communicate with the kernel's hardware device drivers and mount points. For the most part, each file has attributes such as an owner, group, path, and permissions, which are stored in a unique inode. These attributes can be read and edited through POSIX calls like read and write, but each inode must be edited separately rather than as a class.

By contrast, a microkernel like GNU/Hurd include servers called translators [16] that act as an interface for interacting with inodes. Translators are aware of common attributes and can modify existing attributes for all files, or even add new ones.

When an inode is accessed, a translator can return any action or response that is useful. The result is that translators are considerably more versatile than anything used with a monolithic kernel – for instance, as the Debian GNU/Hurd documentation notes, in theory a translator could make a file behave like a directory when the cd or ls commands are used, and like a file when accessed by cat (although why you might want such behavior is another matter).

These characteristics mean that, for all the apparent similarity from an average user's perspective, a Hurd system operates very differently from a Linux system. For one thing, device files are provided by translators instead of the kernel. For another, because the kernel sees translators as just another user process, any user who has the permissions to access a particular inode can use any translators associated with that inode, even changing a translator's characteristics while it is running. Furthermore, one translator can support multiple device files – for instance, a single translator might support all hard disk partitions of a particular format.

To manipulate translators, a Hurd system uses three commands:

• settrans: sets and removes translator characteristics [17]
• showtrans: shows passive translators associated with a file (ones that are not running) [18]
• fsysopts: edits settings for an active translator associated with a file (one that is running) [19]

For instance, if you want to display a filesystem at a particular mount point each time you boot, the command would look something like:

settrans -c /mnt /hurd/ext2fs /dev/hd2s5

instead of any variation of the mount command.

Various pieces of documentation lead you through several examples of translators. The README.txt starts with creating a file and writing (what else?) "Hello, World" to it, then deleting the phrase. It proceeds with instructions on how to set up transparent FTP on a remote site or mount an .ISO image.

Other information can be found on the "Translators" page of the Debian GNU Documentation [20]. For example, you can see how to change a mount point to read only:

fsysopts /mntpoint --readonly

An especially interesting example of what you can do with translators is the creation of a sub-Hurd [21], or secondary Hurd operating system within an existing system.

Currently, the process is limited to accessing secondary Hurd installations, but you can easily imagine it evolving into the equivalent of containers on Linux and running guest operating systems. Meanwhile, sub-Hurds provide an efficient way of creating sandboxes for testing.