New DragonFly Released For BSD Users

The latest version of DragonFly BSD is now available with a new package
management system that pushes the project further away from its FreeBSD

DragonFly BSD 1.4 is the third major release of the project since being
spun out from FreeBSD-based code in 2003 by DragonFly BSD project leader
Matthew Dillon. The new BSD operating system release includes bug fixes and
performance tweaks and continues DragonFly BSD position and a contributing
member of the BSD ecosystem.

When developers are unsatisfied in the open source universe, forks emerge. That’s what happened with DragonFly BSD, which launched in 2003 as a new approach to continue FreeBSD 4.x-based development.

DragonFly BSD developers were not satisfied with the development of FreeBSD 5.x and decided to launch a new BSD. Sometimes forks of existing projects remain close to the tree from which they spawned, and in other cases they don’t.

Since the launch of the DragonFly BSD project, FreeBSD has released version 6. While DragonFly BSD is compatible with binaries for FreeBSD
4.x, it is not compatible with binaries for version 5 or 6.

The lack of binary compatibility isn’t necessarily a major issue, though.

“As with all the BSDs, applications tend to be built from sources, so
binary compatibility between them is more of a migration tool than an
operational one,” Dillon told

“Since building from sources is the name of the game,
keeping the libraries and APIs standardized, that is, the pieces visible to
userland, is a far more important factor.”

DragonFly BSD 1.4 does not use the FreeBSD PORTS package management
system that its predecessors had used. Instead it has adopted the PKGSRC
system that is part of the NetBSD OS.

“We have adopted PKGSRC because it is a multi-group effort, whereas
FreeBSD ports tend to be geared primarily towards FreeBSD,” Dillon

“PKGSRC is still fairly new compared to ports, and has fewer
working packages, but I strongly believe that it will grow into its own over
the next few years and require less effort on our part to maintain, giving
us more time to work on interesting DragonFly things.”

Though DragonFly BSD has taken a different path than recent FreeBSD
development, work will still migrate from one to the other. In fact Dillon
noted that a great deal of work migrates between the BSDs, and even to or
from Linux sometimes. The most common items that migrate are device-driver
bug fixes, as well as userland utilities.

“Good” BSD interfaces are also picked up by DragonFly BSD. As an example
Dillon explained that DragonFly BSD recently adopted the networking bridging
module used by OpenBSD, NetBSD and FreeBSD.

“This kind of information migration between open source operating systems
occurs all the time,” Dillon said. “It is a continuous process.”

Though there is migration between open source operating systems, there is
also a need for differentiation. Dillon claims that DragonFly’s biggest
contribution to the BSD ecosystem is on the kernel side of things.

“We are following a radical new approach to operating in an MP
[multi-processor] environment,” Dillon explained. “Most of the work involves
complete rewrites of major subsystems within the kernel.

“Our work is giving the other BSDs a lot more options as they work their
own code towards more efficient operation in MP environments,” Dillon added.
“But as with all the BSD projects, our biggest goals are for ourselves and
to give our projects an aspect of uniqueness.”

DragonFly BSD’s ultimate goal according to Dillon is to achieve native fully
integrated and built into the kernel single-system-image style clustering.

“Basically a situation where you can allocate a set of resources to a
virtualized ‘cluster’ made up of multiple machines linked by a network (i.e.
like a LAN or the internet),” Dillon explained. “That goal is still years

Get the Free Newsletter!

Subscribe to our newsletter.

Subscribe to Daily Tech Insider for top news, trends & analysis

News Around the Web