Re: Unfortunate dynamic linking for everything

[cc: dropped]

I suppose I should comment on this thread, since I'm closely related
to at least two of the rationales mentioned for moving towards an
all-dynamically-linked system.  (I would prefer to stay out of this
thread.  In my mind we've had all these arguments in various
forums months ago and the issue was put to rest.)

On Tue, Nov 18, 2003 at 05:06:06PM -0700, Scott Long wrote:
> 2.  NSS support out-of-the-box:  Again, this is a user-experience issue
>     in that forcing NSS users to recompile world was seen as a potential
>     roadblock to them.

Some followups mentioned that a different implementation of NSS would
not require dynamically linked binaries.  This is technically true.
Certainly, I explored that avenue.  But practical considerations made
that alternative a poor choice.  Supporting NSS really also means
supporting (in as much as possible) the existing base of NSS modules.
These modules were all designed to be loaded by libc and invoked
in-process. (nscd doesn't do what some seem to think it does, and in
practice it is not well-loved.)

Existing NSS modules also shaped some other decisions that I made
(such as API entry points and thread awareness or lack thereof).
Breaking with the fundamental designs of NSS as found on Solaris and
Linux means practically starting from scratch when `porting' NSS
modules.

I'm sure someone more clever and with more time could make it work
out-of-process.  Based on my experience, I think the result would be
overengineered. *shrug*

Finally, if we could call `dlopen' from statically-linked binaries,
this wouldn't be an issue.  I'd really like to see dlopen support for
statically-linked binaries, for NSS and many other applications.


> 3.  Binary security updates: there is a lot of interest in providing a
>     binary update mechanism for doing security updates.  Having a dynamic
>     root means that vulnerable libraries can be updated without having to
>     update all of the static binaries that might use them.

Actually, not only binary security updates but any security updates,
or bug fixes for that matter.  If there is a bug in a library, fixing
that bug on your system is much more straightforward if everything is
dynamically linked.  It is much easier to rebuild libc or libcrypto
and restart applications then to have to go through an entire `make
world'.  It can be hard for many administrators to avoid `make world',
because it is not always easy to ascertain what applications are using
what APIs and libraries.


There's been a lot of talk about performance, but for my environment
all the workhorse applications are already dynamically linked.  I'd
guess that is the case for most FreeBSD users.  And of course, most
FreeBSD binaries--- in the base system, in ports, and commercially
available--- are already dynamically linked.  For the minority of
users that it actually has a performance impact (show of hands?), of
course they are sophisticated enough to build the affected binaries
statically.  Unless we are talking about /bin/sh, they probably already
have to go through special measures to get a statically linked binary.

Cheers,
-- 
Jacques Vidrine   NTT/Verio SME      FreeBSD UNIX       Heimdal
nectar_at_celabo.org jvidrine_at_verio.net nectar_at_freebsd.org nectar_at_kth.se