NixOS for the Impatient
borretti.me
borretti.me
That being said, once you get the hang of things, you reap amazing benefits:
- You can clone your system to any machine, and immediately have an identical environment
- You can share system configurations as code (declare the means for hosting a website in its repository, for example)
- You can use a fully-fledged programming language to configure any part of your system
- You can make use of an extensive ecosystem of easily composable, prebuilt NixOS modules
- You can seamlessly integrate with Nix, allowing for ephemeral development environments and shells with packages, eliminating much of the need for imperative package management
- Everything in a Nix-based system must be derived strictly from (lockfiled) inputs, making the reproducibility guarantees incredibly strong (barring any network errors or resources being taken down)
- The declarative nature of anything Nix-based means that every change is documented - your system never shifts from the source of truth, compared to other distros where discipline is required to maintain reproducibility
- Nix is so robust that you could even nuke your filesystems on every log out, if you'd like
It's arguably the killer feature of NixOS, if stability and purity means nothing to you.
A few weeks ago I bought a little SBC (Quartz64) for my homemade NAS project. Since I'm already a NixOS user, the bootstrap process was easy:
- Build ARM image for NixOS and boot off the device
- Clone my dotfiles and symlink my config folder into /etc/nixos
- Rebuild my system
And boom. Everything is there, my shell and coreutils and things I've come to expect all get rolled into the system. Updating it just means git pull and a system rebuild. As you say - it's not for the impatient. You have to maintain your config pretty regularly, and covering multiple devices across multiple architectures requires some deliberate config organization.
I'm not sure where I fall on the patience spectrum, but NixOS worked out pretty great for me. It's on my desktop, laptop and homeserver, and I haven't had a single bad update in my 8 months of daily driving it.
/etc/nixos/roles/foo/default.nix has config for the 'foo' role (eg, I have a desktop role that enables all my GUI options)
configuration.nix and hardware-configuration.nix in /etc/nixos/ are symlinked to the actual files in /etc/nixos/hosts/<hostname>/
in the imports section of each machine's configuration.nix, I import /etc/nixos/roles/foo for each role the machine should use. for your graphics card example, I have 'nvidia' and 'nvidia470' roles that pull in their respective nvidia driver (due to an old gaming laptop that requires the legacy driver version)
I have a 'core' role that all machines import, with the global config I want on every host
this allows me to version-control my entire /etc/nixos directory (managed as a private git repo, replicated using syncthing rather than pushed to Github/Gitlab/etc). the symlinks in /etc/nixos are in .gitignore because they're machine-specific, and the actual per-host config files are able to be tracked in their own directories.
I also wipe my entire rootfs every boot with a zfs snapshot rollback[2] using the impermanence module[3] to keep specific stateful data one one of two datasets with regular snapshots: one is backed up with zfs send, the other is just for cache between reboots.
It took a little puzzling to get started, because I didn’t know about the impermanence module at first, so I built my own hacky solution. But I really love this setup. And the way I don’t have cruft to clean.
Also my backups are so much smaller now :’-)
Nix flakes lets you define as many configurations as you want, and (if you don't specify one) will select based on the hostname.
It's reconstructed from the /nix/store and obviously my homedir is on a persistent volume.
Edit: comments on the latter at https://news.ycombinator.com/item?id=22856199
That's not to say NixOS won't waste your time: it will just waste it in a different way.
If you are at all idiosyncratic about your setup, using Nix is better than whatever pile of bootstrapping bash scripts you've kludged together over the years.
Nix seems more competitive with something like Conda or Spack than a traditional package manager like Apt or Pacman. Similarly, NixOS seems more suitable for deployment in containerized environments built on woefully outdated deps than personal dev setups with generally higher security requirements.
I've experimented with both Nix and NixOS, and while I adore both the beautifully functional language and the endlessly helpful community, I haven't been able to justify the overhead of maintaining a nix.conf, flakes or no flakes, on top of everything else I need to do on my machines. I kept running into issues where some program I needed wasn't already integrated with the Nix way of doing things or something that worked on my Linux setup failed to work on my macOS setup despite multiplatform guarantees.
Nevertheless, I wait with baited breath for the day that Nix replaces Conda among a critical mass of practitioners in my field. I've tried getting a few of my teams to switch (with help from Devbox and Devenv), but it's a struggle to get people to learn new things when their (often worse) way of doing things works well enough most of the time. Heck, I count myself lucky for getting some people to switch from the atrociously slow Conda to the significantly faster Mamba as even that was inordinately difficult despite for latter being a drop-in replacement for the former.
As someone who moved from a directory of numbered bash scripts and GNU Stow to Nix, I can't disagree more. The fundamental difference is one is imperative and the other is declarative (and reproducible), and that makes all the difference.
NixOS and nix-darwin both using nixpkgs is the first time I have the exact same shell and programming/CLI environment on all five of my personal and work machines which run Linux and macOS.
I upgraded them all to the 23.05 versions from 22.05 by updating my flake.lock and doing a rebuild switch on all machines. No regressions.
Some cobbled together shell scripts and a Git home dir management system (yadm) is what I had before and it doesn’t come close. I also dreaded upgrades with the previous approach. And didn’t have nearly the same control pristine replicated environment across machines.
It’s even flexible enough that on Linux desktop machines I have X11 and bspwm DE environment, on servers no X11, and on macOS it configures my system preferences, Dock icons and installed App Store apps.
These types of problems are very rare in NixOS (although I do occasionally see it with the module system, but at least this is config dependent, not system-state dependent). If I apply the same config I have a very high confidence that I will get the same system. I lost my desktop's drive the other day and I was back fully functional within an hour. Most of the time was spent logging into Firefox, Email and various websites rather than installing the system. Managing servers is similarly easy, I would have a hard time moving to something else.
Intrinsic state (like user data or application databases) is still hard, but at least that is the only real concern. Better than dealing with state and config.
I like the terms this article used: Divergent, Convergent, Congruent.
https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-...
In a 'divergent' system (e.g. managed by bash scripts), the resulting system state might diverge from what the bash scripts have, because of manually running commands on the system.
In a 'convergent' system, the system tries to reach a target state by comparing what's there with what it's got.
In a 'congruent' system, the system is forcibly built to equal the target state.
But more generally, 'reproduce' just means 'create the same thing again'.
Nix uses "reproducible" in a more general sense: you provide the same inputs, and you'll get a program which behaves the same way, regardless of whether you compiled from source or downloaded binaries from a cache.
IMO, I think "reproducible build" is enough to unambiguously refer to the former. But, if you can think of a nicer word for "you get the same behavior from the same inputs" than "reproducible", it would be worth suggesting.
Is this hypothetical? Or do you have a link you can share?
Many distros have been going through a difficult time just getting reproducible builds. To claim that you can do that (and more) on any traditional Linux distribution so easily is a bold statement.
> compared to other distros where discipline is required to maintain reproducibility
You can do these things yourself, but it won't be standard, and it will be prone to error, and it will likely be inferior in many ways to a solution that is maintained and improved by countless people.
None of your listed package managers can do that, and that’s not even a difficult thing like installing 2 firefox versions with only this deep dependency changed.
When you install a window manager like say, sway, it will install a terminal, alacrity on some distros.
The distro specifically refrains from deleting alacrity when you're uninstalling sway and that's a reasonable thing to do even though people might disagree on it.
Or multithreaded compilation :P
I'd rather use guix and scheme, but it's behind. If I learn nix, and then guix some day catches up, I'll already know nix and won't want to make the change anymore. Can't say I like the outlook for guix.
> Nix is so robust that you could even nuke your filesystems on every log out
Comments like these makes it hard to understand what is really going on.
Persistent storage is kind of the point of using a computer instead of an abacus.
Most of us who use Nix came from one of those tools. I personally went from bash scripts --> Ansible --> Nix.
Nix is lightyears ahead of Ansible. Since I'm familiar with these two, I'll tell you what's wrong with them:
* They are imperative instead of declarative, so you have a ton of extra cognitive load figuring out the order of actions. I have thousands of lines of Nix config, change one file and it's not gonna break because something in another file was installed in the wrong order.
* They are not suited for managing the entire OS, but rather a layer on top of an existing OS. NixOS manages everything from the bottom up, so there are no loose ends to break you.
* They are not truly idempotent. You have to be very disciplined to keep them that way, including Ansible, despite their claims. My ansible deployments broke constantly
* They don't have rollback capability. If you mess up on nix, a single command or keystroke on boot will bring you back to the last working deployment.
* Their DSLs are not powerful enough of an abstraction. Nix is a fully fleshed out language so you don't have to write a bunch of boilerplate like Bash or need some special module like Ansible to make something happen.
* Git support is first class. You can compose your installation from several git repos, so say you want the cutting edge version of a package, you can install the one directly from the maintainer's repo instead of the one in the nixpkgs repo
* Speaking of which, Nix has more packages than any other distro. Key word here, DISTRO. Bash and Ansible aren't distros, and there is no central repo where anything you'd ever want to deploy is available and standardized and denormalized.
And a Nix deployment has persistent and writable storage, not sure where you get the idea that it doesn't.
Each and every point listed here could have be taken verbatim from a ten year old blog post why Puppet, or later Ansible, is the new great thing. Being declarative and idempotent is the basic design idea of these tools.
Managing every layer of infrastructure and the entire OS stack is also exactly what they aim for, and ironically also what many people regularly quote as why they haven't taken off more. Git support, and module versioning, is also completely on point. What is it that Nix does differently, and why? Is it a fundamentally different type of tool, such as Puppet is from plain Ruby scripts, or is it a better screwdriver?
That Nix is a distribution in itself is an important difference. But how does that affect the use case?
I realize the question have been asked before, but that's because not many attempts are ever made to explain where it sits in the problem space. It is not written for anyone who has experience with configuration management and infrastructure as code tooling, but instead for passive observers with the intention of bootstrapping the next hype cycle?
To say that Nix is a better screw driver is like saying that you could write the same level quality and reliability of software using Bash as in Rust. Rust is just a better screw driver than bash - I suppose it's true in some technical legal sense, but most people won't agree, and it's not true in any sense that is useful or valuable.
They're declarative, idempotent, and intended to manage infrastructure, operating systems and clusters, and coordinate application delivery, key rotation and configuration. Repeatability, rollback, and version control are the basic design tenets.
Sorry to hear that an OS upgrade broke your scripts once, but that's hardly the fault of configuration management tools in general or the Puppet/Ansible/Chef/Salt family in particular.
As you might tell from between the lines, I have some experience with these tools in various environments. But I also see the need for another generation, mainly because of the large shift to Kubernetes application delivery. The insistence of these tools to manage the entire OS stack makes people regard them as too complex for what they need. It is my personal belief that the concept of a host is limiting the continued acceptance of this type of tools and I have been spare time experimenting with other primitives to describe state on, such as binary file archives.
Playing with Nix, it is my impression that it is quite similar to other configuration management tools, a host is still the basic entity we serialize state on. State transitions are a linear graph.
What people describe as problematic with configuration management in general is usually perceived complexity, and Nix seems to have the potential for more of that. But I have not used Nix in anger, or in any type of real world complex environment, and I would be very happy to learn from someone who has experience.
That's what I'm saying, they are not declarative or idempotent in my experience, at least not Ansible. I'm not as familiar with Puppet so I wont say anything too confidently with that, but Ansible is 1. not idempotent as it allows you with ease to execute operations that can modify the system differently based on the system's state, and 2. not declarative, as the operations are step-wise.
Anyway sounds like you have experience and an interest in the field. My experience with Nix is more personal than professional but I'm happy to try to answer any questions you have about it.
I've been a programmer and Linux user for many years, I know a lot of terminology behind it and I think it's a lot less of a problem for me to read technical documentation than for the average user. When I heard about NixOS I thought: "how awesome, it solves some of the problems that I have". But then I started to read official docs and dig into all of it and got quickly discouraged. It might solve "some of my problems" but at a time cost that I just couldn't afford. Well, maybe it's just not for me...
It's much easier for someone to be productive with VSCode without having to go out of their way to learn much.
Whereas, Emacs' requires much more effort to learn, even just to get started; but is much more extensible than VSCode is.
For the user who doesn't want to spend much time learning, surely VSCode is better. For the user who wants to get the most out of their editor, Emacs is a reasonable choice.
I think Nix is comparable. Much of the time, Nix is quite straightforward to use. But, when you do run into something that's hard, Nix can be very difficult to work with.
Maybe there'll be a tool that's to Nix/NixOS what VSCode is to Emacs; where you get the benefits of a declarative config.
With VSCode, you've got your settings, and you've got the extensions you can install. With Emacs, the line between "plugin" and "configuration" is more blurred; you can write your own commands to cover how you do your work. -- It's more likely that an Emacs user has touched ELisp, than that a VSCode user has extended VSCode.
I recall running into a problem with VSCode extensions where you couldn't ensure one plugin would be loaded before another plugin. (e.g. loading the direnv plugin, before loading some other program which uses the loaded environment).
Package management is a complex problem and nix is the fist software that actually solves it, instead of just hiding it in the closet (e.g. docker-like solutions). If you want to deal with packages correctly (and I think we all want to), then this is the price.
Although it will improve on the accidental complexity part, e.g. currently many language ecosystems/software is not built with nix in mind.
I haven't tried that combination. I'm currently using NixOS and loving part of it, but am bleeding on the sharp edges.
Oddly enough, I use NixOS as a network-disabled USB live image for handling my Yubikey, SSH, and GNUPG setup. I'm bashing cryptsetup all the time!
Ironically, I couldn't get the 22.11 graphical installer to work. I had to drop down to an Arch style install (which was fine).
My biggest complaint with NixOS is the pain of trying to run things that weren't built in nix (like Minecraft, or some other binary-only tool). I end up creating a podman image to run some of these things. I'm sure I could also create a derivation for them, but haven't bothered running down that rabbit hole yet.
If you're a programmer, Nix is awesome. But I don't think it's for the masses.
Writing your own derivation is incredibly straightforward and there are tons of useful helpers
Right now I’m using Ubuntu, and it’s awesome, with the obvious caveats, but I am Nix-curious for quite a while and would love to give it a spin in that way if it were reasonably doable. Especially to help friends who are less technical easily install all of the things, it could be a game changer.
You could also install the nix package manager on Ubuntu.
That said, I've used the linked NixOS image under WSL every day at work for about a year, and I've been very glad to have it.
Standalone Nix also works well under WSL2. I semi-regularly use it that way as well, on Ubuntu and openSUSE, for some testing at work.
its a giant pile of symlinks