[PLUG] Regression Testing and library versions

[Tim]

> In such an environment, why the heck do we design the loader
> to require the use the same version of libfoo for every
> application on the system?  Why not keep a disk copy of every
> version of libfoo ever needed by any code ever run on the
> system?  /usr/lib takes up about 2GB on my system - with
> hard drives costing $80 for 2TB, and quintuple redundancy 
> including backups), that 2GB costs me 40 cents.   With a
> more granular way to tie applications to particular versions
> of a library, The system could keep every version of libfoo
> that is needed by any piece of code on the system, no matter
> how ancient it is.  And that might cost only a couple of
> bucks for 10GB of extra library.  


I haven't read the entire (verbose) thread on this topic, but one
thing I'd like to point out if someone else hasn't:

Using multiple versions of the same library across multiple
applications costs you more than disk space.  It also costs you
additional memory (RAM) and therefore program exec start time, due to
greater I/O.

For instance, if we have ProgramA and ProgramB, where ProgramA is
linked against LibFoo 1.0 and ProgramB is linked against LibFoo 1.1,
then when both programs are running, each needs a copy of it's
respective version in memory.  If both were linked against the same
version of the library, then each would share that memory segment via
the operating system's MMU.  That is, ProgramA's virtual address space
has a segment mapped to the physical location of LibFoo, and ProgramB
would also have this mapping.  This saves memory and library loading
time.  

This is one reason why the lack of a coherent package management
system in Windows can lead to a big drop in efficiency (in addition to
"DLL Hell" where packages fight over .dll files in system paths).

Now I know some will say that one library here and there isn't a big
deal to load into memory, but it really can add up over time.  Clearly
though, many libraries do break backward compatibility over time and
it is unavoidable to have several versions of them lying around.  The
middle-of-the-road solution that most distros take is to have 
[libfoo1 version 1.0] and [libfoo2 version 2.0] installed at the same
time with appropriate dependencies created in the package management
system to track what is linked to what.  Over time, legacy apps are
updated and linked to libfoo2 and libfoo1 goes away.  I think this is
just the nature of distributed software development and the rapid
speed that open source software is advancing.  Some programmers are
better at it than others...

tim