On 4/18/06, Charles Forsyth <[EMAIL PROTECTED]> wrote: > >> > >> Don't shared libraries also typically provide memory savings? One > >> version of your c library "resident" for all VM spaces to map? > >> > > that's often quoted as a consequence, but in practice, > not that i've seen in ... what is it now? ... at least six or > seven different systems. i think the trouble is that to get savings > that make the pain worthwhile you still need various forms of > discipline, but with shared libraries, people are even less concerned. > and RSS continues up.
That's interesting to know. I've heard a lot of the theory but have experienced far too little of the reality of these systems (at least in ways in which it seems to affect me). So the reality of actually seen improvements from shared libs is really. a) Not having to rebuild everything that's dynamically linked. b) space savings of binary files. b - is not such a big deal. Hard disks are huge (I remember my 60MB Hard disk on my old 286... I was soo impressed, it seemed like infinity, I was 10 years old.) That plus it sounds like in cases where it really matters, we have good alternatives to deal with this. a - this becomes more of a time saver and supposedly simplifies knowing what things need to be rebuilt. Vulnerabilities in a shared lib are "automatically" fixed. However, for the same reasons a is good, it's also bad. Lots of binaries might look for libqt.so and expect qt-1.x. Your friendly sysadmin may have installed libqt.so but it symlinks to libqt-4.x. Apple tried to solve this by introducing "two-level" namespaces. Not only is the library linked but the path to it. Again, the theory sounds good but it's not convincing in practice. The BSDs went with variant symlinks (FreeBSD and Dragonfly will or do both have these) The interesting thing is that Plan 9's great namespace manipulation functionality + the fact that each process can have a private namespace means that Plan 9 probably has the best shot at dealing with "DLL-hell", like when 10 programs need 10 different versions of the same shared library to run respectively. A simple script wrapped around the loading of a program can set up a namespace such that ambiguities don't exist. This is why I think "cheap" and correct private namespaces are interesting to Unix actually. The problem is too much is stored in the filesystem and accessible by users who really don't need to see certain files. A masking bind over /etc/passwd could be disasterous on Unix and I don't think anyone has really solved this problem yet on Linux where it seems the only way to make private namespaces "safe" is to allow only the root user to create a new namespace and binding mounts. On the surface it appears easier for Plan 9 to adopt shared libs than it would be for Unix to do namespaces properly :). That's really the only reason I'm interested in shared libs really. (especially since the claim of memory savings appears to be false). Dave > > another is bug fixing at a stroke, but it also allows > bug and trapdoor introduction at a stroke. > >
