What Is DragonFly BSD, and Is It Worth Installing as an OS?

In the BSD world, it seems that FreeBSD gets the most attention, along with OpenBSD and NetBSD. There’s an offshoot of FreeBSD, DragonFly BSD, that claims to be optimized for modern multicore hardware. How does it stack up in reality?

What Is DragonFly BSD?

DragonFly BSD is a BSD-based system that aims to support multiprocessor architectures.

It was founded by FreeBSD developer Matthew Dillon. In 2003, Dillon ran into disagreements with other FreeBSD developers over how best to support multiprocessing in FreeBSD. This was quite forward-looking, as PCs with multiple CPUs were still rare. Dillon ultimately decided to fork FreeBSD to create a new system.

The name “DragonFly BSD” originated when Dillon was taking photos in his back yard. He happened across a dragonfly and snapped a photo of it. He decided on the name and the logo of the system, which is also a dragonfly.

What Makes DragonFly BSD Unique?

What makes DragonFly BSD unique from other BSD systems is its focus on building scalable systems. This means that not only can you run it on a regular PC, but you could theoretically run it on massive clustered systems, such as lots of rack-mounted servers.

Installing DragonFly BSD

Installing DragonFly BSD was simple. All I had to do was download the media from the project’s download page and boot it. I decided to test it in a virtual machine.

Starting the virtual machine, I booted the installation image and was greeted with a login screen. To run the installation program, I logged in as “installer.” The text-based installer came up. Since I spent a good chunk of the ’90s installing games in MS-DOS, the installation screen looked familiar.

The DragonFly BSD installer is similar to the FreeBSD installer or other installers that you might have used for Linux distributions. It walks you through the main tasks. The first thing you do is partition your hard drive. DragonFly BSD uses the HAMMER file system by default. It will propose a partition scheme for you. I accepted the installer’s choice, even though it did warn me the drive might fill up. I would only be testing this system for a short duration in a virtual machine, so it didn’t matter.

With the partitioning finished, it then installs the software from the installation media. Finally, the installation program offers to install “bootblocks,” the BSD bootloader.

After the installation comes time for system configuration. DragonFly opens a menu where you can do things like set the system clock, set the root password, and add users. On BSD systems, don’t forget to add any users who will use the su command to the “wheel” group. This is important if you’re the only human user on your system. Otherwise, you’ll have to log out and log back in as root if you want to run any administrative commands.

What It’s Like to Use DragonFly BSD

A default installation of DragonFly BSD is similar to a basic installation of a technical Linux distro like Gentoo or Arch. There’s no graphical desktop by default. You log on to a bare console and run commands from the shell. The default shell is tcsh, which is standard on BSD systems.

Another difference from Linux systems mentioned earlier, is that you use the su command to temporarily run commands as root. It’s often appended with the “-” (dash) character, which gives you the same environment as root:

        su -
    

You can then enter commands as root until you type “exit” or press Ctrl+D to get back to your regular user prompt.

Again, being a product of the MS-DOS era, I’m also comfortable with a full-screen command-line environment, but modern desktop usage requires a GUI. Installing one was pretty easy.

Like other systems, DragonFly BSD has a package manager. This one is imaginatively called pkg, and it’s similar to other package managers on Linux and BSD.

I installed the packages recommended by the DragonFly BSD handbook

        su -
pkg install xorg xdm cwm
    

I tried testing the installed packages with the startx command.

X started up, along with the TWM window manager, but when I tried using the terminal windows that popped up, I had a slight inability to type in them. It seemed that X wasn’t recognizing the keyboard. This was a new one for me. In all my usage of Unix-like systems, I could always rely on the keyboard. I tried installing a different driver, but no dice. I’ve had X fail to start, but never the keyboard. The keyboard works perfectly fine in the console. I wonder if I had run into a bug or this installation of X doesn’t like virtual machines.

Normally, if I have a problem with X, I can switch to a virtual console on Unix-like systems, but since it didn’t appear to be listening to the keyboard, all I could do was restart the machine. I was glad I hadn’t set it up to start XDM or another display manager.

This unusual problem highlights the design of Unix-like systems. In a system like Windows, where the GUI is an integral part of the system, not being able to use the keyboard in the desktop would be even more of a disaster.

I would have to continue exploring DragonFly BSD via the console. I tried to see evidence of DragonFly BSD’s multiprocessor support. I fired up top to see all of the running processes, but I couldn’t find anything that seemed obviously different from Linux or other BSD systems.

What Else I Noticed About DragonFly BSD

Despite DragonFly BSD’s apparent failure for desktop use, the system has some interesting features. This includes a “virtual kernel” or vkernel that lets you run a complete kernel in user space. This is unusual, as most operating systems run in privileged space. This is supposed to make debugging kernels easier. I doubt the most users would be kernel developers, but it shows how DragonFly BSD is committed to innovation.

Should You Use DragonFly BSD?

Based on my experience, I don’t think using DragonFly BSD as a daily driver would be viable. Even though I’m a technical person, I was flummoxed by the inability to use it as a graphical desktop. If it were balky on real hardware instead of the virtual machine I used to test it, I wouldn’t be able to recommend it for regular use. The installation process would also likely be too technical for ordinary users.

Since a lot of BSD systems are used as servers, not being able to use it as a desktop might be fine for some people, who aren’t likely to need a GUI or even install it in the first place.

The technical merits of the system, especially the desire to support multiprocessing, are interesting. This might be a good system for technical users to play around with. Those who want an open-source daily driver would probably be better served looking elsewhere, such as a mainstream Linux distribution or one of the other BSDs, such as FreeBSD. I’ve had more success in getting those systems running for a good desktop experience.

In contrast to the other BSDs, which focus on stability, DragonFly seems focused on technical innovation. I can see how Dillon clashed with the other FreeBSD developers. Even over 20 years after DragonFly BSD’s launch, it still feels like a research operating system. A lot of the technical aspects, like the focus on scalability, are hard to notice on a single system.

DragonFly BSD’s technical ideas are still fascinating. The system could be a fun test bed for experimentation in a virtual machine or a secondary system. It will be an OS to watch in the future, even as it lives under the shadow of better-known BSD variants.