On Thu, Feb 28, 2008 at 4:09 PM, Justin C. Sherrill
<justin@shiningsilence.com> wrote:
quoted text
> On Wed, February 27, 2008 11:29 pm, Dmitri Nikulin wrote:
>
>  > The benchmark at http://people.freebsd.org/~kris/scaling/os-mysql.png
>  > (for the full presentation, see
>  > http://www.freedomtc.com/pdf/7.0_Preview.pdf, that plot is on slide
>  > 17) indicates that FreeBSD 7 not only competes strongly with current
>  > Linux performance and scalability, but that DragonFly has been beaten
>  > even by NetBSD which came late to the SMP party.
>
>  Minor quibble: you're pointing at benchmarks on an 8-core xeon.
>  Relatively uncommon hardware, though I'm sure that'll change within a year
>  or so.

Sure, but SMP scalability is one of the key goals of DragonFly, and
for it to be beaten by NetBSD (for which this is not a major goal, and
for which SMP scalability only started being worked on a year ago) is
very confusing. I haven't seen it compared with 1.12, but since no
huge scalability work has gone in for a long time, I doubt it would
close the gap much.

Even so, while 8-core Xeons are not yet common, AMD64 compatible chips
are pretty much the only mass consumer chips available now, and
DragonFly can still only use the 32 bit portion of that, and even
then, doesn't yet scale to two cores fully, let alone the increasingly
common quad cores. That falls far short of the goal to scale well for
increasingly parallel systems, which continue to be picked up by Linux
and now FreeBSD at an increasing rate. That's really disappointing for
an operating system I originally believed would humiliate FreeBSD's
SMP implementation.

quoted text
>  > At the risk of sounding like a troll, may I ask, if FreeBSD 7 has high
>  > performance, high stability and remains reasonably clean and
>  > maintainable, doesn't that partly invalidate the reasons DragonFly was
>  > created? Being cleaner and more revolutionary doesn't count for much
>  > if the product itself doesn't serve as a compelling alternative. Maybe
>  > I'm just missing the point of DragonFly's development.
>
>  There were people attracted to DragonFly early on because they were
>  mistreated by various folks involved with FreeBSD, but liking DragonFly
>  because it's not FreeBSD is not enough to build a project.
>
>  DragonFly is not a FreeBSD replacement, nor does DragonFly require FreeBSD
>  to suck in order to exist.  You could probably make the exact same
>  argument you just did but substitute in the name of another BSD, if you
>  are going to take the tack of "fastest benchmark so why use anything
>  else?".  (I realize I'm oversimplifying your words.)

You're right - you are oversimplifying my words. I'm only saying that,
for goals which DragonFly considers groundwork, FreeBSD still matches
or wins by a large margin. That includes good performance (FreeBSD
wins) and stability (FreeBSD seems to be no worse off). I can't attest
to the maintainability, but they seem to be doing alright, and
"cleanups" get done too. So while DragonFly has a lot going for it
(which I never denied), it's challenging to find a situation for which
DragonFly is actually a better choice than FreeBSD.

quoted text
>  DragonFly is oriented towards creating a single system image over multiple
>  networked computers on the Internet, which has never been done before.

It's years off even for DragonFly. If it does one day achieve that
goal, but by then other systems have advanced to the point that
DragonFly isn't even compelling for a single node, why will anyone
want to run it just to join a cluster? It needs some minimum user base
before internet clustering becomes useful at all. That's my biggest
fear regarding this project - that by the time its highest goals are
achievable, the full potential of those goals will still be out of
reach, perhaps forever.

quoted text
>  FreeBSD -> run on x86
>  OpenBSD -> run securely
>  NetBSD  -> run on anything
>  DragonFly -> run once everywhere?
>
>  For myself, I find DragonFly useful because it's a tight and friendly
>  developer community, with lots of interesting projects to do.  FreeBSD
>  having a good mysql benchmark doesn't affect that.
>
>
>  > neglected. Again, at the risk of sounding like a troll, I'm gravely
>  > concerned about the growth and survival of this brilliant project in
>  > the face of increasing pressure from projects with much larger
>  > developer communities and software ecosystems.
>
>  We've been doing pretty well, really.  The number of changes and new
>  developers in 2007 have been on an upswing relative to 2006.  (I should
>  know, given my digest work.)  There's been enough happening that I've had
>  a steady 2-day buffer of things to post for a month, which has never
>  happened before.

That's really good to hear. It's hard to tell just from mailing lists.

See, my problem is, I really care about DragonFly from a very geeky
perspective. I want the clever, somewhat revolutionary ideas to win
and show the rest of the world how it's done. But on the other hand,
Inferno was set to do that, and how relevant is that now?

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia