📝NixOS vs. FreeBSD👨‍🍳: A Tale of Two Boot Processes⚙️

Table of contents:-

Recipe vs. Catalogue: What's the Difference?

Welcome, digital explorers, to another deep dive from The Distrowrite Project! Today, we're journeying into the very heart of an operating system: the boot process. It’s that magical sequence of events that happens between you pressing the power button and seeing a login prompt. While it often seems like arcane wizardry, understanding how your system comes to life is key to truly mastering it. We’re going to compare two titans of the open-source world, each with a radically different philosophy on how to get from a cold start to a running system: the venerable FreeBSD and the revolutionary NixOS.

To guide us on this technical safari, we’ll use a simple, tasty analogy. Imagine you're in charge of a grand banquet and need to provide a cake.

FreeBSD is like being a master baker who bakes a fresh cake from a detailed recipe every single time. You have your list of instructions (scripts), your ingredients (configuration files), and you follow the steps meticulously. The process is transparent, hands-on, and gives you immense control. If you burn the cake, however, you'll need to clean up the mess and start again, perhaps by pulling a previously baked, perfectly preserved cake from the freezer (a ZFS snapshot).

NixOS, on the other hand, is like running a futuristic patisserie with a digital catalog. The cakes have all been pre-baked to perfection behind the scenes. Your job at the banquet is simply to choose the exact cake you want from the menu (the GRUB bootloader). The staff instantly serves it up. If a guest tries the new tiramisu and doesn't like it, you can instantly serve them the Black Forest gateau they enjoyed yesterday by simply pointing to it in the catalog. The complex baking process (the system build) happens only when a new cake is added to the catalog, not when it's time to serve it.

Grab your aprons and your order pads, because we’re about to explore these two fascinating approaches, from the first spark of electricity to the final, ready-to-use system.

FreeBSD: The Baker's Method 👨‍🍳

FreeBSD is a descendant of the Berkeley Software Distribution (BSD), a lineage that prizes stability, clean design, and comprehensive documentation. Its boot process is a masterclass in the traditional UNIX way of doing things: a clear, sequential, and script-driven procedure. It’s our master baker following a trusted, time-honoured recipe. Let's walk through the kitchen as this cake is baked from scratch every time the power comes on.

The process begins, as with any system, at the hardware level. When you press the power button, the BIOS or UEFI firmware on your motherboard wakes up. It performs a Power-On Self-Test (POST) to make sure all the essential hardware, like memory and processors, is working correctly. Think of this as the baker arriving at the kitchen, turning on the lights, and checking that the oven and mixers are operational. Once the hardware gets the all-clear, the firmware's job is to find a bootable device (like a hard drive or SSD) and hand over control to the very first piece of software in the boot chain: the bootloader.

In the FreeBSD world, this bootloader is a multi-stage affair. The first stage is tiny, just enough code to find and load the second stage. The second stage is more intelligent, and the third stage, loader, is where things get interesting for the user. This is /boot/loader, an interactive program that acts as our baker's mise en place station—the part where you lay out and prepare your ingredients. Here, the loader's primary job is to find and load the most important part of the operating system: the kernel.

Before it does, however, you can interact with it. The loader reads a configuration file, /boot/loader.conf, where you can define crucial pre-flight settings. Want to load a specific kernel module at boot? You can specify it here. Need to tweak a kernel parameter (a "tunable") before the kernel even starts? This is the place. This is akin to the baker deciding whether to use brown sugar instead of white, or adding a pinch of cinnamon to the flour before mixing begins. It’s a powerful point of intervention that allows for deep customisation right at the start.

Once the loader is satisfied, it loads the FreeBSD kernel (/boot/kernel/kernel) and any specified modules into memory and executes it. The kernel is the true core of the operating system, the base batter of our cake. The moment it takes over, it springs to life. It initializes itself, probes the system for all connected hardware—disks, network cards, graphics adapters, USB ports—and loads the necessary drivers to manage them. You can see this happening in real-time as lines of text scroll rapidly up the screen, each one announcing a piece of hardware being detected and configured. The baker is now mixing the core ingredients—flour, eggs, butter, sugar—to create the fundamental structure of the cake.

