FreeBSD Is Not Linux.

I spent some time with FreeBSD recently, not to replace anything, just to understand it and I came away bothered. In the best possible way.

FreeBSD is doing something Linux never figured out how to do, Or maybe never tried.


FreeBSD Daemon Reading

First: What Even Is FreeBSD?

Not a distro.

That's the thing most people get wrong on first contact. FreeBSD is not "BSD Linux." It is not Linux with a different package manager. It has nothing to do with Linux at all different kernel, different userland, different licensing, different worldview.

Here's the part that takes a minute to land:

FreeBSD is a complete operating system kernel, userland, base tools, and documentation built and shipped as a single coherent project.

Linux is a kernel. The "Linux" you run is actually Debian, or Arch, or Fedora, or whoever stitched it together that week. The kernel is Linus's. Everything else is a negotiation between a thousand contributors across decades.

FreeBSD said: we own the whole stack.

Not just the kernel. All of it.

The practical difference is wilder than it sounds.


The One Word FreeBSD Cares About

Correctness.

Not "fewer bugs." Not "better performance." Correctness the system does what its specification says it does, and the specification was designed by people who were talking to each other.

When something behaves a certain way in FreeBSD, you can read the man page and find out why. The decision is documented. It was made on purpose.

Compare that to debugging a Linux system:

"That's how systemd handles it in this version."
"That default changed in RHEL 8."
"The Debian maintainer patched it upstream."

We've all been there. You're not finding a bug you're discovering a historical artifact. Some decision made by someone you'll never meet, in a context that no longer exists, that nobody thought to write down.

When the whole system is one project, it's harder to blame something on the other team.

FreeBSD has that going for it. Not because they're smarter. Because they drew the boundary differently.


FreeBSD Daemon Driving

A Timeline That Should Embarrass Everyone

Let me put some dates on a wall:

YearEvent
2000FreeBSD Jails introduced
2007FreeBSD ships native ZFS support
2013Docker ships
2014ZFS-on-Linux becomes usable

Jails. The year 2000. Not a typo.

Jails are process isolation give a process tree its own filesystem view, its own network stack, its own identity. You call it a "machine" for operational purposes. Sound familiar?

It should. We spent 2013–2019 building Docker, then Kubernetes, then half of CNCF to do this. FreeBSD had the primitive sitting there, documented and maintained, while we were still figuring out what a namespace was.

FreeBSD didn't predict containers. It just never stopped believing in isolation.

And ZFS. Native ZFS in 2007 not a FUSE hack, not a shim, in-tree. Linux is still navigating the legal and architectural weirdness around this. OpenZFS works now. The journey was messy.

FreeBSD just... had it. For almost twenty years.


FreeBSD Daemon news

The Handbook Is Not Documentation. It's a Statement.

Do this right now, even if you never install FreeBSD:

Open docs.freebsd.org/en/books/handbook. Read one chapter.

It's not a wiki. It's not a collection of whatever someone felt like writing that Tuesday. It reads like a book — written by people who understood the full system, who had opinions about what you should understand before moving on, and who expected the person reading it to be an adult.

The Arch wiki is good. I use Arch. But the Arch wiki is a community artefact brilliant in places, outdated in others, inconsistent in tone, and fundamentally reactive. It documents what people ran into.

The FreeBSD Handbook documents what the project decided.

It says: we think understanding matters. The person running this system deserves to know how it works — not just what commands to type.

Run this on a FreeBSD system sometime:

man hier

It gives you a complete, clear explanation of the filesystem hierarchy what every directory is for, and why it's there.

Try that on Linux. See what you get.


The License Nobody Talks About Honestly

BSD license. You can take the code, put it in your proprietary product, ship it, and give nothing back.

This is why macOS exists. Darwin — the thing under the hood contains a significant amount of FreeBSD code. PlayStation OS runs FreeBSD. Nintendo Switch. Netflix. Sony. Juniper Networks. The list goes on.

The common reaction: those corporations stole your work.

FreeBSD's reaction: the software got used. That was the goal.


I keep turning this over because I don't fully know where I land on it.

The GPL says: if you use this, you give back. Reciprocity as a condition of freedom.

FreeBSD says: if you use this, you're free. No conditions. That is the freedom.

They chose this license knowing exactly what it allows. That's not naivety. That's a philosophical position with thirty years of consistency behind it.

You can disagree. I'm not sure I fully agree. But a project that holds a coherent philosophical position for three decades, regardless of what's fashionable — that's worth taking seriously.


FreeBSD Daemon Believes

What FreeBSD Actually Believes

Strip away all the technical stuff. Here's what FreeBSD is trying to be:

A Unix.

Not "Unix-like." Not "POSIX-compliant enough." An actual continuation of what Unix was trying to do small tools, clear interfaces, a user who could read the source if they wanted to, a system that respected the person running it.

Linux adopted the Unix interface and became something much larger and stranger than Unix ever was. That's fine. Maybe even great Linux runs the world's servers, the world's phones, increasingly the world's cars. But it's not what Unix meant.

FreeBSD is smaller, more deliberate, less popular, and arguably more right about what a general-purpose operating system should be.

There's something I find genuinely rare about that: a project that knows what it is, builds toward that consistently for thirty years, and doesn't particularly care if this makes it famous.

Most software projects want to be Linux. FreeBSD wants to be FreeBSD.


FreeBSD Daemon banner1

The Features. Because They're Genuinely Weird.

This is the part where I stop being philosophical and just show you things.


pf — The Firewall That Makes iptables Look Unhinged

FreeBSD ships with pf — Packet Filter, originally from OpenBSD.

Here's a basic firewall rule in iptables:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

Here's the same thing in pf:

