Unstable -- Living on the Edge

Help
1

So I just had a painful experience that was rooted in my running 19.09 in my configuration.nix and nix-enving unstable pkgs in my user profile.

So maybe I should just go all unstable? Is that roughly like sid in Debian? Is it recommended? If you have done so, what are your experiences and suggestions?

1 Like
2

What was the painful experience?

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.

3

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.

4

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):

  1. 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 :wink: .
  2. 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 :frowning: . 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.

5 Likes
5

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 :wink: .

Indeed - and I would recommend to contribute actively :slight_smile:

4 Likes
6

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.

Ok, thatā€™s enough group-hugging for today :wink: .

7 Likes
7

Thanks for the input!

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.

1 Like
8

OK, so Iā€™m unstable now. So far so good. :slight_smile:

2 Likes
9

The unstable release is actually fairly stable. Core packages still have to build for the channel to be updated. They can be found nixpkgs/all-tests.nix at f4d6ed2e8b26657726b46bfe7afc84a2e308bdf9 Ā· NixOS/nixpkgs Ā· GitHub

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.

2 Likes
10

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.

1 Like
11

I am running unstable for years and itā€™s actually stable. There has been a few issues from time to time but nothing a rollback canā€™t fix. We should probably rename it nixos-master or nixos-rolling.

4 Likes
12

Iā€™ve been using unstable on workstations as a daily driver from when I started. All servers @ $work run stable.

Unstable is perfectly fine.

1 Like
13

I hear a lot of people make this suggestion but I wonder what is involved in this?

Personally initially I was a bit scared of the unstable name and later ididnt bother learning where to find backward incompatible changes (so much else to learn). Naming it rolling would helpā€¦

2 Likes
14

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.

3 Likes
15

Is there a more readable version of the upcoming release notes than just looking at the XML file in GitHub?

(Sorry if this is in an obvious place, but quickly searching Discourse and DuckDuckGo didnā€™t turn up anything likely.)

Iā€™ve thought about switching to unstable for a while, but being able to quickly see what the breaking changes might be has given me pauseā€¦

16

I did a manual render- there are instructions but briefly- go to the top level dir in git and run nix-build nixos/release.nix -A manual.x86_64-linux

1 Like
17

Besides @SRGOMā€™s suggestion, you could also look at the latest Hydra build result for the manual:

https://hydra.nixos.org/job/nixos/unstable-small/nixos.manual.x86_64-linux/latest

(Click on the Manual link on that page.)

2 Likes