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

Re: HURD/Linux/BSD* ... Loosing focus.



On Mon, May 20, 2002 at 03:09:04PM -0500, Jeff Licquia wrote:
> On Mon, 2002-05-20 at 06:51, Michael Stone wrote:
> > No, please don't, because your examples are misguided. I don't believe
> > that I've heard any serious suggestion that hurd should be forced to
> > have a /proc.
> 
> Wouldn't that be a "gratuitous difference" between Linux and HURD?
> (And BSD?).

No. That's an architectural difference. This is a different issue than
having differing policies for common components. OTOH, if hurd creates a
clone of linux /proc, it should probably go in /proc--putting a resource
with the same characteristics in a different location *would* be a
gratuitous difference. 

> Arguments for /proc are exactly like arguments for /hurd, with one
> difference: Linux has had political pull and historic precedent to get
> its exceptions canonized; HURD, as an unreleased OS, has not.  

That is correct; the bar to adding things to hurd which do not comply
with existing standards *should* be higher--because compatability is not
an issue. That is not to say that no accomodations will be made for
hurd, but it is reasonable to have a high standard for adding new items
when the cost of redefining those items is low. We would likewise expect
that new additions to the linux side of the house would comply with our
existing standards.

In the specific case of /proc, moving it would break compatability with
a large installed base, as well as all other linux distributions, so
there would have to be a very compelling reason to do so. In the
specific case of the bsd loader, moving it would break compatability
with a large installed base of other bsd installations, so there would
have to be a very compelling reason to do so. In the case of /hurd there
is no installed base to worry about, so moving it wouldn't really cost
that much. That is not to say that it *should* be moved, but that it is
*not* unreasonable to ask the question. For that matter, discussions
*have* come up about moving or redefining linux /proc--such discussions
are a normal, healthy part of a free software project.

> So, the proper question is not whether there is a technical reason to
> change the Linux-biased standard. 

Now you're engaging in gratuitous FUD with the very term "linux-biased
standard." You don't even have the curtesy to state what standard is so
allegedly biased. If your allegation of bias is directed toward fhs and
is based on its inclusion of /proc in the linux section of the
operating-system-specific annex, well, I'm not sure I can help you
overcome your own biases. (Hint: the fact that there is a linux-specific
section hardly precludes the inclusion of a hurd-specific section at
such time as one is written and offered for inclusion.)

> Rather, we should ask whether we will allow the HURD to develop
> without artificial non-technical pressures from "legacy" systems, 

No. We will expect hurd to conform to some existing standards. That's
part and parcel with joining an existing organization. Note that hurd
already accepts pressure from "legacy" standards like POSIX. This does
not preclude us from examing our standards to see what compromises or
enhancements may/should be made.

> and perhaps allow our definition of "what is Debian" to be altered to
> accomodate the new ideas it brings.

FUD. FUD. FUD. 

Instead of the hand-wringing, could you provide some concrete examples
of cases where the Debian organization has forced hurd to abandon a
technical enhancement, so we could discuss some factual material?

-- 
Mike Stone

Attachment: pgp4pKIliCqpf.pgp
Description: PGP signature


Reply to: