Re: Unfortunate dynamic linking for everything

At 8:07 AM -0500 11/18/03, dyson_at_iquest.net wrote:
>
>	It really doesn't make sense to arbitrarily cut-off a
>	discussion especially when a decision might be incorrect.

All I wanted to cut off was the claim that this decision had
not been discussed publicly before.  It was also annoying that
most the recent complaints (before your message) were issues
that had been explicitly discussed and addressed before the
decision had been reached.  Many people seem to be complaining
on what they think we did, as opposed to what we actually did.

>	If there hadn't been a noticed increase in cost by using
>	all-shared-libs, then the measurements were done
>	incorrectly.  If the decision is made based upon allowing
>	for 1.5X (at least) times increase in fork/exec times, and
>	larger memory usage (due to sparse allocations), ...

I do remember some comments about benchmarks, and it was
true that the all-dynamic bin/sbin does come out slower.  I
don't remember if the benchmarks were ours or from NetBSD's
investigation.  However, I think we measured increase in
overall time for some set of commands, instead of "increase
in the fork() routine".  Thus, the penalty observed was much
less than 50%.  I think it was under 2%, but I don't remember
the exact number.  When we're dealing with a 100% increase
in the cost of compiling something with the newer gcc, the
increase due to this change seemed pretty insignificant...

It is probably true that there are several commands where we
would see a worthwhile performance benefit by static linking,
and which have no need for things like dynamic PAM modules.
But commands which care about userids or group information
would need to stay dynamic (IMO), and I think that means all
shells.

Also, when it comes to security fixes, it would be nice for
binary upgrades if all we had to do was replace one library,
instead of replacing every command which is statically-linked
with the problem routine.

The announcement of this change may have played up disk-savings
more than it should have, because we weren't doing this to save
disk space.  It was just that the disk savings were a very nice
side-effect.  It's pretty rare that we can talk about the system
getting smaller!    :-)

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu