Re: [9fans] Install from CD fails

[Roman Shaposhnick <rvs@sun.com>]

On Tue, Apr 18, 2006 at 02:54:40PM -0700, David Leimbach wrote:
> On 4/18/06, Roman Shaposhnick <rvs@sun.com> wrote:
> > On Tue, Apr 18, 2006 at 12:22:30PM -0700, David Leimbach wrote:
> > > On 4/18/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > > 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.
> >
> >   And you would have to go through all of the aforementioned troubles
> >   to achieve exactly what ? What is it, that shared libraries are good
> >   at ?
>
> #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.)

  Perhaps. However, now that I've suffered my own share of .so madness by
  the virtue of working on Sun's C++ compiler, I really don't
  think that maintenance argument is a valid one. As always, it
  sounds good in theory, but as I've mentioned in my previous post
  an absolute lack of a decent management scheme kills it. The fix
  that benefits some application usually breaks others. What's even
  scarier is -- once broken they have to resort to LD_LIBRARY_PATH
  or some such to work around the issue. Not good.

  In a C++ case its even worse, because C++ runtime shared library is
  the worst of them all -- shared library other shared libraries
  might depend upon. It is really difficult to manage even the
  most trivial of cases: when a particular vendor distributes a
  C++ library as a shared object compiled with an older compiler
  and thus having a dependency on a previous generation of a C++
  runtime shared library and later on the customer uses the latest
  version of a compiler only to discover the joys of mixing two
  version of a C++ runtime in one application.

> #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.

  This one I might even agree with. However, there are much better
  ways of saving memory: kernel + file servers clients interact with
  would be the one.

> I'm actually more concerned with #1 overall.

  And that's the problem. Once you start layering dependencies on
  top of each other -- you end up in a mess.

  I think the key issue here is that while it is safe to assume
  that you can control bits and pieces your application is built
  from during the build process itself, it is absolutely naive
  to assume that you have any guarantees of the same kind at a runtime
  if all that you give to a dynamic linker is just a name of an external
  entity (like a function call or a static variable). It sort of reminds
  me of the life in a flat file namespace, if you know what I mean.
  Painful and very difficult to manage right.

Thanks,
Roman.