M. Warner Losh said: > In message: <[EMAIL PROTECTED]> > Garance A Drosihn <[EMAIL PROTECTED]> writes: > : At 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] 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. > (My last last email on this topic -- I had one previous last message :-)).
My reason for bringing this shared lib issue up is indeed related to 'performance', but also the apparent loss of performance (or other non-obvious features) through 'incrementalism.' When spending time on optimizing the FreeBSD VM and buffer cache performance, I had found that the total system performance is very difficult to recover when several (new or pre-existing) impedements are consipiring against best possible performance. VERY OFTEN, you'll not be able to accurately measure each of the incremental performance lossages, but eventually the system will disappoint. If someone very strongly wants XYZ feature that has been impeding the product adoption, then the solution SHOULD NOT be at the cost of other positive (and hard earned) attributes of the project. Just because a certain part of the project isn't being actively worked on, that doesn't mean that the previous work should be slowly and surely degraded by EITHER valid new features, or creeping featurism. If the XYZ feature was strongly desired, then it is important to develop a 'best' solution rather than an expedient answer. It is very clear that building all binaries as fully 'shared' is NOT a necessary prerequisite for the new (and apparently necessary for some applications) features. This doesn't mean that building everything shared (in the way it is done today) shouldn't be a temporary work-around. (*My biggest concern about building programs shared is about shells, but other -- already well shared and performance sensitive processes should also be carefully considered.) I am NOT religious about this issue, but definitely religious about the QUALITY of system wide performance and administrative behavior of a system., Hopefully, when an expedient solution is developed, then that should be remembered, and those who changed the system behavior should work (advocate, program, redesign, etc -- or whatever) to recover the previous desirable attribute. It is almost impossible for someone to follow along trying to clean up 'undesirable' side effects, unless there is a specific assignment to do that. It does seem appropriate that those who had benefitted most for the adoption of the new features should contribute towards an effort to make the 'features' better (which might include assisting in the stewardship of performance, or other negatively changed attributes.) Quality of an OS isn't just dependent on the number of features on a dot item list, but also on how those dot-items avoid accumulating negative effects on other attributes of the system. When I was working on FreeBSD, one of my goals was to avoid making the same mistakes as other OSes had made. Bloat and loss of performance from 'uncareful' addition of features is something that should be avoided -- it has already been perfected by other OS vendors. (Please don't reduce my argument to the absurd by mentioning Plan9 :-)). The 'bloat' attribute is something that I'd like to see FreeBSD avoid. Stagnation also needs to be avoided :-). John _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"