>Could someone make brutally clear to me why it is that MD fixes to some of the
>worst problems of BSD are not being allowed into the source tree?

You asked for "brutal".

I'm not on the NetBSD core team, so I don't gate fixes (MD or not), but I chose
NetBSD over the alternatives for exactly this reason.  In 20 years in the
computing field, I've come to the very firm conclusion that a quick machine
dependant hack substituting for a well-thought-out machine independant
alternative is an almost certain guarantee of bugs and poor performance,
the latter being especially insidious if it removes the pressure to fix
things right, a much better predictor than even run-of-the-mill quick hacks.
There are plenty of times when machine dependant solutions are appropriate,
but there's just something about the attitude that leads to choosing them
inappropriately that is a recipe for disaster.

I'm also rather frustrated over the lack of apparent progress in devising
a machine independant solution, since I, too, am in the position of being
unwilling to spend several hundred dollars more than I need to to improve
the performance of my system.

However, I'd much rather have a base system which is the result of engineering,
not panic, otherwise the extra memory is only going to slow down writing core
dumps all the time.

If having bounce buffers is your overriding technical concern, then you
simply should not be running NetBSD, because it doesn't address that concern.
(Unless, of course, you are willing to maintain a local patch.)  If it is
not your overriding technical concern, then insisting that people abandon
their concern for code quality in exchange for a quick fix is certainly
inappropriate.


Now, on the other hand, it would be reassuring if someone could assert that
there *is* a design in progress, and perhaps give an outline; this being a
volunteer effort, I don't expect elaborate working papers and extensive
meeting notes, but I'd hope it's more than just a collection of workarounds
from four or five people.  And if it's languishing because none of the
volunteers have time to do more than fix the really pressing problems,
then perhaps some people with relevant experience could volunteer to
hammer out a workable and enduring architecture.  (That's probably a question
for the tech-kern list, though.)