In message: <p0600202fbbe08225be4f_at_[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. WarnerReceived on Tue Nov 18 2003 - 19:45:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:29 UTC