Learn OpenBSD - -current vs -stable & Development

#Introduction

In episode 19 you optimized system performance. Now it's time to understand the question most often asked by new OpenBSD users: which version should I use? This episode dissects the OpenBSD development model — -current versus -stable — and how the system maintains long-term security through syspatch.

This decision has a big impact: choosing -current in production means sacrificing stability; choosing -stable means delaying the newest features. There's no single answer — there's the right answer for your context.

#Understanding the Development Model

OpenBSD works with a single, simple development flow:

-current: the active development branch. Every change is committed here, and snapshots are produced almost daily from this branch.
-release: the 6-month release point (April and October) taken from -current.
-stable: the branch that receives security patches and important bug fixes against -release, without adding features.

The key difference: -current moves fast and can be unstable; -stable is -release plus patches — stable and secured without major changes.

#When to Choose Which

Need	Choice
Production server	`-stable` (via syspatch)
Workstation for daily work	`-stable` or `-current` (if you're bold)
Testing the latest features	`-current` / snapshot
Development or contributing	`-current`
New hardware needing new kernel support	`-current` / snapshot

The general rule: production uses -stable. New features are attractive, but downtime costs more. Consider snapshots only if you know the risks and can keep up.

#syspatch: Security Patches on -stable

syspatch is the official way to apply security patches to a release without upgrading:

Applying security patches

syspatch
syspatch -l

syspatch without arguments: applies all available patches for your release.
syspatch -l: lists the patches already applied.

When a security bug is found in a stable release, the OpenBSD team releases a binary patch via syspatch. You apply it without changing the version, without rebuilding anything. This is the main reason -stable is the production choice.

Warning

syspatch only works on still-supported releases and requires a -stable package tree to be consistent. Make sure your base system is a supported release (for example 7.9 at the moment), and also update packages with pkg_add -u to close security holes in the third-party layer.

#Snapshot: Becoming -current

To follow -current, you install the latest snapshot. The fast and official way is sysupgrade:

Upgrading to a snapshot

sysupgrade

sysupgrade downloads the snapshot, boots into it, and upgrades the base system. Since -current changes daily, a snapshot is "one day old" at most — you must consciously decide to follow it.

#Building from Source

#Fetching the Source Tree

OpenBSD source code is fetched via cvs or git:

Fetching source with git

cd /usr/src
git clone https://github.com/openbsd/src.git -b OPENBSD_7_9

For -current, use the master branch. For a release, use a branch like OPENBSD_7_9. The kernel lives in /sys (often a symlink to /usr/src/sys).

#make build: Building the World

Building the entire base system — the "world" — is a two-stage process:

Building the world

cd /usr/src
make build

make build compiles the compiler, userland, and kernel, then installs them. This is a long process demanding disk and memory — that's why many users choose binary snapshots rather than building themselves.

#Building a Custom Kernel

For a custom kernel, the kernel configuration is in /sys/arch/<arch>/conf. The default config is GENERIC — the equivalent of what's called KERNCONF in other BSD worlds:

Building a custom kernel

cd /sys/arch/amd64/conf
config GENERIC
cd ../compile/GENERIC
make
make install

config GENERIC generates the compile directory, then make builds the kernel, and make install installs it to /bsd. Reboot to use the new kernel. Since KARL (episode 2) relinks on every boot, your kernel layout stays random even from the same build.

Info

Building from source is a great path for learning and contributing, but it's not a production requirement. Binary snapshots and syspatch are enough for most users. Build from source when you want deep customization or to participate in development.

#Contributing to the Project

-current is the gateway to contribution. The common flow:

Fetch the -current source.
Study CONTRIBUTING and OpenBSD's code conventions.
Test your changes on your own -current system.
Send a diff via the tech@openbsd.org mailing list.

Diffs are made with diff -u or git diff. OpenBSD values small, clear, tested patches. Contributing is the best way to deepen your understanding — and you join a community that has lasted three decades.

#Closing

In episode 20 you understood the OpenBSD development model: the difference between -current and -stable, when to choose a snapshot or a release, applying security patches with syspatch, and building the world and kernel from source with cvs/git and make build.

Key takeaways:

Production uses -stable; -current is for development and the newest features.
syspatch applies security patches to a stable release without upgrading.
sysupgrade is the official path to a -current snapshot.
make build builds the world; config GENERIC then make builds a custom kernel.

In the next episode, episode 21, we'll discuss OpenBSD 7.9 & roadmap — the new features of the May 2026 release including LibreSSL 4.3.0 and OpenSSH updates, the development direction toward 8.0, and how to keep the system updated.