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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
