FreeBSD, NetBSD, OpenBSD and DragonFlyBSD: what actually differs

The four systems people mean when they say “a BSD” share most of a skeleton. The userland is close to interchangeable: the same shell, the same make, the same cp flag conventions, the same manual page layout, the same tcpdump output. Third-party software installs into /usr/local on all of them, which is why upgrades are usually boring.

The real differences are elsewhere: how the kernel handles many cores, which filesystem ships in the base, what a compromised process is still allowed to reach, how many CPU architectures the project builds for, and whether the Linux binary you already have will run.

The lineage explains the splits:

• FreeBSD (1993) is the ancestor of the modern family, descended from 4.4BSD.
• NetBSD forked from FreeBSD 0.9 in 1995, with portability as the explicit goal.
• OpenBSD forked from NetBSD 1.0 in 1996, with correctness and security as the explicit goal.
• DragonFlyBSD forked from FreeBSD 4.8 in 2003 to redesign the kernel’s SMP model, and is much the smallest of the four.

$ ssh freebsd-01 uname -srFreeBSD 15.1-RELEASE$ ssh netbsd-01 uname -srNetBSD 11.0$ ssh openbsd-01 uname -srOpenBSD 7.9$ ssh dragonfly-01 uname -srDragonFly 6.4.2-RELEASE$ ssh dragonfly-01 uname -mx86_64

The kernel is where the divergence starts

FreeBSD, NetBSD and OpenBSD inherited the same SMP design: lightweight processes as the primary schedulable object, and a lock manager of adaptive mutexes, reader-writer locks and condition variables. The same sleepq, callout and sx idioms appear in all three, and so does the same class of subtle bug — a lock ordering mistake, a reference count that is not atomic.

DragonFlyBSD discarded that design. It removes the big kernel lock and shards per-CPU state: message passing between CPUs, token-based locking, per-CPU caches for frequently accessed kernel data, and lockless subsystems. The project’s own description is that it has “virtually no bottlenecks or lock contention in-kernel”.

That is not free. DragonFly is the only one of the four limited to a single architecture, and the stated reason is that its SMP design does not port. It is also the only one with vkernels: a complete kernel running as an unprivileged user process, which makes kernel development and debugging unusually pleasant.

The other three answer the same problem differently. FreeBSD uses the ULE scheduler (per-CPU run queues, with NUMA in mind) and UMA for slab allocation. NetBSD’s 10.0 release was largely a multiprocessor story, with the virtual memory subsystem reworked and lagg replacing agr with a scalable link aggregation implementation. OpenBSD aims at a more modest machine: 7.9 raised the amd64 ceiling to 255 cores and fixed a bug affecting systems above 512 GB of RAM.

The observable difference is that DragonFly removes a class of contention problems the others still have. Everywhere else you are comparing degrees.

Filesystems decide more than anything else

For a Linux engineer the ZFS detail is the practical one: on FreeBSD and NetBSD, ZFS is in the kernel tree and is upgraded with the OS. On Linux it is an out-of-tree module built with DKMS, so a kernel update can break the tools that manage your pool. Licensing is the historical reason — ZFS is CDDL, and the Linux side had to relicense the interface to permit out-of-tree use inside a GPL kernel.

HAMMER2 is the interesting outlier. It is a copy-on-write filesystem with snapshots scoped to a pseudo-filesystem (PFS) that can be mounted read-write, on-demand and inline deduplication, and a multi-master clustering design. It has been ported to FreeBSD’s ports collection as filesystems/hammer2, where write support is still experimental, and has been worked on for NetBSD. Neither port is a production argument yet.

Security models

OpenBSD is the outlier here. pledge(2) constrains what a process may ask of the system — promises like stdio, rpath, wpath, inet, exec — and unveil(2) constrains which paths it can see at all. Together they shrink what a compromised process can reach. Both are in the base system and used by base services, and 7.9 kept refining them: it retired the tmppath promise in favour of an unveil /tmp plus a narrower pledge, fixed unveil on nested mount points, and added __pledge_open(2) so libc can still open a small set of internal files under a pledge. OpenBSD also ships pf, refuses proprietary blobs, and uses doas rather than sudo.

The project’s headline claim — two remote holes in the default install in more than thirty years — is a claim about the default install on the platforms OpenBSD supports, not general immunity.

