I had an issue recently that I suspect was related to the gcc bump or having system on one channel and user on another. Or at least the gcc bump made it harder to diagnose and fix. I was doing some odd things like running multiple nix-daemons and having them use different NIX_STATE_DIRs, running non-chroot builds. Basically I deserved it.
Nevertheless, having both system and user on the same channel is good. And running unstable usually fine if you are a power Nix user and can solve the issues that come up. Otherwise a stable channel is probably better.
The trouble that arose was a result of having jackaudio in my system config, at 19.09, and some jack clients installed in my user profile, at unstable. Some of these were unable to connect to the server and others were. And the way it manifested was not at all suggestive of the cause.
There are some packages that I suspect of having bugs and I’d like to be able to get the fixes in a timely way.
It is some work. To run unstable, you basically have two choices (excluding the possibility to run directly from a git checkout, since that increases the probability of resulting in a system that does not boot):
The nixos-unstable-small channel. This channel requires fewer tests to pass. Therefore, this channel typically moves fast, but often results in more source builds, since not all packages may be rebuilt and in the cache yet. Since it requires fewer tests, the small channel breaks more often, often meaning that some package fails to compile. When that happens, you basically have to wait until someone fixes it; or better submit a PR to fix the issue .
The nixos-unstable channel. This channel requires more tests to pass. Consequently, on a random system, it breaks less often and more packages can be retrieved from the binary cache. However, the non-small channel often gets stuck for a few days, because some required test fails. This can be problematic when you want quick security updates. Of course, you could mix both channels, getting e.g. browser packages from the small channel.
Aside from breaking builds, software in the unstable channels sometimes have more bugs. E.g. at some point (I think it was during the 20.09 cycle) GNOME was upgraded, which introduced a bug where mutter would segfault after a suspend-resume. Losing all your open applications after suspend-resume is no fun . I submitted a PR, which was merged quickly, so this bug bothered me a few days at most.
That said, for me running unstable is not much more work than other rolling releases that I used before (e.g. Arch), with the difference that it is much easier to submit fixes for any problems that you encounter. But I would only recommend it if you want to contribute actively to NixOS. With a half-year cycle, all software is always fairly up-to-date anyway and with some exceptions (like your jack problem) you can always get specific packages from unstable or even the master branch.
In my experience, it is much nicer than running sid in Debian, because it’s easier to (possibly selectively) switch part of your system back and forth in case of trouble, and the contributor experience is nicer.
I’m running the nixos-unstable channel and this matches my experience exactly. Also, if a bug disrupts your workflow it is typically easy to roll that particular package back.
For me, part of the point of free software is blurring the line between ‘producer’ and ‘consumer’, so seeing bugs early and being able to participate in getting them fixed is actually an advantage .
Indeed - and I would recommend to contribute actively
I agree. NixOS was the first thing OS that felt like a community to me. I don’t want to be to negative here, but in other distributions there is a lot of bureaucracy and some package ‘owners’ are quite hostile to outside contributions. With Nix it’s easy to contribute, thanks to the GitHub PR workflow and tooling (ofborg) and I feel like PRs only get rejected for technical reasons (they rarely get rejected at all, usually you get helpful comments until it’s in a good shape). So, even without being a committer, you can quickly be a part of and help improving NixOS.
I’m leaning toward just going nixos-unstable then. Especially since I expect that there will particular pkgs for which I would like to get early fixes for, and yeah, hopefully contribute. That is an appealing aspect of this community; being more directly involved and responsible. I loved Debian for years. But in a sense it did feel distant.
I’ve seen where people have defined unstable in their otherwise stable config (or vice versa). But I’ve not been successful in getting that to work yet.
The main concern is about packages that you use, you’re more like to have a broken package, but issues with packages are more likely to have a quick turn-around. If you send in PRs, you can fix it locally, then upstream the fix.
PSA- something I didn’t realize but @danbst pointed me to- as commits go, release notes, and thus incompatible changes too get updated. So right now if you’re running unstable, see the release notes of nix 20.09. After learning of it, I’m seriously considering running “unstable” since I’ve used arch for the 3 years before the last 10 months.
Changing the name is not very difficult, it involves changing a few lines in the channel release script. Most of the cost is around coordination, to switch to the new channel name in public and private repos. Most likely we will have to keep the old name around for a few years so we better be sure that the new name is the one we want.
Maybe a better solution is to make sure new users are hitting a “select your release” page that explains what releases are available and what guarantee they provide.