This was to be the kernel for the "official" FSF/GNU operating system project, the goal being to create a "free" version of Unix. Other "free" OSes such as Linux and FreeBSD have rather beaten Hurd to the punch.
Hurd is an acronym for "Hird of Unix-Replacing Daemons". Hird, in turn, is an acronym for "Hurd of Interfaces Representing Depth".
Unfortunately, it wasn't until quite recently that they had had a sufficient base of tools to be able to create an OS kernel. Other projects (Linux, the sundry BSDs ) have provided other free Unix-like operating systems providing people generally more satisfying solutions to their Unix needs.
One brief description of Hurd says that: " The Hurd ... breaks the giant Unix kernel down into various MACH programs running as daemons. Working in concert with facilities placed in the C library, these daemons provide all of the POSIX system-calls and features; from the outside they look just like a standard Unix kernel. This means that, for practical purposes, anything that you can port to Linux will also port to the Hurd. "
The hoped-for advantages of Hurd (over alternatives) were:
Hurd would provide the advantages of using Microkernels, such as easy porting to additional architectures, and easy SMP support.
This would have been true if Mach had "taken over the world" and been the microkernel getting ported instantly to every new computer architecture that came along. Unfortunately, Microsoft hired off the CMU Mach team to run Microsoft Research, which took the wind out of that idea. Hurd is just about the only thing still depending on the Mach microkernel, with the result that there are only tiny numbers of people that care about it being ported to newer and better hardware.
Interestingly, Linux has turned into a incredibly widely ported OS kernel.
Additional nifty features:
Since practically all of the functions of the OS run in user space, everything can be changed on the fly. This contrasts with the present situation where OS facilities can typically only be modified by highly privileged users. LISP Machines and Smalltalk-80 represented systems where all of the system was accessible by the user. (With the corresponding problem that users and programs were not necessarily well-insulated from one another, leaving you with a somewhat fragile system. Somewhat like Windows ...) Hurd would provide the best of both of these worlds, providing "safe" mechanisms for modifying system facilities.
A multi-server Hurd kernel would provide services such as:
An authentication server
This would be used to connect processes to ports, allowing them to identify themselves and to pass initial information to each other. This server could make use of encryption and message digest algorithms to allow authentication to take place securely across less-than-secure networks.
A process server
This would be used to maintain a database of information about Hurd processes that is not stored by the underlying kernel.
Automated resource rebalancing, where processes would migrate themselves to less-busy hosts/nodes/processors on the network.
Clever Filesystem Isomorphisms
A translator could be used to present a filesystem-like view of another part of the system, with some change of semantics. Linux's /proc file system is one example of what this could provide.
A translator would be used to present a single directory to users containing all programs they would want to execute. This eliminates the need for various /bin directories; software can be installed in whatever locations are best for managing the code.
Accessing files via FTP with an interface that treats them as being part of a file system just like any other file. To see files on a remote system, one could: cd /ftp/gnu.ai.mit.edu:rms:passwd; ls; vi README
A similar facility has been implemented within GNU Emacs in the form of the ange-ftp package.
Presumably, you lose the ability to do random access of files; FTP really only provides "sequential" access of the whole file. But this transparently provides access to files on a whole pile of OSes (MVS and VMS being probably the most special examples).
This would emulate POSIX terminal semantics. Programs could use the underlying MACH device ports for terminals for higher performance as necessary.
Program Execution Server
With a server to process arguments, a server to authenticate execution permissions, and finally a server to determine how the program actually ought to be run.
This could be modified to recognize additional sorts of executable formats.
Not unlike the Linux IBCS2 translator that turns system calls for IA-32 OSes like SCO and Solaris86 into Linux system calls, this would convert POSIX/BSD/Linux/whatever system calls into the Hurd equivalents.
Since Linux has been moving to the use of GLIBC, which is the "native" library used by Hurd, only minimal translation should prove necessary to translate the calls, as the "Hurd instance" of GLIBC has the same function calls with the same semantics. This also means that recompiling such applications for Hurd should normally be a trivial task, which the Debian Hurd Project should ensure stays so.
The understanding that went into the construction of IBCS2 should allow further translations for other OSes to be be, if not easy, not too complex.
TCP/IP, and whatever other protocols seem valuable...
Unfortunately, people wouldn't redesign applications to depend on this kind of dynamic unless Hurd actually become dominant; since it isn't, so, in practice, these neat features are curiosities rather than being practically important.
A recent set of servers distributed with Hurd include: "auth, crash, devio, devport, exec, ext2fs, fifo, fwd, ifsock, init, magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, ufs."
The term single-server refers to the idea of running a monolithic operating system kernel as a single large task on top of a microkernel like MACH or L4 or Fiasco. At present, MkLinux, Linux running atop MACH, represents running a "Linux single-server."
Hurd, on the other hand, is a multi-server that replaces the Unix kernel with a whole bunch (20, the last time I counted) of MACH servers/daemons.
Hurd activity has appeared rather slow over the last dozen years. More recently, efforts have been combined with those of the developers of Debian to produce a "Debian Hurd" system that is a little easier to install and manage than it has been in the past.