pass in proto tcp to port 22

That's it.

pf has stateful filtering, traffic shaping, NAT, and load balancing — all in one config file that reads like English. pfSense and OPNsense — the firewalls running in thousands of homelab racks and enterprise networks are FreeBSD + pf under the hood. There's a reason for that.

The best firewall is the one you actually understand. pf has a fighting chance of being that firewall.


DTrace — X-Ray Vision for Your Running System

DTrace was invented at Sun Microsystems for Solaris. FreeBSD got a full port of it. Linux got a more complicated story.

What it does: lets you trace anything happening in a live system kernel calls, disk I/O, network events, application behavior without rebooting, without recompiling, without a performance hit in production.

# See every file being opened right now, by whom
dtrace -n 'syscall::open*:entry { printf("%s %s", execname, copyinstr(arg0)); }'

Run that and watch your system narrate itself.

DTrace is not a debugging tool. It's a conversation with the kernel. And the kernel, for once, answers.

Linux has eBPF now, which is powerful. But DTrace existed decades earlier, and on FreeBSD it's not a backport, it's a first-class citizen with proper documentation and a coherent scripting language (D) designed around the tracing model.


Capsicum — Security You Can Actually Reason About

Most Unix security is about who you are. Users, groups, permissions.

Capsicum is about what you're allowed to do. Specifically: what syscalls a process can make, once you hand it a capability descriptor instead of a raw file descriptor.

OpenSSH on FreeBSD uses Capsicum. Chromium uses it. The idea is simple: after a process does its initial setup, you revoke its ability to open new files, make network connections, or fork processes. It can only work with the file descriptors it already has.

A compromised process that can't open /etc/passwd is a much less interesting compromised process.

This is not SELinux. It's not AppArmor. It's a different security model capabilities instead of labels and it composes cleanly with the rest of the system.


bhyve — A Hypervisor Nobody Talks About

FreeBSD has a native Type-2 hypervisor called bhyve (pronounced "beehive").

It runs Linux VMs. It runs Windows VMs. It's fast, it supports VirtIO, it uses hardware virtualization. iXsystems runs TrueNAS on FreeBSD + bhyve. Some cloud providers quietly use it.

bhyve -c 2 -m 2G -H -P \
  -s 0,hostbridge \
  -s 3,ahci-hd,disk.img \
  -s 4,virtio-net,tap0 \
  ubuntu-vm

No GUI. No management layer. Just a hypervisor that does what you tell it.

Most people have never heard of bhyve. The VMs running on it don't know that, and they don't care.


The Ports Tree — 35,000 Packages, All Negotiable

Linux package managers give you what the packager decided. That's fine for most things.

FreeBSD's Ports Collection gives you the source, plus a build system, plus compile-time options you can tune.

cd /usr/ports/www/nginx
make config    # opens a menu: WITH_DEBUG, WITH_GEOIP2, WITH_BROTLI...
make install clean

Every port has a Makefile that describes how to fetch, patch, configure, and build it. You can toggle features at compile time. You can apply your own patches. You can track upstream source directly.

Binary packages (pkg) exist too — for when you just want the thing installed. But the option to go deeper is always there. The ports tree is documentation and build system and packaging format rolled into one.

Featureapt / dnfFreeBSD pkgFreeBSD Ports
Binary install
Custom compile flags
Source-level patching
Reproducible buildspartialpartial

The Linuxulator — Running Linux Binaries. Natively.

This one surprises people.

FreeBSD has a Linux binary compatibility layer built into the kernel. Not a VM. Not WINE. Not emulation. It's a set of Linux syscall implementations that let Linux ELF binaries run directly on FreeBSD, on the same hardware, with near-native performance.

pkg install linux_base-rl9   # Rocky Linux 9 userland
./your-linux-binary           # just runs

Steam on FreeBSD. Linux-only proprietary software. Closed-source tools with no BSD build. They work.

FreeBSD said: we'll just speak Linux when we need to. One more reason to be hard to ignore.


Netflix Runs on FreeBSD's TCP Stack

This is the one I keep coming back to.

Netflix built Open Connect their CDN, responsible for serving a significant portion of global internet video traffic on FreeBSD. Not partly. Their edge servers run FreeBSD. They chose it specifically for the network stack performance and the ability to tune the kernel for high-throughput streaming.

They contribute back. FreeBSD's kernel has patches from Netflix in it.

The system that serves your 4K stream at 3am is probably running FreeBSD. It's just not advertising that fact.


Why You Should Care (And You Don't Run FreeBSD)

Not to switch. I'm not switching.

To think differently.

When you understand why FreeBSD ships as one coherent system, you start looking at your Linux setup and asking who made this decision and why. When you see that Jails predated Docker by thirteen years, you start wondering what other primitives are sitting quietly in corners of computing you haven't looked at. When you read ZFS documentation that assumes competence instead of protecting you from yourself, you want that assumption applied everywhere.

FreeBSD is a mirror.

It shows you what happens when a project optimises for correctness instead of adoption. When the user is the point, not the growth metric.

You spend enough time in that mental model and it changes how you debug. How you read documentation. How you think about what "working correctly" means versus "not currently failing."

Those are different things. Most of the time we don't notice.


Where I Am With This

I have it running in a VM. Reading the Handbook, I want to understand Jails before I write about them. I want to understand ZFS from the BSD side before comparing it to ZFS-on-Linux.

There'll be a follow-up post on actually setting it up. But that's not the point yet.

The point, right now, is that there is a way of thinking about operating systems that Linux never had to develop, because Linux won without it. FreeBSD didn't win. And somehow, because of that, it stayed honest.

FreeBSD has been doing this since 1993.