Well, I'll give you my 5-second opinion.

    What I am not worried about:

	* Developer interest has always increased slowly and continues to
	  do so.  I'd be interested in commit statistics but my gut feeling,
	  from NOT having to push into subsystems that I used to have to
	  push into, is that more developers are working on more of the
	  critical infrastructure.

	* More developers are doing the 'harder' aspects of kernel
	  development rather then just me.  This is very, very important.

	* Ports and packages.  This was a huge worry of mine at the beginning
	  of the project.  I no longer worry about it.

    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.

	* 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.

	* 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).

    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 ...
[ message continues ]

On Fri, Feb 29, 2008 at 5:05 AM, Matthew Dillon

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

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,

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

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

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

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.
...
[ message continues ]

Given that theirs has choked several times on some fairly common 
hardware that DID work thru 6.2 RELEASE, that would not necessarily be 

It may seem so in the rear-view mirror, but had you NOT done the 
low-level infrastructure, AND the 2+ year code-clean-up of what was 
adapted from Free (and other) BSD, nothing else would be working as well 
as it does.

That was time that pays back with long-running and ongoing dividends.

JM2CW,

Bill

I agree.  I really appreciate that you spent the time perfecting the low
level infrastructure first.  That is one of the reasons we have switched
our projects over to DragonFly.  I am tired of systems that are like
a sky scraper built on top of a rickety foundation.  That is one of the
reasons Linux became so unstable that we left it after being on it for
at least 10 years, and again with FreeBSD.  When FreeBSD-5.x became so
unstable that we could not even complete NFS backups without the server
hanging, and stayed that way for months, we left it and went to NetBSD,
which is still a pretty nice system, although not as feature rich in
a lot of ways.  We did not wait for years for FreeBSD to stabilize like
we did with Linux (Hard lesson learned) before discovering it was not
going to.  Of course, I hope that does not prove true with FreeBSD.
FreeBSD still seem to have a more professional development community
than Linux.  However, we have since switched to DragonFly because of
architecture, planning, developer attitude, and emphasis on clean code
and stability.  

I believe a perfected low level infrastructure should pay off in the
long run with accelerated development without loosing stability.

I have been impressed with the progress of DragonFly so far, especially
considering the comparatively modest number of developers.

Vince

Note that Noah Yan has been working on an AMD64 port. Some stuff is 
already committed, and last time I checked, he had about 328KB of 
uncommitted patches in his git repository 
(http://repo.or.cz/w/dragonfly/port-amd64.git).

He doesn't seem to have much time at the moment but said he'll return to 
it as soon as the stuff he's occupied with has settled down a bit.

Sascha

-- 
http://yoyodyne.ath.cx