T
the emergence of Docker and Kubernetes was a massive leap in how we build and deploy software. They accelerated the shift from monolithic applications to microservices architectures and fundamentally changed deployment strategies.
For the first time, we could package an application together with its runtime and dependencies into a container image. When built correctly (with pinned base images and fixed versions), that image behaves deterministically.
However, our development machines remains far from this. Traditional Linux distributions such as Ubuntu or Red Hat Enterprise Linux use mutable package management systems. They install packages into a global filesystem, resolve dependencies dynamically, and depend on the current state of remote repositories. That means it does NOT guarantee you will get the same package version, when you try to install the same package after a month or a year. Reproducing the same environment is diffucult, unless you have `Satellite` or `Foreman` like system management tools.
This is where NixOS comes into play. NixOS is immutable Linux distribution which allows us to define our sytem configurations as code. When your system configuration is declared declaratively, every rebuild produces the same result — consistently, predictably, and reproducibly.
However, our development machines remains far from this. Traditional Linux distributions such as Ubuntu or Red Hat Enterprise Linux use mutable package management systems. They install packages into a global filesystem, resolve dependencies dynamically, and depend on the current state of remote repositories. That means it does NOT guarantee you will get the same package version, when you try to install the same package after a month or a year. Reproducing the same environment is diffucult, unless you have `Satellite` or `Foreman` like system management tools.
This is where NixOS comes into play. NixOS is immutable Linux distribution which allows us to define our sytem configurations as code. When your system configuration is declared declaratively, every rebuild produces the same result — consistently, predictably, and reproducibly.
| Feature | Traditional Linux (Ubuntu/RHEL) | NixOS |
|---|---|---|
| State Management | Imperative (Manual changes) | Declarative (Config files) |
| File System | Mutable (Files can be changed) | Immutable (Read-only /nix/store) |
| Reproducibility | Low (Depends on install timing) | High (Guaranteed by hashes) |
| Rollbacks | Difficult / Manual | Atomic (Instant via Boot Menu) |
Under the hood, packages
- stored in
/nix/store - Each build is content-adddressed and hashed.
- Dependencies are isolated.
- System generations are atomic.
Above features provides us following advantages
- Reproducibility
- Rollbacks
- Isolation
NixOS has its own programming language. At first glance, it may seem unusual or even intimidating. However, once you become familiar with it, you realize it is a powerful tool for defining system configuration in a precise and reproducible way.
There is definitely a learning curve when it comes to understanding the Nix language and the core NixOS concepts. However, once you become familiar with overlays, modules, and Home Manager, things start to feel much more intuitive.
I’m still learning and exploring NixOS myself. I have to admit that the configuration I’m sharing below may be far from best practices. As I continue learning, I plan to refine and improve it over time.