Since I've been saving up this thread for a snowy day, and it snowed
here last night, I've got a couple of comments to at least this early
post that it seems still haven't been fully addressed in any later
posts.

[ On Saturday, December 29, 2001 at 18:50:48 (-0500), Todd Vierling wrote: ]
> Subject: Re: RFC: migration to a fully dynamically linked system
>
> On Sat, 29 Dec 2001, Rick Kelly wrote:
> : 
> : Also, one should consider how these changes will affect the performance of
> : 68k and other very old systems.
> 
> Actually, dynamic binaries in /bin and /sbin should significantly *decrease*
> system boot time on older and low-memory systems, because of the inherent
> shared code between all such programs.

Are you sure?  Have you measured it on such systems?

>  In fact, I had measured a very
> significant speed increase on a netbooted SPARCstation 2, in NetBSD-current
> between 1.3 and 1.4, with 8MB RAM when /bin and /sbin are dynamic -- nearly
> 50% faster bootup at the time.

Net-booting skews your measurements significantly.  Furthermore any kind
of booting is a very poor choice of metric (unless you're trying to
obfuscate things :-).  How many times do you boot your system?  At boot
time many programs are run for their very first (and sometimes only)
time, necessitating a much higher I/O load than might be necessary when
starting normally used programs in an already running system, especially
when there are many users and they all do similar kinds of things.

I've got a completely statically linked NetBSD running on a SS-20 clone
(including all of X11), and in general use I'd say it's about 20% faster
from a user perspective (maybe even a bit more for a repetetive task
like 'make build' especially if you run it with '-j n' where n >= 2),
and at some particular things it's nearly 50% faster (eg. repeatedly
starting an executable that links with many shared libraries, but does
nothing else significant, such as 'xset q').

Now that particular machine is not "low memory" by any stretch of the
imagination (it has 320MB of RAM and is running a kernel with VM and UBC
parameters tuned to match), but having had several decades of experience
with static linked Unix systems on really low memory machines, I can
assure you that many of the claims for memory savings with dynamic
linking are not quite so concrete as the proponents of dynamic linking
would like you to believe.  Shared text of any kind is always a big win,
but until you get into the realm of doing what's proposed with locale
support (which when fully implemented will bloat every binary that comes
even close to using it), dynamic linking of system libraries isn't
anything near so wonderful as it's often claimed to be.  The costs often
dramatically outweigh the meager benefits.

> There is a concern when it comes to /bin programs used extensively in
> scripts, for instance; but these can be tested empirically.

Hmmm... or in, say, "make build".....

> But most do require access to the passwd database, which we want to use via
> pluggable modules.

I, for one, don't want to ever even contemplate having my passwd
database accessed by any kind of run-time self-modifying code.

(I might not mind having my user's authentication attempts adjudicated
by an easily replacable statically linked authentication daemon though.  :-)

> The disk space requirements of the system are reduced by having dynamic /bin
> and /sbin.  This was illustrated earlier.

This is about the only hard claim of dynamic linking of shared libraries
which is guaranteed 100% true in all cases.  :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>