Linux/Hurd compatibility
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.
Reply to: