[N.B.: The original thread was cross-posted to at least 2 or 3
lists---I don't know how many, as the mail-index.netbsd.org server
doesn't preserve such information.  I'm only going to post to one
list.  I really don't need to read copies of these emails on every
list that I read.]

I'm a bit concerned that you seem to be trying to pressure the
NetBSD developers into a "release early, release often" cycle.
-current for NetBSD is actually (generally) a very stable OS; if
you want the drivers that are only in -current (for now), then run
-current.  You'll find very few problems, in all likelihood.

If you are concerned about the (slight, but real) issue of -current
having code that hasn't been tested or finalized, then run a release.

I for one would rather *not* see the developers rush out a release
that is approximately what -current is today.  I see the releases as
much higher quality---and slower cooked---and like them that way.
I run -current on one or two machines, and releases elsehwere.


Re. TNF asking for money: It didn't sound like they were hurting,
to me.  For a long time, TNF has not too blatantly asked for money.
But then on some of the lists, people pointed out that there is no
shame in a non-profit organization asking for money.  Or in selling
"premium" CDs as a way for people to make tax-deductable business
purchases that would help TNF.  It did not sound at all, to me, as
if TNF was "hurting", as you say.

But, maybe it depends on the context one sees or doesn't see.  I
happened to see the context where TNF was *prompted* to ask for
money by users.  Certainly, TNF has always had a very low budget
in the past, and people have complained a bit about some of the
servers being down.  It's nice that the recent call for funding
was met with enthusiastic support and that there are now going to
be some new servers to take care of things like automated builds
and the CVS repository.


Re. comparing to other operating systems: It has long been the case that
some things are available for other systems first...and some things have
been available for NetBSD first.  We (NetBSD users) were first with
USB support, but have no released support with Firewire yet (that
I know of).  Despite the intervening years, we still don't have DRI
support in-tree (last I heard; (^&).  When I first installed NetBSD/AMD64
about 20 to 22 months ago, NetBSD was much better than SuSE GNU/LINUX for
this system with this graphics card, and last I checked, FreeBSD was still
not supporting DRI for me nor did it support sound on my system---but NetBSD
supported sound and fast (if not DRI) graphics.

I just installed Red Hat GNU/LINUX on a second hard drive for this computer.
I can't get it to drive the graphics to better than 1024x768 (or maybe
800x600; I forget)---under NetBSD, I have no problem supporting 1792x1344.
(I tried getting Red Hat GNU/LINUX to go higher, but then the video mode
went out of range for the monitor---but the monitor capabilities in the
X config file looked right, so...I could try lying to RedHat GNU/LINUX,
but I shouldn't have to do that.)

Also, the DRI-supported OpenGL seems to have some bugs: pbuffers for
offscreen rendering seem not to work, and something else is causing
problems (at least, some programs I have fail and/or crash with
RedHat GNU/LINUX).  But the X/Mesa combination with NetBSD---while
not as fast as hardware accelerated graphics---is quite robust.
I'll take a slower, but WORKING configuration over fast-but-broken
configuration any day.  (^&

Maybe if I tried a bunch of other GNU/LINUX distributions, I'd find one
that worked as well as NetBSD.  (Actually, Mandrake 10 beta worked pretty
well a year ago.)  Maybe if I tried the latest FreeBSD version, it would
also work better.  But I've been pretty happy with NetBSD for close to
two years on this box.

So...in short, I am not so sure that NetBSD is "falling behind" the
other systems.  It has always lagged in some areas, and excelled in
others.  One of the areas where it is strong is in robustness; I'd
hate to see that compromised just to get a few drivers out a little
faster, especially when those drivers are available already for the
impatient (just run -current).


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/