Lots of changes to the website

content/posts/why-openbsd.md

@@ -1,35 +1,40 @@
 ---
-title: "Why OpenBSD for a Homelab"
+title: "Why FreeBSD for a Homelab"
 date: 2026-03-01
-tags: [openbsd, homelab]
-slug: why-openbsd
-description: "The case for running OpenBSD as the foundation of a homelab — security model, pf, clean base system, and the value of good documentation."
+tags: [freebsd, homelab]
+slug: why-freebsd
+description: "The case for running FreeBSD as the foundation of a homelab — ZFS, jails, pf, clean base system, and the value of good documentation."
 draft: false
 ---
 
-A few people have asked why I chose OpenBSD for this homelab instead of the usual suspects —
+A few people have asked why I chose FreeBSD for this homelab instead of the usual suspects —
 Proxmox, TrueNAS, some flavor of Linux. The short answer: I wanted to actually understand what
-my infrastructure is doing, and OpenBSD forces that in a way nothing else does.
+my infrastructure is doing, and FreeBSD forces that in a way nothing else does.
 
-## The Security Model Is Different
+## ZFS Is the Right Filesystem
 
-Most operating systems bolt security on. OpenBSD builds it in.
+FreeBSD ships ZFS in the base system and it's a first-class citizen. Copy-on-write,
+checksumming, snapshots, send/receive for replication, compression, deduplication. For a
+homelab running storage workloads, ZFS means you actually trust your data is what you think it is.
 
-`pledge(2)` and `unveil(2)` are the clearest expression of this. Programs declare up front exactly
-what syscalls they'll use and which filesystem paths they'll touch. The kernel enforces it. If a
-daemon gets compromised, the blast radius is bounded by what it pledged. This isn't theoretical —
-the base system uses these everywhere.
+Compare that to the ext4/LVM dance on Linux — it works, but you're stitching together multiple
+tools to get what ZFS gives you out of the box.
 
-Compare that to a typical Linux daemon running as root (or even a non-root user) with access to
-the full filesystem. The attack surface is enormous by default.
+## Jails Are the Right Way to Isolate Services
+
+FreeBSD jails give you lightweight OS-level isolation without the overhead or complexity of VMs,
+and without the moving parts of Docker. A jail is just a restricted process tree with its own
+filesystem view. Predictable, auditable, and you control exactly what it can see.
+
+The security model is sound. A compromised service in a jail can't reach the host or other jails
+without explicit configuration. Compare this to a typical Linux container where the security
+boundary depends on which kernel namespaces you've set up correctly.
 
 ## pf Is the Best Firewall I've Used
 
-I've spent time with iptables, nftables, and a few others. `pf(4)` is in a different category.
-
-The rule syntax reads like English. State tracking is intelligent by default. `relayd(8)` handles
-reverse proxying and TLS termination in a way that integrates naturally with pf. The whole
-networking stack hangs together coherently.
+FreeBSD ships pf — the same packet filter that made BSD firewalls famous. The rule syntax reads
+like English. State tracking is intelligent by default. The whole networking stack hangs together
+coherently.
 
 Here's a minimal pf.conf to give a sense of the syntax:
 
@@ -47,37 +52,32 @@ That's readable. You can audit that in two minutes.
 
 ## The Base System Is Clean
 
-OpenBSD ships a complete, minimal base system. No package manager drama, no systemd, no
-six-hundred-dependency init system. The base is coherent. Everything in `/usr/bin` and
-`/sbin` has been reviewed and fits together.
+FreeBSD ships a complete, coherent base system — separate from ports and packages. No systemd.
+Everything in the base has been considered deliberately and fits together.
 
 When I install a service, I know exactly what I'm adding on top of a well-understood foundation.
 On a typical Linux distro, I'm never quite sure what's lurking in the base.
 
 ## The Documentation Is Accurate
 
-This is underrated. OpenBSD man pages are written by the people who wrote the code. They are
-current. They are correct. When the man page says `pledge(2)` takes these promises in this
-order, that is exactly what happens.
+The FreeBSD Handbook is one of the best pieces of technical documentation in open source. The
+man pages are maintained by the people who wrote the code. When the Handbook describes how to
+set up ZFS or configure pf, it describes what actually happens.
 
-How many times have you followed a Linux man page only to find it describes behavior from four
-kernel versions ago? Or read documentation that's accurate for one distro but not another?
-
-With OpenBSD, the man page is the specification. This matters enormously when you're learning
-a new tool or debugging an obscure issue at 2am.
+With FreeBSD, the documentation and the system agree with each other. This matters enormously
+when you're learning a new tool or debugging an obscure issue at 2am.
 
 ## The Tradeoffs
 
-OpenBSD isn't the right choice for everything. ZFS isn't in the base (use FreeBSD for that).
-The package ecosystem is smaller than Linux. Some software just doesn't run on OpenBSD, or
-runs with limitations.
+FreeBSD isn't the right choice for everything. The package ecosystem is smaller than Linux.
+Some software just doesn't run on FreeBSD, or requires extra effort to get working.
 
 For a homelab where the goal is to *understand* the infrastructure rather than just consume
 services, these tradeoffs are worth it. The constraint of a smaller, more deliberate ecosystem
 means you end up with a leaner, more auditable system.
 
-If you want to run Kubernetes on your homelab, OpenBSD is the wrong choice. If you want to
-actually know what your firewall is doing and why, it's worth the investment.
+If you want a point-and-click hypervisor, use Proxmox. If you want to actually know what your
+firewall is doing and why, FreeBSD is worth the investment.
 
 ## What's Next