> 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 _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
