DragonFly At DragonFly 1.0-CURRENT

CoolVibe writes "For months, the DragonflyBSD fork of FreeBSD was maintaining compatibility with the existing FreeBSD-STABLE branch by using the 'FreeBSD 4.8-STABLE' name internally. In a few commits, Matt Dillon changed all the names, and DragonFly is finally sailing under its own banner. Things that DragonFlyBSD already has that FreeBSD-STABLE doesn't are, among others, application checkpointing, variant symlinks (not unlike Domain OS), Light-weight kernel threads, a more efficient slab-allocator, a multithreaded network stack, and the rcNG system."

Hmm, well..

[JVStalin]

Things that DragonFlyBSD already has that FreeBSD-STABLE doesn't are, among others, application checkpointing, variant symlinks (not unlike Domain OS), Light-weight kernel threads, a more efficient slab-allocator, a multithreaded network stack, and the rcNG system." Oh, boy! Let's look at 5.1-RELEASE's features: rcNG, KSE, Mandatory Access Control framework, better SMP, fast ATA drivers. I hate to say it, but, DragonFlyBSD is all most as silly as that xMach project. :-) It's about arrogance, not software.

Re:Hmm, well..

[Anonymous Coward]

Silly? Such a judgemental attitude seems much more silly than the fortitude it takes to accomplish what Matt has.

I'm happy Matt has a place to try his ideas which have been shouted down time and time again by loudmouth, arrogant Dane and Australian developers (you know who you are).

Dragonfly will either prove the latter to be the FUD frauds we suspect they are or to have been right all along.

Stay tuned, you might just learn something. Then again, maybe not.

Re:Hmm, well..

[Anonymous Coward]

You might want to take a look at the DragonFly design page. FreeBSD-CURRENT's SMP design is based
on the traditional "lock everything down" model, which has scaling problems with current hardware trends. In addition, their particular implementation will be particularly hard to maintain in the long run. Really, the only thing you mention that is
likely to be considered for incorporation in DragonFly is tht ATAng.

You sound like one of the BSD developers who dislikes Matt on principle. So you may be right in your case about the arrogance vs. software.

Re:Variant symlinks are really cool

[CoolVibe]

They will be used, but not gratuitously. It's mostly to get our packaging system to go where we want to, without having to worry about the new VFS stuff yet. Variant symlinks solve about 90% of the problems at 10% of the cost, so that's why they were implemented. Also, it kinda depends on what the person that installed DFly on his machine is doing :)

When DFly's VFS subsystem is getting into shape, the need for varsyms will be less and less.