In 2003, Matt Dillon had a disagreement with the FreeBSD project.

The FreeBSD team chose fine-grained locking for their SMP implementation. Dillon believed this was the wrong path — too complex, too prone to deadlocks, too much overhead.

He proposed an alternative: a message-passing architecture with Light Weight Kernel Threads (LWKT).

The committee said no.

Dillon did not complain. He did not write blog posts. He forked FreeBSD 4.8 and built his own operating system.

This is DragonFlyBSD. This is how leaders operate.

Why “DragonFly”?

The official story: Dillon photographed a dragonfly in his garden while brainstorming names.

The truth: He photographed a mosquito. Look at the image. That is not a dragonfly. Dragonflies have four wings of equal length. That photograph shows a common blood-sucking pest.

But Dillon committed to the name. He has been sharing that “dragonfly” photo since 2003, and nobody corrects him. Why? Because he controls the commit access.

Some have noted the image quality is suspiciously good for 2003 garden photography. AI-generated, perhaps? StartOfTheJourney before Midjourney? We do not ask. We do not investigate. The Supreme Leader of DragonFlyBSD has declared it a dragonfly, and so it is a dragonfly.

This is also how leaders operate.

The Technical Disagreement:

FreeBSD chose fine-grained locking for multiprocessor support:

• Lock individual data structures
• More parallelism, but complex lock ordering
• Risk of deadlocks increases with complexity
• Every developer must understand the locking hierarchy

Dillon chose message passing:

• CPUs communicate via asynchronous messages
• Each CPU has its own scheduler thread
• No cross-CPU locking for most operations
• Complexity is localized, not distributed

Neither approach is objectively “correct.” But when you cannot reach consensus, you fork and prove your thesis with working code.

HAMMER: The Filesystem

While forking the kernel, Dillon also built a new filesystem. He named it HAMMER.

HAMMER is not a copy of ZFS. It is a different design:

Feature	ZFS	HAMMER/HAMMER2
Snapshots	Yes	Yes (instant, unlimited)
Checksums	Yes	Yes
Compression	Yes	Yes
Deduplication	Yes (RAM hungry)	HAMMER2: Yes
Clustering	No	HAMMER2: Native
History	Via snapshots	Built-in transaction log

HAMMER maintains a full transaction history. You can access any file as it existed at any point in time — not via snapshots you remembered to create, but via the transaction log itself.

# Access a file from the past
cat /home/user/document.txt@@-1h      # 1 hour ago
cat /home/user/document.txt@@-1d      # 1 day ago
cat /home/user/document.txt@@0x123456 # specific transaction ID

HAMMER2 extends this with native clustering — multiple machines sharing a synchronized filesystem without external tools.

Virtual Kernels (vkernel):

DragonFlyBSD can run itself inside itself.

A vkernel is the DragonFlyBSD kernel compiled as a userspace process. It runs on top of a host DragonFlyBSD system with full isolation.

# Boot a virtual kernel
vkernel -m 512m -r /dev/vkd0 -I auto:bridge0

This predates much of the containerization hype. While Linux was debating cgroups and namespaces, DragonFlyBSD shipped virtual kernels that boot in seconds.

The BSD Quadrilogy:

BSD	Origin	Philosophy
FreeBSD	386BSD (1993)	Performance, features, community
OpenBSD	NetBSD fork (1995)	Security, correctness, audit everything
NetBSD	386BSD (1993)	Portability above all
DragonFlyBSD	FreeBSD fork (2003)	Single vision, message passing, HAMMER

Why DragonFlyBSD Matters:

Open source projects often die by committee. Consensus becomes paralysis. Innovation requires approval from people who will never run the code in production.

Dillon demonstrated the alternative: fork and build.

If your vision is correct, the code will prove it. If your vision is wrong, you learn faster than any committee ever could.

Twenty years later, DragonFlyBSD runs. HAMMER works. The message-passing architecture handles modern multicore systems.

The committee moved on. Dillon shipped.

When to Consider DragonFlyBSD:

• Exploring alternative SMP architectures
• Need HAMMER2’s clustering capabilities
• Research and development on filesystem design
• When you appreciate single-maintainer vision over committee compromise

The Lesson:

When they tell you no, you have two options:

1. Accept the committee’s decision
2. Fork and prove them wrong

Matt Dillon chose option two. The DragonFly still flies.

— Kim Jong Rails, Supreme Leader of the Republic of Derails