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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
