[Top][All Lists]

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

Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

From: Marcus Brinkmann
Subject: Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)
Date: Tue, 19 Mar 2002 02:07:35 +0100
User-agent: Mutt/1.3.27i

On Tue, Mar 19, 2002 at 12:14:55AM +0100, Jeroen Dekkers wrote:
> On Tue, Mar 19, 2002 at 12:05:02AM +0100, Marcus Brinkmann wrote:
> > On Mon, Mar 18, 2002 at 11:35:36PM +0100, Jeroen Dekkers wrote:
> > > I think the whole /sbin directory is old unix-craft like /usr.
> > 
> > We will not link /sbin to /bin.
> It's nice that you give a good argumentation. I'm really convinced.

The paradigm to apply here is not: "We merge directories whenever we
think the distinction is too small to be worth the separation it creates.",
but the paradigm is "We merge directories whenever the separation is
artificial or based on obsolete technical, rather than semantic reasons."

The distinction between /bin and /usr/bin is based on obsolete technical
reasons, and there is no semantical difference between the two that matters
to the user.  The distinction between /bin and /sbin is supported by some real
semantic difference between the two.  You can argue that the difference is
small.  You can argue that the number of binaries that end up in /sbin are
small.  Both argumentes are correct, but they are not sufficient to support
changing that right now.

At some time we might make more changes than just the current ones.  But our
plate is pretty full with things we need to get designed, implented and
explained to the world that really are supported by strong paradigms, that
we don't want to load ourselve with weaker, less clear cut things that might
or might not be worth to be cleaned up at some time.

The /sbin and /bin argument has come up in the past, on this list or
bug-hurd or debian-hurd, or probably at all of these places, and the reason
to reject it have always been the same.  For some people, we might not be
radical enough.  For many other people we have already jumped over the edge. 
I think we have so far always found a good rationale to go as far as we do,
but not further.  That we have /X11R6 at all is really only because Debian
is not yet ready for it (but I hope it will be), this is more important to
get rid off than sbin (because there is a real technical defect as a
consequence).  Also moving some stuff from sbin to bin would be very
beneficial (like mke2fs and e2fsck, I am always annoyed if I don't have it
in my path, although I frequently create and corrupt file system images in
files as a user).

As long as there are programs that can only be sensefully run by the
sysadmin, there will be /sbin.  So let's fix it so everybody can run those
programs sensefully, then we can get rid off /sbin as a side effect ;)


`Rhubarb is no Egyptian god.' Debian
Marcus Brinkmann              GNU

reply via email to

[Prev in Thread] Current Thread [Next in Thread]