My experience is that the rolling "NixOS unstable" channel is more usable. The releases don't offer any improvement in security and have less maintenance effort overall. And despite the name "unstable", the breaking changes typically incubate in the staging branch first for a few months.
But that's using it on a desktop, maybe on a server releases are more useful.
I would recommend anyone using NixOS in production to use the release versions. That's what I do on my servers..
Like for other distros, the point of releases is that they don't upgrade random software under your feet, resulting in unplanned behaviour changes and unplanned required maintenance.
Like for other distros, release channels get important upgrades and minor bugfix releases of upstream software.
NixOS releases are every 6 months, so that's frequent enough to have pretty up-to-date software most of the time. NixOS also makes it very easy to cherry-pick fixes from master and make custom changes (it's just a /git cherry-pick/ away), allowing to selectively upgrade things that you need for your use case.
Interesting. I was not aware of the staging branch. I thought that patches are always merged into master and then automatically trickle down to unstable once all of the integration tests pass.
How often do you find yourself performing a rollback? I've always stuck to the stable channel, but I may give unstable a shot if it doesn't break too often, as you say.
That was how it worked in the past, but it becomes frustrating because some changes result in many, many package rebuilds which hold up everyone else, or otherwise drains resources of the CI system, which would be better spent building existing packages. Staging is generally where changes that result in mass rebuilds go (or may introduce large instability) in order to keep the main branch "up to date".
Changes that are backwards incompatible (but do not result in mass rebuilds) can and will often just go to master directly. For example, NixOS module changes rarely result in mass rebuilds, even if it breaks an API -- but changing the default kernel version does. The latter would go to staging.
I exclusively use the unstable branch on all my Nix/NixOS machines. I rarely do rollbacks. But it's important to note that I'm a developer with commit access, so I can basically "just" fix things if they're problematic. Not everyone has that luxury. (Many Linux distro maintainers likely operate this way, I guess. :)
There have been events in the past where unstable has had changes that made rollback impossible. In particular, if the bootloader becomes unstable somehow, your rollback capabilities are toast (and you won't know until you reboot, when it's too late). But I don't think anything like that has happened in a long time...
> I exclusively use the unstable branch on all my Nix/NixOS machines. I rarely do rollbacks. But it's important to note that I'm a developer with commit access, so I can basically "just" fix things if they're problematic. Not everyone has that luxury. (Many Linux distro maintainers likely operate this way, I guess. :)
An important thing with NixOS is that since the whole distro is built from a monorepo, it's also very easy for an advanced user to just git clone and fix the problematic things too (and hopefully send a pull request!).
I've used it on servers, its handy but the install process is pretty weak compared to some other OSes. A lot of the drivers were pretty behind so custom builds had to be made.
Nix on Ubuntu was pretty useful, I tried Nix on FreeBSD but was disappointed.
Two or three weeks ago I switched from Ubuntu to NixOS. I love it now -- but the first few days were rocky.
The first few times I installed it, once it was installed I could not connect to a network. Eventually I determined I could add these to `environment.systemPackages.pkgs`:
```
networkmanager
plasma-nm
```
I also ran into a permissions issue -- when I migrated my data from Ubuntu I couldn't access most of it. I still have Ubuntu at work so I have to be able to move between the two. The solution was to discover that the default user id NixOS is 1001, whereas the default in Ubuntu is 1000. Adding this to config nearly solved that:
```
# User accounts.
# Don't forget to set a password with ‘passwd’.
users.users.jeff = {
uid = 1000; # for compatibility with Ubuntu
isNormalUser = true;
extraGroups = [
"docker"
"wheel" # for sudo
"networkmanager" # for the plasma-nm widget, and
# the privilege of changing settings (adding networks)
"audio"
];
};
```
I say nearly because NixOS won't let you change uid (at least via `configuration.nix`) for an existing user. I had to log in as root, delete the user, rebuild, reboot, then add the user with the options I needed, rebuild, and finally reboot again.
And between those two problems came the problem of trying to use MusNix as a channel (for apps to make music). I followed the instructions on MusNix's README.md and totally broke my system. I found an issue on MusNix's issue tracker with the same complaint, and the response was "are you using an old version of Nix?" But I was using 19.03, which at that time was the latest version. My system told me I had conflicting hardware configurations (some supposed-to-be-unique value was set in multiple places to distinct values), and it wouldn't let me rebuild until I fixed that, and I had no idea how, so I just reinstalled. (Later in that issue the solution seemed to be, "Don't use it as a channel, even though the README says you can.")
But each reinstall was much easier than the last, because (unlike Ubuntu or anything else I've ever used) you don't have to repeat the same set of actions each time. Instead your config script gets more complicated, and you just copy that into the new system, and it handles the rest.
There are still a few tweaks I do by hand, out of ignorance -- I set some KDE options manually, and ... hmm, maybe that's all. But I've read that even those can be copied from one system to another; they just require some digging, as they're scattered around rather than contained in a single place like you might expect.
But that's using it on a desktop, maybe on a server releases are more useful.