Re: [9fans] Install from CD fails

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

On 4/18/06, Brantley Coile <brantley@coraid.com> wrote:
> System designers have a responsibility to help the rest of the
> system's community by providing a useable system.  I'll make the
> following observations regarding shared libraries as if you and I were
> debating putting shared libraries into a system.  I have worked both
> sides of this issue, so I have an experienced opinion, not just apriori
> idea of good system hygiene.
>
> First, let me deal with your two `advantages.'
>
> > #1 Maintenance - If you have 50 programs that depend on one library
> > and you have a fix for the library how many things do you want to
> > "remember to build"?  (though people are throwing up straw man
> > arguments for this too.  I suspect the worst case scenario is not
> > always the common case though.)
>
> This has an ugly other side.  If I have 50 programs that depend on one
> library and fix a bug in the library, I now have 50 live programs in
> production that haven't been tested.  I don't know if my change has
> broken something else and won't know until I re-test all 50 programs.
> I now have to do all that testing at once.  With static libraries I
> have the luxury of going thru the 50 programs one at a time and
> relinking them with the new library or reverting to an old library if
> there's a problem.

This is definitely a point of view I've not heard before, regarding
suddenly changed but now untested binaries.  However let me say that I
have experienced this problem before.

Mac OS X Tiger betas shipped with new software that broke old software
that relied on glib, which relied on some old software behavior.  Lots
of stuff just stopped working as a result.

There goes my maintenance claim :)... and it's not just theory, it happend.

> >
> > #2 Supposed physical memory savings - libSystem on Mac OS X only
> > exists in memory 1 time for all the programs that use it... sorta.
> > Read Only pages are shared, writable pages are COW and yes, this adds
> > a good deal of complexity to the VM of the OS to have this.
>
> Before X windows, 10% of programs were from the library.  With X
> windows that number ballooned to 90%, so there is an apparent (see
> below) space savings with X windows.  This is because when to touch
> anything you get everything.  That, I would argue, is bad design.  (I
> added shared library to a custom embedded Unix I did 15 years ago
> because the application was also mis-designed.) The X library is
> really a sub-system that should be somewhere other than the user's
> program.
>
>
> Also on the down side, shared libraries make it hard to distrubute
> binaries without also sending out the library.  The binary, or even
> the files in the same directory, are no longer all that is required to
> run the program.  You also have to have the correct version of the
> library.  Since you get different binaries that need different
> versions of the library, you now wind up with three or six or more
> slight variations of the same library, all get loaded into core.  Now,
> where's my space saving?  Remove one and now you have a bunch of
> programs that don't work, but you don't know it yet.
>
> To load a binary that is linked to a library takes longer to load.
>
>
> I have seen code sharing done right, such as Oberon, but every version
> of shared libraries in Unix I've seen cost more than they were worth.
> Including my own.
>
> Hope the above arguments at least seem rational.  They are off the top
> of my head.  I'm sure others on 9fans have other, better data points
> that do the engineering calculation on the cost/benefits of shared
> libraries.
>
>

Sure these are good arguments.  For the record, I know people outside
the Plan 9 camp who stick to the "shared libraries are bad argument"
and I've always liked to think of myself as pretty open minded to
unpopular ideas.  I know from experience that popular doesn't mean
it's correct.

Dave

>  bc
>
>