I’ve always used nixpkgs-unstable but am considering dropping back to a stable channel now, particularly when pinning nixpkgs in individual projects. I’m surprised there’s no nixpkgs-stable though - I would expect this to just point to “the latest stable release channel” (i.e. 19.03 right now, but pointing to 19.09 once that’s released). That way you get stability, but when a stable release is made you get that upgrade by default, rather than having to upgrade release branches everywhere you’ve pinned nixpkgs (you can always drop back to the previous named stable if that causes issues).
5 Likes
Is nixpkgs-unstable not stable enough for you?
Some times it can be difficult to find a channel that works both on darwin and linux when using it as a nix-shell. Other than that it’s working pretty well for me.
1 Like
Jumping between stable branches has backward incompatibilities. I’m fairly certain that’s one of important “stability” aspects, so the “nixpkgs-stable” name might be a bit misleading. When you do such a change on a “production system”, you certainly want to at least read the release notes (and typically do some more testing), which is why I believe it’s usually better to do that step manually (twice a year).
8 Likes
It’s less about stability (things rarely break, which is great). More about frequency of updates. Whenever I nix-channel --update on unstable I need to do a lot of re-downloading (a bit annoying with slow internet), and a whole lot of rebuilding for customisations and other package sets which aren’t in nixpkgs (e.g. lots of ocaml). I assume (untested) there would be fewer rebuilds required on a stable branch. Pretty much everything would need a rebuild every 6 months when the next release came out, but outside that there should be a slower rate of change.
For clarity I wasn’t suggesting this would replace the actual stable release branches, just a meta-branch tracking the “latest” stable branch. On a production system I’d pick a specific release, but for my home system it’d just be like “unstable” but on a larger timescale, with far fewer incremental updates required between release versions.
There may be a better name than “stable” though. “nixos-release”?
4 Likes
The stability is okay and given the ability to go back to a previous build if something breaks it is very usable. But I would say that it’s definitively not comparable to a stable branch.
Especially annoying to me is that if something breaks, it takes some time to be fixed. It happened multiple times to me that something broke and I couldn’t rebuild my system (and e.g. add new packages) for several days - until the fix (which could be a git revert or a oneliner) was through hydra. (maybe it would make sense to think about a way to add quickfixes faster to unstable). In my eyes it’s still quite far from a stable release, I see it more like a testing branch 
1 Like
In other distros the channel switching would typically happen at another level. For example apt-get update notifies the user that there is a new system release available. Once the user is ready to do the upgrade they can do it with a command that switches the channel for them. We could implement something similar in the nixos-rebuild command to check the list of releases and compare it with the current system. I think it’s better than creating yet another channel as users are already confused by the current set of options.
I stopped using nix-channel for that reason. Once you know how to do it, it’s easier to use a git checkout and rebase your changes on top of the tracked channel. It removes the hard dependency for things to be merged or go through the build pipeline before they can be used which is great. I am no longer frustrated if things move slowly 
-
set
export NIX_PATH=nixpkgs=path/to/nixpkgs-checkout:nixos-config=machines/my-machine/configuration.nixusing direnv or a wrapper script that then invokesnixos-rebuild. -
to use the same nixpkgs checkout everywhere, add the following in the nixos configuration:
{ pkgs, ... }:
{
nix.nixPath = [ "nixpkgs=${toString pkgs.path}" ];
}
- remove all the channels
[sudo] nix-channel --remove nixos
9 Likes
This is the reason why I now follow 3 channels simultaneously. Most of my software come from nixos-stable, but since some fixes take a long time to land there, I also have some software from nixos-unstable. Then there are packages which broke when I switched from 18.09 to 19.03, so I have few packages from the old stable as well
1 Like
The main point of the waiting is to avoid such breakages. The channel only updates after a set of tests passes.
Yeah that’s obvious to me. It’s nonetheless annoying IF something gets through
As I mentioned, it may make sense to be able to mark a PR/commit as “quickfix” or “important” so that it gets tested more quickly. But I do also understand that it may not be something we would want to have, as it can be really hard to tell/define when a commit is “important enough” to add this label.
Absolutely right. Unfortunately, having a -stable alias for the channel is likely to make people think “Oh, stable? I want my production servers to be stable”, then suddenly their services are hosed after the next release upgrade. That’s why I think it’s a bad idea to have the alias.
What do you mean by fewer incremental updates, and what benefit do you get from it?
2 Likes
Let’s say some package (say, libfoo) is updated every month on average in the unstable channel. That means I have to re-download or re-build all its transitive dependencies every month. On a stable channel, that would go closer to every 6 months (aside from security updates).
That’d make me less reluctant to update, because right now updating a channel means waiting around for ages while things rebuild or re-download. This can be hours depending on what’s changed, so it’s not something I want to do every few days. If that update was due to a minor feature in a library that I don’t know about or use, it doesn’t feel very worthwhile. If it’s due to a security update or a every-6-month feature jump then that’s much more reasonable.
I’m sure this isn’t a normal case, but I have a sizeable stack of stuff which is not in nixpkgs/hydra, so “just use a binary cache” won’t speed anything up.
4 Likes
Yes, currently the updates can consume a lot – usually I’d say on the order of gigabytes per month of both network and drive, for a desktop machine at least (servers might have much smaller closures).
If you’re looking for a stable channel that only updates every ~6 months, modulo bugfixes and security backports, isn’t that precisely what the nixos-YY-MM channels are?
Apologies for necroing this thread, but does it make sense to have a nix rolling channel that is kind of a hybrid between stable and unstable?
The idea is that its rolling release (i.e. you don’t have a set 6 month release cycle) however the channel only gets updated when hydra’s test suite passes for a certain confidence level.
I guess the issue I have with nixos-stable is that the 6 months is completely arbitrary, it would make more sense to have a technical definition of stable and a channel that only accepts versions that pass that definition of “stable”.
2 Likes
This is what unstable already is. If you don’t want to wait for Hydra and can tolerate more instability, you can use nixpkgs master directly.
5 Likes
Then maybe its just a naming thing, I would associate the current nixos-unstable as a rolling release and nixos-master as unstable?
1 Like
Yes, unstable is a rolling release; but I wouldn’t merely call master unstable, because it doesn’t even depend on boot tests passing or anything—using master can break your boot and your boot-time rollback without warning. With nixos-unstable, you have a bit of protection against that sort of thing at least.
The reason unstable is still called unstable is that breaking changes can happen at any time. Each channel bump may mean needing to edit your config. With stable channels, these backwards-incompatible changes are, to the best of our ability, bundled into packets you only need to deal with every 6 months, so that you can (if everything goes well) write your config enabling autoUpgrade, deploy it, and forget about it until the next release (though some logging and monitoring wouldn’t hurt ). If you’re a desktop user and know what you’re doing, maybe you’d prefer to use unstable. If you’re managing a desktop for a less-computer-literate family member or some servers running your company services, then you probably want stable.
Personally, I use stable on my laptop, but am considering switching to unstable so I can catch and report/help fix regressions earlier.
6 Likes
One way to view the name “unstable” is that it changes a lot. (And that by itself is some risk for breakage.)
2 Likes
Its more accurate to say that this is more closely connected to “rolling” in terms of terminology than unstable. Its the same reason why Arch Linux, for example, is called a rolling distro and not an unstable distro.
Unstable generally means a master/nightly branch that has only minimal (or no testing) and hasn’t been bundled into a release form yet, from what I gathered the unstable nixos branch still needs to pass Hydra tests in order for it to be released.
6 Likes
nixos-unstable feels stable enough for me for a non-critical desktop setup.
Renaming it to nixos-rolling would work quite well. While the name still implies some instability it also reflects the fact that the channel is reasonably tested and not just a volatile development branch.
8 Likes