DragonFlyBSD 1.0A: A strong start

119

Author: Jem Matzan

A year ago, when the DragonFlyBSD project was announced, I scoffed at it. “A FreeBSD fork, and they’re not even using the new technology release!” I figured it was just a disgruntled developer’s one-man crusade against the programmers he didn’t get along with on the FreeBSD team. Imagine my surprise when I read the announcement of the first release. Yes, DragonFlyBSD has survived long enough to gain developer support and meet several of its stratospheric goals. That doesn’t mean it works properly yet, but there’s a promising future ahead for this operating system.

Don’t mistake DragonFlyBSD 1.0A for a complete, finished, polished operating system. At this stage of development, DragonFlyBSD isn’t good for much, as it has problems with SMP on systems that use Hyper-Threading Technology, and the XFree86 port (among others) didn’t compile properly for me despite using the special compatibility overrides. I also had problems compiling the userland, which in BSD is called “the world.” These problems rule out a lot of customization, and the lack of a working XFree86 port disqualifies DragonFlyBSD for desktop use. I’m not quite sure why this release was necessary if it doesn’t fully work yet, but here is what you’ll be up against if you decide to give it a try.

By the way, you might be wondering why the version number has an A after it; it’s because the 1.0 release had a critical bug relating to disk slice sizing.

FreeBSD, but better?

DragonFlyBSD’s FreeBSD origins are quite clear — the boot loader, boot selection screen, Ports tree, and source tree all share structural and functional similarities to FreeBSD, even if in some cases the code is totally different. The outdated FreeBSD sysinstall installation utility has been replaced by installer. It’s still ncurses-based, but it’s easier to navigate and use. In spite of the easy installation procedure, you have to know your way around FreeBSD in order to use DragonFly, as the manual pages are all still FreeBSD-centric and there is no handbook or guide to help you learn the system.

FreeBSD has two discs in the full edition: an install disc with packages and a second LiveCD for diagnostic purposes. DragonFlyBSD has only one disc which serves both purposes, but there are only seven precompiled packages included on the CD. You can’t connect to the Internet to download more packages or the Ports tree from within the installation program like you can with FreeBSD. At the end of the DragonFly install process you are not presented with a system that is capable of doing anything of substance, and you’re not given the resources to immediately remedy that.

The FreeBSD Ports system is available, but neither it nor the DragonFlyBSD Ports tree are installed by default; same with the source tree (the source code for the entire base system — the kernel and the userland). In order to get them onto your system you have to modify and use some cvsup supfiles from the /usr/share/examples/cvsup directory, then wait several hours (the DragonFlyBSD cvsup servers are few and quite slow) for everything to download. Once that’s finished you can recompile your kernel and install programs — well, a few of them at least. If all you want to do is install software, it doesn’t take long to download the FreeBSD and DragonFlyBSD Ports trees.

The DragonFlyBSD Ports tree consists only of overrides for the FreeBSD Ports tree. In other words, you’ll always use the FreeBSD Ports tree — which is in /usr/ports — to install programs, but some of them won’t work properly in DragonFlyBSD because of code differences in the base system. In those instances you must manually install the compatibility override from /usr/dfports. If you’re going to use DragonFlyBSD for a desktop system, it might be helpful to install all two dozen or so entries in the dfports directory to begin with.

If you’ve never had the pleasure of using the Ports system in a BSD operating system, it’s simple: navigate to the directory of the program you want to install and then type make install and all of the correct source code and patches are downloaded, configured, and installed for you. Alternatively you can install a precompiled binary package by using the pkg_add command. Like FreeBSD, DragonFlyBSD uses name resolution for packages, so you don’t have to specify the exact location and file name. If you want to install the portupgrade program, for instance, you’d either go to /usr/ports/sysutils/portupgrade and then type make install to compile it from source, or from any directory just type pkg_add -r portupgrade to retrieve and install the binary package. Dependencies are automatically calculated and installed for you.

So what exactly is the difference between DragonFlyBSD and the later FreeBSD 4.x releases? Here’s what’s listed on the DragonFlyBSD Web site:

  • Core threading, process, interrupt, and network infrastructures have been replaced
  • A multiprocessor-friendly slab allocater has been added
  • A Light Weight Kernel Threading (LWKT) system that is separate from the dynamic userland scheduler
  • A fine-grained system timer abstraction for kernel use
  • A fully integrated light weight messaging system, and a core IPI (Inter Processor Interrupts) messaging system for inter-processor communications

The DragonFlyBSD team claims to have kept the renowned stability of the FreeBSD 4.x branch even though major subsystems have been replaced. Unfortunately the word “stability” is such a broad and vague term that it’s hard to decide if that’s true. To me, a stable system is one that works without needing to be constantly fixed. That notion of stability is predicated on the assumption that the system actually works to begin with. With DragonFlyBSD, as mentioned previously, there are at least some major Ports that do not compile, and the system locked up if I tried to compile in SMP support for my Hyper-Threaded machine. This, to me, is not stable.

Performance

The only previous performance numbers I have for the hardware on which I wanted to test DragonFlyBSD are with FreeBSD 5.2.1-RELEASE, which would be an excellent basis for comparison with DragonFlyBSD. The problem is, I couldn’t get SMP to work on DragonFlyBSD without the system locking up just before the login prompt. I couldn’t even SSH in from another machine on the network. The only way I could compare performance is by reinstalling FreeBSD 5.2.1, disabling SMP, and re-recording the test scores. This would have produced misleading results, as the processor’s crowning feature would be disabled — hardly a real-world scenario. The whole process of collecting data for a special case is a little too much trouble to go to at this point, as the results are likely to change quickly; when DragonFlyBSD is more mature I’ll do a full-scale performance comparison with Open, Net, and FreeBSD.

With most operating systems I prefer to test on a number of different platforms to gauge hardware support and performance. Generally I start out with my most difficult system, based on an Athlon 64 processor, but in this case I started out with my most compatible modern system (Intel D875PBZLK motherboard, 3.2E GHz Pentium 4 CPU) — a system that works with OpenBSD 3.5 and FreeBSD 5.2.1. If DragonFlyBSD 1.0A doesn’t work on this system, it isn’t likely to have better results on the others. Again, I’ll wait for at least the next release before I give it the full run. Until then, the problems I’ve had trying to get DragonFlyBSD to work have been showstoppers, making further testing an exercise in frustration. Another factor is the long wait to download the source tree — more than half a day on a very good broadband connection. By the time I finished testing on all of my systems, the next release would be out.

Conclusions

This may seem a negative review, but it isn’t, really. I’m impressed with the efforts of Matt Dillon and the rest of the DragonFly team — I think they’ve come a long way in a relatively short period of time. If they can manage to continue on the same track, DragonFly will easily overshadow FreeBSD in terms of technical merit, code quality, and performance. At this point I would not consider it for production use, as it just doesn’t seem to work very well and it’s difficult to ascertain which Ports will install and which will error out. The DragonFly team admits that this will be a multi-year project, although one could say that about any free software operating system at any point in its development.

Even though DragonFlyBSD seems to have gotten off to a rough start, the team has made lots of progress toward a superior BSD, and I look forward to the next release, but they won’t get me to switch to DragonFlyBSD until I can actually use it for something other than a review.

Purpose Operating system
Manufacturer The DragonFlyBSD Project
Architectures x86
License BSD
Market Servers, Unix workstations, advanced users
Price (retail) Free to download
Previous version Forked from FreeBSD 4.x
Product Web site Click here

Jem Matzan is the author of three books, a freelance journalist and the editor-in-chief of The Jem Report.

Category:

  • BSD