Re: Intent To Split: netbase
Manoj Srivastava <firstname.lastname@example.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.