Herbert Graf wrote:
> On Wed, 2005-10-19 at 15:19 -0700, Harold Hallikainen wrote:
>>I'm still trying to figure out the meaning of all the directories in
>>linux. bin makes sense for binaries... What's /usr mean? and /usr/local?
>>I'm thinking sbin is binaries for the superuser or root, right? Of course,
>>all the configs end up in /etc instead of in the directory where the
>>application is... And they log stuff to /var/log . So... stuff's scattered
>>somewhat. But what's the difference between /usr/local and /usr?

   There used to be a really good rundown of this in one of the Linux 
HOWTOs.  I looked around a bit, but couldn't find it.

   Part of the problem is that different distros have different 
interpretations of what goes where.  This is in addition to the 
(usually) minor differences between different incarnations of *nix and 
what the interpretations of those variants are.

   Keep in mind that I'm not claiming to be an expert at administration 
on _any_ OS and this is from memory so take this with an appropriately 
large grain of salt.

   /sbin - historically, this would contain statically linked versions 
of  tools necessary for administration.  This would be handy when, say, 
the system libraries are mounted over the network or are sitting on a 
partition with disk errors/etc.  Clearly, these need to be on local 
storage to be useful.  Lately, this seems to be turning into a catch-all 
for useful system administration utils.

   /bin - binaries that are part of the os distribution.  Historically, 
this would be the minimum set of system binaries that would get a 
machine up and talking on the network.  Probably some of the same utils 
as in /sbin, but not statically linked.

   /usr - static contents that could be shared across the environment. 
   Probably network mounted, should be usable mounted read-only. 
Probably changes very little unless there is an os upgrade or something 
along those lines.

   /usr/local -  locally maintained contents.  Could be per-machine or 
per-environment.  Sometimes both.  Generally used for things that didn't 
come with the os distribution or things that do come with the 
distribution but have been customized to fit the needs of the environment.

   /etc - configuration.  Unfortunately, this tends to be a mixture of 
site-wide _and_ machine specific data.  In an ideal world, this would be 
better separated.  Truly distributed enviroments employ various 
techniques (of varying levels of hackishness) in order to hide this 
somewhat.

   /var - dynamic content.  Logs/etc.  Things that change often, can 
grow quickly, and are otherwise going to be the bane of whoever gets 
stuck maintaining this mess.

   /opt - vendor provided content.  Sometimes optional packages provided 
by the os vendor that are unsupported, sometimes commercial apps, very 
similar in usage to /usr/local.

   /tmp - don't put anything here you want to keep.  World writable 
scratch space.  May be memory mapped or even in ramdisk for speed.

   /home - boring user data.  Keep it small and delete it often ;)  May 
be a slightly better place to store user data than /tmp but it's a 
toss-up.  Historically, this would be a network resource and each user's 
tiny portion of the hierarchy follows them around to any machine they 
log in to.  Most applications will store user-level config here (within 
the user's defined "home" directory) so that it will also follow them 
wherever they may go.

   None of these are hard and fast rules and every os, every 
distribution and every organization is going to have their own take on 
what goes where in the hierarchy.  Similar, not identical.

   Clearly, a lot of this doesn't make as much sense outside of a 
distributed environment.  PCs supporting and being maintained by a 
single user weren't exactly taken into account.

   I wouldn't suggest entirely ignoring the lessons learned though. 
Loosely following the structure laid out above when setting up a system 
makes it a lot easier to back up the important stuff, upgrade the os, 
lock things down,  migrate to a new machine (and keep all of your 
settings), etc.

> Well scattering isn't necessary bad, if all programs scatter what needs
> to be scattered the exact same way. /etc is an example of this. All
> programs should put their config files in this directory (or
> subdirectory), and most good programs do. In a way the windows registry
> is exactly the same concept: all programs put their config stuff in the
> same place. There is an argument there that programs should keep their
> configs in their own directories, I personally find a centralized
> "config" directory a MUCH better idea.

   That depends on what you're trying to accomplish.  Storing in the 
application directory can make installation and maintenance as simple as 
moving a directory in place and adding the executables directory to the 
system path.  It also makes it possible for ordinary users to install 
and use the software without system permissions (provided the software 
doesn't itself require additional permissions).

   You can even have the best of both worlds by linking the config files 
(or config dir) into the /etc mount point.  Or even the executables to 
/bin /usr/local/bin or wherever makes sense.

   Obviously there are trade offs to any approach, but IMHO making 
software installation unnecessarily opaque to the user and/or 
administrator causes as many problems as it solves.

Tad Anhalt
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist