I would be interested in a summary of Linux/Hurd compatibility issues. Could someone be so kind as to rewrite the following so as to reflect the current state of this universe, as opposed to my guesses?
There are three main levels of compatibility: (1) Source-compatibility, meaning you can use the same source code. Source-compatibility depends on the source being written carefully. (People might just stick bits of assembly language in the source.) The Hurd is supposed to be source-compatibible with Linux. If a source package can not be built on the Hurd it's because of a bug in the Hurd or a bug in the source (if we call non-portability a bug). (2) Binary-compatibility, meaning you can use the same binaries, provided the binaries don't use system calls directly. Since Debian GNU/Linux and Debian GNU/Hurd use the same libraries, glibc2, etc, this should in principle be not too hard to achieve. The main problems are ... well, what are they? The first release of Debian GNU/Hurd won't be binary-compatibile, but later releases probably will be. You might be able to have most binary packages shared between Linux and the Hurd (exceptions being, for example, sash and libc6 itself). In that case you could release a single CD image for both, perhaps with the installation tool asking whether you want Linux or the Hurd as your kernel. (3) System-call-compatibility, meaning you can always use the same binaries, even libraries and statically linked ones. To achieve this you would have to intercept system calls and emulate the foreign ones, which is quite a lot of extra work. There's no immediate demand for this, but it could be done if someone really wanted it.
