> No matter how slow it gets, maintaining VAX in the NetBSD tree will
> always have benefits.

For one (well, another, since you claimed "one" :), it will keep people
from getting lazy and throwing cycles instead of thought at problems.
You can get awfully sloppy when you have a dual-core multi-GHz CPU to
cover up your sloppiness with raw cycle availability.  But get sloppy
on a VAX and you can't miss the resulting performance hit.

But, of course, that requires people to pay attention to VAXen.  I'm
not seeing that happening; instead, I'm seeing "that's the price you
pay for a better system".  I don't know how inevitable such degradation
actually is; while features do entail costs, I also think that not
enough thought is being put into how features are implemented.  To pick
a probably inaccurate example, people coming from the peecee "512MB of
RAM is a small machine" world think nothing of tossing around a
megabyte of lookup table or use-once buffer space.  You can't get away
with that sort of carelessness on a 5MB hp300.

I've been looking, on and off, at the ROMs for the Tempest videogame.
That's 24KB (_kilo_bytes) of ROM, and that includes all the fixed
aspects of the graphics.  And yet it's more playable in many respects
than some of today's multi-gigabyte games - I've recently been playing
a PlayStation2 game under the Frogger name and despite the huge
disparity in resources I think Tempest is by far the more playable of
the two.

"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry."  People are getting sloppy, depending on
Moore's law to cover up their sins.  Keeping slow machines like the VAX
in-tree - and paying attention to problems on them - would be one way
to keep NetBSD from succumbing to that effect.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B