implemented features (Re: Decision time....)

Rahul Siddharthan rsidd120 at gmail.com
Mon Jun 4 01:45:18 PDT 2007


I found this comment on Dmitri's blog possibly unfair, but somewhat 
reflecting my own perception as well:
http://spetskod.blogspot.com/2007/05/immature-optimization.html#comment-8539868674748140994

DragonFly was forked from FreeBSD-4 because of dissatisfaction with
FreeBSD 5's approach to many things, including SMP.  But nothing
visible to the user seems completed yet, especially not SMP.  And it
looks like it won't be completed for 2.0 either.

Today, nearly any new machine one buys will have at least 2 CPU cores,
perhaps 4 or more. 

Also, nearly any new machine, whether AMD or Intel, will be 64-bit.
On my own code (computational biology), using gcc, 32-bit binaries are
50% slower than 64-bit binaries.  (This is true of both gcc3 and gcc4.
In fact, gcc 64-bit binaries are faster than 64-bit binaries generated
by the Sun Studio compilers on amd64.)  That sort of speed difference
is not trivial for the sort of work I do.

So on a new machine I would really want to run a 64-bit, SMP OS.
DragonFly is ruled out on both counts.

If one views DragonFly as a pet research project of Matt, Simon and
others, this is fine.  But if it is to be a serious alternative to
FreeBSD or other systems, shouldn't there be some focus on near-term
goals that are actually useful to regular users, rather than ambitious
ideas like a brand-new filesystem?  It seems to me that SMP and 64-bit
support should be the first priorities.

If DragonFly were usable to me, I would be able to contribute to some
things -- pkgsrc, testing device drivers -- though not to kernel-level
stuff.  But at this point, I can't even run DragonFly on a new
computer without crippling myself.

Rahul





More information about the Kernel mailing list