[wplug] Anyone else read the NetBSD article?

[Tom Rhodes]

On Fri, 1 Sep 2006 09:22:27 -0400
Bill Moran <wmoran at potentialtech.com> wrote:

> 
> http://mail-index.netbsd.org/netbsd-users/2006/08/30/0016.html
> 
> This has been causing a bit of a stir in the BSD communities.  I'm not
> sure I agree 100% with what he's saying -- I know that some of the cool
> new features in FreeBSD (rcng, for instance) were inherited from NetBSD.
> 
> But it's interesting none the less.

Belated notice of the message, I followed it and the follow ups
for several days and have kept silent.

Point is, NetBSD is not dying.  It's not dead.  He's just annoyed
at how things are going.  There isn't much interest in trying to
handle the large projects which NetBSD (and to an extent all the
BSDs and Linux distros) need.

Fine grained locking mechanisms.

More compatibility with POSIX and C99 standards

Better API (only in some aspects though, things like suser()
should actually be overhauled.

Etc. etc.

There are a lot of things he is complaining about, I'll only
say a few things about a few of his issues.

It's true that non-profit, open source projects can have some
issues with work loads.  As a FreeBSD committer, I'd rather not
be told that any given week I'm going to take over some part of
the tree.  Especially if I have no knowledge of that area, or
desires.  Some things that need done just flat out suck.  Perfect
FreeBSD example: tty system.  Really needs a lot of work to
come in line with our locking model.  No one wants to deal with
it.  It's a lot of work, and not really a fun area to play in.

So unless you start handing out assignments, you can expect that
some areas will rot without any interest.

The FreeBSD answer to this:  Get your drivers and areas of
interest up to standards.  If your driver doesn't have locking
support, at least at a disabled point if waiting on another
subsystem, it's gone.  Cut.  Completely cvs rm'ed until someone
picks it up.

Thus far, ATM seems to be the only system on the list to be
bined, and there has been interest.  USB was picked up, various
other parts as well, this seems to have worked.

Management issues.  One, I think he's a little bitter over some
past issue.  Otherwise, if you tell me how everyone in a large
project, hobby, fun past time, etc. should be managed, let us know.
In FreeBSD, the core team more or less follows the developers and
rarely offers a true sense of direction.  They support ideas, push
for better outcomes, and settle disputes.  The only time they
really jump in and "steer" the project is if a major issue comes
up which would affect the project and/or tree as a whole (locking
comes to mind, major API change, etc).  Things mostly get done
if and when someone is willing to do it.  That's how we obtained
MAC support - Robert said he wanted to work on it and bring it
in.  Done.  Same with the SMPng project, threading, etc.  Sure
there's a task list of "recommended" or "desired" features, but
it pretty much just sits there.

Google has been a big help here, along with other large companies
pushing donations.

The "Linux has a strong leader" statement is a moot point.  I've
seen people in open source projects step up to the plate, get
things done, help the project evolve.  Many times it was two or
three people.  A strong leader, a few strong leaders, both are
good.  If he thinks their leadership failed, it's not the lack
of a single leader but something else.  Yes, Linus did good with
the direction of Linux, but he had help.  Perhaps I'm wrong, but
aren't the various aspects of the Linux kernel done by "teams"
and not really "lead" by Linus?  Not sure.

Project locking is a double edged sword.  Sure, you don't want
to make a 300+ line change only to have a difficult time merging
it because someone thought it a good idea to run a spell check
or change a typedef or something.  At the same time it can block
useful changes.  FreeBSD doesn't really have a "perfect" way to
handle this.

As for FreeBSD scrambling to support a new arch, heh, I have my
own opinions about that.  But I keep mostly silent because there
isn't much action from me in the areas I've worked in.

-- 
Tom Rhodes