Thanks for the update on BSD, Isildur...

> some BI , but not much. no XMI. the CSRG diverged from the VAX for a
...
> vaxen never got support. the main reason, though, is that DEC was
> extremely secretive about BI and XMI stuff specs were not so readily
> available, nor was programming information.

I will never understand how management can be so stupid. Secrecy never
pays off.

> > so neither shm nor mmap, that means no shared memory at all, right?
> > I can't quite agree that that is so good. ...
> 
> it isnt so bad
>  yes a lot of modern stuff wont compile under it
> but capability wise, it is more that stuff liek shm make things easy for
> a certain way of solving problems, which have other kinds of solutions too

O.K. of course, like socket-based IPC. But, isn't the shared memory
model very much in the spirit of the VAX with all it's scatter-garther
communications? So, why do you want to do without it?

[Shared libs ugly or beautiful, easy or painful]:

> i think the acrobatics that must go on behind the scenes to make it
> possible are really ugly, and in order to do shared libs, you must
> destroy a much simpler and more elegant model of an executable. also,
> i have objections to programs whose code isnt there. a binary should
> stand on its own. 

isn't late-binding kind of popular these days (and for good reasons?)
With a shard library, you could in theory improve a buggy module
without having to recompile all the programs that use this module,
ain't it right? This looks like a very useful improvement over the
static binary. 

> when i have a binary that i have no chance of finding source for anymore,
> it is stuck on the machine that it lives on, imprisoned by its shared
> libraries- if it dependson a version of the shared libs that another
> machine doesnt have, then i'm SOL when i want to move that thing to
> another system. sure, if i have the permissions i can copy the shared
> libs over too... one should expect to have root on every system one uses.

wait, wait, :-) if you have a program that you don't have sources
for and you want to use it with a module that has reduced bugs, you
can do that with shared libraries better than with static code, 
can't you? To find out what the dependencies are, just do

ldd /usr/local/bin/mygizmowosource

and it will tell you exactly what shared libs and versions it is 
currently depending on. Now you can go move the program to its 
new home. Do an ldd there and chances are it'll pick up a couple
of basics, like libc.so, libm.so, and other things. Only the ones
that are missing, you need to copy from the other system. You should
not need supervisor rights either to run those. I believe the 
dynamic linker uses an environment variable, like LDPATH or 
something like that to find shared libraries. You should be able
to put /home/isildur/lib into that path and go just fine.

Also, there should IMHO be no reason why it shouldn't theoretically
be possible to incrementally convert a dynamic linked object into
a static object. I would be surprized if the GNU binutils would not
allow you to build something like that (if they don't have that
already.) (BTW: with the GNU binutils you may even be able to
convert executables and shared objects between different OSses
on the same type of machine, like FreeBSD and NetBSD, and Linux
and SCO on the i386.)

> what then of the forest of multiple versions of shared libs one
> accumulates over time?

ldd is your friend and will tell you exactly what version to use.
You can write a shell script in no time that scans through all
dynamically linked executables and finds those shared library 
versions that are no longer used and deletes those (shlib grabage
collector.) ... I guess I need to do this after 3 years.

> i dont think the savings in disk space is really
> all that great (aside from having _lots_ of X stuff) when you start having
> four and five different versions of libc because different things demand
> different versions. i think that's pathetic.

The X stuff is reason enough. I remember back around 1992 when I just
got X11R5 (before the name XFree86 was chosen) and I had a hard 
time to fit all of this on my 340 MB disk that cost me 600 bucks
at that time. Some guy had written a very non-robust shared libraries
implementation for 386BSD back than and I was so devastated about the 
X-bloat that I did use that. It helped. Although it was a pain without 
any kind of version management or other kind of safety.

> plus, if i'm just joe Q user, and the sysadmin 'upgrades' the shared
> libs, and my binaries break, theres nothing i can do. 

You superuser needs to leave old shared libraries where they are,
that's simple. But nothing helps against bad superusers :-)

> When some of its code can change at the
> whim of someone else, without any notice or knowledge of it til things
> start behaving differently, that is really wrong.

hmm, we don't have to agree on everything and still be friends,
I guess :-). I think late binding is a good idea, and just another
step towards modularization and reuseable software components. If
the interface is well specified (design by contract) -- and Unix
is a pretty good example for that -- it is quite safe to do that.

Thanks for the little discussion,
-Gunther

-- 
Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistent Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org