[TUHS] Understanding the /bin, /sbin, /usr/bin, /usr/sbin Split

[Steve Nickolas]

On Fri, 3 Feb 2012, Jose R. Valverde wrote:

(snipping)

> 	There was a reason to separate user data from system data to avoid
> the system disk from becoming unusable by a misbehaving user. There was one
> to separate /tmp for the same reason (a buggy program might generate a huge
> temporary file and render the system unusable for all other users). Same for
> /var and out of control log files. When vendors started adding their software
> in /usr (and maintaining it) there ceased to be a standard, well known set
> of "reserved system program names" and it made sense to separate /usr/local
> for non-vendor maintained files which might have an unknown naming conflict
> (and I witnessed many at the time, not the less GNU) with "non-standard-UNIX"
> vendor additions. When LANs started to be common it made sense to share as
> many files as possible, and since executables would not be shareable on an
> heterogeneous network (something most newcomers have never experienced -or
> fancied) it became sensible to have /home and /usr/share separate and served
> over the network. When UNIX systems became more complex and started to take
> over mainframes and get many users, it made sense to separate system programs
> from user programs, and it didn't make sense to duplicate all of them: hence
> a /bin for programs common to users and admins, and a /sbin for just admins
> (for standard system commands) and a /usr/bin and /usr/sbin (for vendor
> maintained commands and  system daemons) and a /usr/local/bin and a
> /usr/local/sbin (for locally added commands and system tools and daemons).
> /lib, /lib64, /usr/lib and /usr/lib64? Heck! that's not even enough to
> ensure user programs keep on running after a system upgrade and cleanup.
> I often try to keep relevant packages in their own directory and run an
> automated ldd to save in their own .../lib their shared libraries before
> doing an upgrade. There are binaries that haven't been updated since the
> '90s and require very old libraries (or even worst, complex sources that
> require various versions of the GCC toolchain). It doesn't make sense to
> port them, it's easier to ensure they keep on running keeping their libraries.
> And so on.
>
> 	And many of these arguments might hold today. One might argue that
> since people is now tied to a vendor (Ubuntu, or RedHat, or Oracle, or HP,
> or whomever) one no longer needs separate / and /usr spaces. The problem
> is that would only work for newbies and occasional users, but would fail
> for most other cases (large computing servers and multiuser shops as well
> as tiny embedded devices, as pointed out). So, as long as systems are shipped
> to run on any machine, the layout should be versatile enough to accommodate
> all uses. Hence the need for maintaining these conventions, not legacy or
> bureaucracy. What is shortsighted is to expect all use-cases to be like a
> home user who only runs one game or, at most, his/her word-processor,
> e-mail and navigator simultaneously.
>
> 	Beyond that, the original articles and comments complained also about
> directory naming (/bin /etc /lib) as "unintuitive". I fail to understand in
> what way is it easier for someone new to a computer to learn a "/bin /etc /var
> /lib" alien terminology and what it means, than to learn "System Config Libraries
> etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..." The
> point is one needs to learn them and if you are familiar with one terminology
> then to map terms, and if we are to use a standard, at least POSIX is one.
>
> 	That said, I often place everything (but /boot) in a single partition
> for single-user machines (except for power users who usually demand at least
> separate /tmp and /home) and there is nothing to prevent one from making symlinks
> (er, aliases for Windowers) to system directories with whatever names you like.
> And I still see a need to separate the system from vendor files and from user
> files (like, e.g. when you later want to switch from say RedHat to Debian). Only
> a moron would ignore the risk of system files left around by vendor-specific
> naming conventions.
>
> 	I said originally I could rant on and on. And I can. And add lots of
> anecdotes, but I'll leave it here.
>
> 	Sorry. Couldn't resist.
>
> 				j
>
>

Actually, I tend to think the bare minimum to get the system running goes 
in /bin, /sbin and /lib, the rest of the base in /usr/bin, /usr/lib, 
/usr/include and /usr/sbin ... and all installed apps really ought to be 
in trees off /opt (although that would break stuff that expects X in 
/usr/X11R6/bin if I put it in /opt/X11 instead).  But that's just my own 
opinion.

-uso.