Arbitrary Limits (was: Help in testing a patch for efax-gtk FTBFS on hurd)
- To: email@example.com
- Subject: Arbitrary Limits (was: Help in testing a patch for efax-gtk FTBFS on hurd)
- From: <olafBuddenhagen@gmx.net>
- Date: Mon, 9 Aug 2010 22:55:31 +0200
- Message-id: <20100809205531.GB28906@sky.local>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <email@example.com>
- References: <AANLkTikCRlajNGlZYB_HV1zK-Enpz-ckJYXr_SEc65Ct@mail.gmail.com> <AANLkTikXasNszuIwucqiC9zal1R9oqFWhdWQ_lDcU0JW@mail.gmail.com> <4C0EA102.firstname.lastname@example.org> <email@example.com> <4C0EB82F.firstname.lastname@example.org> <email@example.com> <4C0EBBA1.firstname.lastname@example.org> <email@example.com>
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.