Arbitrary Limits (was: Help in testing a patch for efax-gtk FTBFS on hurd)

[<olafBuddenhagen@gmx.net>]

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-