On Wed, 18 Apr 2007 16:21:35 -0500
Przemys?aw Pawe?czyk <pp@kv.net.pl> wrote:



> >
> > There was once something you're looking for(?):
> > http://www.debian.org/ports/netbsd/
> >
> > You can revive it...  ;)
> If I were C++ able I'd choose GNU/Hurd. ;)
>=20
> But my e-mail concerned NetBSD, Debian was to be supportive fabric.
>=20
I'll probably regret posting this, but I'll do it anyway.

You've asked two very different questions: what is the goal of the
NetBSD project, and why aren't its goals similar to Debian's?

The first is very valid -- I've asked it myself several times,
including on the developers' mailing list.  I've yet to receive an
answer I consider fully satisfactory.  I think some of the problem with
the project is that is hasn't answered that question.

That said, one answer  -- and this addresses your second question -- a
full-blown, novice-friendly, desktop system, is not the answer for
NetBSD. It's not that it's a bad goal -- virtually all of us use
desktops of one type or another -- but there is neither the interest
nor the critical mass of developers to do it.  It doesn't mean that
such things shouldn't exist; it's just that NetBSD, as a project, can't
compete in that market.  If it tried, it would fail and become
completely irrelevant.

It wouldn't take unreasonably much to take big strides towards that
goal.  One could easily assemble metapackages for things like KDE
(though that one exists), Gnome plus customization, etc.  That's mostly
a matter of pkgsrc and packaging, rather than C programming.  For
better or worse, NetBSD and pkgsrc don't have the people who are
interested in doing that.  Furthermore, simply adding better packages
won't solve some of the issues that require kernel support or better
adaptation layers; those require fairly sophisticated C programming.
I'm speaking of things like drivers for certain devices, suspend/resume
or power management support, etc.  (Indeed, the latter is likely to
make me move somewhat away from NetBSD for my next laptop, because
NetBSD doesn't support some things I require and I don't have the time
to do them myself.)  There are other issues that are deeper, such as
easy updates to installed packages.  But whether you agree or not, the
project simply doesn't have the resources to pursue them.

Should the choices be different?  Perhaps, though it's hard in a
volunteer project to force people to work on things they don't find
interesting.  Name-calling -- and to be blunt, that's what you've been
doing, much of the time -- doesn't help. =20

For many reasons, some of them historical, Linux has mindshare and
hence a very large pool of developers.  That doesn't mean it's a great
OS, or that it has a clean codebase.  (It doesn't.  At least 3 of the 4
faculty members in my department --including me -- who teach operating
systems independently concluded that (a) *BSD was much better written,
and (b) we had to teach Linux kernel code.)  It is, however, reality,
and that means that there are many more Linux developers.  (By that I
include not just people who work on the Linux kernel but also those who
write applications that won't work with other open source
operating systems and simply don't care.)

What can be done?  In the short run, there are only two choices: move,
or try to fix thing yourself.  Yelling at people won't help.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb