[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request

From: Oystein Viggen
Subject: Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord)
Date: Tue, 26 Mar 2002 09:58:17 +0100
User-agent: Gnus/5.090005 (Oort Gnus v0.05) XEmacs/21.1 (Capitol Reef, i386-debian-linux)

* [Jeroen Dekkers] 

> On Mon, Mar 25, 2002 at 09:59:14PM +0100, Farid Hajji wrote:
>> All in all, binary compatibility is a nice thing to have.
> If it's only used for running non-free software I disagree.

I can see no other reason.  As you said, if it's free, we just recompile
it.  Then we can remove PATH_MAX and MAXHOSTNAMELEN dependencies, too.

> The only
> really reason I see is that you can have the same Debian packages for
> GNU/Hurd and GNU/Linux, which would same some few GBs in the
> archive. For this the ABI has to be completely the same which still
> has some issues.

For complete binary compatibility, I should think you also need complete
feature compatibility.  This means either enhancing Linux to support
things like translators, dumbing down the Hurd, or providing fake stubs
in the Linux libc.  None of these are very likely.

(ex: rm for Hurd should check if a directory is a translator when
running in -r mode.  (at least I think so.  does it currently do that?)
In Linux it doesn't need to do this, as mount points are trusted.)

This message was brought to you by the letter ß and the number e.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]