[reconbot]

I had no idea what dragonofly is, it looks to be an experimental BSD based OS https://www.dragonflybsd.org/release54/

    DragonFly belongs to the same class of operating systems
    as other BSD-derived systems and Linux. It is based on the
    same UNIX ideals and APIs and shares ancestor code with
    other BSD operating systems. DragonFly provides an
    opportunity for the BSD base to grow in an entirely
    different direction from the one taken in the FreeBSD,
    NetBSD, and OpenBSD series.
    
    DragonFly includes many useful features that differentiate
    it from other operating systems in the same class.

[andrewl]

It may be experimental in that it's diverged significantly from FreeBSD, from which it was forked. But experimental does not mean new. Release 1.0 was in July 2004. Apparently the lead developer's experience with the Amiga OS influenced the project to some degree.

[loeg]

Yeah, Dillon (lead developer) forked FreeBSD 4 over (at least) a dispute in how SMP should be implemented. (FreeBSD 5 was the first release to support SMP.) DragonFlyBSD => DFBSD => Dillon's FreeBSD.

[jabl]

I recall back then Dillon had some unconventional ideas how to do SMP compared to the traditional approach of ever more fine-grained locking as done by FreeBSD and Linux. Is DragonFlyBSD still following this design, and if so, how well did it work out, or if not, did they revert to a more traditional approach?

[loeg]

I don't follow DFBSD development too closely, but it looks like they still have the somewhat novel lock tokens:

https://www.dragonflybsd.org/docs/developer/Locking_and_Sync...

I don't know how well it works for them or if they've gone back to using more typical locking more recently.

[tedunangst]

FreeBSD 3 supported SMP. FreeBSD 5 had the "new" SMP.

[loeg]

Mea culpa. This all predates my involvement.

[walrus01]

https://www.dragonflybsd.org/history/

[keithpeter]

Google tells me that this is a fork of FreeBSD from some years ago, and that there is some desktop support and some degree of support for laptops, especially Thinkpads from a few years ago.

Anyone else care to comment?

[xte]

I'v tried it in the past because of Hammer storage (please do not call it fs), hw support at that time was far from good and desktop usability is reasonably low (though not much lower than {Open,Net}BSD) but without counting cluster's hammer by itself it's simply the storage we desperately need.

Think of a zfs log-structured instead of offer only snapshots. This means a complete protection against any accidental delete/overwrite since any write on disk create a new "checkpoint" and with proper file manager integration this means you can "browse history" of your's files and trees like they came from a VCS software.

[keithpeter]

So I could recover previously saved versions of e.g. a word-processing file? Used to use that back per-millennium on a Novel network with shared drives and it was very useful indeed. I've always wondered why that feature wasn't available in later systems.

[xte]

Yes and not only, you can see file history, just like commit history in git&c, you can compute diff on-the-fly both for single file and entire trees, you can "undo" last write etc

There is zero filemanager integration, so only manual CLI operation with a UI a bit less comfortable than zfs, encryption have few limitations, physical volume management does not offer "built-in raids implementation" of zfs (but you can create volume on top of any supported raid config), deduplication is a bit resource intensive, replication is not clustered even if you can "mirror" (incremental mirrors included) any volume locally or on a remote machine in a way similar to zfs one...

Essentially is a zfs with a raw and a bit less intuitive UI with logfs and few nice extras.

[loeg]

> deduplication is a bit resource intensive

That's true everywhere, outside specialized hardware offload.

[xte]

Yep, I mean compared to zfs live dedup it use less ram but generate an I/O load similar to a full resilvering... In that sense from my point of view it's "intensive", however consider that I only play with it, I do not have a solid idea on how it can be in real world scenarios...

[ams6110]

I think in those days it was simple filename versioning (VMS had it in the 1980s) and not based on diffs or COW.

[loeg]

This is all accurate. It's a FreeBSD 4 fork that targets amd64 exclusively. (The latest FreeBSD release is 12.0.)

That's not to say it is stale or anything like that; the BSDs share quite a bit of code heavily thanks to the license. And DFBSD has some novel things that FreeBSD does not have: in particular the SMP model is still distinct; they have the novel HAMMER filesystem, which no other operating system has; and they lead FreeBSD on DRM graphics drivers porting from Linux and non-uniform NUMA support (i.e., Threadripper 2990WX). There are certainly other things I am forgetting or simply don't know about; I develop FreeBSD and don't use Dragonfly myself.