Unfortunate dynamic linking for everything

[M. Warner Losh]

In message: <p0600202fbbe08225be4f@[128.113.24.47]>
            Garance A Drosihn <drosih at rpi.edu> writes:
: At 9:02 PM -0500 11/18/03, dyson at iquest.net wrote:
: >  Of course, there was a development resource limitation,
: >but the decision (discussion) was made approx 6months ago?
: >(Enough time to solve the problem without a GLOBAL
: >performance hit.)
: 
: Well, yes, perhaps.  But there is that issue of "development
: resource limitation".  Back when we did debate this publicly,
: no one stepped forward and said "I have the time to implement
: a better solution".  Thus, we went with this solution.

And it still isn't too late for someone to step forward with a better
solution.  Or to develop one.  The main reason we went with dynamic /
was to be able to get dynamic libary/loading support for newer
authentication and user technologies.  The size advantage is one minor
added benefit.

: Speaking as to what we can do right now, I would not want to
: delay the 5.x-stable branch by adding some project right now
: to start writing an alternate PAM/NSS solution.  If someone
: wants to write one for 6.0, that would be good.  There is
: nothing in this solution which would cause problems for
: some later solution.  Disk space will only get cheaper.

I tend to agree.  If there's a performance regression with the dynamic
change, then the right solution isn't to yell 'back it out', but
rather to build a better mouse trap.  FreeBSD gets better through
these tentions and people scratching an itch.  FreeBSD doesn't get
better by stagnating and never changing anything.

With all things it is a balance.  Sometimes it tips a little this way
or that.  As our user base changes, the balance point changes.  If
FreeBSD isn't willing to adapt to the new balance point, it runs the
risk of losing relevance.

Finally, I'll just observe that most of our users care most about
apache, which has been dynamically linked for a long time.

Warner