Traditionally, we have two traditions, one based in AT&T and the
other based in BSD. I've long ago forgotten which is which.
The rational for Unix path assignments was quite logical
/usr probably never meant "user" but "unix system resources" or some
such. /usr was the basic Unix with /lib, /bin and /sbin taking more
primitive roles as the bootloader, recovery disk, command monitor or
other low-level sysadmin-eyes-only toolkit.
sbin meant "static binary" not "system binary" and should only include
programs statically linked as insurance against dynamic linker
emergencies.
/usr/bin, /usr/sbin, /usr/share, /usr/lib were for Unix distribution
files, ie, those packages shipped by the O/S vendor. Therefore RH is
historically justified in placing KDE in there because it is included
in their RH disks. When you do your backups, you should not need to
include these directories (because you have them all on CD anyway) and
when you upgrade, only these directories are affected.
FSF (I believe) first started the tradition of offering their GNU
packages based at /opt although this may have been a Sun convention
for any extra packages added by the system administrator for access by
all users. We would use /opt for packages we were unrelated to the
distro, as a means to keep them out of the way of official package
upgrades. /opt is, not surprisingly, "optional" and all items in there
come from other sources. If you call your vendor tech support about
/opt packages, they politely hang up on you. Thus, KDE is perfectly
right to place their RPMs in here because their RPMs come from
KDE.org, not from your O/S vendor.
Not everone knew about /opt, and prior to Richard Stallman, most 3rd
party software (who is the 2nd party?) was placed into /usr/local to
make it easy to commit to tape backup. Thus does Apache today install
itself to /usr/local as does most experimental beta and alpha
software.
/usr/local, back when people were honest, decent folk, traditionally
had open or group-write permissions (or at least /usr/local/share).
If I found some program for my team and we thought others might want
to use it, we would place it into /usr/local, most often without
bothering the system admins. /usr/local meant "caveat emptor: buyer
beware", "ops does not support this" and no guarantees were given or
expected. This was typically unprofessionally installed and
unsanctioned skunkworks software, and thus, even in modern Linux, the
root account, by default, does not include /usr/local for fear of it
containing trojan-horses masking out important commands.
Most often, users had /usr/local/bin and /usr/local/lib ahead of the
system paths so the administrator could create wrappers around apps
that may need more protections before the unwashed masses could use
it. Today this custom persists in the Netscape shell script that
checks for a running process before it launches a new browser window
(although RH puts this script into /usr/bin)
As time went on and backup methods matured, /var was added to move out
all those files considered too volatile to be usefully added to a tar
archive, and /home was added to allow sharing personal files across
many machines so you would log in to your own one set of files regardless
which terminal or server you approached. Similarly, we added /export
for non-sensitive material that could be offered for varying degrees of
NFS access.
Alas, the world is a different place today, our civilization is going
to ruin, the young people have no respect for their elders and they
spend all their days in the pubs (actually, that statement is a quote,
inscribed thousands of years ago on the walls of the Great Pyramid of
Giza ;) and all our best intended conventions have been cast aside on
whims of fancy.
--
Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc
Business Telecom Services : Internet Consulting : http://www.teledyn.com
Linux/GNU Education Group: http://www.egroups.com/group/linux-education/
"Computers are useless. They can only give you answers."(Pablo Picasso)
