Re: Understanding /root, /usr, /var and so on
On Sun, Mar 26, 2006 at 02:32:51PM -0500, Kevin Mark wrote:
> On Sun, Mar 26, 2006 at 03:22:06AM -0500, Andrew Cady wrote:
>
> > The only reasons for having a separate /sbin are historical, and even
> > then they are unclear. They certainly have nothing to do with security,
> > which is provided by other means. Perhaps originally /bin represented
> > a stable interface for users while /sbin was allowed to be changed by
> > adminstrators? *shrug*
>
> Hi Andrew,
> my cobwebbed brain always associates 'sbin' with 2 things: statically
> linked binaries and sysadmin binaries (which maybe statically linked
> to allow them to be used when you are in runlevel 'S' and only have
> /root and /)
> And 'bin' to be user binaries.
Well, /bin and /lib are always available in the root filesystem, and
/bin is at least as necessary for boot as /sbin. While static linking
may be an advantage sometimes, it is pointless for /sbin unless /bin
is also statically linked; and of course there is /usr/sbin still to
explain.
I am really getting curious about this now.
btw, hier(7) says:
/sbin:
Like /bin, this directory holds commands needed to boot the system,
but which are usually not executed by normal users.
/usr/sbin:
This directory contains program binaries for system administration
which are not essential for the boot process, for mounting /usr, or
for system repair.
But this still does not really justify the special directory; why bother
to segregate commands not usually used by normal users at all?
A little research reveals that the original AT&T Unix contained no
/sbin; however, the traditional contents of /sbin were present in /etc,
mixed with configuration files. 4.3BSD placed these files in /etc also,
but 4.4BSD moved them to /sbin, reserving /etc for configuration files
only.
Apparently the BSD folks decided in retrospect that mixing binaries with
configuration was a bad idea. But why not put them in /bin? It may
well have been performance reasons; that also seems to have been the
original reason for placing binaries in /usr/bin. At least, AT&T unix
shipped everything in /bin, but recommended the administrator place most
of those commands in /usr/bin for faster performance on lookups in /bin.
Reply to:
- References:
- Re: Understanding /root, /usr, /var and so on
- From: Gene Heskett <gene.heskett@verizon.net>
- Re: Understanding /root, /usr, /var and so on
- From: "Matthew R. Dempsky" <mrd@alkemio.org>
- Re: Understanding /root, /usr, /var and so on
- From: Gene Heskett <gene.heskett@verizon.net>
- Re: Understanding /root, /usr, /var and so on
- From: Andrew Cady <d@jerkface.net>
- Re: Understanding /root, /usr, /var and so on
- From: Kevin Mark <kmark+debian-user@pipeline.com>