Re: [9fans] Install from CD fails

["David Leimbach" <leimy2k@gmail.com>]

On 4/18/06, Charles Forsyth <forsyth@terzarima.net> 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.
>
>