On Fri, 3 Feb 2012, Jose R. Valverde wrote:
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
etc..." or "Windows Windows32 Windows64 Temp Users and Settings, etc..."
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
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.
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