[sf-lug] the latest on the servepath colo story

[jim stockford]

For those with similarly vague understanding as I,
per Rick's previous email re partitioning...

<la la la...>
> More of this is covered in:
> http://www.pathname.com/fhs/   <---------------------------------!
> http://twiki.iwethey.org/Main/NixPartitioning
>
> Both are well worth reading.

Yes, both are well, well worth reading. For example,
I was unclear about /usr/share; i am now more clear....
/usr/share : Architecture-independent data
Purpose
The /usr/share hierarchy is for all read-only architecture independent 
data files.  [30]

This hierarchy is intended to be shareable among all architecture 
platforms of a given OS; thus, for example, a site with i386, Alpha, 
and PPC platforms might maintain a single /usr/share directory that is 
centrally-mounted. Note, however, that /usr/share is generally not 
intended to be shared by different OSes or by different releases of the 
same OS.

Any program or package which contains or requires data that doesn't 
need to be modified should store that data in /usr/share (or 
/usr/local/share, if installed locally). It is recommended that a 
subdirectory be used in /usr/share for this purpose.

Game data stored in /usr/share/games must be purely static data. Any 
modifiable files, such as score files, game play logs, and so forth, 
should be placed in /var/games.

<me, again> ..."architecture" means "THE CPU", as in 64 bit PPC or S390
or Intel or AMD, or 32 bit Intel or AMD (or 31 bit S390), mentioned 
elsewhere.

the directories scattered about with the name "lib" have to do with
binary libraries, but the "lib" director(y, ies) under /var, as an 
example,
store tracking or variable data pertaining to the binary libraries that
themselves are stored in /lib or in /usr/lib (or /usr/local/lib or...); 
the
games directories scattered about relate to games, but those under
/usr/share/ are different from those under /var/ or those elsewhere,
the upper–level directories indicate the nature of the files, the lower-
level directories the purpose. well, i'm venturing further afield, in
hopes someone will correct me.

"31 bit S390"?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3752 bytes
Desc: not available
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20061018/cedc08d7/attachment.bin>