GNU Hurd

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. Nevertheless, during 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.

Since 2005, Brinkmann and Walfield started researching Coyotos as a new kernel for HURD.[22][23] In 2006, Brinkmann 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. In further discussion HURD developers realised that Coyotos (as well as other similar kernels) are not suitable for HURD.[24]

In 2007, Hurd developers Neal Walfield and Marcus Brinkmann gave a critique of the Hurd architecture, known as "the critique",[25] and a proposal for how a future system may be designed, known as "the position paper".[26] In 2008, Neal Walfield began working on the Viengoos microkernel as a modern native kernel for HURD. As of 2009, development on Viengoos is paused due to Walfield lacking time to work on it.[27]

In the meantime, others have continued working on the Mach variant of Hurd.[28]

A number of traditional Unix concepts are replaced or extended in the Hurd.

Under Unix, every running program 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, like 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 ftpfs 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.

The Hurd requires a multiboot-compliant boot loader, such as GRUB.

According to the Debian documentation, there are 24 servers (18 core servers and 6 file system servers) named as follows:[29]

• auth (authentication server): Receives requests and passwords from programs and gives them an ID, which changes the privileges of the program.
• crash (crash server): Handles all fatal errors.
• eieio (translation server): TODO
• exec (execution server): Translates an executable image (currently ELF and a.out are supported) to a runnable image in memory.
• fifo (FIFO translator): Implements named pipes.
• new-fifo (new FIFO server): An alternate server for named pipes.
• firmlink (the firmlink translator): Implements firmlinks ‒ "half-way between a symbolic link and a hard link".[30]
• fwd (forward server): Forwards requests to other servers, used by fifo and symlink servers.
• hostmux (host multiplexer server)
• ifsock (server for sockets interface): Helps with UNIX domain socket addresses.
• init (init server): Basic system booting and configuration.
• magic (magic server): Signals that a name lookup must be resolved internally by a process when the result involves the process's state.
• null (null server): Implements /dev/null and /dev/zero.
• pfinet (pfinet server): Implements the PF_INET protocol family.
• pflocal (pflocal server): Implements UNIX domain sockets.
• proc (process server): Assigns PIDs and manages process-level actions.
• symlink (symbolic link translator): Implements symbolic links for filesystems that don't support them.
• term (terminal server): A POSIX terminal.
• usermux (user multiplexer server): Invokes user-specific translators.

ext2fs

The ext2 filesystem translator. It receives disk blocks from the microkernel and gives files and directories to the applications.

isofs

The translator for the ISO 9660 filesystem. Translates blocks of a CD or DVD to files and directories for the applications.

nfs

See Network File System.

ufs

Translator for the BSD filesystem of the same name, UFS.

ftpfs

File transfer protocol filesystem translator.

storeio

The storage translator.

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 libraries.