NixOS Part 1

Recently, I switched both of my primary laptops from Arch (cesium/vulcan) and Windows (carbon) to NixOS, mostly on a whim. Some friends of mine have been encouraging me to try it out for a while, and I did so over the winter break on Carbon, but I couldn’t get flakes to work properly, so I abandoned it and put Windows on it. What I needed from carbon was for it to work as a notetaking tablet, and Windows came with OneNote so it was easy to get set up.

Ever since, NixOS has been in the back of my mind. The idea of a system configuration tracked in Git that I can use on clients and servers intrigued me and I wanted to see how I could use that in my systems administration.

First Steps

The first thing I did was talk with my friends who were trying to get me to use NixOS in the first place. They recommended that I go with setting up my flake immediately, instead of trying to merge my existing configuration.nix into a flake later. This turned out to be the right move, and I’m now tracking my system configuration at muirrum/nix. This has led to me being able to share a baseline configuration across both carbon and cesium, including my user configuration and the packages I expect to have (including neovim, zsh, firefox, and my custom fork of dwm).

Encapsulate and Unifiy

Everything else I’m planning to split into modules, for both my user configuration and my system configuration. I’ve already started this with nixos/modules/*.nix and home/modules/mail.nix which set up system modules like Steam, Darktable, and virtualization, as well as my mail sync systemd service. That way, I can enable the things I need per-system, while still maintaining the ability to centrally manage it. Now I can add ./nixos/modules/steam.nix to my system configuration and I get my Steam setup on every system, every time. It’s the same with Darktable, libvirtd, or mbsync. Getting a unified system configuration is as simple as nixos-rebuild switch in my flake directory. I’m planning on rolling this out to my servers slowly, starting with my physical server during the next break.

Packaging

NixOS is based on the Nix package manager, which allows developers to describe exactly which versions of which packages should be built to make their app work every time. I’ve been using this to package my bots and configure their development environments so I don’t have those tools polluting my $PATH outside of the directories where I intend to work on them. I have one of my bots set up to automatically build a small Docker image for me, so that I can quickly push it up to my private registry.

Conclusion

I plan to keep using NixOS for all my devices. I’ve found it fun to tinker with, especially since it keeps a backup of previous versions of your system, so that if you mess something up you can just reboot and choose a different one. I haven’t needed that yet but I’m sure it’s coming soon, knowing how much I like to mess with things that shouldn’t be messed with.

I’ll probably write about my experience getting NixOS set up on my home server in another post.