Re: Linux/Hurd compatibility
On Sun, May 09, 1999 at 02:07:32PM +0100, firstname.lastname@example.org wrote:
> Source-compatibility depends on the source being written carefully.
> (People might just stick bits of assembly language in the source.)
This is bad practice anyway, as it breaks inter-architecture compatibility
even within Linux systems. I know of only two packages (mpg123 and cpm)
under Linux which do this; mpg123 does it for performance reasons and
includes equivalent C source for other systems, and cpm does it because it's
very old and used the only free Z80 emulation core at the time (which
happened to be in i386 assembler).
> 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).
I would tend to call non-portability a bug. I would rather see applications
modified for generality (using autoconf, for instance) than see Hurd's
design altered to fit the applications.
> 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?
/dev access springs to mind. Perhaps we could have a linux-dev server that
faked the popular Linux devices?
However, that's not really an issue. I would guess that performance would be
better for natively-built Hurd apps than for Linux apps runnning under a
compatibility system. The only apps that you'd want to do this for would be
binary-only --- commercial --- apps. And I doubt, at least for now, that
many people would want to use commercial software under GNU/Hurd.
> 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.
I must admit that I do like that idea; I just think it would be too hard to
do without causing performance problems. As I understand it, Hurd and Linux
are different enough that this could cause problems --- and who'd want to
run everything under emulation? Plus, you'd have some packages that would be
Hurd-specific, taking advantage of Hurd features, and those wouldn't run
However, the "Which kernel would you like to use?" install question does
seem terribly attractive. You could even install both, so you can pick from
your GRUB prompt...