This page without all items inlined.
General-discussion FAQs
Remember that what counts is not just years but rather years x people, and in this regard, the investment into GNU Hurd's development is way below that of the Linux kernel or the BSDs. Considering how many developers are (and have been) working on the Hurd, it is actually impressive that so much has been achieved in the past couple of decades with so few people.
A good explanation is available, translated (sic) in several languages.
GNU Hurd 0.9 has been released on 2016-12-18, along with GNU Mach 1.8, and GNU MIG 1.8. Read about the Hurd's status.
OK, but when will it be finished?
Well, is the Linux kernel considered to be really "finished"? Hurd 0.9 does
work, but of course it can still become better -- beginning to
contribute and joining us is the best
way for you to help achieve that. 
The Hurd will be considerably more flexible and robust than generic Unix. Wherever possible, Unix kernel features have been moved into unprivileged space. Once there, anyone who desires can develop custom replacements for them. Users will be able to write and use their own file systems, their own `exec' servers, or their own network protocols if they like, all without disturbing other users.
A series of interesting examples is available.
The Linux kernel has now been modified to allow user-level file systems, so there is proof that people will actually use features such as these. It will be much easier to do under the Hurd, however, because the Hurd is almost entirely run in user space and because the various servers are designed for this sort of modification.
Notably, flexibility for the user:
transparent ftp
$ cd /ftp://ftp.debian.org/debian $ lspersonal filesystem
$ dd < /dev/zero > myspace.img bs=1M count=1024 $ /sbin/mke2fs -E root_owner=$UID:0 myspace.img $ settrans myspace /hurd/ext2fs myspace.img $ cd myspaceJust curious, but I keep seeing these (and other similar) concepts being brought up as the amazing selling points of the Hurd, but all of this is entirely doable now in Linux with FUSE or things like it.
Nowadays, at LAST, yes, partly. And only on machines where fuse is enabled. Is it enabled on the servers you have an account on?
I'm not sure if an ftp filesystem has been implemented for FUSE yet, but its definately doable; and loopback filesystems like in your second example have been supported for years.
As a normal user? And establish a tap interface connected through ppp over ssh or whatever you could want to imagine?
What, then, are the major selling points or benefits?
These were just examples, Linux is trying to catch up in ugly ways indeed (yes, have a look at the details of fuse, it's deemed to be inefficient). In the Hurd, it's that way from the ground and there is no limitation like having to be root or ask for root to add magic lines, etc.
It also for instance provides userland drivers, for instance the network drivers are actually Linux drivers running in a separate userland process.
It also for instance provides very fine-grain virtualization support, such as VPN for only one process, etc.
etc. etc. The implications are really very diverse...
How Many Developers?
Literally only half a handful works on the core of the system in their free time, and another half of handful helps with Debian GNU/Hurd and Arch Hurd packaging. Also, an additional half of handful of former developers are still available for answering technical questions, but are not participating in the current development anymore.
In the past (that is, a lot of years ago), the FSF did pay a few developers for working full time on the GNU Hurd. But that was for a limited amount of time only, and evidently, it was too little for getting the system into a competitive state. Nowadays, it's only unpaid (apart from some bounties) and free-time volunteers' work.
In contrast to the Linux kernel, there is no industry involvement in development. For one, this is a good thing: independency; no conflicts of interests. For another, it is also a bad thing: no dedicated full-time workforce -- which matters a lot.
This also answers the question "How come the Hurd still can't do (...) after so many years of development?"
Why So Few?
We can only speculate. One major problem might be that the architectural benefits are generally perceived as very abstract, with little practical benefit. We currently don't have many tools that are actually making use of all the possibilities.
Another reason is that it's been taking too long. Today, most people don't believe it will ever be ready for production use, and thus would consider involvement a waste of time. This latter point is invalid, of course, as learning can never be a waste of time. The same holds for the challenges raised by the GNU Hurd -- we can only learn and improve upon working on them.
For likely the same reasons there is no industry interest in the GNU Hurd: its advantages are too abstract and incomplete for being of interest there.
As for the scientific sector, the GNU Hurd projects was rather about using a microkernel intead of doing research on them, for example. But, there have been some projects and theses done, and some scientific papers published on GNU Hurd topics, and we're generally very interested in further such projects.
Attracting New Faces
We're an open project: any interested party (you!) are very welcome to start contributing. Mentoring is possible, too, to help you get started.
Likewise, for reaching out to new developers, we're participating in Google's Summer of Code program.
As el_presidente commented on http://lwn.net/Articles/568745/#CommAnchor568780:
Developers, developers, developers, developers.
They are the people that matter at this point in time.
More technical details are described in PATH_MAX Is Tricky
For porting guidelines, see guidelines
Is it really standard not to define them?
These macros are indeed optional in Posix, so not defining them remains standard-compliant.
Their definition was actually not completely clear, Posix 1990 was ambiguous
about it including \0 or not, it was made clear later on that it does include
it, but some software still add +1. Sometimes PATH_MAX is even understood as
the filename sections of paths, which is actually NAME_MAX, which is indeed
limited by filesystems constraints, but then it is filesystem-dependent, and
even depend on its revision, so to be rather queried at runtime with pathconf.
But it's really convenient! Isn't allocating dynamically much more complex?
FOO_MAX constants are most often used as “reasonable size to allocate a
path”. On Linux it is typically 4096, which is not that reasonable (a whole
memory page, thus a TLB lookup) when manipulating a lot of paths. Allocating
dynamically would use much less memory.
Most often interfaces can be made to properly allocate dynamically. Notably,
since Posix 2008 realpath(path, NULL) and getcwd(NULL, 0) allocate the path
dynamically.
In general, using FOO_MAX in source code (with a large value) leads to code
that is not actually checking against overflows. PATH_MAX being 4096 is
actually "wrong" on Linux:
$ printf '#include <limits.h>\nPATH_MAX' | cpp -P
$ d=0123456789; for i in `seq 1 1000`; do mkdir $d; cd $d 2>/dev/null; done
$ pwd | wc -c
Using such paths lead to various broken software, we could for instance notice:
- nautilus crashes because of unhandled signal 8, arithmetic exception
- tar can create an archive containing such paths, but cannot untar it
- filelight just ignores the path
- gdb refuses to work
Using a large PATH_MAX value just hides these bugs under the
carpet. Attackers will happily try to exploit them.
Can't it just be defined to PTRDIFF_MAX?
A lot of programs which blindly use FOO_MAX as allocation size would then just
at best either not compile or at worse compile but fail or segfault at execution.
These also imply ABI problems
Exposing a hardcoded limitation like FOO_MAX also means hard-defining them
into binaries, making them part of the ABI, and then a hell to change. See for
instance Windows which has been stuck with MAX_PATH being 260. Some libraries
(e.g. libusb1) even expose them in their own ABI, thus making the increase a
very nasty flag-day.
Before asking a question, first make an effort to find the answer to your question. A lot of questions have been asked and answered before, so please spend some time trying to solve the problem on your own (e.g. search the web, search these web pages, etc.), and show us that you did so when you ask your question.
When asking, (1) be detailed, and (2) demonstrate that you made an effort, e.g. "I am having trouble frobbing the foo. I searched the web and only found information regarding how to frob a bar, but that seems unrelated." Provide as many relevant details as possible, as well as how to reproduce the issue.
This document may help you understand some developers attitudes and social norms.
A Microkernel has nothing to do with the size of the kernel. Rather, it refers to the functionality that the kernel provides. It is generally agreed that this is; a set of interfaces to allow processes to communicate and a way to talk to the hardware. Software drivers, as we like to call them, are then implemented in user space as servers. The most obvious examples of these are the TCP/IP stack, the ext2 filesystem and NFS. In the case of the Hurd, users now have access to functionality that, in a monolithic kernel, they could never use, but now, because the server runs in user space as the user that started it, they may, for instance, mount an FTP filesystem in their home directory.
For more information about the design of the Hurd, read the paper by Thomas Bushnell, BSG: Towards a New Strategy of OS Design.
The Hurd is currently slower than Linux, yes. But not very much, so it is completely usable.
Take care when running the Hurd in fully-virtualized machines: virtualization software use ugly heuristics to make Linux run faster, which will not work on the Hurd (or BSD, etc.) so comparisons in virtualized environments do not really hold. Also take care of not comparing Hurd (which is currently 32bit) with a 64bit Linux execution: 64bit has much more computational and optimization possibilities than 32bit. At least, use -m32 to build a 32bit Linux version of a test for comparison.
The main reason for slowness is not because of the overhead of RPCs. It's mostly simply because less care has been done on implementing what makes Linux fast: intelligent read-ahead, carefully-tuned page cache, etc. or even just missing DMA support for your disk controller.
There is no ground reason this can not be achieved on GNU/Hurd, it has just not been a priority until now (first make it work, then make it work fast). We are currently working on multi-page pager and read-ahead, which should improve this a lot.
Please see the contributing page.
Yes and no. GNU refers to the system as a whole, while GNU/Hurd is more specific, saying that it is the GNU system running on the Hurd -- to differentiate it from the GNU system running on Linux, GNU/Linux.
It's on Savannah. See also the GNU Development Resources, for more information.
The microkernel has to provide memory management and user-level-managed page faulting, thread scheduling, and IPC.
One would have to reimplement the mach/ and sysdeps/mach/ parts of glibc
and libpthread. One would have to rewrite mig to generate the new IPCs. One
would have to rewrite libpager to handle paging.
All mach_ calls in glibc and hurd would need to be updated.
Quite a few other Hurd tools also assume a Mach kernel and would have to be adapted or rewritten.
Please try to reproduce bugs which are not obviously Hurd-specific on Debian GNU/Linux and then file them there.
If you find a genuine issue in Debian GNU/Hurd, please read this debian page to learn how to submit report a bug. If you are running Debian, then its much easier to use the reportbug package.
If you find a bug in the Hurd or GNU Mach themselves, either file a bug against the respective Debian packages, or directly at http://savannah.gnu.org/bugs/?group=hurd
It is a frequently asked question, which microkernel the Hurd should be based upon assuming that Mach is no longer considered state of the art, and it is well known that there has been a lot of discussion about this topic, and also some code produced, but then, years later, the Hurd is still based on GNU Mach.
Around the turn of the millenium, some of the Hurd developers began experimenting with using other microkernels for the Hurd, as they have been encountering a number of fundamental design issues with the Mach microkernel, mostly with respect to resource management problems.
At that time, L4 (Pistachio) was the prime candidate. A reimplementation of
the Hurd on this microkernel looked promising, and got pretty far (running some
simple POSIX programs, such as banner). However, over time some lingering
design issues turned out to be fundamental problems: the original L4 is not
suitable for building object-capability systems like the Hurd. Thus
development was aborted in 2005.
During that process, Neal Walfield and Marcus Brinkmann started on a period of research on other microkernels, getting in deeper contact with other researchers. There was a lot of discussion, and a lot of good ideas produced, but a straight-forward port of the Hurd to such a modern microkernel (Coyotos, or the new L4 variants, for example) didn't seem feasible to them anymore: they found microkernel design and system design to be interconnected in very intricate ways, and this demanded design changes in the Hurd's core itself.
Based on this experience, the next step was to write an own microkernel instead, which Neal Walfield began doing with his experimental Viengoos project, for his research on resource management. Currently he works in another research area though, and thus Viengoos is on hold.
Note that while none of the microkernel research work is active now, the previous experiments already yielded a lot of experience, which will be very useful in the further development / improvement of the mainline (Mach-based) Hurd implementation.
For more details about this topic, please see our history page about the port to another microkernel.
GHAMP is the GNU/Hurd-based Apache, MySQL, PHP solution stack -- analoguous to GLAMP, which is based on GNU/Linux.
Pronounce it like the G in GNU, followed by a mostly silent H, and AMP as in amplifier.
Hardware/Software support FAQs
As of September 2024, the Hurd runs well on old Thinkpads. We recommend the Thinkpad T60, which supports a maximum of 4GB of RAM, and you can use an SSD. If you have difficulty installing the Hurd, then try setting your harddrive mode to "legacy" in the BIOS. A cheaper option is the T43 (2GB max RAM).
Other working Thinkpads include the X200, T400, or T500 Thinkpads, which support internet connectivity via the ethernet port. You can use an SSD on these laptops, which support a maximum of 8GB of RAM. The Debian installer images from 2023 fail to boot these machines, but you can install the Hurd via Debian's CrossInstall. Until we fix the libdiskfs/ext2fs issues on the 64 bit port, we recommend that you use the 32 bit version of the Hurd.
Other hardware that is known to work includes the Dell Inspiron 1750 on i386 Debian/Hurd. It won't boot with the current installer (June 2023 debian-hurd i386 net-install) because of an FPU issue (fixed upstream). I had to remove the optical drive. It hangs for one minute during boot on ACPI init, but otherwise fine when disabling full tree parsing. The touchpad, keyboard, display, ethernet, and the hard drive works (in legacy mode).
The Hurd can run on more recent Intel machines, but with no internet connectivity! You can always use the Hurd via qemu.
Currently, for disks Mach integrates old drivers from Linux through some driver glue code, which provide IDE disk support, and we have an AHCI driver which provides SATA support. Rumpdisk lets us use modern hard drives, like SSDs.
For network boards, we curently use the DDE toolkit to run linux 2.6.32 drivers in userland processes, which we may eventually replace with rump drivers. Note however that we have of course not tested all drivers. We obviously don't even have all kinds of hardware. So we can not promise that they will all work. What probably works for sure is what we usually use: the rtl8139 and e1000 drivers for instance. Firmware loading is not implemented yet.
For graphical mode, Xorg is supported, e.g. with the vesa driver. DRM is not supported yet. To run X then, you must use the proprietary BIOS, since coreboot/libreboot do not include a working vesa driver.
Hurd developers are working on adding USB support with rumpusbdisk.
Xen is also supported, both blkfront and netfront.
As of March 2014, 79% of all Debian packages are available for Debian GNU/Hurd. Of course, testing and bug fixing is welcome, as we have obviously not tested all of them.
Generally, packages that aren't Linux-specific (see Packages That Won't Be Ported) are expected to work on GNU/Hurd too. Notably, X.Org, GNOME, KDE, Firefox work. See the guidelines document for some common build problems and their solutions.
It is not, there is no real reason why it would be particularly slow, it is just about switching virtual addresses and registers, which all OS have to perform anyway.
A quick-and-dirty benchmark:
#include <fcntl.h>
#include <semaphore.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>
#include <sys/mman.h>
sem_t *sem1, *sem2;
void worker1(void) {
time_t last;
int n = 0;
last = time(NULL);
while(1) {
time_t new = time(NULL);
if (new != last) {
printf("%d\n", n);
n = 0;
last = new;
}
n++;
sem_wait(sem1);
sem_post(sem2);
}
}
void worker2(void) {
while(1) {
sem_post(sem1);
sem_wait(sem2);
}
}
int fd;
void get_sems(void) {
void *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
sem1 = ptr;
sem2 = sem1+1;
}
int main(void) {
fd = open("/tmp/foo", O_CREAT|O_TRUNC|O_RDWR, 0666);
ftruncate(fd, 4096);
get_sems();
sem_init(sem1, 1, 0);
sem_init(sem2, 1, 0);
if (fork())
worker1();
else {
get_sems();
worker2();
}
}
run on my current Linux system (a Core i5-10210U), gets about 300k switches per second on Linux. Running it on Hurd-in-kvm (which would supposedly be slower) gets about 400k switches per second.
More precisely, during the Debian installation, around the extraction of the netdde package one gets:
/hurd/random: Warning: Failed to read random seed file /var/lib/random-seed: (system kern) error with unknown subsystem
This is a harmless glitch.
Yes. The default pager recognises and respects Linux swap partitions.
There are plans for 64-bit kernelland with 32-bit userland, which will notably permit to efficiently make use of more than 2 GiB memory and provide 4 GiB userland addressing space.
A 64-bit GNU/Hurd is also coming soon, progress is tracked on 64-bit port! Hurd developers ported GNUMach to 64-bit some time ago. Then they started making significant progress on the x86_64 userland port in Feb 2023. As of September 2024, the Debian hurd-amd64 port works just like the hurd-i386, except for missing packages and more bugs, namely swapping issues with rumpdisk and deadlocking issues with libdiskfs/ext2fs. We are currently building 64-bit packages. We plan on supporting both a 32-bit and 64-bit Debian GNU/Hurd, only not both at the same time. However, there is no plan to fix the year 2038 concern on a 32-bit system.
That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory.
There is a start of work on implementing a FUSE library on Hurd; its support is not updated to the latest version, but at least some fuse filesystems do work already.
The 2 GiB ext2fs limit has been removed.
IDE disk drivers however currently do not support more than 2^28 sectors, i.e. 128GiB.
The gnumach AHCI disk driver supports up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB.
You can have a bigger disk, you just should not put disk partitions beyond these limits for the drivers to be able to read from them.
The 830MB RAM limit has been removed, but just like any 32-bit OS without bad tricks,
GNU Mach can not cope well with lots of memory. Latest versions of the Debian gnumach
package will limit themselves to 3 GiB of memory. If you want more, you can twiddle
the VM_MAX_ADDRESS limit between kernelland and userland in
i386/include/mach/i386/vm_param.h, but glibc and the hurd servers will not cope
well with less than 1 GB.
There is a 64-bit port in progress.
If you have an older version, or still experience problems with vmstat (see
above) reported much less memory than you have, the best is to limit the memory
it can see via GRUB's upppermem feature. Add uppermem 786432 to GRUB's Hurd
entry in menu.lst.
Until recently, GNU Mach did not support SATA disk drives (/dev/sda etc. in GNU/Linux) natively, the only way to get those drives to work used to be to put them into compatibility mode in the BIOS, if such an option exists. GNU Mach will then recognize them as hd etc.
An AHCI driver has been added on 10th May 2013, which should bring support for a wide range of SATA controlers. Please however make sure to configure the BIOS in AHCI mode (as opposed to RAID mode).
Damien Zammit ported a rump kernel to the Hurd to use SSD devices. We call it rumpdisk. With rumpdisk you can have a 2TB partition!
IRC, freenode, #hurd, 2012-01-13
<veganman> so there's absolutely no way, even slowly to run i386 linux code
under hurd/i386? I have a small app, commercial, which I have to get
running there
<veganman> no source
<braunr> no way
<braunr> you'd need to create a userspace linux server catching linux
system calls and calling hurd specific stuff to implement them
<braunr> it doesn't exist, it may be hard to implement
<braunr> some cases will definitely be hard to implement
<veganman> so, no magic linux lxemu on windows?
<veganman> or linuxemu on plan9
<pinotree> nope
<veganman> I remember something silly, sonmone had compiled linux as a user
application on plan9 and inserted his own binaries as
a code object, to be run on plan9, for use on ibm hpc hardware
<veganman> it was ron minich
<veganman> 5e.iwp9.org/slides/linuxemu.pdf
<veganman> I think that was it
<veganman> google for linux & cnk for additional clues
IRC, freenode, #hurd, 2012-01-21
<chromaticwt> is it possible to transfer servers running on one microkernel
on one machine, to another microkernel running on a different machine?
<chromaticwt> two machines will be running the complete os
<antrik> well, if the code for network-transparent IPC still existed, it
might be possible to move a task to another machine, while keeping the
port associations with the original system...
<antrik> if you mean actually moving it to another system, that's pretty
much impossible in any system that has stateful interfaces
How difficult is it to port the GNU/Hurd system to run on another architecture?
The GNU/Hurd system consists of Hurd servers running as user-space processes on top of the GNU Mach microkernel. The system functionality is usually accessed through the POSIX interface that is provided by glibc and libpthread.
A whole-system port involves touching all these components, with varying degree, of course. In 2024, Sergey Bugaev completed an experimental system port to AArch64, so be sure to consult him, if you are considering a system port.
For a CPU architecture port, the microkernel is the most involved part, followed by glibc and the threading library.
The original Mach microkernel was portable to a number of architectures which were a lot more popular at the beginning of the 1990s than they are now.
The Debian GNU/Hurd system is currently available for the x86 and X86_64 architectures and it is probably the most up-to-date with about 70% of Debian's packages available. There also exists an experimental GNU/Hurd AArch64 port. Contact Sergey if you are interested in running the Hurd on AArch64. You can also run the Hurd with emulators such as QEMU (or KVM), or VirtualBox. Besides this, there is a port for the Xen domU sub-architecture. With Xen, you can run the Hurd and GNU/Linux in parallel. If you are already running Guix System, then childhurds are probably the easiest way to try out the Hurd.
Further on, there are some unfinished porting attempts for the Alpha, MIPS and PowerPC architectures. These have not been completed due to little developer interest.
Another option is to do the port at a different layer: port the Hurd servers to not run on the GNU Mach microkernel, but instead on top of another microkernel. Or, even by providing a Mach emulation layer on top of a monolithic kernel. For example, there could be a port for having Mach run as a POSIX user-space process, or by implementing the Mach IPC facility (as well as several others) as Linux kernel modules. While there have been some experiments, no such port has been completed yet.
IRC, freenode, #hurd, 2013-09-05
<rah> what would be required to port the hurd to sparc?
<pinotree> port gnumach, write the sparc bits of mach/hurd in glibc, and
maybe some small parts in hurd itself too
<rah> what would be required to port gnumach? :-)
<braunr> a new arch/ directory
<braunr> bootstrap code
<braunr> pmap (mmu handling) code
<braunr> trap handling
<braunr> basic device support (timers for example)
<braunr> besides, sparc is a weird beast
<braunr> so expect to need to work around tricky issues
<braunr> in addition, sparc is dead
<rah> mmm
<rah> it's not totally dead
<rah> the T1 chips and their decendents are still in production
<rah> the thing is I'd like to have real hardware for the hurd
<rah> and if I'm going to have two machines running at once, I'd rather one
of them was my UltraSPARC box :-)
<braunr> rah: unless you work hard on it, it's unlikely you'll get it
<rah> braunr: of course
The Hurd servers themselves are multithreaded, so they should be able to benefit of the parallelism brought by SMP/Multicore boxes. This needs testing as SMP support has recently been added to Mach.
Mach used to be running on SMP boxes like the Intel iPSC/860, so principally has the required infrastructure. It has recently been enhanced to support nowadays' SMP standards like ACPI.
However, GNU Mach's Linux device driver glue code isn't SMP-safe so build with --disable-linux-groups to test SMP and use rumpdisk to provide disk access.
To build an SMP supported gnumach with kdb: ../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups
This will by default allow you to boot with one core isolated to the default processor set, and all the other detected cpus will be in the slave processor set. The slave processors need to be enabled per-task using RPCs to manipulate processor sets.
See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program that can enable a task to use the slave processors by calling ./smp /bin/bash for example.
Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting to boot a full SMP system, (if you revert the slave processor pinning commit). This is what needs to be debugged one-by-one by running each translator using ./smp until we can squash these race condition bugs.
There are follow-up issues about multiprocessing and multithreading.
Many computer operating systems strive to be POSIX (Portable Operating System Interface) compliant, as it makes cross-compiling and program portability much easier than having to package something for every new distribution.
Is it favorable of rather a hindrance to be compatible to POSIX and similar standards?
A lot of things in POSIX et al. are designed for UNIX-like systems with traditional monolithic kernels.
Thus, a microkernel-based system, as ours is, has to employ a bunch of
detours, for example to implement the fork system call.
On the other hand, (mostly) complying to these standards, made a really big body of software just work without any (or just trivial) porting. Especially so for command-line programs, and libraries.
But: a large part of today's user programs are not written according to POSIX et al. low-level interfaces, but against GNOME, GTK+2, and other high-level frameworks and libraries. It may be a valid option to enrich these instead of striving for total POSIX compliance -- and the high-level programs (that is, their users) may not even notice this, but we would avoid a lot of overhead that comes with wrapping the Hurd interfaces to be POSIX compliant.
External
- The Open Groups POSIX Specification
- Wikipedia article on POSIX
Given that both Linux and GNU Hurd are using the ?ELF binary format, it is in theory possible to have a system installation where you can dual-boot using either the ?Linux kernel, or the GNU Hurd, so that everything but the kernel is shared. For this, all programs need to agree to rely on only one abstraction layer, for example the standard C library (glibc). (Additionally, for example for system calls that are not covered by glibc calls, you'd need to be able to reliably trap and emulate these.) However, Linux' and the GNU Hurd's ?ABI's have sufficiently diverged, so that this is not easy to do. That's why you can't currently install a system in this way, but you need a separate installation of the userspace suited for the Linux kernel, or the GNU Hurd.
Running GNU/Hurd FAQs
You are apparently not running the Hurd console, only the Mach console, which Xorg does not know how to read.
Make sure to enable the Hurd console in /etc/default/hurd-console
Possibly something broke translators there. You can run
dpkg-reconfigure hurd
to rebuild entries there.
This is due to a missing implementation of a corner case of Posix signaling for non-root processes to root processes.
One can however use the usual ctrl-alt-backspace shortcut to kill the X server.
You just need to configure it via the file:
/etc/X11/xorg.conf.d/xorg-ctrl-backspace.conf
Section "InputDevice"
Identifier "Generic KeyBoard"
Driver "kbd"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
This is the error message for EIEIO (pronounce E-I-E-I-O). This error code is
used for a variety of "hopeless" error conditions. Most probably you will
encounter it when a translator crashes while you were trying to use a file
that it serves.
You can thus think of it as an equivalent of the "blue screen of the death" or "Oops"... except that it's just an error! It doesn't take your whole system away with it, only the particular operations that was going on.
The term "Buy the farm" is synonymous to "Kick the bucket," meaning "to die". More specifically, "Bought the farm" was used by the US Air Force to denote a fatal crash. To say "Computer bought the farm" is simply saying "Your computer crashed".
Sure, we could just say "Crash!", but then again, so could the Air Force.
Old versions of emacs used to have this issue. This is fixed in emacs24.
- You can try out the Serial Howto at http://www.nongnu.org/thug/serial-howto.txt
- For kernel messages, you can append
console=com0to the kernel command line.
Edit /etc/default/hurd-console to configure the Hurd console.
See console for further information about the Hurd console.
There is no dmesg command, since the kernel does not keep a buffer of its
messages. syslog however dumps them into /var/log/dmesg, so you can simply cat
that.
If ps hangs, try ps -M which should still work by not getting detailed
information from processes.
The distinction between / and /usr has historical reasons. Back when Unix
systems were booted from two tapes, a small root tape and a big user tape.
Today, we like to use different partitions for these two spaces. The Hurd
throws this historical garbage away. We think that we have found a more
flexible solution called union filesystems, which allow to create virtual
filesystems which are the union of several other filesystems. However, support
for union filesystems is still in early development.
This happens because currently there is no way to detect console users.
On Debian GNU/Hurd systems, you need to run
# dpkg-reconfigure xserver-xorg-legacy
and select Anybody for starting X.
Debian GNU/Hurd FAQs
If you want to use the apt source facility, make sure that
/etc/apt/sources.list contains a line like
deb-src http://ftp.de.debian.org/debian unstable main
... replacing de with your homeland's code.
Open Issues FAQs
If logging in doesn't work, e.g. you enter a username, and it doesn't even prompt for a password, but directly say "Invalid password", you probably have some translators which got deconfigured for some reason. You can try to reboot in emergency mode, and run
# dpkg-reconfigure hurd
to reinstall translators.
Quite a few of them are actually benign:
/dev/hd0s1: Deleted inode 95849 has zero dtime. FIXED.
[...]
Block bitmap differences: -(988160--988163) -(989627--989634) [...]
[...]
Free blocks count wrong for group #30 (16477, counted=16741).
[...]
Free blocks count wrong (2170675, counted=2170956).
[...]
Inode bitmap differences: -244986 -245011 -(245107--245108) [...]
[...]
Free inodes count wrong for group #30 (4632, counted=4649).
[...]
Free inodes count wrong (880891, counted=880909).
see ext2fs dtime
/dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0.
see e2fsck i file acl hi, fixed in e2fsprogs 1.42.13
Some applications don't themselves link against libpthread, but then load plugins which do link against libpthread. This means internally switching from single-threading to multi-threading, which is only supported since libc0.3 2.19-16~2. Previously, it would result in errors such as:
./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
This could be worked around by making the application link against libpthread (i.e. not only the plugin, but also the main binary), or without recompiling by explicitly pre-loading libpthread, for example:
$ LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 [application]
But it should now be gone, simply upgrade libc0.3.
If you see a db> prompt on the console, something unexpected and bad happened
inside the GNU Mach kernel, which it cannot
recover from. (Think of it as the equivalent of a Linux kernel oops, for example.) The db> prompt is actually the GNU Mach
kernel debugger waiting for your commands. For example, you can then reboot
the system by issuing the reboot command, or if you want to help analyze the
problem, start by typing in the trace command, which will display the
function call trace leading to the crash:
0x8007cf1(8088488,5e,40000008,2aa008,0)
0x80071bc(0,0,0,0,0)
0x8006831(24fe00,2000,b,800,0)
This can be decyphered by using:
$ addr2line -i -f -e /boot/gnumach 0x8007cf1 0x80071bc 0x8006831
You can then send us the whole results of the trace and the
addr2line commands, as well as
the exact version of the GNU Mach kernel you were running, for further
investigation. More information about the GNU Mach
debugger is available.
If you get the error bad hypermeta data when trying to mount an ext3
partition from GNU/Linux, that is usually because the file system has not been
unmounted cleanly (maybe GNU/Linux got suspended to disk) and the Hurd cannot
mount it as ext2 without checking. Either boot back into GNU/Linux and unmount
it or you can try to run fsck.ext3 from GNU/Hurd directly.
In some virtual machines (e.g. VirtualBox), "probing eata on XXX" may be quite long. This is apparently due to poor efficiency of the virtualizer, not Mach. There is no such issue on real hardware or using qemu/kvm.
Copying baseGNU to the virtual disk works. Even booting got through but when I try to run native-install it never gets to the very end. First time it froze on sed package, the other time on sysv-rc.
How much memory did you configure for the QEMU system? It may simply be -- I've seen this myself -- that the system runs out of memory, as at the native-install stage (I think at least) swap is not yet configured and enabled. What I've been doing is: boot (with -s), MAKEDEV hdWHATEVER in /dev/ for the swap device, run /hurd/mach-defpager, followed by swapon /dev/hdWHATEVER. Does this help?
Thank You very much, more memory solved the freezing.
Development FAQs
In Debian, to get ?debugging information for glibc, you need to install the
libc0.3-dbg package. At the place ?GDB looks for debugging
symbols by default (/usr/lib/debug/lib/), Debian's libc0.3-dbg stores only
the frame unwind information used for backtracing. If you want to step into
glibc while debugging, you need to add LD_LIBRARY_PATH=/usr/lib/debug to
debugged program's environment (set env VAR value from the GDB command line).
If that still does not work, try LD_PRELOAD=/usr/lib/debug/libc.so.0.3
instead.
In order to ?debug translators and being able to step into glibc
during it, on Debian you need the hurd-dbgsym and libc0.3-dbg packages installed.
If you need to debug the initialization of the translator, start the translator
like
$ settrans -Pa /foo /usr/bin/env LD_LIBRARY_PATH=/usr/lib/debug /hurd/foofs
The -P option will make it
pause and you will be able to attach ?GDB to the process.
Old FAQs
Frequently Asked Questions about the GNU Hurd
This document attempts to answer the questions that most often plague
users when they are talking about, installing, using, compiling and
developing the GNU Hurd as well as its binary distribution Debian
GNU/Hurd. Be sure to read this before asking for help.
The GNU Hurd is under active development.
Be aware that there is a lot of work yet to be
completed; you will find bugs; your system will crash. That said, there
is a lot of room for contributions at all levels: development of the
Hurd and Mach proper, porting applications, writing documentation and,
most importantly, user feedback.
Should you have a question that is not answered by this document and you
feel that it should be, submit it and, if possible, with an answer.
Each section is copyright its respective author(s). Permission is
granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.1 or any later version
published by the Free Software Foundation; with no Invariant Sections,
with no Front-Cover Texts and with no Back-Cover Texts. A copy of the
license is included in the file COPYRIGHT.
Neal H Walfield
neal@cs.uml.edu
? Installation
?? What partition type should I use for my GNU/Hurd partitions?
{MB} You should use an ext2 filesystem. Alternatively, you may use BSD
style ufs. The partition type number for ext2fs is 0x83 (this is the
same as in Linux), not 0x63 (GNU HURD). Thomas explains why 0x63 is the
wrong choice:
One day we may have a new filesystem format, which would
probably be called the GNU Hurd filesystem format, and might
well use that partition code.
Regardless, as Roland points out, it is always an error to use that code
for an ext2fs partition,
?? How do I name partitions?
{MB,NHW} I knew you would ask this. If I had to reduce this FAQ to only
one question, I'd choose this one. It is pretty easy, but you have to
know that there are actually several incompatibly naming convention.
First, the Hurd: if the disk is question is a SCSI disk, you must know
the SCSI device number; if it is an IDE disk, you must know what
controller the disk is on and whether it is a master or a slave. The
Hurd uses the BSD naming convention which, is to say, disks are ordered
according to their physical location, numerically, starting from zero.
This naming scheme is quite similar to that found in Linux. There, the
master disk on the primary controller is designated as `hda' and the
slave as `hdb'. On the secondary controller, the master and the slave
are designated by `hdc' and `hdd' respectively. Under the Hurd, `hda'
would become `hd0', `hdb' would be referred to as `hd1', etc.
In the Hurd, like in BSD, partitions are called `slices' and are
numbered starting from one. Thus, to name a particular partition, we
take the disk name, append a `s' and the partition number. Again, this
is similar to Linux except, there is no `s'. For instance, `hda1' would
become `hd0s1'.
GRUB, the boot loader, uses a completely different nomenclature: it
probes the BIOS and appends each disk in turn to an array. Disks are enumerated
using zero based arrays. GRUB 2 enumerates partitions from one, while GRUB 1
used to enumerate them from zero.
The format is:
`hd (<disk>, <partition>)'. Thus, in GRUB 2 `hd (0, 1)' refers to the first
partition on the first drive detected by the BIOS (or the second partition with
GRUB 1). As Grub now has tab
completion, there is not a lot of guess work.
?? How much swap do I need?
{ST} The usual rule of thumb applies: the same amount as RAM, for instance.
?? Why do I get ``Operation not permitted error''?
{MB} You forgot to set the file system owner of the GNU/Hurd partition to
``hurd''. The Hurd uses additional information in the inodes to set
translators. To make this work, the partition must be marked as ``owned
by the Hurd''. This is normally done by passing the `-o hurd' option to
`mke2fs' when creating ext2 system from other operating systems
(filesystems created in GNU/Hurd automatically enable this option).
If you failed to do this, you can still use the `e2os' script.
?? After `native-install' is finished, I had to write tthhiiss
wwaayy. In particular, I had to type `rreebboooott' to reboot.
{MB} Funny, isn't it? In addition to the rescue `term' server in
`/tmp/console', another `term' server got started and is clobbing the
keyboard input. After a reboot this problem vanishes as only one `term'
server will remain. If `tar' would support translator, we would not
have this problem... Even if you don't experience this problem right
after the installation, reboot immediately so you don't hit this bug by
accident.
? Setup
?? How do I add a swap partition?
{MB} A swap partition is also called a paging file. Usually, it is
sufficient to add the swap partition to `/etc/fstab', just as you would
under Linux. You can swap to a Linux swap partition and the Hurd will
honour the Linux swap signature (both versions). The Hurd will just as
happily swap to any other raw disk space and overwrite anything it
finds. So, be careful!
If you want to swap to a file or make sure that it checks the Linux swap
signature before, you need to edit `/boot/servers.boot'. The syntax is
the partition device file name plus, optionally, the swap file inside an
ext2fs partition, followed by a space and then one of:
`$(add-raw-paging-file)', `$(add-linux-paging-file)',
`$(add-paging-file)'. The first works with any partition or file and
does not honour any swap signature or other data. The second has a
safety check and only uses the file if a Linux swap signature is found.
The third looks for a swap signature first and falls back to raw paging
if it failed to find one. This is also the default for entries in
`/etc/fstab'.
?? How do I set up a network?
How do I set up a loopback device?
{MB} In the former case, be sure that GNU Mach detected your network
card. Either way, you need to setup `pfinet'. Documentation can be
found at:
http://www.debian.org/ports/hurd/hurd-doc-server#pfinet
Don't forget to fill in `/etc/resolv.conf', `/etc/hosts', etc.
Of course, you only need to do this if the installation routine didn't
do it for you.
?? Can I use the GNU/Linux version of `e2fsck' on a GNU/Hurd partition?
{MB} Yes, at least since `e2fsprogs-1.05'. Check this with `e2fsck -V'
first.
{NHW} Do not try to defrag your partition as this utility does not know
about translators.
?? Why are pipes not working?
{MB} `settrans -fgc /servers/socket/1 /hurd/pflocal' should help.
? Usage
?? Where is the documentation?
{NHW,MM} There are neither man pages nor info nodes for the Hurd
translators and commands. Documentation lives inside of the binaries
and can be found by passing the `--help' option to a given command.
For instance:
# /hurd/ext2fs --help
will tell you what types of options the ext2fs translator accepts.
The GNU/Hurd User's Guide and the GNU Hurd Reference Manual both
provide some help about the usage of and concepts behind the GNU Hurd.
You can find them, among others, at:
http://www.gnu.org/software/hurd/docs.html
?? What is the login shell?
{MB} The Hurd has the concept of a not-logged in user. This user has
neither user ids nor groups ids. This stems from the fact that the Hurd
supports uid and gid sets and one possibility is, of course, the empty
set. Rather than deny access in this case, filesystems in the Hurd offer a
fourth permission triplet (i.e. rwx) which is used to determine the
privileges for users with no credentials. This, however, needs to be
enabled on a file by file basis. By default, the `other' permission
triplet is used.
The Hurd login shell is a shell running with neither uids nor gids. To
restrict access to your files, either enable and change the fourth
permission triplet or change the login shell of the `login' user in the
password file to `/bin/loginpr' which implements the standard login
prompt.
?? How do I use non-US keyboard bindings?
{ST} On Debian Hurd, you can configure the console layout from
`/etc/default/hurd-console`.
?? How do I enable color on the console?
{NHW} If you are using the GNU Mach microkernel, you can set your
terminal to `mach-gnu-color'. For instance:
# export TERM=mach-gnu-color
?? How can I enable virtual consoles?
{ST} On Debian Hurd, it is already enabled by default, and configured from
`/etc/default/hurd-console`.
{AMS} This can be done by running the following command:
console -d vga -d pc_kbd -d generic_speaker /dev/vcs
If something went wrong, or if you just wish to exit the Hurd console
then hitting C-A-<backspace> will exit it.
?? What are these strange pids `0`, `2', `3', `4`, and `5`?
{MB,ST} Zero is the kernel, one is the root filesystem server, two is the
`exec` server (which handles starting programs), three is the init process, four
is the `proc` processus server, five is the `auth` server (which
handles user authentication).
?? Why does `ps aux' give me strange output?
{MB,MM} Try `ps Aux'. Indeed, under GNU/Hurd, `ps aux' doesn't list
all processes: it omits the session and group leaders, and the
processes without parent.
?? I have a hung process that I want to kill, however, `ps' is now
hanging too.
{MB} Interrupt it and pass it the `-M' option.
{NHW} By default, `ps' gathers information from both the proc server and
the processes themselves (via their message port). If a process it
hung, it will not be able respond to its message port and thus, ps will
wait forever. The `-M' option instructs ps to not gather information
that would require use of the message port.
?? Why are my translators dying?
{NHW} Try passing the `-ap' flag to settrans. By default, settrans only
sets a passive translator, therefore, no output will show up on your
terminal. Using `-ap', however, sets both the active and the passive
translator which, means that the translator starts immediately and its
stderr is connected to you terminal.
Additionally, the biggest problem is passing relative paths to passive
translators. You cannot predict what the current working directory of a
translator will be when it is setup as a passive translator.
?? Why can I `read' a directory?
{MB} It is important to understand that there is nothing special about a
directory under the Hurd, it is just another file. This fits in with
the translator concept where a translator can appear as a directory but
provide also as a file.
? Trouble shooting
?? When the APM support in the BIOS spins down my disk drives, the
Hurd is unable to wake up. What's wrong?
{MB} APM is not supported in the current version of GNU Mach, sorry.
Please disable APM in your BIOS setup.
?? What are these messages referring to `default pager', `paging',
and `pager request'?
{MB} The default pager handles virtual memory allocation. If it can't
allocate a new memory page because you are out of memory, some terrible
things may happen. Whenever you get errors referring to any of these,
you either need more memory (make sure you have swap) or you have found
a memory leak.
?? What is a gratuitous error?
{MB} This comes from `strerror(EGRATUITOUS)'. If you check glibc's
documentation, it will say that this error code has no purpose. This,
however, is not quite true. You only get this when something terrible
happens. Thomas explains:
More precisely `EGRATUITOUS' officially means that some server
has responded in an impossible or protocol-violating fashion.
There are some cases in the Hurd where `EGRATUITOUS' is returned
and probably something else should be chosen instead.
If you can reproduce this error message, please report it.
?? What does ``/dev/hd0s1: MOUNTED READ-ONLY; MUST USE `fsysopts
--writable''' mean?
{NHW} In this case, /dev/hd0s1 was not unmounted cleanly. The Hurd
will, on boot up, run ``fsck -p'' on any partitions that it finds in
/etc/fstab, so, you may want to consider adding this partition to that
file. If you are sure that the partition is fine, you can run:
# fsysopts /home --writable
to ask the translator sitting on /home to change from read-only to
read/write mode. Note that the command is being sent to the filesystem
and not the store (e.g. /dev/hd0s1).
?? When GNU/Hurd crashes, GNU Mach automatically reboots. Is
there anyway I can make it pause so I can write down the error?
{MB} Pass the `-H' option to init (add it to the boot command line), and
`init' will tell Mach to enter the kernel debugger instead to rebooting
it. At the debugger prompt (`db>'), you can type `reboot' any time to
reboot the system.
? Porting
?? Is porting easy?
{NHW} Porting applications to GNU/Hurd is relatively easy assuming the
application is POSIX compliant as GNU/Hurd does its best to be a
conforming operating system.
The most common error made by programmers is assuming the MAXPATHLEN and
PATH_MAX are defined. On most operating systems this is set to a few
thousand, however, on GNU/Hurd, there is no maximum and thus, this is
not set. The correct thing to do is to submit a patch to the upstream
author that allocates memory dynamically.
? Compiling
?? Where can I get the source?
{AMS} Instructions on how to download the CVS tree from Savanah are
available at https://savannah.gnu.org/cvs/?group=hurd
{NHW} To get the source to the latest debian package, look on any
debian mirror.
?? Can I cross compile?
{ST} To REDO.
{NHW} Yes. If you are running Debian GNU/Linux on IA32, this is quite
easy as there is a cheap cross compiler available; all that is required
is installing the gcc-i386-gnu and mig-i386-gnu Debian packages. When
running configure, you will have to specify tools directly:
# MIG=/usr/bin/i386-gnu-mig CC=/usr/bin/i386-gnu-gcc \
../src/hurd/configure ...
If you are running another distribution, you will have to do this the
long way. You can find instructions at the Cross Compiling HOW-TO
available at:
http://hurddocs.sourceforge.net/howto/cross.html
Farid Hajji <farid.hajji@ob.kamp.net> also talks about his experiences
at:
http://lists.debian.org/debian-hurd-0012/msg00062.html
?? Any general tips?
{NHW} Yeah, building in the source tree is untested. Try:
# ../src/hurd/configure ...
? Development
?? What is OSKit-Mach?
{NHW,FH} There have once been two versions of GNU Mach developed: GNU Mach
1.x and GNU Mach 2.x, formerly known as OSKit-Mach. The former uses
the drivers from Linux 2.0.x while the latter uses the University of
Utah's OSKit library for drivers. You can find out more about the
OSKit library at:
http://www.cs.utah.edu/flux/oskit
The project didn't work out too well, so development has again been halted.
?? Where is the documentation?
{NHW} There were several books written on the Mach kernel. The
information that they contain is still mostly pertinent and should be
considered required reading for potential hackers. They can be found
at:
http://www.cs.cmu.edu/afs/cs/project/mach/public/www/doc/publications.html
The documentation for the Hurd is quite inadequate. The starting of a
book, ``The GNU Hurd'' is in the doc directory in the Hurd source. You
can read this using:
# info hurd
The authoritative place is, of course, the source code; that does not,
however, mean that we would not welcome more documentation. To get
started, take a look at <hurd>/doc/navigating.
?? How do I make sure that my code is POSIX compliant?
{NHW} Unfortunately, you have to buy the POSIX standard from IEEE. The
Single Unix Specification version 2, a superset of POSIX, is available
for free on the Internet. Try:
http://www.unix-systems.org/online.html
?? Who do I submit patches to?
{NHW} If they are against the Hurd, Mach or MiG, send a patch to the
bug-hurd mailing list.
If they are against other packages, the Debian BTS is a good place. In
this case, be sure to advise the debian-hurd mailing list of the bug.
?? In what format should patches for the Hurd and GNU Mach be?
{MB} All patches should be sent in unified context diff format (option
`-u' to GNU diff). It is helpful for us if you also use the `-p'
option which includes information about the function changed by a
patch. Changes that are similar can be grouped together in one file,
but unrelated changes should be sent in seperate files. The patches
can be included in the message or as a MIME attachement. They should
not be compressed and/or archived unless they are very large, and if
they are very large it is probably better to store them on-line at
some place and only sent an URL.
Write a ChangeLog entry for each change, following the format of the
existing files. Here is an example:
2000-12-02 Marcus Brinkmann <marcus@gnu.org>
* ops.c (op_readlink): Before returning, check if the buffer
pointed to by transp is ours. If not, munmap it.
(op_read): Likewise for bp.
(op_readdir): Don't alloca a buffer here. Instead initialize
BUF and BUFSIZE to 0 and let the server (eh, MiG) do it.
munmap BUF before returning.
The file name and the name of the function changed should always be
spelled out completely, and not abbreviated or otherwise mangled (like
foo.{c,h}), because that would make searching for all changes to a
file or function impossible. Local variable names are all
capitalized. There are two spaces between sentences. You can use
``C-x 4 a'' in Emacs to add a new ChangeLog entry. If you do that
with the mark being in a function, Emacs will automatically fill in
the file and function name for you.
Do not send in a patch for the ChangeLog file. Rather include the
ChangeLog entries in the message that contains the patch. Patches for
ChangeLog files often conflict.
If you have the original source tree in the directory `hurd-orig', and
the modified source tree in the directory `hurd', the following
command will produce a good patch (please make sure there are no extra
files like backups in the modified tree, or leave away the option
`-N'). You will need to collect the ChangeLog entries seperately.
# diff -x ChangeLog -Nurp hurd-orig hurd
Answers were given by (in chronological order):
* {NHW} Neal H Walfield <neal@cs.uml.edu>
* {MB} Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
* {AMS} Alfred M. Szmidt <ams@gnu.org>
* {OK} Ognyan Kulev <ogi@fmi.uni-sofia.bg>
* {FH} Frédéric Henry <neryel@reveries.info>
* {MM} Manuel Menal <mmenal@hurdfr.org>
* {ST} Samuel Thibault <samuel.thibault@gnu.org>
The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13
Contributions by:
Michael I. Bushnell <mib@gnu.org>
Len Tower <tower@gnu.org>
Trent Fisher <trent@gnurd.uu.pdx.edu>
jlr@usoft.spb.su
Remy Card <Remy.Card@masi.ibp.fr>
Louis-Dominique Dubeau <hallu@info.polymtl.ca>
Original Document by: Derek Upham <upham@cs.ubc.ca>
Mach is a micro-kernel, written at Carnegie Mellon
University. A more descriptive term might be a greatest-common-factor
kernel, since it provides facilities common to all ``real'' operating
systems, such as memory management, inter-process communication,
processes, and a bunch of other stuff. Unfortunately, the system
calls used to access these facilities are only vaguely related to the
familiar and cherished Unix system calls. There are no "fork",
"wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All
this makes it rather difficult to, say, port GNU Emacs to a Mach box.
The trick is, of course, to write an emulation library. Unix programs
can then use (what they think are) POSIX system calls and facilities
while they are really using Mach system calls and facilities.
The simplest way of going about this is to take an ordinary Unix
kernel, open it up, and rip out all the machine-specific guts; any
time the Unix kernel talks to the machine, replace the code with calls
to the Mach micro-kernel. Run this fake kernel on a Mach machine and
you end up with something that looks and acts just like Unix (even to
GNU Emacs). Note that the Unix kernel we have implemented is just one
Really Big Mach program (called a single-server).
The Hurd, on the other hand, 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.
Of course, if a user wishes to run his own daemons, he can do that as
well....
Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at
the University of Utah. They are working on another free operating
system, and part of it includes an enhanced, more flexible version of
Mach. The Hurd has moved to Mach 4.0, which is good, because it is a
lot easier to build than 3.0 was.
You can find more information on Mach by browsing the Hurd pages given
in the next answer, or by looking at the Project Mach and Flux
homepages at:
Carnegie Mellon University (for Mach versions before 4.0):
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
the University of Utah (for Mach 4.0):
http://www.cs.utah.edu/projects/flux/mach4/html/
==============================
Footnotes:
?1 Yes, I know that ``micro-kernel'' is about as apt a description
as ``Reduced Instruction Set Chip'', but we're stuck with it.