Today we feature a very interesting interview with well known *BSD hacker Matthew Dillon over his latest project, DragonFly BSD (also known for his Linux kernel contributions, Amiga C compiler hacking back in the day and the Backplane distributed database). Matthew discusses DragonFly's status, goals, the overall BSD platform, innovation, and more. Update: Added one more question at the end of the Q&A.

1. Please tell us about the general status of DragonFly BSD.

Matthew Dillon: The project has been going very well. We've primarily been focused on the 'guts' of the system during this initial period, and you can get a fair idea of the work that has been accomplished so far by looking at the Diary page on our site.

Most of the work so far has been to operating systems internals. The
work has been a combination of new work, like our light weight kernel
threading core, plus selective backports from FreeBSD-5 to keep the
system's device drivers up to date (e.g. such as the USB subsystem).

From a userland perspective we have maintained a FreeBSD style
environment, so DragonFly basically runs everything that FreeBSD-4.x
can run. The packaging system probably won't be done until the second
release so we are at the moment leveraging off of FreeBSD's ports system
for user apps. Everything you'd expect of a BSD system (X, mozilla,
etc) is available to DragonFly users.

The first release is slated for some time in mid-June, hopefully
before the USENIX Technical Conference. That will be the 1.0 release.
We've been fairly careful to maintain as high a level of reliability
as possible during development and I think we've done a pretty good job
meeting that goal. The first release is intended to be more of a
technology showpiece then an integrated end-user platform.

2. Are you using any bits and pieces from FreeBSD-5, or you only strictly importing/exporting to FreeBSD-4 codebase?

Matthew Dillon: DragonFly began as a fork off of FreeBSD-4, because that was the most
reliable starting point and because we wanted to do major core pieces
of the system quite differently from the direction FreeBSD-5 took. For
example, we are focused on more of a compartmentalized threading model
to scale to SMP rather then the mutex model that FreeBSD-5 has chosen
to use. But the FreeBSD-4 codebase is of strictly limited utility as
a source of new code and maintainance updates. FreeBSD developers
are doing nearly all new coding in the FreeBSD-5 branch.

So, basically, we are doing the major core pieces of the OS differently,
such as our significantly evolved threading and messaging subsystems,
but we are also maintaining a FreeBSD-5 compatible (or mostly compatible)
device driver API in order to be able to bring in all the excellent
device driver work that has gone into FreeBSD-5. It's simple logic,
really... we don't have the manpower to be able to accomplish both
our infrastructure goals *AND* be able to maintain pace with new PC
hardware at the same time. This methodology allows us to proceed on
both fronts by focusing our own new work on the infrastructure and
bringing in FreeBSD-5's device driver work. This isn't to say that we
don't do some of our own DD work, but the vast majority of it is
take from FreeBSD-5 by design.

3. What is the primary goal of dragonfly, servers or desktops?

Matthew Dillon: Both. When it comes right down to it the idea of targeting a system
to the 'server' is simply another word for 'reliability and scaleability',
and the idea of targeting a system to the 'desktop' is simply another
word for 'out of the box GUI'. It's not really an either-or deal.
All UNIX systems, including Linux, the BSD's, DragonFly... basically
use the same desktop components so supporting a desktop environment
comes down to being able to provide integrated solutions that work out
of the box.

It is extraordinarily difficult to make GUIs work out of the box on
PCs due to the wide variability in hardware and peripherals, but at the
same time technology has continued to progress over the years towards
standards that actually make this easier to accomplish. At some point
the standards going in one direction will meet the software going in the
other and systems such as Linux and the BSDs (including DragonFly) will
be able to approach the out-of-the-box compatibility that took Microsoft
billions of dollars of development to accomplish. It isn't a matter of
if, it's a matter of when.

4. Do you eye the embedded systems market at all?

Matthew Dillon: It is not a focus. We fully intend to make DragonFly operate in
64 bit environments such as the AMD64 (which is also compatible with
the Intel's latest 64 bit announcements even though Intel doesn't like to
admit it), but embedded systems are already very well served by
Linux and NetBSD and we would prefer to focus on technology rather
then platform ports. FreeBSD-5 has had a difficult time supporting
the half dozen or so platforms they are trying to work with and I doubt
we would fare any better, so I am not even going to try. Eventually, if
DragonFly becomes popular enough, embedded systems ports will probably
happen, but it's probably several years down the line.

5. How big is the DragonFly team currently? Are you happy with the development pace?

Matthew Dillon: Very happy. The main kernel@ mailing list has 241 people subscribed
to it as of now and I have handed out 9 commit bits, with another dozen
or so people submitting patch sets outside of that. We have a good
spread of developers focused on different subsystems. For example,
Jeffrey Hsu is focused on threading the network stack while Joerg
Sonnenberg has been focused on the PCI bus and ATA disk driver subsystems,
which frees me up to be able to focus on technological infrastructure such
as the threading subsystem. It's about at the limit which I can sustain
and still have time to do significant programming myself, in fact!