Re: Unfortunate dynamic linking for everything

M. Warner Losh said:
> 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.
> 
(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