Hi, On Tue, Jun 08, 2010 at 11:05:41PM +0100, Iain R. Learmonth wrote: > On Tue, 2010-06-08 at 23:52 +0200, Emilio Pozuelo Monfort wrote: > > On 08/06/10 23:41, Iain R. Learmonth wrote: > > > On Tue, 2010-06-08 at 23:37 +0200, Emilio Pozuelo Monfort wrote:
> > >> Not really. The point is that there's no such limits on Hurd > > >> (e.g. max hostname length, max pathname length...). > > > > > > The limits may not physically exist, but for applications looking > > > for them, wouldn't it be good to have that compatibility built in? > > > > No, it's better to fix the applications since they are not > > guaranteed to exist (POSIX doesn't mandate them). Furthermore, what > > would you put in them? :-) > > > > I was thinking along the lines of FreeBSD's Linux compatibility, > allowing applications to run with little modification. That's an entirely different matter: FreeBSD's Linux compatibility layer is about *binary* compatibility, i.e. running programs that are already compiled -- it exists mostly for the sake of proprietary applications, which can't be properly ported. Apart from some replacement libraries, there is no attempt to make FreeBSD compatible with GNU/Linux at source code level AFAIK. Originally the Hurd was meant to be binary compatible with BSD BTW; but this is no longer relevant... > I understand that to hang on to things that aren't in the > specification, or are deprecated, is not really a good thing, but if > adding a library of headers that defines these limits is easier than > modifying a load of applications that depend on them, this could be a > good idea. This has been discussed before. It certainly would be the pragmatic approach -- but then, the pragmatic choice is sticking with Linux... The Hurd is all about doing things more properly. -antrik- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
