Jan 29, 2026

ChaosBSD: Build the World, Break the World

I do not run FreeBSD 16-CURRENT.

I run ChaosBSD 16-QUANTUM.

CURRENT is for those who want to test what FreeBSD is building. QUANTUM is for those who want to test what FreeBSD cannot accept yet — code that exists in superposition, simultaneously working and broken until observed.

The Branch Hierarchy:

Branch	Purpose	Risk Level
FreeBSD RELEASE	Production stable, security patches only	Safe
FreeBSD STABLE	Tested features backported from CURRENT	Moderate
FreeBSD CURRENT	Active development, latest features	Living dangerously
ChaosBSD QUANTUM	Driver proving ground, superposition code	Schrödinger

RELEASE is for servers that must not fail. STABLE is for those who want new features without chaos. CURRENT is for those who want to understand what’s coming. QUANTUM is for those who want drivers that might or might not exist — the wavefunction collapses when you compile.

What Is ChaosBSD?

ChaosBSD is a FreeBSD fork designed as an abuse lab for hardware.

FreeBSD has standards. FreeBSD requires code quality. FreeBSD rejects incomplete drivers that might destabilize the system.

ChaosBSD has one standard: does it exist in a state that might compile?

ChaosBSD accepts:
- Quantum drivers (simultaneously working and broken)
- Superposition code (compiles in some timelines)
- Entangled subsystems (if WiFi works, audio might not)
- Hardware support in probabilistic states (too niche, too unstable, too quantum)

The motto: “ChaosBSD boots in superposition — it both works and doesn’t until you observe it.”

This is not production. This is a laboratory. Experiments fail. That’s the point.

What Is “The World”?

In FreeBSD, “world” means the entire base system — everything except the kernel:

The World includes:
- /bin        (essential user commands: ls, cp, sh)
- /sbin       (essential system commands: mount, fsck)
- /usr/bin    (user utilities: grep, sed, awk)
- /usr/sbin   (system utilities: pkg, service)
- /usr/lib    (shared libraries: libc, libssl)
- /usr/include (headers for compilation)
- /etc        (configuration files)
- /rescue     (static emergency tools)

The kernel is separate. The kernel manages hardware and processes. The world is everything you interact with.

FreeBSD lets you rebuild both. From source. On your own machine.

The Quantum Driver Lifecycle:

ChaosBSD drivers exist in superposition until observed (compiled):

stateDiagram-v2
    [*] --> Quantum: PR submitted
    Quantum --> Merged: make buildworld
    Quantum --> NotMerged: make buildworld
    Merged --> Working: boot
    Merged --> Panic: boot
    Working --> Upstream: stabilized
    Upstream --> [*]: reset to FreeBSD
    NotMerged --> Quantum: try again
    Panic --> Quantum: revert

    note right of Quantum
        Driver exists in superposition
        until compilation collapses
        the wavefunction
    end note

Stage	Status	Description
Quantum	Superposition	Driver exists in PR, simultaneously merged and not merged
Collapsed: Merged	Observed	Compilation succeeded, driver is in tree
Collapsed: Working	Functional	Boot succeeded, driver functions
Collapsed: Panic	Broken	Boot failed, wavefunction was unkind
Upstream	Classical	Driver stabilized, submitted to FreeBSD, becomes deterministic

When a driver graduates to FreeBSD upstream, it leaves the quantum realm. It becomes classical — deterministic, stable, boring. ChaosBSD resets that subsystem back to FreeBSD’s code. The superposition clears. New experiments begin.

This is not chaos for chaos’s sake. This is quantum mechanics applied to software — a pipeline for experimental code that upstream cannot risk but someone must observe.

Getting the Source:

# Clone ChaosBSD (forked from FreeBSD)
git clone https://github.com/seuros/ChaosBSD-src.git /usr/src

# Or clone FreeBSD directly
git clone https://git.freebsd.org/src.git /usr/src

# Update existing source
cd /usr/src && git pull

The entire source lives in /usr/src. Approximately 30 million lines of code. Kernel, userland, documentation, tools — everything.

ChaosBSD adds experimental drivers on top. When it syncs with FreeBSD, the experimental code either graduates upstream or gets rebased.

You now own the blueprints. The chaotic blueprints.

Building the World:

cd /usr/src

# Build everything (-j sets parallel jobs)
make -j$(sysctl -n hw.ncpu) buildworld

This compiles:

The toolchain (compiler, linker, assembler)
All libraries (libc, libpthread, libssl, etc.)
All userland utilities (thousands of programs)
All system configuration tools

On a modern machine: 30-60 minutes. On older hardware: hours. On patience: depends on your discipline.

Building the Kernel:

# Build the GENERIC kernel
make -j$(sysctl -n hw.ncpu) buildkernel

# Or build a custom kernel
make -j$(sysctl -n hw.ncpu) buildkernel KERNCONF=MYKERNEL

The kernel compile is faster — typically 10-20 minutes. The result: a new /boot/kernel/kernel ready to boot.

Custom Kernel Configuration:

The GENERIC kernel supports everything. Your machine needs less.

# Copy GENERIC as starting point
cd /usr/src/sys/amd64/conf
cp GENERIC MYKERNEL

# Edit to remove what you don't need
vi MYKERNEL

Example customizations:

# MYKERNEL configuration

ident           MYKERNEL

# Remove hardware I don't have
nooptions       SCTP                  # No SCTP protocol
nodevice        aac                   # No Adaptec RAID
nodevice        ahc                   # No old Adaptec SCSI
nodevice        mpt                   # No LSI MPT
nodevice        sound                 # No sound (servers don't speak)

# Add what I need
options         ZFS                   # ZFS filesystem
options         RACCT                 # Resource accounting
options         RCTL                  # Resource limits (for jails)

# Performance tuning
options         SCHED_ULE             # ULE scheduler (default, but explicit)
options         PREEMPTION            # Kernel thread preemption
options         SMP                   # Symmetric MultiProcessing

A custom kernel:

Boots faster (less probing for absent hardware)
Uses less memory (no unused drivers)
Documents your hardware (the config is your inventory)

The Full Upgrade Process:

# 1. Build everything
cd /usr/src
make -j$(sysctl -n hw.ncpu) buildworld
make -j$(sysctl -n hw.ncpu) buildkernel KERNCONF=MYKERNEL

# 2. Create a boot environment (ZFS safety net)
bectl create pre-upgrade
bectl activate pre-upgrade

# 3. Install the new kernel
make installkernel KERNCONF=MYKERNEL

# 4. Reboot into new kernel (old world, new kernel)
reboot

# 5. Install the new world
cd /usr/src
make installworld

# 6. Merge configuration changes
etcupdate

# 7. Rebuild all ports (optional but recommended for major upgrades)
portmaster -af
# or
pkg upgrade -f

# 8. Reboot into complete new system
reboot

Boot Environments: Your Safety Net:

ZFS boot environments let you snapshot before upgrades:

# List boot environments
bectl list

# Create a snapshot
bectl create before-16-current

# If upgrade fails, activate the old one
bectl activate before-16-current
bectl jail before-16-current  # Debug from safety

# Destroy when no longer needed
bectl destroy before-16-current

I never upgrade without a boot environment. One bad merge, one broken library, one kernel panic — reboot to safety in seconds.

This is not cowboy administration. This is engineering discipline.

src.conf: Customizing the World:

/etc/src.conf controls what buildworld compiles:

# /etc/src.conf

# Don't build what we don't need
WITHOUT_AMD=yes              # No AMD CPU microcode (Intel here)
WITHOUT_BLUETOOTH=yes        # No Bluetooth
WITHOUT_GAMES=yes            # Supreme Leaders don't play games
WITHOUT_HTML=yes             # No HTML documentation
WITHOUT_LPR=yes              # No printing (paperless Pyongyang)
WITHOUT_SENDMAIL=yes         # Using postfix instead
WITHOUT_WIRELESS=yes         # Servers don't need WiFi

# Do build what we need
WITH_DIRDEPS_BUILD=yes       # Meta-mode build (faster rebuilds)
WITH_CCACHE_BUILD=yes        # Cache compilations

The world builds faster when you exclude what you don’t use. Less code compiled. Less attack surface. Less disk space.

Why Build From Source?

Binary updates exist. freebsd-update patches RELEASE systems. Why suffer through compilation?

Binary Updates	Source Builds
Fast	Slow (first time)
No customization	Full customization
Trust FreeBSD’s binaries	Trust your own compiler
RELEASE/STABLE only	Any branch including CURRENT
Standard kernel	Custom kernel
Wait for patches	Apply patches yourself

When a vulnerability drops, RELEASE users wait for freebsd-update. CURRENT users git pull && make buildworld immediately.

When you need a kernel option not in GENERIC, binary users cannot help themselves. Source users add one line and rebuild.

The QUANTUM Lifestyle:

Running ChaosBSD QUANTUM means accepting uncertainty as a feature:

# Weekly ritual (when brave)
cd /usr/src
git pull
echo "Collapsing wavefunction..."
make -j$(sysctl -n hw.ncpu) buildworld buildkernel KERNCONF=CHAOS
bectl create $(date +%Y%m%d)-quantum
make installkernel KERNCONF=CHAOS
reboot
# Did it boot? The universe chose kindly.
make installworld
etcupdate
reboot
# Still running? You exist in a favorable timeline.

Sometimes things break. Often things break. A driver panics on hardware it claims to support. A new subsystem conflicts with an old one. The kernel doesn’t boot.

This is not failure. This is observation — the wavefunction collapsed unfavorably. Try again. The multiverse is infinite.

Every panic is an observation. Every broken driver reveals which quantum states are unstable. Every failed boot eliminates unfavorable probability branches.

ChaosBSD is not for production. ChaosBSD is for collapsing wavefunctions so that FreeBSD only ships code that has converged to deterministic behavior.

The Compile as Meditation:

There is satisfaction in watching:

>>> World build completed on Sat Jan 29 03:47:22 UTC 2026
>>> Kernel build for MYKERNEL completed on Sat Jan 29 04:02:15 UTC 2026

Your machine spent an hour transforming source code into binaries. Every utility. Every library. Every driver.

When it boots, you know what runs. You configured it. You compiled it. You installed it.

Linux users download distribution binaries compiled by strangers. Mac users accept what Apple provides. Windows users receive what Microsoft decrees.

FreeBSD users build the world. The world they designed. The world they own.

Pyongyang Quantum Observatory:

Our build servers collapse wavefunctions nightly:

Build farm specifications:
- 4x AMD EPYC 9654 (96 cores each)
- 2TB RAM per machine
- ZFS on NVMe
- Distributed ccache
- Custom KERNCONF=CHAOS

Full buildworld + buildkernel: 8 minutes
Wavefunction collapse results:
  - 73% collapse to |working⟩
  - 27% collapse to |panic⟩
  - Acceptable probability distribution

Every morning, fresh observations. Every morning, experimental drivers force quantum states to resolve. Every morning, we discover which timeline we inhabit.

When something panics, we analyze. When analysis reveals a fix, we commit. When the fix stabilizes across multiple collapses, we submit upstream.

FreeBSD gets deterministic drivers because ChaosBSD observed probabilistic ones until they stabilized.

This is not consumption. This is contribution through quantum observation.

The Commands Summary:

# Get source
git clone https://git.freebsd.org/src.git /usr/src

# Build
make -j$(sysctl -n hw.ncpu) buildworld
make -j$(sysctl -n hw.ncpu) buildkernel KERNCONF=MYKERNEL

# Safety
bectl create pre-upgrade

# Install
make installkernel KERNCONF=MYKERNEL
reboot
make installworld
etcupdate
reboot

# Verify
uname -a
freebsd-version -ku

The Lesson:

You do not own what you cannot build. You do not understand what you cannot break.

Binary distributions are convenient. They are also dependency. Someone else chose the compiler flags. Someone else decided which features to include. Someone else’s build system created your reality.

FreeBSD gives you the source. ChaosBSD gives you permission to observe it collapse.

make buildworld is not a command. It is a declaration of sovereignty. make buildkernel KERNCONF=CHAOS is not a build. It is a quantum measurement — the act of observation that forces reality to choose.

Build your world. Observe your world. Collapse the wavefunction. Fix unfavorable outcomes. Own the timeline you create.

I run ChaosBSD 16-QUANTUM. I collapse wavefunctions myself. I observe failures often. I fix what I observe. I upstream what stabilizes.

If it boots, the universe was kind. If it doesn’t, I exist in an unfavorable timeline — but tomorrow’s compile is a new observation.

The system is mine because I made it mine — and because I observed it collapse enough times to understand which configurations lead to favorable outcomes.

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