The Operating System That Treats Your Entire Machine Like a Git Repo — And Why Hardcore Engineers Can’t Stop Talking About It

="">

Somewhere between the sterile predictability of macOS and the duct-tape chaos of a hand-configured Arch Linux install, there’s NixOS. It’s not new. It’s not flashy. And for years it lived in relative obscurity, championed by a small cadre of functional-programming enthusiasts and infrastructure engineers who didn’t mind reading academic papers for fun. But something has shifted. NixOS and its underlying package manager, Nix, are generating a level of grassroots enthusiasm among serious technologists that’s hard to ignore — the kind of fervor usually reserved for a new programming language or a startup with improbable funding.

A recent post by Jack Birkey on his personal blog captures this sentiment with unusual clarity. Titled “Why I Love NixOS,” the piece — written by someone who clearly lives in the terminal — lays out a case not just for the operating system’s technical merits but for a fundamentally different philosophy of how computers should be configured and managed. The argument isn’t about convenience. It’s about correctness. And reproducibility. And the freedom to break things without consequence.

That last point deserves attention.

In traditional Linux distributions — Ubuntu, Fedora, Arch, pick your flavor — installing software means mutating global state. You run apt install or pacman -S, and packages land in /usr/bin, libraries scatter across /usr/lib, configuration files nest in /etc. Over time, the system accumulates cruft. Uninstalling a package doesn’t always clean up its dependencies. Upgrading one library can silently break another application. Anyone who has managed a Linux server for more than a year knows this pain intimately. It’s the reason “works on my machine” became a meme, and it’s the reason Docker exploded in popularity — containers offered a way to sidestep the problem entirely by shipping the whole dependency tree in a box.

NixOS takes a different approach. A radical one, actually. As Birkey explains in his blog post, the entire operating system — every package, every service, every kernel module, every line of configuration — is declared in a single file (or a set of files) written in the Nix expression language. Change that file, rebuild the system, and NixOS produces a new, immutable generation of your OS. The old generation still exists. You can roll back to it at boot time. Think of it like version control for your entire machine.

“It’s the closest thing to treating your operating system like source code,” Birkey writes. And he’s not wrong.

The Nix package manager, which predates NixOS and can run on any Linux distribution or macOS, is the engine underneath all of this. Every package is built in isolation, with its dependencies explicitly declared and hashed. Two packages that need different versions of the same library can coexist without conflict because they’re stored in separate paths in the Nix store, identified by cryptographic hashes of their entire dependency graph. There are no version collisions. No dependency hell. The approach was originally described in Eelco Dolstra’s 2006 PhD thesis at Utrecht University, and it took nearly two decades for the broader engineering community to start appreciating just how prescient it was.

So why now? Why is NixOS suddenly showing up in conference talks, Hacker News threads, and infrastructure team Slack channels with increasing frequency?

Part of the answer is that the tooling has matured. Nix Flakes — an experimental but widely adopted feature — brought a standardized way to define project inputs and outputs, making Nix configurations more composable and shareable. The community around Home Manager, a tool for managing user-level dotfiles and applications through Nix, has grown substantially. And projects like devenv and Flakes have lowered the barrier for developers who want Nix’s benefits without committing to a full OS replacement.

But the deeper reason is philosophical, and Birkey’s post gets at it directly. Modern software development has become an exercise in managing complexity across layers of abstraction. Containers, orchestrators, CI/CD pipelines, infrastructure-as-code tools — they all attempt to impose order on systems that tend toward entropy. NixOS doesn’t just add another layer. It rethinks the foundation. When your OS configuration is a pure function of its inputs — when you can guarantee that the same configuration file produces the same system, byte for byte, on any machine — a whole category of problems simply evaporates.

Reproducibility. That word keeps coming up in NixOS discussions, and it carries weight beyond academic neatness. In production environments, reproducibility means that the system you tested is identical to the system you deploy. In development, it means onboarding a new engineer doesn’t require a week of fighting with package versions. In personal computing, it means you can rebuild your exact desktop environment on new hardware in minutes.

Birkey describes this experience vividly — the satisfaction of declaring everything about his system in Nix configuration files, pushing them to a Git repository, and knowing that he can reconstruct his entire computing environment from scratch. “My system is defined by code, not by the history of commands I’ve run,” he writes on his blog. For anyone who has spent a Sunday afternoon trying to remember which obscure sysctl tweak they applied six months ago, this is a compelling proposition.

The tradeoffs are real, though, and honest advocates don’t hide them.

The Nix language itself is often cited as the steepest barrier to entry. It’s a lazy, purely functional language with a syntax that can feel alien even to experienced programmers. Documentation has historically been scattered and inconsistent — a problem the community has been working to address through efforts like nix.dev and improved official docs. Error messages from the Nix evaluator can be cryptic. And the sheer volume of concepts a newcomer must absorb — derivations, overlays, flakes, the Nix store, profiles, generations — can be overwhelming.

There’s also the question of community governance. In early 2024, NixOS experienced significant internal turbulence. Disagreements over governance structure, sponsorship policies, and community moderation led to heated public discussions and the departure of some prominent contributors. A new governance model was eventually adopted, establishing an elected steering committee — a move covered extensively on community forums and platforms like NixOS Discourse. The situation stabilized, but it served as a reminder that even the most technically elegant projects are ultimately sustained by people, and people are complicated.

