GNU Hurd (usually referred to as the Hurd) is a free software computer operating system kernel, released under the GNU General Public License. It consists of a set of servers (or daemons, in Unix terminology) that work on top of a microkernel; together they form the kernel of GNU. The Hurd aims to surpass Unix kernels in functionality, security, and stability, while remaining largely compatible with them.
HURD is a mutually recursive acronym, standing for HIRD of Unix-Replacing Daemons, where HIRD stands for HURD of Interfaces Representing Depth. It is also a play on the words herd of gnus, reflecting how it works.
Development on the Hurd began in 1990 after an abandoned kernel attempt in 1986, based on the research TRIX operating system developed by Professor Steve Ward and his group at MIT's Laboratory for Computer Science (LCS). According to Thomas Bushnell, the initial Hurd architect, their early plan was to adapt the 4.4BSD-Lite kernel and, in hindsight, "It is now perfectly obvious to me that this would have succeeded splendidly and the world would be a very different place today". However, in 1987, due to a lack of cooperation from the Berkeley programmers, Richard Stallman proposed instead to use the Mach microkernel developed at Carnegie-Mellon University. Work on this was delayed for three years due to uncertainty over whether CMU would release the Mach code under a suitable license.
Development of the Hurd has proceeded slowly. Despite an optimistic announcement by Stallman in 2002 predicting a release of GNU/Hurd later that year, the Hurd is still not considered suitable for production environments. Development in general has not met expectations, and there are still bugs and missing features. This has resulted in a poorer product than many (including Stallman) had expected.
From 2004 onward, various efforts were launched to port the Hurd to more modern microkernels. The L4 microkernel was the original choice in 2004, but progress slowed to a halt. In 2005, there was a discussion of whether to change to L4.sec (a different L4 microkernel) or to Coyotos (EROS successor). Although no formal decision was made, most of the Hurd developers' time has gone into thinking about Coyotos, especially since 2006.
Other Unix-like systems working on top of the Mach microkernel include OSF/1, Lites, and MkLinux. These are implemented as a single Unix server which, together with the microkernel, replaces the monolithic kernel of a traditional Unix system. Mac OS X and NEXTSTEP use monolithic kernels based on Mach, often incorrectly believed to be microkernels.
In the Hurd, elements of a monolithic kernel are instead handled by separate server processes. Such a "set of servers" was one of the main design goals of Mach, but Hurd appears to be the first Mach-based system to be implemented in this way. (QNX and Minix-3 are similar but based on their own microkernels.) It is not entirely clear why this happened, but it might have something to do with the high performance hit of Mach IPC. Hurd also aims to be microkernel-independent.
OSKit-Mach began as a branch of the GNU Mach 1.2 kernel, but since the release of GNU Mach 1.3 was merged as the new GNU Mach 2.x mainline.
In 2005, Hurd developer Neal Walfield finished the initial memory management framework for the L4/Hurd port, and Marcus Brinkmann ported essential parts of glibc; namely, getting the process startup code working, allowing programs to run, thus allowing the first user programs (trivial ones such as the hello world program in C) to run.
In 2006, Marcus Brinkmann and associates met with Jonathan Shapiro (a primary architect of the Coyotos Operating System) to aid in and discuss the use of the Coyotos kernel for GNU/Hurd. These discussions continued into 2007, but progress is slow.
Under Unix every program running has an associated user id, which normally corresponds to the user that started the process. This id largely dictates the actions permitted to the program. No outside process can change the user id of a running program. A Hurd process, on the other hand, runs under a set of user ids, which can contain multiple ids, one, or none. A sufficiently privileged process can add and remove ids to another process. For example there is a password server that will hand out ids in return for a correct login password.
Regarding the file system, a suitable program can be designated as a translator for a single file or a whole directory hierarchy. Every access to the translated file, or files below a hierarchy in the second case, is in fact handled by the program. For example a file translator may simply redirect read and write operations to another file, not unlike a Unix symbolic link. The effect of Unix mounting is achieved by setting up a filesystem translator (using the "settrans" command). Translators can also be used to provide services to the user. For example, the  translator allows a user to encapsulate remote FTP sites within a directory. Then, standard tools such as ls, cp, and rm can be used to manipulate files on the remote system. Even more powerful translators are ones such as UnionFS, which allows a user to unify multiple directories into one; thus listing the unified directory reveals the contents of all the directories (a feature that is missing in many Unixes, although available in modern BSDs).
The servers collectively implement the POSIX API, with each server implementing a part of the interface. For instance, the various filesystem servers each implement the filesystem calls. The storage server will work as a wrapping layer, similar to the block layer of Linux. The equivalent of VFS of Linux is achieved by libdiskfs and libpager, mere libraries used by these servers.
10 Alternative Operating Systems; Tomorrow's OS Today: The Desktops That Microsoft Should Watch Closely. There's a Whole World beyond Windows, after All
Mar 01, 2011; Right now, someone somewhere is developing the killer operating system feature of the future - a feature that will change...