Re: FreeBSD 7, DragonFly's status

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

On Fri, Feb 29, 2008 at 5:05 AM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>     Well, I'll give you my 5-second opinion.
>
>     What I am not worried about:
>
. ..
>         * Ports and packages.  This was a huge worry of mine at the beginning
>           of the project.  I no longer worry about it.

Yeah, pkgsrc is a real life saver. I discovered NetBSD around the same
time DragonFly was picking up pkgsrc, so it was very pleasant for me
to have a reasonably uniform administrative strategy across the two
operating systems.

>     What I am worried about:
>
>         * The big-ticket items that we have traditionally compared ourselves
>           against, SMP primarily, have developed slowly, primarily because
>           up until recently I was the only person working on it.
>
>           It an issue of man-hours more then anything else.  FreeBSD simply
>           has more developers working on SMP then we do.
>
>           We have the infrastructure and the abstraction, we now need to get
>           down to the brass balls and finish it.

Well yeah, that's my point. FreeBSD's vast developer base lets it get
away with relatively unclean code and still remain relevant in
performance and functionality. Stability has picked up a lot too,
although that's hard to measure with hard evidence.

>         * I really want to see someone take up the ball on getting the
>           network stack MP safe.  It's important to the project but I can't
>           do that and HAMMER at the same time.  It's the easiest thing
>           to make MP safe in the project.

Wasn't it "almost done" years ago, and then virtually untouched
thereafter? I haven't been keeping up with source-level changes like
that, but I got the impression the last 10% takes 99.99% of the time
which is why it's still not done.

>         * Similarly with AMD64.  We need it.  I've developed the
>           infrastructure separation required and we even have a fully
>           virtualized kernel (vkernel) which demonstratres the infrastructure
>           separation.  Most of the generic kernel code can easily support
>           a 64 bit architecture.  The compiler supports it.  It's a project
>           waiting for someone to take up the ball.
>
>         * Our interrupt routing subsystem really needs a major upgrade.
>           (i.e. a major port from FreeBSD).

That's pretty much a showstopper for a lot of deployments. It's things
like that which I believe bring the project down. Even if it's only a
problem for 6 months, that's 6 months worth of new users which may be
discouraged from using the system, or use another system "temporarily"
that never gets replaced with DragonFly again.

This has brought down Linux and other projects a lot in the past,
where a critical bug was left unchecked long enough that hundreds or
thousands of users took years to try again. I contend that fixing
major problems must come before implementing new technology,
especially if that new technology is likely to add new problems. If
somebody installs DragonFly just to try HAMMERFS and discovers half of
his hardware fails because of an interrupt bug, what good does that
do?

>     Where I think the future is:
>
>         * SMP, Storage, and SSI.  Real time mirroring at the logical level.
>           HAMMER is a major component for the storage, SSI, and mirroring
>           components, and I believe HAMMER will be a large interest magnet.

I for one don't like to speculate about the future like that, because
such gambles often cost a lot even to companies who have a lot of
information from which to predict. Although it's been said the best
way to know the future is to invent it, a lot of inventors have had
their efforts wasted because of the lack of marketability of their
inventions.

>         Our project goals have not changed, but if I had it all to do over
>         again I would have started work on HAMMER much earlier then I did.
>
>         I spent more time then I should have perfecting the low level
>         infrastructure, trying to build a base upon which all the other
>         work could occur.

No, I agree with everyone who says the low level stuff is what makes
this project great in the first place. I'm just concerned it's nowhere
near enough to take enough market share that SSI becomes truly useful.

If it's just 1000 hardcore geeks in the whole world split into a few
SSIs, what practical benefit is there? They may as well SSH in to a
few powerful machines, and even consumer machines are becoming
ludicrously powerful lately. The security and efficiency of shell
access is a much more mature field than the security and efficiency of
SSI in general, saying nothing of any specific implementation.

And then, application clustering for web serving, databases, etc. is
already largely solved on the application level, often much more
optimally than a general approach could ever be. SSI doesn't help
there either, unfortunately.

>                                                 -Matt

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia