Exploring GNU/Hurd – The lost operating system
Have You Hurd
The GNU project hasn't given up on the venerable Hurd project, and this long-running GNU Free OS project has recently received a burst of new energy with the release of a new Debian port.
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 . (See the box "Why the Spelling? Why the Name?")
Why the Spelling? Why the Name?
Original lead developer and architect Thomas Bushnell claims that HURD is an acronym for "Hird of Unix-Replacing Daemons," where "Hird" is intended to mean "Hurd of Interfaces Representing Depth." Bushnell refers to this extreme turn of geeky wordplay as "mutually recursive acronyms." Beyond the humor, however, one is invited to imagine the cloud of services around the kernel as a herd (or hurd). The name is often taken to mean a hurd of gnus.
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 . 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.)
Even in 1992, not everyone was enamored of the microkernel concept. In his memoir , Linus Torvalds states his reason for rejecting the microkernel architecture for Linux. "The theory behind the microkernel was that you split the kernel into fifty independent parts, and each of the parts is a fiftieth of the complexity. But everybody ignores the fact that the communication among the parts is actually more complicated than the original system was – never mind the fact that the parts are still not trivial." A messy, monolithic system can thus offer some performance and scalability benefits, even if it lacks the (theoretical) stability and flexibility of a microkernel.
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  .
More on the Hurd
Today, pure microkernels have all but disappeared from modern computers, although some modern systems are so-called hybrid kernels , 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 ; and Dragonfly BSD  – 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 , 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  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  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 . 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:
/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 , so try the main
debian-hurd list instead . You may find some information around the general GNU Hurd page , but check it against the Debian GNU/Hurd pages instead of assuming it is applicable. Your best resources for installation are the
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.
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 . 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.
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  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
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 
showtrans: shows passive translators associated with a file (ones that are not running) 
fsysopts: edits settings for an active translator associated with a file (one that is running) 
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
Other information can be found on the "Translators" page of the Debian GNU Documentation . 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 , 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.
Buy this article as PDF
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.