This is somewhat a common newbie question for arch, which i was surprised not to find here
I would guess most sensible answers from any rolling release distro apply here, but still I wanted to ask your opinions.
case 1: a dev laptop:
browser, messengers are flatpak, so that can easily be updated daily (semi)automatically,
everything else lives in flake-based dev envs, probably updated rarely to keep things predictable
so system is basically kernel, DE, docker and such stuff
case 2: a small server with minimum things installed
i’m the adept of “if it ain’t broke - don’t fix it” ideology, but security is important.
Ideally I’d only want to update only when some bug that affected me was fixed, or some vulnerability in something I use was patched, but there is no reasonable way to know, isn’t there?
I guess it depends what your goals are. I like to have recent security and functional releases, so I run nixos-unstable, updated weekly via github actions. I then install at my convenience or on some of my machines, also weekly.
NixOS is actually not a rolling release distro. It’s stable, rolling or neither depending on what you prefer.
That’s the entire point of stable release distros, and what they do.
Using stable NixOS will only give you security updates and major bugfixes when there is a good reason for them. Then every six months there’s a version bump to update for non-bugfix reasons, with release notes that tell you about significant changes you should adapt to when updating.
This is achieved by having maintainers of stable release distros painstakingly track upstreams they’re responsible for, making sure only updates they deem as necessary make it into your update stream. Debian maintainers even go the extra mile and backport security fixes to ensure there are no feature changes. This is less common on other distros. Short of tracking the projects of all software you use personally, this is the most reasonable way to know when you should update.
So by sticking to stable, you will only get updates when a (major) bug that affected you was patched, or when there was a vulnerability in something you used. Exactly what you wanted!
Once you’ve chosen a stable distro, you then update as frequently as reasonably possible. Package managers (including nix) won’t download things you don’t use, so this will effectively poll for exactly
the moments you actually want to update.
NixOS is of course the best of both worlds, because unlike with debian & co. you can actually choose specific packages you want from unstable on top of a stable baseline. This allows you to have newer features from software you care enough about to track manually, while getting the stability guarantees for everything else.
NixOS is also unique in that it has consequence-free updates - you can always roll back a generation so you don’t need to worry about updates breaking anything ever.
I can recommend RSS feeds to keep track of unstable packages so you don’t get ambushed by nixpkgs version bumps
Hence, assuming a stable NixOS, perhaps with some unstable you know about peppered in:
For personal computers, I think updating once per boot cycle - so ~daily - is ideal, because that will line up nicely with full kernel/service restarts while being relatively unintrusive. Personally I do my updates ~weekly, because I don’t purely use nixpkgs stable and nvidia+a recent kernel requirement makes things annoying.
For servers, use your judgement of what your services need and when you can afford downtime. You can still update frequently, and simply not reboot (and therefore not actually restart/update most services or the kernel) until you can afford downtime again, but depending on the software you run the resulting drift with kernel headers can cause problems. Overall, weekly on a day of relative calm isn’t a bad idea. IME Wednesday shortly after office hours is usually chosen by professional ops people because it’s the furthest from Friday and Monday you get, and the least disruptive as well, especially since users know about and expect it. Schedule emergency maintenance as major bugs in ssh and whatnot are discovered.
If you have high uptime requirements of course you know more about kexec than I do, have specific business guarantees, and at least have some kind of failover in place. You probably wouldn’t be asking this question, either.
In addition to the available methods of picking a mix of packages from different branches/channels, the above point is really key.
For a dev laptop, having all your tools as part of the flake devShell is great, especially where you have different branches of your code that need different versions of the tools; switch to that branch and the relevant versions of deps and compilers and whatever just appear.
But this means they don’t need to be part of the system installation at all, and that in turn means that the answer to this question matters much less. That’s great flexibility!
You can pick a release desktop for stability, and not get stuck with older versions of dev tools that can be so frustrating on other platforms
You can pick a more current desktop, and not have your dev tools broken by surprise updates, and of course roll back in the very rare case of something that breaks the desktop as a whole.
You can even pick a non-NixOS desktop, if you really want to, for some inexplicable reason.
thank you for an expanded answer!
I guess i had sort of a gut feeling that somewhat aligned with what you are saying.
My servers are all personal ones, so there is no too nigh uptime/availability requirements.
But for personal laptop - i just keep forgetting to update because of the workflow i have: you work, you close laptop to sleep, you open laptop, you work… so it’s not really ever off, and i do need to keep remembering to update it. and sometimes the “evening” arguments not to are as simple as: well i have all these terminals and IDEs opened… I don’t wanna close it all and reboot, maybe later… it can go up to a month like this
as about RSS feeds - do you mean the standard github’s feed? or is there something more specialized provided by nix community/foundation
Yeah, I’ve seen these kinds of workflows. Suspend-to-stop-thinking. Getting frequent full updates like that may require some workflow changes. Making your browser and IDE restore sessions on start can help, and I think tmux/screen have something like that too.
Usually, yeah. It won’t sync up perfectly with nixpkgs bumps, but it will be close and you get advance warning.
Great tips and very useful responses here in this posting! Thank you all very much for sharing.
I am really interested in this. Being a new nixos user, I searched high and low and could not find how to do this so I fully switched to unstable due to a number of key packages being older than my config/db/data. Is there an article or howto that you can refer to that details how to do this for a new nixos user?
