[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.)
Oystein
--
This message was brought to you by the letter ß and the number e.
- Re: memory_object_lock_request and memory_object_data_return fnord, (continued)
- Re: memory_object_lock_request and memory_object_data_return fnord, Neal H Walfield, 2002/03/25
- Re: memory_object_lock_request and memory_object_data_return fnord, Roland McGrath, 2002/03/25
- GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Jeroen Dekkers, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Wolfgang Jährling, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Jeff Bailey, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Marcus Brinkmann, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Oystein Viggen, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Jeroen Dekkers, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Farid Hajji, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Jeroen Dekkers, 2002/03/25
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord),
Oystein Viggen <=
- Re: GNU/Linux binary compatibility (Was: Re: memory_object_lock_request and memory_object_data_return fnord), Jeroen Dekkers, 2002/03/26
- Re: memory_object_lock_request and memory_object_data_return fnord, Roland McGrath, 2002/03/25
- Re: memory_object_lock_request and memory_object_data_return fnord, Neal H Walfield, 2002/03/27
- Re: memory_object_lock_request and memory_object_data_return fnord, Thomas Bushnell, BSG, 2002/03/27
- Re: memory_object_lock_request and memory_object_data_return fnord, Thomas Bushnell, BSG, 2002/03/14