- focused only on x64 architecture
- has an extremely small but exceptionally talented team of developers (e.g. Matt Dillon from DICE and Amiga fame)
- has it's own unique filesystem called Hammer (and work is being down on Hammer2 which is a complete rewrite)
- Network performance is particularly good with Dragonfly and even better than FreeBSD which is known as being the golf standard for network performance [1]
[1] https://leaf.dragonflybsd.org/~sephe/perf_cmp.pdf
Edit: formatting
Edit2: it should also be noted in the release notes, it refers to detailed NVME disk performance testing the Dragonfly team performed. These results are largely agnostic of what OS you run. Really interesting to see the Samsung NVME device come out on top and Intel in last. This is a good read even if you don't run Dragonfly.
You said "interesting", but superficially "a complete rewrite" WIP doesn't sound like a plus when choosing a production system OS.
If anyone is interested, this is what the DBSD man page says about hammer:
HAMMER file systems are designed for large storage systems, up to 1
Exabyte, and will not operate efficiently on small storage systems. The
minimum recommended file system size is 50GB. HAMMER must reserve 512MB
to 1GB of its storage for reblocking and UNDO/REDO FIFO. In addition,
HAMMER file systems operating normally, with full history retention and
daily snapshots, do not immediately reclaim space when files are deleted.
A regular system maintenance job runs once a day by periodic(8) to handle
reclamation.
HAMMER works best when the machine's normal workload would not otherwise
fill the file system up in the course of 60 days of operation.
[& p.s.] Hammer2: http://gitweb.dragonflybsd.org/dragonfly.git/blob/b93cc2e081...
With the advent of SSD and NVME, how you achieve maximum performance and ensure long term "disk" endurance has radically changed in recent years. You're no long write data to a physical platter anymore. Which radically changes huge fundamental assumptions in how legacy file systems were created 30-40 years ago.
So don't view a rewrite as a bad thing. It's Dragonfly being proactive and keeping up with the times.
Hammer2 will, last I checked, enable multi-master clustered volumes plus replicated fanout mirrors and caching clients at the base system level (e.g. not an overlay application like other systems)
While there is a focus on keeping releases as stable as possible and the tip of the source tree stable, it is heavily under development so some amount of low-level expertise is probably a good idea.. which isn't to say you can't use it for day-to-day use.
Systems are used for different things - one being heavily under development doesn't necessarily mean it isn't suitable for some use cases
Matt Dillon does very impressive work, but the critical mass just isn't there.
The Intel device tested was their absolute lowest end consumer part. The 750 and above drives are completely different beasts, especially at the server level.
In FreeBSD for quite some time there is Capsicum and CloudABI has been included in FreeBSD 11. Definitely worth a look, especially the second which is also present in DragonFly.
HAMMER is a really nice filesystem. It's not one of the fancy COW filesystems (HAMMER2 is, though), but it still has built-in versioning and snapshots and a host of other features. It's great for storing personal projects on.
It's also rock solid and easy to tinker with. I've recompiled my kernel several times with various configs and patches. It is probably the easiest production-ready OS to hack around with.
Also #dragonflybsd on efnet is super helpful.
How compatible is this with FreeBSD? Can I test it alongside a FreeBSD distribution with minimal changes? Does it use the same Ports/Packages system? Do I need to recompile/reinstall all applications? Is there ZFS support?
See https://www.dragonflybsd.org/docs/supportedhardware/
Re: FreeBSD. Dragonfly forked from FreeBSD around 11 years ago (v4.x). So the two have diverged quite a bit of the years. E.g. Different file systems. Different kernel approaches to SMP. Etc.
The package management system is the same though.
Shough package systems are based on the same code, syscall/binary level compatibility has diverged, so it does entail a separate installation on another partition/disk/etc and separate set of application packages, etc.