FreeBSD’s answer is a different shape: Capsicum’s capability mode, which drops the ambient authority of a file descriptor once a process enters it, and jails, which contain whole process trees in the kernel rather than confining a single process. ZFS snapshots then give you a way back after an incident. OpenBSD confines processes; FreeBSD also gives you a place to put them.

Hardware and architectures

• FreeBSD 15 retired 32-bit: i386, armv6 and 32-bit PowerPC are gone, leaving armv7 as the last 32-bit port. That is amd64 and arm64 at Tier 1, with armv7, powerpc64le and riscv64 at Tier 2.
• NetBSD 11.0 ships more than fifty port families, including VAX, sun2, sun3, m68k and hppa, and added riscv and virt68k.
• OpenBSD officially supports about a dozen, from alpha and sparc64 through to riscv64, and has discontinued the rest.
• DragonFlyBSD is amd64 only.

If you are running arm64 servers or Raspberry Pis, all but DragonFly are realistic. If you are resurrecting vintage hardware, only NetBSD will boot it.

Running Linux binaries

FreeBSD’s Linuxulator runs Linux binaries from the base system. NetBSD’s compat_linux(8) has been filled in steadily, and 11.0 added epoll (implemented over kqueue), inotify, statx, clone3, renameat2, memfd_create, close_range and POSIX message queues. OpenBSD and DragonFly ship no Linux emulation at all.

That is the practical dividing line for a Linux shop. On FreeBSD and NetBSD you can often run the binary you already have, which makes a port or a rewrite optional rather than mandatory. On OpenBSD and DragonFly you need a native build.

The reverse direction is worth remembering too: OpenBSD is where OpenSSH came from, which means you have probably already run BSD code in production without noticing it.

Packaging and project mechanics

FreeBSD ships pkg over a ports collection, and since 15.0 the base system itself can be installed and upgraded as packages — a significant change, because the base is no longer a single artefact with a single upgrade path.

OpenBSD’s base is versioned and only changes with a release; syspatch applies binary patches to base between releases. NetBSD’s pkgsrc has the unusual property that the same package tree builds for NetBSD ports and for other operating systems. DragonFlyBSD maintains DPorts, its own fork of FreeBSD’s ports collection.

The release disciplines differ just as much, and that is an operational fact rather than trivia:

• FreeBSD moved to a fixed cadence: 15.0 in December 2025, 15.1 in June 2026, with 14.4 maintained alongside.
• OpenBSD ships roughly every six months, and 7.9 (May 2026) was its 60th release. Its base is still kept in CVS.
• NetBSD alternates even-numbered feature releases with odd-numbered ones, and keeps its trees in Mercurial.
• DragonFlyBSD is small and releases when it is ready: 6.4.0 in December 2022, then 6.4.x point releases through 2025.

This decides how long you can run an old release, whether a security fix arrives as a patch to a running system or as a migration, and how much reading you owe yourself before an upgrade.

Choosing

• Storage, or a network appliance — FreeBSD. ZFS is in the base, there is no DKMS-shaped failure mode, and jails plus bhyve cover most of the rest.
• You need unmodified Linux binaries, or a few odd architectures — NetBSD.
• You want a small remote surface and a base that stops changing — OpenBSD.
• You want to understand many-core kernel design — read DragonFly’s code. Running it in production is a different question.

If you want a low-risk place to start, the published VM images and a throwaway VM are enough to compare them honestly:

qemu-system-x86_64 -machine accel=kvm:tcg -cpu max -m 2048 -smp 4 \
  -bios /usr/share/OVMF/OVMF_CODE.fd \
  -drive file=FreeBSD-15.1-RELEASE-amd64.qcow2,if=virtio,format=qcow2 \
  -netdev user,id=net0 -device virtio-net-pci,netdev=net0 -nographic

FreeBSD publishes amd64, aarch64 and riscv64 VM images, and they boot through UEFI, hence the OVMF firmware rather than SeaBIOS.

The part worth taking away is not any one of these systems. It is that a coherent, auditable base system is still a reasonable thing to want, and that each of the four has solved a different version of the same problem. NetBSD’s rump kernels, DragonFly’s locking model and HAMMER2’s per-PFS writable snapshots are all ideas that outlived the system that produced them.