FreeBSD Is What Unix Was Supposed to Be

I’ve been running Linux for over thirty years. It’s fine. It’s more than fine. It runs most of the internet, most of the phones, most of the cloud. Linux won.

But lately I keep finding myself on FreeBSD machines, mostly for network appliances and jailed services, and thinking, “Right. This is how it was supposed to feel.”

A system, not a collection

I’ve written before about why the Unix philosophy keeps outlasting everything else. Small tools, text streams, composition. The ideas from 1970s Bell Labs that just keep working.

Linux embodies the philosophy at the tool level. The GNU coreutils are excellent. The pipes work. You can compose programs in the shell exactly like Doug McIlroy intended when he invented Unix pipes. But Linux as an operating system is not one thing. It’s a kernel, plus whatever distribution bolted onto it, plus whatever init system the distro picked, plus whatever package manager they chose, plus whatever opinions they have about where config files go.

FreeBSD is a complete operating system. The kernel, the userland, the documentation, the ports system. All developed together, by one project, with one coherent design. When you read the FreeBSD Handbook, you’re reading the manual for a single integrated system. When you read Linux documentation, you’re reading the manual for whichever slice of the ecosystem the author happened to be using.

That distinction sounds academic until you’ve debugged a problem that lives in the gap between the kernel team’s assumptions and the distro maintainer’s decisions. Then it sounds like a weekend you’re not getting back.

The base system concept

FreeBSD draws a clear line between the base system and third-party software. The base system is everything you need to boot, run, and manage the machine. It’s maintained as one unit, with one version number, one release cycle, one set of guarantees.

Third-party software lives in ports and packages. Separate. Your applications don’t interfere with the base system. The base system doesn’t break your applications.

Linux distributions try to do this, but the line is blurry. Is systemd part of the base system? Is NetworkManager? Is PulseAudio? Depends on who you ask and which distro you’re running. The answer changes between releases.

FreeBSD’s answer doesn’t change. The base system is the base system. Everything else is a port. The clarity is the feature.

Jails got there first

Docker showed up in 2013 and everyone acted like containers were a new idea. FreeBSD had jails in FreeBSD 4.0, released March 2000. Thirteen years earlier.

Jails give you isolated environments with their own process space, network stack, and filesystem. Sound familiar? The difference is that jails are a first-class operating system feature, not a layer of abstractions stapled on top of a kernel that wasn’t designed for them.

Linux containers work. They work well enough that Docker built an industry on top of them. But they’re built from cgroups, namespaces, seccomp, AppArmor or SELinux, and a dozen other subsystems that were each developed independently and then wired together. The complexity lives in the seams.

FreeBSD jails are one feature. One mechanism. One set of documentation. One mental model. The Unix way.

I’m not saying jails are better for every use case. Docker’s ecosystem is enormous and that counts for a lot. But when I hear people complain about container complexity, I think about how jails solved the same problem with a fraction of the moving parts.

ZFS as a first-class citizen

Linux and ZFS have a complicated relationship. Oracle’s CDDL license and the GPL don’t play well together. The result is that running ZFS on Linux works, but it’s always slightly outside the tent. You install it from a separate repo. Kernel updates sometimes break it. The legal status stays ambiguous.

FreeBSD ships ZFS in the base system. It’s the default filesystem. It’s integrated with the boot loader, the installer, the documentation. It’s not a bolt-on. It’s how the system was designed to work.

ZFS is worth paying attention to because it brings the text files philosophy to storage: you can inspect it, understand it, and trust it. Snapshots, replication, checksums, compression. Built into the filesystem, not layered on top.

The documentation culture

FreeBSD has a Handbook. Not a wiki. Not a collection of community posts. A genuine, maintained, comprehensive handbook that covers everything from installation to storage to networking to security to the ports system to kernel tuning.

Go read a chapter. Pick any chapter. It’s one of the most impressive pieces of technical documentation in open source. Clear writing, consistent structure, accurate examples that actually work on the version they claim to document. It reads like it was written by people who think documentation is part of the product, because in FreeBSD’s culture, it is.

Linux has the Arch Wiki, which is genuinely excellent but community-maintained and Arch-specific. Debian has the Debian Administrator’s Handbook. Red Hat has its product documentation. Ubuntu has its own community docs. Gentoo has its own wiki. Each one covers that distro’s way of doing things, which may or may not resemble the distro you’re actually running. Then there are man pages, Stack Overflow threads, blog posts from 2014 that may or may not still apply. You piece together your understanding from a dozen sources and hope they agree with each other.

The FreeBSD Handbook is a single source of truth for the entire operating system. That’s only possible because FreeBSD is one thing. You can document a system coherently when the system was designed coherently.

The whole stack

The coherence argument isn’t just about the base system and jails. It runs through everything.

pf. FreeBSD’s packet filter has one config file, one syntax, one mental model. On Linux, your firewall might be iptables, nftables, firewalld, or ufw, depending on which distro you’re running and which decade it was designed in. pf’s config reads like English. You can audit it by reading it.