When the kernel has a complete picture of the hardware landscape and has its core functions running, its final major task is to start the very first user-space process. This is the legendary Process ID 1 (PID 1), also known as init. The init process is the ancestor of all other processes that will run on the system. If the kernel created the raw cake batter, init is the head chef who will oversee the rest of the baking, decorating, and plating.

Here is where the "recipe" part of our analogy truly comes into its own. FreeBSD's init is a relatively simple program. Its main job is to execute the master shell script: /etc/rc. This single script is the start of a chain reaction. It’s the first page of our recipe book. The /etc/rc script begins by reading the main configuration file for the system, /etc/rc.conf. This file is the baker's ingredient list and high-level instructions. It’s a collection of simple variables that turn services on or off. For example, to enable the SSH server, you would have a line that says sshd_enable="YES". To enable the Apache web server, you’d add apache24_enable="YES". This file doesn't do anything on its own; it merely declares what you want to be done.

After sourcing these variables, the /etc/rc script then orchestrates the execution of dozens of smaller, individual scripts located in directories like /etc/rc.d/. Each of these smaller scripts is responsible for one specific task: starting the networking service, mounting file systems, launching the SSH daemon, starting the firewall, and so on. They are the individual steps in the recipe: "Step 1: Whisk the eggs," "Step 2: Fold in the flour," "Step 3: Pour into a greased tin." The master script calls them in a carefully determined order. Each script checks /etc/rc.conf to see if it should run (is sshd_enable set to YES?) and, if so, it performs its duty.

This approach is beautifully transparent and easy to debug. If a service fails to start, you can run its script manually from the command line to see what went wrong. You can read the scripts—they are just shell scripts, after all—to understand exactly what they do. It’s an imperative process: it’s a list of commands executed in sequence to transform the system from a basic, kernel-only state into a fully functional, multi-service environment.

Finally, after the last script in the sequence has run, the system is considered "up." One of the final steps is to start getty processes, which are responsible for displaying a login prompt on your terminals. The cake is baked, decorated, and presented. You can now log in and start using it.

But what if the cake is a disaster? What if a recent change to a configuration file or a faulty script prevents the system from booting correctly? This is where FreeBSD’s modern safety net, often implemented with the ZFS filesystem, comes in. ZFS allows you to take instantaneous "snapshots" of your entire system. Using tools like beadm and bectl, you can create a "boot environment" before making a risky change, like a major system upgrade. If the upgrade goes wrong and the system won't boot, you can simply tell the bootloader to boot from the previous, known-good boot environment. This is like having a perfectly baked cake from yesterday stored in a blast freezer. If today's baking attempt results in a charred brick, you can throw it away and serve the pristine one from the freezer. It's a powerful recovery mechanism, but it's important to note it's a form of backup and restore. You are reverting the entire state of the system to a previous point in time.

NixOS: Choosing from the Catalogue 📝

Now, let's step out of the traditional kitchen and into the gleaming, automated world of the NixOS patisserie. NixOS takes a fundamentally different approach. It argues that building the system state from scratch on every boot is inefficient and prone to error. Instead, it champions a declarative and reproducible model. The hard work—the baking—is done beforehand. The boot process is merely the act of selecting a finished, perfect product from a catalog.

The story of a NixOS system begins not at boot time, but at "build time." The entire configuration of a NixOS system is defined in a single primary file: /etc/nixos/configuration.nix. This file is the master blueprint, the complete recipe for a specific version of your system. It’s written in the Nix expression language, and it describes everything: the user accounts that should exist, the packages that should be installed, the system services that should be enabled (using systemd), the content of the firewall rules, and the kernel version to use. You declare the what, not the how. You don't write a script to create a user; you add the user's name to a list of users in the configuration file.

When you're ready to apply your changes, you run a command like nixos-rebuild switch. This command is the master baker in our NixOS patisserie. It reads your configuration.nix blueprint and gets to work. It meticulously builds or downloads every single piece of software and every configuration file required for your system. The magic of Nix is that each of these pieces is stored in its own unique, immutable directory in a special location called the Nix store, /nix/store. A path might look something like /nix/store/1a2b3c...-openssh-9.7p1. The long string of characters is a cryptographic hash of all the inputs used to build that package, ensuring that it is unique and cannot be changed. This means you can have dozens of versions of the same library or application living side-by-side without any conflict.

The result of a successful nixos-rebuild command is a new system generation. A generation is essentially a single directory (a symlink, technically) that contains a complete, self-contained description of a runnable system. It’s a forest of symbolic links pointing to all the correct, version-specific files in the /nix/store that make up your declared configuration. This newly created generation is our perfectly pre-baked cake, complete with all its layers, frosting, and decorations, now sitting in the patisserie's climate-controlled display case. Critically, the old generations—your previous cakes—are not thrown away. They remain untouched and available.

The nixos-rebuild command then performs one final, crucial step: it regenerates the bootloader configuration. This is where the catalog is updated. The bootloader, typically GRUB, is configured to display a menu where each entry corresponds to a specific system generation. Your boot menu might look like this:

NixOS, Generation 121 (built on 2025-09-17)
NixOS, Generation 120 (built on 2025-09-15)
NixOS, Generation 119 (built on 2025-09-14)
...and so on.

Now, let's finally boot the machine. The BIOS/UEFI hands off to the GRUB bootloader, just like before. But instead of a simple menu to pick a kernel, you are presented with your catalog of complete, bootable system generations. You are the customer at the banquet. Do you want the new cake you ordered today (Generation 121), or do you prefer the one you had two days ago (Generation 120)? The choice is yours.

When you select a generation and press Enter, the boot process is stunningly simple and fast. The bootloader loads the specific kernel and initial RAM disk (initrd) that are associated with that chosen generation. They live in the Nix store, just like everything else.

The initrd takes over and performs the most critical part of the NixOS boot. It contains a special script whose main job is to prepare the environment so that the chosen generation can run. It mounts the /nix/store (where all the real files live) and then "activates" the selected generation. This activation involves creating the necessary top-level symbolic links, like /run/current-system, to point to the generation you chose from the boot menu. It then prepares to hand off control to the real init process for that generation, which is almost always systemd.

The key insight here is that there are no /etc/rc.d scripts to run. There are no sequential steps to configure services. All of that work was already done at build time. The systemd unit files, the network configurations, the user accounts—everything was pre-computed and placed into the Nix store when the generation was built. The boot process simply sets up the pointers to this pre-built world and then lets systemd take over. Since systemd's configuration is also part of the generation, it knows exactly what services to start and how they depend on each other, and it can do so in a highly parallel and efficient manner.

The result is a boot process that is not about building a state, but about instantiating a pre-defined one. You aren't baking a cake; you're simply taking a finished one out of its box and placing it on the serving platter.

The power of this model for rollbacks is immense. Imagine you just updated to Generation 121, but you discover a critical bug in a piece of software or a misconfiguration that breaks your workflow. With a traditional system, you might have to start troubleshooting, editing config files, or downgrading packages. With NixOS, the solution is trivial: you just reboot the machine. At the GRUB menu, you select Generation 120. The system will boot into a state that is bit-for-bit identical to how it was before your last update. The problematic Generation 121 is still there, but it is not active. You haven't "restored" anything; you've simply chosen to boot a different, co-existing, and complete system definition. It’s the ultimate "undo" button for your entire operating system.

Recipe vs. Catalogue: What's the Difference?

