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

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: