If you’ve used Linux for any meaningful amount of time, you’ve probably distro-hopped at least once. Maybe twice. Maybe you lost count. Each distribution promises a slightly better experience — faster updates, more stability, better hardware support — but under the hood, most of them share the same fundamental approach: install packages imperatively, mutate the filesystem in place, and hope things don’t break on the next upgrade.

I’ve been running NixOS as my daily driver for a while now, and I can confidently say it’s unlike anything else in the Linux world. It solves real problems that no other distro even attempts to address, but it also introduces new friction that can be genuinely frustrating. This post is my honest take on the experience — what’s good, what’s bad, and why I still think it’s awesome.

The Linux Landscape Link to heading

Before we talk about NixOS, let’s zoom out. The Linux desktop ecosystem roughly breaks down into a few families:

  • Debian-based (Ubuntu, Mint, Pop!_OS) — The safe bet. Massive community, .deb packages, stable but sometimes stale.
  • RPM-based (Fedora, OpenSUSE) — More cutting-edge than Debian, solid enterprise backing, strong defaults.
  • Arch-based (Arch, EndeavourOS, Manjaro) — Rolling release, bleeding edge, you build your own experience.

This isn’t an exhaustive classification. There are other long-standing distros like Gentoo (compile everything from source, maximum control) and Slackware (one of the oldest, deliberately minimal and Unix-pure) that don’t fit neatly into these families. They’re excellent systems with loyal communities, but they occupy a niche that keeps them off most people’s radar.

Then there’s the newer wave of distros that build on top of the mainstream families:

  • CachyOS — Arch-based with performance-tuned kernels and scheduler optimizations.
  • Bazzite — Built on Fedora’s atomic/immutable image system, targeting gaming and desktop use.

This newer wave reflects a growing trend: immutable operating systems. The idea is that the OS layer should be read-only and atomically updated, reducing the risk of a broken system. Fedora Silverblue, OpenSUSE MicroOS, and Vanilla OS all follow this model to varying degrees.

But NixOS? It sits in its own category entirely.

How NixOS is Different Link to heading

NixOS doesn’t just layer immutability on top of a traditional Linux base. It rebuilds the entire concept of system management from the ground up using functional package management.

Here’s the core idea: every package, every dependency, every configuration lives in /nix/store, identified by a cryptographic hash of its inputs. Nothing is ever modified in place. When you change your system configuration and rebuild, NixOS creates a new generation — a complete, self-contained snapshot of your system state. The old generation remains untouched.

Your entire system is defined declaratively in a configuration file (or a set of flakes). Want to install a package? Add it to the config. Want to enable a service? Declare it. Want to change a kernel parameter? It’s one line. Then you run nixos-rebuild switch and the system converges to the state you described.

This has a few powerful implications:

  • Reproducibility — Your config file is your system. Copy it to another machine, rebuild, and you get an identical setup.
  • Atomic upgrades — Either the entire rebuild succeeds or nothing changes. No half-applied updates.
  • Rollback — Every generation is bootable. Messed something up? Reboot into the previous generation from the bootloader. Done.

It’s not just immutable in the way Silverblue is immutable. It’s declarative and reproducible in a way nothing else achieves.

The Good Link to heading

A Centralized, Version-Controlled System Link to heading

This is the killer feature. My entire system configuration lives in a git repository. Hardware config, installed packages, enabled services, firewall rules, user accounts, shell configuration — all of it. Declarative. Diffable. Reviewable.

When I set up a new machine, I clone the repo, run nixos-rebuild, and within minutes I have my exact environment. No more maintaining dotfile scripts that break across distros. No more “I forgot I installed that thing manually three months ago.” Everything is accounted for.

Access to a Massive, Cutting-Edge Package Repository Link to heading

Nixpkgs is one of the largest package repositories in existence, with over 120,000 packages. And because it’s community-driven with a rapid contribution cycle, packages are often more up to date than what you’d find in Fedora or even the AUR.

Need the latest version of some niche developer tool? It’s probably already packaged. And if it’s not, the Nix language makes it straightforward to package it yourself without polluting your system.

A Resilient System You Can Trust Link to heading

I’ve broken my system configuration more times than I’d like to admit. On any other distro, that usually mean a recovery USB and a fresh install. On NixOS, it means rebooting and selecting the previous generation from the GRUB menu. Thirty seconds and I’m back to a working system.

This safety net changes how you interact with your OS. You experiment more freely because the cost of failure is near zero.

The Bad Link to heading

The Storage Tax is Real Link to heading

Here’s the uncomfortable truth: /nix/store is hungry. Even a minor dependency bump produces an entirely new store path, so over time distinct but overlapping closures accumulate and disk usage adds up fast. Community members regularly report their store growing to 50-100GB, and even with garbage collection (nix-collect-garbage -d) and store optimization (nix store optimise), a typical NixOS system with development tooling will comfortably sit at 40-70GB just for the store.

On my 512GB NVMe — where I also keep projects, music production files, and container images — this is a constant balancing act. You learn to run garbage collection regularly and keep old generations pruned. It’s manageable, but it’s a tax you don’t pay on a traditional distro.

With current SSD prices, this isn’t a dealbreaker if you plan for it. But on a laptop with a smaller drive, it can catch you off guard.

Rebuilds Take Forever Link to heading

When you run nixos-rebuild switch, the system evaluates your entire configuration, fetches or builds any missing packages, and assembles a new generation. For minor changes, this usually takes seconds. But a full system update? Especially on nixos-unstable where hundreds of packages might have new versions? You’re looking at 40-60 minutes of downloading and linking. Sometimes more.

This isn’t like apt upgrade where packages are swapped in place. NixOS is doing something fundamentally more thorough — and that thoroughness costs time. You learn to batch your changes and update less frequently, or you invest in a binary cache. But that initial “why is this taking so long” frustration is real.

The Learning Curve Link to heading

I didn’t list this in my initial notes, but it deserves mention. The Nix language is its own thing. It’s not Bash, it’s not YAML, it’s not TOML. It’s a lazy, purely functional language with its own quirks. Module options are powerful but sometimes cryptic. Error messages can be unhelpful. And finding the right way to do something often means reading source code in nixpkgs rather than a friendly wiki page.

You will spend time learning. That’s the investment. That said, an AI coding agent like Kiro can soften the curve considerably — asking it to explain a module option, generate a flake template, or debug a cryptic evaluation error gets you unstuck faster than digging through source code alone.

The Awesome Link to heading

Despite the storage overhead and the rebuild times, NixOS gives me something no other distribution can: complete confidence in my system’s state. I know exactly what’s installed. I know exactly what’s configured. I can reproduce it on any machine. And if anything goes wrong, I can roll back in seconds.

It’s the closest thing to infrastructure-as-code for your personal machine. And once you’ve experienced that level of control, going back to a traditional mutable distro feels like editing production servers by hand.

Would I recommend NixOS to everyone? Absolutely not. If you’re used to how traditional Linux works — apt install, editing config files in /etc, expecting the filesystem to behave like every other Unix — NixOS will fight you at every turn. It asks you to unlearn decades of conventions and adopt a completely different mental model.

But if you value reproducibility, if you manage multiple machines, or if you simply want your OS to be as version-controlled as your code — NixOS isn’t just good. It’s awesome.

Interested on taking advantage of the Linux OS for your project? Let’s talk!