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

Re: Intent To Split: netbase

Manoj Srivastava <srivasta@debian.org> writes:

>  Manoj>  The /bin vs /sbin distinction is purely about avoiding
>  Manoj>  inconvenience and/or confusion for the normal user.  The sole

Actually, this is incorrect.  On platforms predating FHS/FSSTND, /sbin
was for statically-linked binaries -- versions of vital system tools
(fsck, sh, etc) linked statically for repair in an emergency.  You may
recall I have advocated having a few statically-linked binaries in
Debian packages in the past.

>  Manoj>  thing accomplished by putting some things in /sbin rather
>  Manoj>  than /bin is that if you don't put /sbin in your path, you
>  Manoj>  won't see those things.  I myself, probably like most people
>  Manoj>  on this list, rarely notice the distinction since I do have
>  Manoj>  /sbin and /usr/sbin in my path.  But the idea is that the
>  Manoj>  average user won't have /sbin or /usr/sbin in their path, and
>  Manoj>  so the programs in those directories can have simple names
>  Manoj>  for the convenience of those who do use them, without an
>  Manoj>  average user either accidentally running one because it has a

I don't see very many (any?) commands in /sbin that could cause harm
to the system, much less the user, if run accidentally by an average
non-root user.  I think the value is of organizing binaries -- this is
why we have a hierarchial filesystem, after all.

> 	You have also, perhaps correctly, classified me as an old
>  fashioned curmudeon who is wildly conservative. Perhaps. I do tend to
>  resist change merely for the sake of change, or for benefits that I
>  believe are unpalpable compared to compatibility and tradition lost. 

I might say that on occasion you tend to resist change merely for the
sake of resisting :-)

Anyway, I think the current situation is largely fine, although I am
still dismayed by the lack of statically-linked binaries in /sbin.

Reply to: