Hi everyone, I've been busy so I haven't said anything here in a long time, but reading about FreeBSD 7 has raised some thoughts.
I'm really interested to see that FreeBSD 7 in particular is becoming a hybrid of its old self and DragonFly's kernel architecture concepts. More subsystems like the scheduler and network stack are becoming CPU localised in a DragonFly way, but not based on message passing quite as much. Threading primitives are being optimized as well, improving performance to a Linux level. The trend seems to be towards modernizing and optimizing just as much as DragonFly, but still based on the fine-grained locking model rather than a massive localised parallelism model. 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. I don't know if this benchmark has been discussed here, but out of interest, is it just a couple of small optimisations or configuration tweaks that need to be made for DragonFly to shine on such a benchmark, or is DragonFly still in architecture work and not really optimized? Is it just the giant lock grinding in the kernel? 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. I can look back over everything that's come in to DragonFly, including a lot of really great ideas with great implementations, but it still doesn't seem to be nearly enough to satisfy an administrator selecting an operating system for a new project or solution. Some items like journalling and DragonFly-on-DragonFly virtualization were never driven to their logical or even feature set conclusions, while de facto standards like Xen support and even AMD64 are almost entirely 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. I look forward to being told I'm completely wrong and everything is much better than it seems :) Cheers -- Dmitri Nikulin Centre for Synchrotron Science Monash University Victoria 3800, Australia