💾 Archived View for gem.twunk.uk › log › 2024-01-29-setting-up-nixos.gmi captured on 2024-05-12 at 14:48:51. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Setting up NixOS

I got a new laptop (yay!), so I need to set it up. A good opportunity to try NixOS for the first time. Actually for the second time - the first time, a few years ago, I bounced off it almost immediately.

Miscellaneous thoughts on NixOS after having used in for just a couple of days (January 2024):

The documentation is pretty bad. The option and package search is ok except that there are things in those views that are totally unexplained. For example: The laptop has a fingerprint sensor, so I search (on the internet) for how to enable that, and I get it working! Hooray! But then I find that it doesn't actually work nicely because of... well, reasons I'll get to in a moment, but I decide maybe I can ues it for the lock screen only. In the options search I find that PAM options in NixOS have a mechanism for enabling/disabling fingerprint auth support in PAM. And the option is described as "security.pam.services.<name>.fprintAuth". There is no description of what "<name>" refers to or how to work out what it needs to be. Eventually by trying various things and digging fairly deep into the underlying Nix code that implements PAM configuration I work out that the <name> is the "application" for which the PAM configuration applies. Now, people with extensive knowledge of PAM may find this obvious (since the <name> is under a table called 'services') but for someone with much more basic knowledge of PAM it took me a while to work this out. Of course this is just a single example and I have encountered similar problems when trying to work out how to correctly use various other NixOS configuration options - the core problem here is that although options have metadata used to build comprehensive and searchable documentation (great!), the actual documentation text provided is frequently very basic, not really giving any useful information and it is not presented with adequate context to understand. For example the fprintAuth option has documentation but the pam.services table itself does not (it's not an "option" so there's nowhere for metadata to attach in the current structure).
For some basic software it's obviously available but it's not clear which actual package is needed. For example, I needed a C++ compiler - ok, I'd like to use clang. There are many related LLVM+Clang packages. How do I pick? They are not documented well enough to make an informed decision.
Nix doesn't play nicely with "more traditional" ways of doing things sometimes. For example, NixOS doesn't populate /bin or /usr/bin (well, ok it puts /bin/sh there and /usr/bin/env, but *that's all*); instead everything is made available from various other locations using $PATH. Sure, ok, that's fine for most purposes. However if you have a script with a shebang line, if it doesn't use exactly `#!/bin/sh` or `#!/urs/bin/env` then it won't work. You _must_ use `#!/usr/bin/env python3` or whatever similar shebang. Now, maybe that's good practice anyway, so ok. On the other hand, maybe it's not good practice (opinions vary about whether 'env' supports passing extra parameters through or not). Regardless, in practice there are lots of scripts floating around that don't do that and instead assume that /usr/bin/python3 (or ruby or whatever) exists at that path. Those scripts all break and need to change to run successfully on NixOS. Or you need to employ weird magic (there is a magic FUSE filesystem available that _looks at the PID of the requesting process_, grabs its PATH out of its environment, and uses that to create a magic view of /usr/bin. This is... well, genius but also completely crazy and IMHO a cure worse than the disease in terms of being able to understand what the hell is going on, since it involves SHENANIGANS of reading PATH out of other processes' environment)
Did I mention the documentation is bad? The install manual is a weird combination of (a) minimal in terms of its coverage of the actual system configuration that you may want to set up when installing the system, but then (b) also lists a whole raft of randomly chosen pieces of software that you might want to run. This is just really poorly structured.
NixOS is blessed-path solutions for really core things. Using secrets in your configuration is one example: It's not at all unusual to need to use a secret from the configuration (for example if you're using immutable users so all your users are configured within the nix config then you'll need to set up your user with a password - probably anyway - and _that's a secret_). You absolutely shouldn't put secrets directly into the configuration because the config is world-readable/exposed in various ways. "This is totally a solved problem!" I hear you say. And yes, if you search on the internet you'll find plenty(!) of blog posts and wiki pages and whatever about how to do this. But the problem there is that there isn't a single recommended way of doing it that's described clearly in the canonical documentation and is maintained as part of the core Nix system. Instead there are N different solutions and it's up to you - the brand new first-time NixOS user - to read a bunch of blog posts and work out (a) which ones are still relevant, and which are outdated, and (b) which approach is going to work for you.

Overall, I maintain the position I had last time I tried NixOS which is that I really like the _core_ idea: a system where the configuration is fully described in a clean set of configuration files that can be versioned together and can include comments and basic abstractions and so on, and that in total can be built into a whole system image (or similar) and allow you to trivially try things out and revert back to previous configurations safe in the knowledge that you'll always end up with a perfectly "clean" system after your experiments. I like that idea, it's great. However, NixOS in practice has several problems: the configuration doesn't feel like it has a unified vision behind it of how things should work. The documentation is very lacking. Problems that everyone knows are problems have solutions that are widely known by the community but that haven't been actually curated properly and integrated back into the core, so every individual user is left to make a lot of technical choices about how to solve their problems, without adequate information to guide those choices (and frankly they're choices that mostly shouldn't be necessary anyway). And of course there's the whole thing of Nix being its own special programming language, though that doesn't bother me so much.

Anyway, this time I'm (so far - it's only been a couple of days) sticking with NixOS. Hopefully I can stick with it long enough to get real advantages from it. I am looking forward to gradually evolving and improving my system configuration over time and putting it in version control and, if I get comfortable enough with it, getting it to the point where I wipe my desktop and switch to NixOS there as well (and then I can actually keep configuration in sync between the two machines easily, at last!)