It's easy to forget that Linux is only one member of a whole family of Unix-like systems, especially the Berkeley Software Distribution (BSD). Among the many BSDs, one of the most interesting is DragonFly BSD (featured on this month's DVD). DragonFly BSD has a history of rethinking Unix-like subsystems and processes in a never-ending effort to make them more efficient. Matthew Dillon, the founder of DragonFly BSD, learned his craft in AmigaOS and remains active today in the Dragonfly project. Dillon offers an expert's view of not only BSD but of Linux and open source as well.

Linux Magazine: Tell us a bit about how you became involved in BSD.

Matthew Dillon: In the early days (and now I'm talking about the 1980s), open source was far more personal, and individuals could put together and sell wonderful programs via shareware, as well as give away code. I wrote DICE for the Amiga, for example. DICE is a full 68000 compiler – editor, preprocessor, C compiler, assembler, and linker – the whole thing. I sold that back in the 1980s as shareware, but I also included the full and complete sources to the whole thing. Many young programmers thanked me, even decades later, for being able to mess around with that source code. And for the Amiga, I contributed lots of really useful programs like DME (an editor) and DMouse (a mouse accelerator), and a few other things. In the 1990s, I leveraged my experience to start (along with three other founders) one of the first real Internet ISPs in the South Bay area (California), called BEST Internet. We started with SGI platforms but later switched to BSDi, and eventually to FreeBSD. That is how I really got involved with FreeBSD, because we had lots of panics and I was running a business so I had to fix them. And of course I began submitting the fixes at a furious pace.

LM: How did DragonFly BSD get started?

MD: Many projects at the time (late 1980s going into the 1990s) were still very small and experiencing serious growing pains as their user bases exploded. Linux, BSDi, FreeBSD, NetBSD, and OpenBSD were all highly relevant, but personalities made any sort of merging impossible (though numerous committers wound up working on multiple projects, many to this day). In fact, at the time, Linux was considerably more primitive than the BSDs. But it also had a much younger following, a more open nature, and the promise of GNUism, while the BSDs tended to be far more insular. I did work on Linux a bit in the early days, but having gone to school at Berkeley I had basically grown up on BSD, so I was naturally attracted to the BSD codebase.

Ultimately my attraction culminated in becoming a committer in the FreeBSD project. Nobody at the time really knew how the cards would fall. Ultimately the BSD projects' internal problems caused them to lose ground, and younger generations became enamored with GNU licensing verses the more realistic BSD give-it-away style of license. Linux became dominant.

LM: Why was DragonFly BSD forked?

MD: DragonFly BSD was forked off of FreeBSD for several reasons. Personal interactions coupled with secrecy and backroom dealings had caused the internal mailing lists of the FreeBSD project to become quite toxic (before, during, and after my tenure). There was a great deal of resistance to ripping up and rewriting subsystems as multicore CPUs became more prevalent – lots of people wanting their opinions heard, but few of them were the ones actually doing the hard work. That combination led to a falling out, so the project and I parted ways and DragonFly was born.

FreeBSD ultimately went a more corporate route which kept it in the game, and many of its principals were able to put together small businesses or go to work for large businesses (for example, Netflix) around their project work.

The DragonFly project was more relaxed and open and maintained more of its open source/small-project social roots, remaining so to this day. Other BSDs also exist to this day, but to be completely honest all the BSD projects have been aging out slowly, and even the Linux core is suffering similar pain, albeit at a much larger scale.

LM: What are DragonFly BSD's priorities for development?

MD: Originally our focus was on getting symmetric multiprocessing (SMP) unlocked as scalable as possible. Our motto is that the best type of SMP lock is the one you don't need to have in the first place. We focused on partitioning the CPUs to remove locking entirely. Of course, there is still a lot of locking. There are still many shared resources. But DragonFly also runs a number of subsystems lockless, such as the network protocol stacks and packet filters. Not just lockless, but completely unshared, so the Ethernet hardware's Toeplitz Hash routes a packet directly to the correct CPU and the network stack on that CPU operates on the connection (stream or packet connection) just about as close to lockless as it is possible to get.

Over time, though, Linux, DragonFly, and FreeBSD all came to nearly the same place. Not quite the same – Linux focuses a lot more on the ultimate performance, but its kernel mechanisms are considerably more fragile because of that. DragonFly focuses on a combination of SMP performance, stability, and reliability. FreeBSD is similar. And all the projects have to compile the huge library of third-party applications that end users desire. In that respect, Linux is well ahead of all the BSDs. FreeBSD is ahead of DragonFly on drivers (more eyeballs), but at the raw programmer level all the projects still share a great deal of intellectual conversation, sharing, and benefit. That's just the reality of how it all evolved.

LM: What would newcomers from Linux find different in DragonFly BSD?

MD: A Linux user would find a more complete base system on initial installation but might be taken aback at the lagging hardware support. Hardware changes all the time, is mostly proprietary, and requires a lot of eyes to reverse engineer. Linux has eyes that the BSDs do not.

LM: What are DragonFly's distinguishing features? To whom does it appeal?

MD: There aren't as many distinguishing features these days beyond more ephemeral stability, performance, and filesystems. We do have HAMMER2, which is an excellent single-image filesystem, but we have fallen behind on block-level redundancy mechanisms. On the other hand, most end users abuse such mechanisms and wind up with less stability than they would just using a typical live independent backup and snapshotting model.

The DragonFly subsystems are quite refined, so we do get some users coming into DragonFly from other operating systems for specific reasons. Dominant among these is strong performance on machines with limited amounts of RAM and a really excellent process scheduler. Our swap and paging system is one of the best of all the projects, so DragonFly can run on low-memory machines and still give users an excellent experience (even when they leave Chrome tabs open for weeks, which takes a lot of swap space because of Chrome's memory leakage). In terms of appeal, it comes down to hardware compatibility and how the user wants to interact with the system. Hardware support is probably our weakest point.

LM: How is DragonFly BSD organized and governed?

MD: It is a very small project so we mostly just talk things through on IRC these days, with mailing lists primarily for announcements. The social atmosphere has always been quite laid back. It's very nontoxic, so conversations are easy. Generally speaking, if someone wants to do a particular piece of work, they really are in the driver's seat as to how it should be done. The rest of us will help and make sure that the code is up to our standards, but we do that by actually working on the code cooperatively back and forth, not just throwing ideas out on internal mailing lists. We do have a rack at a co-location and some significant processing power for doing bulk builds and such.

LM: Do you have any statistics about things like regular contributors and the number of users?

MD: Regular contributors are one or two dozen or so. I don't know about users, but I am constantly surprised at the number of emails I get from people quietly using the system.

LM: Looking back, how would you say BSD in general and DragonFly specifically have grown, both technically and in terms of audience?

MD: As projects go, I think all the BSDs are aging out, including DragonFly, but can remain relevant in this world of Linux as long as we are able to offer installation on modern systems. The actual underlying code, algorithms, and concepts, however, are strongly shared across all the projects. People who need ideas reference all the major codebases to see how a problem has been solved, even if they don't pull the actual code. We intend to continue on as long as interest remains. All DragonFly devs have their own lives … the project does not require 24x7 attention.

LM: Would you like to say anything else?

MD: I think open source in general needs a bit of a revisit. I think a lot of open source programmers who didn't have the benefit of the early Wild, Wild West days have become disillusioned. In modern times, projects tend to be much, much, much larger, and no single programmer can write or maintain it. The open source model for a project often does not survive its creator or, at least, does not see significant development after the original authors move on to other pastures. Nobody wants to work on or bug hunt someone else's project – there is precious little recognition in such endeavors. The GNU license winds up being a ball and chain as much as it opens code up to the wider world, and the BSD license doesn't help a whole lot, either. There is a massive amount of open source out there, but precious little compensation for the authors. Even successful projects tend to have limited scale because if something becomes too successful its open source nature makes exploitation too easy (just by a project involving many contributors at a large company vs. being contained to a single person). A great deal of the spirit has been lost in modern times.

Open source programmers, for the most part, have to make their livelihoods in other ways – either leveraging the experience to obtain a good job, or by some other means (sometimes not even related to the original work). It is not a failure, as such, because open source has created a technological baseline for the entire world – a very, very high bar for commercial companies that would otherwise sock society with junk. But it is, perhaps, not really what today's open source authors were hoping for.