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

[Jeroen Dekkers]

On Tue, Mar 19, 2002 at 02:07:35AM +0100, Marcus Brinkmann wrote:
> 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.

In the Hurd things have changed. Filesystem tools should go into
/bin. All daemons should go into /bin. Networking tools should also go
into /bin. And so on, in the end when we have shadowfs and all users
can have their own / filesystem, users might even be able to install
Debian packages. I don't think much is left in /sbin.

Now we can do 2 things. We can annoy all maintainers that they should
move the binaries in /bin for GNU/Hurd. Then they need to change
everything using the absolute path. We will probably have about 20
binaries left in /sbin or so.

We can also move everything into /bin at once and provide a backwards
compatible symlink. That would be the easiest solution. It's also
looks the most logical solutions to me. I don't really see a very big
difference between those programs left in /sbin and those in /bin.

Sure there is a small difference, but for me it just looks as small as
the /bin and /usr/bin difference. /bin is used for booting, mounting
the /usr partition and rescuing the system and /usr/bin is used for
all other things. /sbin is used to store programs needed for system
administration, /bin all others.

But do we need to have different directories for programs with a
different use? A 'normal' user won't do any development, why would he
be interested in the development tools? Also there can be multiple
sysadmins with all their own account to do system administation.

This would be useful in the Hurd. A sysadmin would run addauth, run
the command and then lower the permission again. I think having a
/sbin is really made obsolote: most programs can be sensefully run by
normal people. I don't see a reason to have a distinction between
/sbin and /bin other than they did it in the past.

> 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.

I think this change is perfectly justifiable.
 
> 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).  

But getting rid of /sbin shouldn't be that hard I think.

> 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).

You would still do that, you would automatically type /sbin for the
program name.
 
> 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 ;)

We already have a lot of programs that should go into /bin. The
programs left probably won't be able to run sensefully for others
(like grub, shutdown, etc).

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: jeroen@openprojects

pgpmuwmzdglIJ.pgp
Description: PGP signature