From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4b52ff4754285fc80e44bd031b2527b0@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Install from CD fails
Date: Tue, 18 Apr 2006 22:14:19 +0200
From: lucio@proxima.alt.za
In-Reply-To: <3e1162e60604181222j5901d428udd71067d75336001@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 3d066730-ead1-11e9-9d60-3106f5b1d025

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

Not quite.  It compounds DLL hell, instead.  Consider the flaming
hoops NetBSD needs to go through to retain backwards compatibility of
all symbols that have existed since DLLs were introduced.  To the
extent that "libc" cannot have its major version number bumped.  Which
means that there is a single "libc" DLL with everything since the ark
in it.

Now add the ability for the _user_ to construct the namespace.  No,
thank you, I think there must be less painful ways to die.

What Russ may have overlooked, for the particular problem involved
here (too large for a floppy) is stripping the binaries.  Or he may
already have thought of it.  I am surprised, however, that ?l binds
the full library rather than only the essential components.  Even
early MSDOS compiler/linker combinations knew how to do this.  But I
may have misunderstood.

++L