Tools v. Policy: Dynamic linking

First, this can be moved right to -chat or /dev/null. Whatever trips your
trigger. The first post is just to -current, because that's where all the
commotion is.  I think everyone can concede that the discussion has
basically begun to bore most.  I think, however, that a fundamental point
has been lost in the noise here: The current decision to make dynamic 
linking the default is a policy issue, and not one of providing additional
functionality.

I don't think anyone is disatisfied that someone finally did the work to 
make support for NSS and PAM et al. work for those who need it. It was a
difficult and long-awaited set of functions.  A good deal of thanks should
go to Gordon and Jacques and all the others who hacked and tested to make
it work. Even if there might have been a technical middle road that would 
have more easily pleased everyone, those who do the work have the 
final say as to the implementation.

The real problem, that seems to have gotten lost here, is why does this 
set of new functions need to be the system default?  I can only imagine
that the true reason is one of maintenance.  Hooking dynamic linking into 
the system forces the project to make sure it always builds and works.
This, imho, should be more the responsibility of the small set of
individuals (and I do think the number of users who need this type of
functionality is relatively small when viewing the big picture) who need 
dynamic linking in their systems.  One could even dedicate a build cycle
within the build cluster to make sure that the dynamically built worlds 
continue to build with on-going changes.

The pros and cons have been discussed ad nauseum. I don't think one side 
will be able to convince the other that their approach is better or worse
in the long run and that eventually, people are just going to get even more
irrational in their arguements. I mean, comparing compiler upgrades (which
are externally developed and support new architectures) to dynamic linking
seems to be tangental at best. Running "fork bombs" vs. port builds to make
a point is just selective analysis. Labelling one side as "dynamic,
progressive, innovative" and the other "crusty conservative old-timers" is
just adding noise. Those advocating "progress" need to realize that moving
forward doesn't always mean you're moving in the right direction. Making
FreeBSD more "like" Solaris or Linux is only valid up to a certain point.
We all like this new functionality. We just don't want it in our
backyard... (further bantering suppressed)

Fast or slow, NSS support or not, does it really need to be default? Can't
the project make a commitment to this set of functions without making it
the system default? No one objects to making this set of functions
possible. It seems a good deal object to making it the default.

-- 
Yours truly,

shaun at shamz.net