DragonFly BSD Goals/Direction

[Justin Sherrill]

On Fri, Dec 2, 2011 at 1:39 AM, Samuel J. Greear <sjg at evilcode.net> wrote:
> This email is intended primarily for active DragonFly committers and
> contributors.
>
> I intend to bring the goals page on the DragonFly website up to date
> like I did previously with several of the other prominent pages, so I
> need to know what your goals are. Please provide me, either on or
> off-list at least a brief summary of your near-term (current or next
> release), medium-term (1-3 years) and long-term (3 years +) goals.

My goal - Define and differentiate the DragonFly project.  NetBSD is
about portability, OpenBSD is about security, FreeBSD is about...
running on x86?  I don't have as direct a description there.  PC-BSD
is about providing a desktop.  I'm oversimplifying it, but that's
necessary for giving people an immediate "why".  I was reading an
article that said projects need to define their own narrative, and
tell that narrative to people outside the project so they understand
what's being done.

In the near term, talking about DragonFly as a way to do SMP
differently, and distributed computing differently, is a good story.
SSI, as a separate idea is no longer needed because of the growth of
processor count, but Hammer2 would effectively do that for us.

In the long term, I'd like to have DragonFly known as a server
operating system.  Being a BSD platform and trying to catch up on all
the different desktop enviroments is worthwhile, but we don't have the
resources to do it better than, say, Canonical, so it's not worth
having it as our focus.  However, we've got a clean codebase that's
been hammered on (no pun intended) for 40 years, good man pages
(thanks Sascha), a great file system (thanks Matt and others), and a
supportive community (thanks everybody).

For example, with the recent drastic vm_token changes, we had a few
weeks where you could get a crash running bleeding edge code.  That's
the first time I recall any significant number of issues with the
latest code in 8 years.  8 years!  Being quick to fix bugs and willing
to take in submitted code is really what it takes for that, and we've
done well.  I think we are well on our way to creating an operating
system environment where an experienced user can come in and get work
done.