Let's put our two systems side-by-side and compare the philosophical and practical differences that emerge from their boot processes.

The most profound difference is imperative versus declarative. FreeBSD's boot is imperative. It’s a script that says, "First, do A. Then, do B. Then, if C is true, do D." You are commanding the system, step-by-step, to assemble itself. NixOS's boot is declarative. The configuration file says, "The final system should look like this," and the build tools figure out how to make it happen. The boot process itself is just the simple act of activating that pre-built declaration.

This leads to a vast difference in reproducibility and predictability. A FreeBSD system's state can change over time. An administrator might manually edit a file in /usr/local/etc, install a package outside the package manager, or change a setting on the fly. This "configuration drift" means that two machines that started with the same setup can diverge over time. The boot process tries to enforce the configured state, but it operates on a mutable filesystem. A NixOS generation, being based entirely on the immutable /nix/store, is perfectly reproducible. If you take the same configuration.nix file and build it on two different machines, you will get byte-for-byte identical systems. Booting Generation 120 will always yield the exact same environment, every single time, guaranteed.

The approach to updates and rollbacks is another stark contrast. In FreeBSD, an update mutates the live system. pkg upgrade will replace old files with new ones. While robust, there's a small window where an interruption (like a power failure) could leave the system in an inconsistent state. A rollback, as we saw, is a powerful but distinct operation, akin to restoring a backup via ZFS. In NixOS, updates are atomic. The nixos-rebuild command builds the new generation completely in the background. Only when it has succeeded, 100%, does it make the new generation available in the boot menu and switch the running system to it. If the build fails for any reason, your current running system is completely untouched. There is no possibility of a partial or broken update. Rollbacks are not a recovery procedure but a core feature of the bootloader—simply choosing an older, perfectly preserved configuration from a menu.

Finally, consider configuration management. In FreeBSD, configuration is spread across many files in the /etc and /boot directories. This follows the UNIX philosophy of placing configuration near the service it controls. It's a system that many administrators are very comfortable with. NixOS centralises almost all system-wide configuration into configuration.nix. This creates a single source of truth for your entire system, making it incredibly easy to track, version control, and replicate your setup elsewhere.

Conclusion

So, which method is better? The traditional baker or the futuristic patisserie? The truth is, they are both exceptional at what they do, but they cater to different philosophies.

FreeBSD's boot process is a testament to decades of UNIX development. It is transparent, logical, and offers fine-grained control at every step. For the administrator who wants to understand and, if necessary, modify every aspect of how their system comes online, the "baking from a recipe" method is empowering and clear. It represents a mature, robust, and highly respected tradition in system administration.

NixOS's boot process is a bold reimagining of how a system should be managed. By front-loading the complexity into a declarative build phase, it achieves an unparalleled level of atomicity, reproducibility, and effortless rollbacks. For the administrator who values absolute predictability and wants to treat their entire operating system configuration as code, the "choosing from a catalogue" method is a game-changer.

Ultimately, the choice between following a time-tested recipe and selecting from a catalogue of perfect creations depends on what you value most in your operating system: the hands-on process or the guaranteed outcome. Both will give you a delicious cake in the end.🎂

Disclaimer: NixOS, FreeBSD, and other product names are trademarks or registered trademarks of their respective holders. Their use in this article is for identification and commentary purposes only and does not imply any affiliation with or endorsement by the trademark holders. We’ve worked diligently to make this article as accurate, clear and complete as possible. Drawing from official sources, The Distrowrite Project aims to reflect the subject faithfully—though for the freshest details, we always recommend checking the original documentation.

References:

The FreeBSD Handbook, Chapter 15: The FreeBSD Booting Process: https://docs.freebsd.org/en/books/handbook/boot/
The NixOS Manual: https://nixos.org/manual/nixos
NixOS Wiki: https://nixos.wiki/

Back to top

Search This Blog

The Distrowrite Project