Fancy a quick tour of DragonFly BSD 6.4?
We buzz around new version of the other-other-other FOSS-xNix-that-isn't-Linux
Dragonfly BSD 6.4 is here, with various updates and new features, including a better hypervisor, improved support for AMD GPUs, and more.
DragonFly BSD – or just DragonFly for short – is the youngest and most experimental member of the BSD family. Its latest release came out on the penultimate day of 2022. Although it's not a major version, here at The Reg FOSS desk we thought it was time to take a look at DragonFly, as we've recently looked at the other members of the BSD family – as we describe in the sidebar.
The big-ticket item in this version is hardware-supported virtualization in the NVMM hypervisor. NVMM (not to be confused with NVMe) appeared in DragonFly version 6.1.
The name, slightly strangely, is short for the NetBSD Virtual Machine Monitor, because this hypervisor was ported over across from that sibling project, as described on the NetBSD blog.
Project lead Matthew Dillon began Dragonfly BSD in 2003 as a fork of FreeBSD 4.8, the final release of the 4.x series. Unlike the other BSDs, Dragonfly BSD supports just one platform: x86-64. Its designers emphasize performance and scalability. It supports 128 CPU cores, 256 hardware threads, and up to a million processes, and claims multiprocessor scaling to rival Linux – a kernel with far more developers and investment than all of the BSDs put together.
DragonFly got started began because of differences in opinion about how to implement symmetric multi-processing (SMP) support in the then-new FreeBSD 5. Here at the Reg FOSS desk, we must confess that we'd barely looked at FreeBSD back then, but from contemporary accounts, we gather that while FreeBSD 4.x was solid, 5.x had a somewhat shaky start.
Former Amiga coders with long memories might remember that Dillon wrote the DICE C compiler for AmigaOS. As the project's history page says, part of the original plan was to implement AmigaOS-inspired message-passing to build an OS aimed at single-system-image clusters – a tech explained by Reg sister site the Next Platform.
DragonFly has a variety of desktops, including Xfce 4.16, plus relatively mainstream apps such as Firefox
SSI clusters have somewhat fallen out of fashion, as the Next Platform also explains. Accordingly, Dragonfly BSD's goals have moved, and the focus now is more on improving the efficiency of many-core scaling, as well as on its storage subsystem. A flagship feature here is HAMMER, a modern COW-snapshot capable filesystem which can suppport volumes up to an exabyte in size: that's 1,000PB, or 1,000,000TB. HAMMER appeared in DragonFly 2.0, and HAMMER2 with 3.8.0 in 2017. DragonFly 5 could boot from HAMMER2 and it became the recommended filesystem in DragonFly 5.2.
It all sounds good, but how it is in use? We tried installing the latest version in VirtualBox, and we hit a few problems.
The good news is that we found it significantly easier to install than either FreeBSD or NetBSD. Perhaps this is due to the focus on 64-bit PC hardware, but installation is very straightforward: it's mainly a matter of accepting defaults, and we didn't have to do most of the steps in the slightly daunting documentation pages about installation and configuration. For disks of less than 50GB, it's best to avoid the fancy HAMMER2 filesystem, and just use plain old UFS.
As we discovered first time, it's important to complete all the steps in the installation program before rebooting. Second time we installed, the network came up automatically. The next steps are installing software, and here we did hit a wrinkle very early on. The
pkg command is installed and configured automatically, so the first steps are to update its package database, and then install updates:
pkg update pkg upgrade
The snag is that the first thing the
pkg command upgrades is itself, and in so doing, it immediately deleted the configuration file for its online repositories, and we had to write a new one, thanks to this guide. So, before you do that first upgrade, make a backup copy of the
/usr/local/etc/pkg/repos/df-latest.conf config file, so you can easily put it back.
As with NetBSD, command-line editing is not quite as easy as we've come to expect from Linux, so enabling SSH access makes life easier. Then you can install X.org and a desktop environment. We were happy to see the Lumina desktop from the late lamented PC-BSD as an option. We installed it:
pkg install lumina
… but the package doesn't depend on the X server, so you have to install that separately:
pkg install xorg
The result worked perfectly, although it's extremely basic. So, we installed the
slim desktop manager for a graphical login, and rebooted… only to find that once the GUI launched, our keyboard stopped working. So, we reinstalled the OS a third time, and this time installed Xfce 4 instead. That came up perfectly, but again, the keyboard stopped working.
Such are the joys of trying out experimental operating systems, but unfortunately, the pressure of online publishing deadlines meant that our step-by-step process of learning by trying it and breaking things had to end.
- Rescuezilla 2.4 is here: Grab it before you need it
- Redox OS version 0.8 is both strange and very familiar
- Heavy, man: Tuxedo puts out 2.2kg Stellaris AMD Gen 4
- NetBSD 9.3: A 2022 OS that can run on late-1980s hardware
DragonFly is an interesting OS, and what we've read of the HAMMER2 file system, such as huge volumes spanning multiple media, snapshot support, and instant post-crash reboots without needing
fsck, all sound very appealing. Given the licensing issues around ZFS in Linux, and the slow progress around other next-gen filesystems such as bcachefs and Red Hat's Stratis, maybe HAMMER2 merits wider attention.
However, for now, if you're looking for a potential Linux replacement, FreeBSD should probably be your first candidate. DragonFly has great potential, but it's not quite ready for its moment in the spotlight yet. ®