[colug-432] GoboLinux

[William Yang]

On Wed, 2011-01-26 at 07:28 -0500, Steve VanSlyck wrote: 
> This does sound interesting (from 
> http://gobolinux.org/index.php?page=at_a_glance ) :

> What is GoboLinux?
> GoboLinux is a modular Linux distribution: it organizes the programs in 
> your system in a new, logical way. Instead of having parts of a program 
> thrown at /usr/bin, other parts at /etc and yet more parts thrown at 
> /usr/share/something/or/another, each program gets its own directory 
> tree, keeping them all neatly separated and allowing you to see 
> everything that's installed in the system and which files belong to which 
> programs in a simple and obvious way.

We did something like this to stock Sun Solaris machines back when I was
at the Ohio Supercomputer Center (I left 10+ years ago now).  We
installed all compiled software in /opt/[package-name]-[version] then
generated symlinks into standard system locations.  I vaguely remember
the thinking being that we wanted to be able to inventory software and
rapidly yet granularly deploy shared software through NFS.

In my experience, this is a big a waste of energy and attention at small
to medium installations (exceptions noted for systems with rapidly
changing compiled code bases/experimental systems, particularly large
installations, or shared storage installations where you maintain one
copy of software packages for many systems and share it via networked
filesystem).  

The thing is, apt, rpm, sun packaging, portage, pretty much all
packaging systems -- they all do a reasoanble job keeping track of what
package contains what files and provide mechanisms to query the file
listings.  This is just yet another packaging paradigm, which happens to
run contra to how other *IX systems do things.  They say there's no
compatibility issues, but I'm pretty sure they either are just wrong
about that, or they maintain a complicated sym/hard link structure to
provide backward compatibility (which actually does cause a tiny (and
probably unnoticable on modern hardware) performance hit.

I do want to offer an alternative analysis to what Richard Troth* wrote
on another thread this morning, about /var being an undesirable place to
store package installation and configuration data.  My understanding of
the original differentiation between some of these directories and
filesystems does not make that undesirable:  the / filesystem had to
have all and only everthing needed to get the OS started (and /etc is
there) but /usr was usually a seperate FS of normal utilities (thus the
historic difference between /sbin and /bin versus /usr/sbin
and /usr/bin).  Same's true of /lib and /usr/lib, even today.  I
see /var to be "information that varies" (which includes logs and local
system config data that's not required at startup but which is required
for day-to-day operation (like when you maintain packages) -- and that's
stuff that can reasonably be seen to be different from local system
configuration data required at boot time.  Kernels used to sit at / --
it's a relatively recent development that they moved elsewhere!  But
then, I'm pretty old school.

	-Bill

<playfulness>
* @Rich- Invoking my name in a thread has been known to sometimes summon
a response, much in the same way horrific beings were summoned from the
ether merely by the power of an utterance of their name according to
ancient lore and mythology.  Given that HP Lovecraft is a favorite of
mine, I may just sign off as "Hastur" (pronounced "um-ummm" to avoid any
sanity-threatening appearances ;-).
</playfulness>
-- 
William Yang
wyang at gcfn.net