:-What is DragonFlyBSD and what's its current state?
DragonFly is part of the BSD UNIX family of systems. Currently we
have a fully integrated kernel and system distribution and most
major user applications compile and install from PkgSrc. It runs
(in 32 bit mode) on PC platforms.
:-How did DragonFlyBSD started, it was only a disagreement from the
:direction FreeBSD was taking or you had other interests that led you
:to the creation of a new BSD distribution?
Both, in fact. I had a major disagreement with the way FreeBSD
was implementing SMP (symetric multi processor) support. I felt
that the methodologies and coding were not being done in a maintainable
fashion and would be prone to hard-to-find bugs and code attrition.
But I also have other interests as well, and it was the combination of
the two that resulted in my starting the DragonFly project.
DragonFly's major goal is to fully integrate native clustering
capabilities into the kernel, to be able to reliably cluster machines
together and effortlessly access their pooled resources.
The project has been around for over two years now and we are
approximately two years away from accomplishing our goal.
:-I believe that every Operating System has its own philosophy, what is
:the philosophy behind DragonFlyBSD?
Wow. Well, I could go on for hours about my philosophy, but in a
nutshell, apart from wanting to accomplish the goals I have set out
for the project, I want to create a social development environment
that removes walls between developers instead of building walls
between developers. That means both recognizing individual skill
and also recognizing that the core of the project... its codebase,
must be considered a community resource and never be compartmentalized
or 'owned' by a particular person. Sometimes projects become overly
stratified and seeped in requirements that only serve the interests
and desires of a small portion of the community - something I think
the FreeBSD project has suffered from greatly over the last few years.
I absolutely do not want DragonFly to turn into that.
One of the biggest advantages the BSD community has is that many
of the concepts and much of the core OS code, if not compatible, is
still easily ported between projects. I make it a point to encourage
all DragonFly developers to look at the work being done in all the BSD
projects, as well as Linux, and bring that work into DragonFly when it
is clearly superior. We have brought in considerable infrastructure
from OpenBSD, NetBSD, FreeBSD, and even a little from Linux, and of
course a lot from GNU. And we have rewritten just as much infrastructure
natively.
Another major philosophy of the project is to not bring in code before
its time. We all want SMP, but we are not willing to make quick hacks
to the code base that will only bite us in the rear at some future date,
or create such a mess that it essentially becomes unmaintainable and
bug-prone. This is particularly true of our SMP support. Good SMP
support is one goal of the project, and we have a development methodology
for it, but we aren't going to rush through hacks that destabilize the
system just to win a few benchmarks. My philosophy, which everyone in
the project shares, is to use the right algorithm *FIRST*, even if it
means rewriting entire subsystems, and then work towards the goal from
that basis instead of from the basis of a decades-old algorithm that
was never designed with SMP (or clustering) in mind.
Over the last two years nearly every major subsystem in the DragonFly
kernel has been rewritten with this in mind, and while it may seem to
some that we aren't making progress towards our goals, in fact we
are making very significant progress. I am very happy with the way
the project is progressing.
:-Why should anyone choose DragonFlyBSD, which are its main advantages?
For mass deployment and production it is probably best to wait until
we get closer to our major goal. At that point DragonFly will have
distinct advantages for a large class of problems over other operating
systems. Of course, DragonFly works just fine right now as a Generic
UNIX-like platform, similar to Linux (and, in fact, BSD in general
existed long before Linux did), but since Linux has pretty much
taken over that market I would be hard put to recommend DragonFly over
Linux for any sort of major commercial deployment. Yet.
However, anyone with more personal requirements, a small business, or
the need for a turnkey PC platform, and the know-how to run a UNIX
system, will probably like DragonFly as it is right now. What I really
want is a modest deployment that we can support with our limited
developer resources.
That is perhaps too blunt a statement but I feel it is always important
to understand and live in the real world. I do not feel that it is
possible for Linux to run away with the market simply because so much
of the market is based far more on the user application infrastructure
(based on open standards which all the linux and BSD dists support)
then on the operating system core. The intent with DragonFly is to
stay within shouting distance on the application side while adding
major features to the system core.
:-Not many people knows the Amiga nowadays (that's a shame), I
:understand that you got involved with it some years ago, is
:DragonFlyBSD taking ideas from AmigaOS or any other OS for that
:matter?
Not so much any more, but certain programming concepts used in
DragonFly, particularly the kernel messaging layer, were developed
from my experiences with the Amiga. I think what I get most from
my Amiga days is a pragmatism about code longevity. Ideas, algorithms,
and protocols last forever. Code (in usable form) doesn't. Dragonfly's
largest goals are idea, algorithm, and protocol oriented, and if I hit
the mark properly those ideas, algorithms, and protocols will still
be known hundreds of years from now even if the original code used
to implement them becomes unrecognizable to future generations.
:-How would you describe the DragonFlyBSD kernel?
Progressing well towards our goals.
:-By the time this interview is published maybe the next release of
:DragonFlyBSD is ready to download, can you tell us what are the main
:changes from version 1.6?
The 1.8 release is planned for the end of January. The Diary entry
for January 2007 at http://www.dragonflybsd.org/status/diary.shtml
contains a complete list of changes.
:-Right now DragonFlyBSD is using NetBSD's pkgsrc to install third
:party software, are there any plans to create a package management
:system specifically for DragonFlyBSD?
We plan to continue to use PkgSrc. There are many reasons for this
but two really stand out. First, the PkgSrc developers are dedicated
to producing a portable infrastructure, which means that we are not
constantly having to hack packages or DragonFly to maintain
compatibility (something we had to do with the FreeBSD ports system
as DragonFly diverged from FreeBSD). Packages updated by NetBSD or
OpenBSD developers works with DragonFly and on the occassion that an
issue arises, a solution is worked towards based on the portability
goal. Secondly, PkgSrc provides a very time and effort-efficient
means of providing DragonFly with a large number of third party packages.
As a small project, we cannot afford to dedicate a huge number of
resources to maintaining packages and still be able to work towards
the goals for the operating system. PkgSrc isn't perfect, updating
packages is still a pain, but it fits the goals and philosophy of the
DragonFly project like a glove.
jueves, enero 25, 2007
Interview with Matt Dillon
A few days ago this interview was published in RevistaSL, here's the original in english for those who don't understand spanish. ;-)
jueves, enero 11, 2007
Suscribirse a:
Entradas (Atom)
