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

Jose R. Valverde jrvalverde at cnb.csic.es
Wed Feb 1 21:12:14 AEST 2012


On Tue, 31 Jan 2012 13:16:17 -0600
"A. P. Garcia" <a.phillip.garcia at gmail.com> wrote:
> http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split

I think this is typical misunderstanding of modern-day newcomers. The main 
problem to me seems to be that they think of UNIX (and Linux) as a Windows
PC, which it isn't (and they even do not understand the Windows PC itself).

The fact that at some point people was strained by disk space (and it has
nothing to do with Ken or Dennis or disk availability) only means they had 
a pressure to split contents, and unless anyone was a moron, everyone would 
do it in a similar rational way.

A rational way in the times meant adapting for the times' needs, and by
then UNIX was a multi-user OS.

So, beyond the point of filling up a disk (and that's the point for the partition
system) there was a need to ensure you could separate user data from system data:
adding user programs or data to a separate space (disk, partition, whatever)
ensured the system space was not filled and the system would not become unusable.

That was the real reason for /, /usr, /tmp and /var as standard partitions for
most of us, not the availability of new disks. And the same is valid for 
separating system-specific binaries from general users.

When disks came it would be handy to move a partition to a separate disk,
but the need itself has nothing to do with the availability of extra disks.

This is something obvious to anyone maintaining a multi-user server, only
presumptuous single-user windows toyers think they know better. Even now
when I get a user asking to set up a new computing server, their first
query is how to separate system from users and scratch space. Any power
user has filled his own system once and knows the risk. They also know they
can cope with their own system and files. And they all know they cannot in
a shared environment where they cannot control other users' files. Point
is, the very first idea that occurs to any sensible being when facing a
multiuser system is how to separate contents safely.

That Ken and Denis did the obvious thing (as many of us did at the time --I
remember having a /usr/local on my machines years before it was commonplace 
use) only speaks of their common sense (and the ignorance or lack of common 
sense in complainers).

This is still valid in the times of petabyte disk arrays, ACLs, quotas,
queuing systems and all what nots. Even more so in these large installations
(I have witnessed multi-TB scratch files in jobs, filling a supercomputing
installation and requiring operator intervention to avoid stopping the work
of all other users).

And so on, I could rant all day arguing why this was the obvious approach
to many problems then, and often now too.

So, to me, this looks more like a case of "reintrepreting and twisting the
facts to justify untenable beliefs" instead of trying to understand what 
actually happened and why. Like saying the wheel was invented only to make 
carriages and that we keep using carriages (instead of say helicopters) just 
because of tradition and "bureaucrats" instead of accepting that there were 
many needs and when the wheel came it was -and still is- the obvious solution 
to most of those problems (among them carrying loads in carriages).

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

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



More information about the TUHS mailing list