How I like to install NixOS (declaratively)
57 points by stapelberg
57 points by stapelberg
Great post, Michael! Thanks for this writeup! I learned some new tips.
I was looking for an alternative to Flatcar Container Linux and tried out NixOS again (after an almost 10 year break).
I find that the best NixOS blog posts are from people who learned Nix recently.
There seems to be some point in learning Nix where people just morph into aliens who only know how to communicate with other Nix aliens. They’ll explain how to fix some issue by saying something like, “Oh, just add these three lines,” and omit where you’re supposed to add them, what command you run to apply the change, or what flake/package those lines implicitly depended on installing beforehand.
I appreciate Nix posts like these where the author is still a human that remembers how other regular humans think about Nix/NixOS.
Thank you! I plan to share some more writing on Nix/NixOS use-cases and will try to keep it as approachable :)
nix aliens
100% this. I feel like a lot of very specialized disciplines with broad applications fall into this trap, but it made me chuckle.
Nix is very self-referential. Things in Nix tend to be simple, by building on how other things in Nix work, and it all makes sense… after you know Nix well.This makes it hard to describe anything, because it’s a bit like unwinding an infinite spool. It’s tiresome to explain something to non-Nixer when it would be sooo much shorter, if you were explaining it to a Nixer. Some stuff is so simple that it appears obvious (to a Nixer) - explaining them seems unnecessary. On top of it, after a while it’s like your whole computing paradigm became one with Nix. Remember - Nix can do almost anything, in a Nix way. You forget how it was to do things not in a Nix way.
It is hard to communicate because in a way it is a completely different culture/civilization. The difference between Debian and Fedora is like between UK and France, while NixOS would be like donno… Japan… in a different century.
Really well described.
I think the reason (besides the body snatching) is because there are so many ways you can set up your system that where you’re supposed to add it and what command to run changes drastically depending on decisions you made earlier. The frustrating part is that you made those decisions earlier on a whim, or based on a random blogger’s opinion because you had no idea of the long term consequences.
I almost wish they could figure out how to write a Nix book that explains in technical depth the resulting consequences of every choice. I can only guess there’s very few people that actually understand them all.
Probably the key is just starting SOMEWHERE and learning from there. I really like the approach in the article. In my opinion it’s where a full NixOS makes the most sense. I currently use nix on top of other OSes for dev work. I’m not there yet in using NixOS on my workstation… the all-or-nothingness of it is too frustrating for that.
Perfect for making server cattle though. Reminds me of https://grahamc.com/blog/erase-your-darlings/
“Erase your darlings” isn’t about server cattle, in my opinion: it’s about control of your “pet” systems.
One of my gripes with Linux used to be that, even though I could get my system working exactly the way I wanted to, it was always a one-time thing and all the knowledge I gained setting up my system would end up being ejected from my head shortly after. The entropy of my system would start growing organically from the moment I installed it, and it would do so until I decided I didn’t like my current distro anymore and it was time to reinstall. For me NixOS was a tool to manage that entropy; I don’t feel the need to start with a clean slate anymore because NixOS lets me control most of everything that matters in my computer.
“Erase your darlings” is a further step towards total control over your system: it’s about controlling where the entropy is allowed to grow. It can be useful in servers, but I think it’s primarily an extension of the mindset of control that NixOS encourages.
This is pretty much exactly how I install NixOS on machines these days. I find that disko can be a bit of a moving target, so when I go to install on a new machine (which is not frequent) there’s some catch up to do because something has changed. Other than that, being able to configure a bunch of different ZFS data sets, etc declaratively is really nice.
Note that disko also states that there might be breaking changes between updates. For that reason, I pin disko in my flakes to a specific release tag with an update note:
# Check https://github.com/nix-community/disko/blob/master/docs/upgrade-guide.md
# before updating.
disko.url = "github:nix-community/disko/v1.12.0";
How would the nix run nixpkgs#nixos-rebuild -- --target-host michael@zammadn ...
trick need to be modified if I want to run it on macOS-ARM and the target host is either ARM or x86 NixOS? Is this even possible?
You need a builder for the same system. Which often can be the target system itself.
From my justfile
which I use to deploy stuff to computers:
deploy-to-remote-with-self-builder FLAKE_HOST SSH_HOST="":
#!/usr/bin/env bash
SSH_HOST={{SSH_HOST}}
if [ -z "${SSH_HOST:-}" ]; then
SSH_HOST={{FLAKE_HOST}}
fi
nixos-rebuild --flake .#{{FLAKE_HOST}} \
--target-host "${SSH_HOST}" \
--build-host "${SSH_HOST}" \
--use-remote-sudo \
--fast switch --impure
Another approach is just to rsync
your files, ssh and run in there.
Ah, that makes sense. Thanks!
It seems I can either use the target host or a VM running on my Mac as the build host. Usually, the target host is a VM running on my Mac, making things even easier.
Another approach is just to rsync your files, ssh and run in there.
That’s what I’m currently doing, but my hope was to keep all the configuration on my main system.