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

[Jose R. Valverde]

Whoa!

	I wasn't expecting this flood of comments! :-)

	Anyway, I think that I was clear: the choices about separating files
into directories, partitions, disks, network shares, etc... have always been
pretty obvious to anybody with a minimum of common sense. The only way around
them is foolishness or ignorance (or both).

	I can understand a newcomer, using a computer for his/her petty games
one task at a time and not doing much, to believe the world would be simpler
if it (or the filesystem) were flat and suited to his unvoiced personal 
expectations. This is nothing new, the machine language opcode RPM (read  
programmer's mind) is as old a joke as I can remember.

	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

-- 
			EMBnet/CNB
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es
		  http://www.es.embnet.org