bhyve. FreeBSD’s native hypervisor. One tool for virtual machines, integrated with the base system. On Linux, you’re wiring together QEMU, KVM, libvirt, and virt-manager, four projects from different teams with different release cycles. bhyve does less. It also breaks less.

The network stack. This is the real reason Netflix chose FreeBSD for Open Connect, their content delivery network that handles a significant chunk of internet traffic. FreeBSD’s TCP/IP stack has been tuned for decades by people who treat networking as the primary use case, not one feature among hundreds. It’s also why pfSense and OPNsense, two of the most widely deployed open source firewalls, are built on FreeBSD and not Linux.

DTrace. System-wide tracing built into the kernel. Inspect any running process, any system call, any I/O operation, live, without restarting anything. Linux got similar capabilities eventually through eBPF, but DTrace was a first-class FreeBSD feature years earlier.

Security. FreeBSD has a dedicated security team, a formal advisory process, and a culture of auditing. Jails were a security feature before anyone thought to use them for deployment. The security model isn’t bolted on. It’s how the system was designed.

Each of these is a case where Linux offers more options and FreeBSD offers more coherence. More options means more flexibility. More coherence means fewer surprises at 3am.

The licensing philosophy

FreeBSD uses the BSD 2-Clause license. Do what you want. Keep the copyright notice. That’s it. It’s why Netflix uses it, why Sony built the PlayStation OS on it, why Apple used it as the foundation for macOS. The open source story of 2025 showed that the relationship between open source and business is more nuanced than the GPL assumed. The BSD approach is simpler, and simple ages well.

Why now?

The Linux ecosystem is getting complex in ways that feel increasingly un-Unix. Systemd absorbed cron, logging, networking, DNS resolution, home directories, and boot management into a single interconnected system. It works. It’s also a monolith wearing a trenchcoat.

Cloud providers are adding layers. Container orchestration is adding layers. AI infrastructure management is adding layers. Every layer makes it harder to understand what your machine is actually doing.

FreeBSD is still just FreeBSD. The base system boots the same way it did ten years ago. The tools are where you expect them. The configs are where the Handbook says they are. You can understand the whole system because the system was designed to be understood.

That’s not nostalgia. That’s an engineering advantage that compounds over time. The more layers the industry adds, the more valuable a transparent system becomes.

The desktop question

The knock on FreeBSD has always been the desktop. And for a long time, that was fair. X11 worked, but the experience was years behind what Linux distributions offered.

Wayland is changing that equation. FreeBSD now has a full Wayland chapter in the Handbook, and the progress is real. KDE Plasma 6 runs on FreeBSD via Wayland. Sway works. The compositor ecosystem that Linux spent years building is arriving on FreeBSD because Wayland was designed as a protocol, not a Linux feature.

Over on the Linux side, DHH and 37signals built Omarchy, an opinionated Arch Linux distribution running Hyprland as a Wayland tiling compositor. These are the same people who repatriated from the cloud and saved millions. Now they’re moving their entire company to a tiling Wayland desktop. The pattern is consistent: understand the layer you’re running on, choose tools that are transparent and composable, don’t accept complexity you didn’t ask for.

Omarchy is Linux, not FreeBSD. But the philosophy behind it, a curated system where every piece is there on purpose and nothing is hidden, is the same philosophy FreeBSD has applied to the operating system itself for decades. The desktop is finally catching up to that idea on both sides.

FreeBSD still isn’t going to replace Linux on most laptops. Hardware support is narrower. Driver coverage lags. If you need Docker’s ecosystem, you need Linux (or macOS). But “FreeBSD can’t do desktop” is becoming less true every release, and for the kind of person who wants to understand their entire stack top to bottom, that’s worth watching.

The honest tradeoffs

The job market runs on Linux skills. The container ecosystem assumes Linux. Most cloud providers don’t offer FreeBSD images by default.

FreeBSD’s strength is in servers, appliances, and infrastructure. Places where the operating system should be invisible and reliable and fully understood by the people running it.

If you’re running a server and you’ve never tried FreeBSD, it’s worth an afternoon. Not because it does things Linux can’t do. Because it does the same things with less machinery, and sometimes that’s exactly what you need.

The philosophy, not the brand

This isn’t really about FreeBSD versus Linux. It’s about what happens when you design a system around coherence instead of assembling one from parts.

The Unix philosophy says: small tools, clear interfaces, text streams, composition. FreeBSD applies that philosophy to the operating system itself. One project. One design. One handbook.

Linux applies it at the tool level and lets everything else be someone else’s problem. That flexibility is Linux’s greatest strength and its most persistent weakness.

Both approaches work. But in an industry that’s adding complexity at every layer, I find myself drawn to the one that keeps things simple on purpose.

The tools from 1970s Bell Labs keep winning. The operating system that stayed closest to those ideas is worth your attention.

Have you run FreeBSD for anything? I’m curious what draws people to it, or what’s kept them away.