None of this has dampened momentum among the core user base. The Nixpkgs repository — the collection of package definitions for Nix — is one of the largest and most active open-source repositories on GitHub, with over 100,000 packages and thousands of contributors. Recent activity on X (formerly Twitter) shows a steady stream of engineers sharing their NixOS configurations, troubleshooting tips, and expressions of the particular joy that comes from getting a complex Nix setup working correctly. It’s a community that skews toward experienced developers — people comfortable reading source code as documentation and debugging build failures at the derivation level.

The enterprise angle is developing, too, albeit more slowly. Companies like Determinate Systems have built commercial tooling around Nix, including the Determinate Nix Installer, which simplifies the initial setup process that has historically tripped up newcomers. Flox, another startup in the space, offers a managed developer environment platform built on Nix. And large organizations — including parts of the European Space Agency, various financial institutions, and several well-known tech companies — have adopted Nix in parts of their build and deployment infrastructure, though most remain quiet about it publicly.

The comparison to Docker and containers is inevitable, and worth addressing head-on. Containers solve the “it works on my machine” problem by packaging an application with its runtime dependencies. Nix solves it by making the build process itself deterministic. These aren’t mutually exclusive — many teams use Nix to build Docker images, getting the reproducibility of Nix with the deployment convenience of containers. In fact, NixOS can produce minimal Docker images that contain only the exact dependencies a service needs, often resulting in images dramatically smaller than those built from traditional base images like ubuntu:latest.

But NixOS as a daily driver — as your actual desktop operating system — is where the conversation gets more personal and more polarizing. Birkey’s enthusiasm in his post is clearly rooted in this use case. He describes configuring window managers, shell environments, development tools, and system services all through Nix. Everything declarative. Everything version-controlled. And crucially, everything rollbackable. Install a bad driver? Reboot into the previous generation. Misconfigure your network? The last working configuration is one nixos-rebuild switch --rollback away.

This atomic upgrade model isn’t unique to NixOS — Fedora Silverblue and other immutable Linux distributions offer similar guarantees. But NixOS was doing it first, and it does it with a granularity that others haven’t matched. You don’t just roll back the OS image; you roll back to a precisely defined state that includes every package version, every configuration option, every enabled service. The diff between two system generations is meaningful and inspectable.

For infrastructure engineers and DevOps practitioners, the implications extend further. NixOS includes a built-in deployment tool called nixos-rebuild that can target remote machines, and community projects like deploy-rs and Colmena provide more sophisticated fleet management capabilities. The idea is straightforward: if you can describe one machine’s configuration as code, you can describe a hundred machines the same way, with variations expressed as function arguments rather than ad hoc scripts.

And then there’s the developer experience angle. Nix’s nix develop command (or the older nix-shell) lets you drop into a shell with specific tools and dependencies available, without installing anything globally. A Python project can have Python 3.11, a specific version of PostgreSQL, and a particular set of system libraries available in its development shell, defined in a flake.nix file at the project root. A Rust project next door can have a completely different toolchain. No conflicts. No virtual environment hacks. No Docker Compose file that takes three minutes to start up.

This is the feature that often hooks people who aren’t ready to switch their entire OS. You can use Nix on macOS or any Linux distribution purely as a package manager and development environment tool. The path from “I use Nix to manage my project dependencies” to “I run NixOS on my laptop” to “I deploy NixOS servers in production” is well-worn, and Birkey’s trajectory seems to follow it.

The learning curve remains the elephant in the room. Nix demands an upfront investment that most tools don’t. You have to learn a new language. You have to internalize a new mental model for how software is built and composed. You will spend time reading other people’s configurations to understand patterns that aren’t documented anywhere. The community knows this, and there’s an ongoing tension between Nix’s power and its accessibility — a tension that flares up periodically in GitHub issues and forum threads.

Some recent efforts aim to address this directly. The Nix documentation team has been overhauling guides and tutorials. Third-party resources like Zero to Nix by Determinate Systems provide structured onboarding paths. YouTube channels and blog posts from experienced users — Birkey’s included — serve as informal documentation that often proves more useful than official references for specific use cases.

Where does all this go? Predicting the trajectory of open-source projects is a fool’s errand, but some trends are visible. Nix adoption is growing, particularly among infrastructure teams at mid-size and large companies. The Flakes feature, despite still being technically experimental, has become the de facto standard for new Nix projects. The governance reforms of 2024 appear to have brought stability. And the broader industry trend toward reproducible builds, supply chain security, and hermetic build systems — driven in part by concerns about software supply chain attacks — plays directly to Nix’s strengths.

NixOS won’t become the next Ubuntu. It’s too opinionated, too demanding, too different. But it doesn’t need to. Its influence is already visible in how other systems think about package management, reproducibility, and declarative configuration. And for engineers like Birkey — people who want their computers to behave predictably, who treat configuration as code not because it’s trendy but because the alternative is unacceptable — NixOS isn’t just a tool. It’s an answer to a question they’ve been asking for years.

Sometimes the best technology isn’t the easiest to adopt. Sometimes it’s the one that refuses to compromise on the things that actually matter.