I dont get it why Nix have different stable and unstable channels. Isn’t Stable channels necessary only because of dependency hell? Like in Debian you need a Stable channel so there is no scenario where there is a package that needs dependency x version 1 but there is only version 2 in the repository, you cant update packages until all packages that depend on its dependency are also updated.
In Nix you can have multiple versions of dependencies in paralel, so why not only get rolling-release channels?
In more words: no. Stable channels receive minor version upgrades and skip major ones. The idea is that most upgrades from 1.2.1 to 1.2.2 are less risky than upgrades from 1.2.2 to 1.3, by the conventions used by many software projects. So stable channels are for people who would like to set aside two windows a year in which to deal with all the things that a 1.2.2 → 1.3 upgrade might break, and unstable channels are for people who don’t mind dealing with bugs from 1.2.2 → 1.3 upgrades any time they run nixos-rebuild.
(Security fixes are also included in stable channels, so for example browsers and other security-sensitive software will get major updates on the stable channels as well. And of course even bug-fix releases can introduce bugs as well. But even with exceptions, the separation still makes things better for people who want to be able to schedule time for upgrades going wrong.)
There’s also the secondary benefit that unstable users get to be beta testers for changes that will eventually be in stable, so that when a release is not imminent, more bugs get caught and fixed before stable users see them.
I understand but i still find this way of thinking that 1.x.1 updates are more prone to bugs than 1.1.x a little nonsensical. In my understanding, the 1.1.x updates are just the first pass to get to 1.x.1 updates, or that may change a lot between projects. That is still more irrelevant if we acknowledge that nix can pin packages in older versions if something wrong occurs.
Anyway i think there is not much negative impact about the existence of that channels. maybe unstable could be the default.
Stable or unstable have nothing to do with dependency hell. As @rhendric mentioned, stable vs. unstable is all about the timing of breaking changes; all accumulated breaking changes at once at two fixed points a year vs. breaking changes as they come at unpredictable times but spread throughout the year.
Breaking changes happen in either case because they must. Stability is an illusion; nothing is stable.
A software that worked yesterday could stop working today merely because today’s date is different.
Thus, software must be changed to fit the changing conditions of the environments it runs in which ultimately is dictated by our reality.
With significant effort, you can however mitigate the effects somewhat and delay most necessary breaking changes for a little while and that’s what stable distros do.
Note that dependency hell still exists in Nix, just just pushed one abstraction level up. Rather than being inherent due to the on-disk format, dependency hell in Nix exists at the abstract Nix expression level. This is of course much easier to manage and doesn’t have most of the constraints that make dependency hell impossible to solve in on-disk formats but that doesn’t mean it’s trivial.
While we could have infinitely many versions of some software, maintaining each of them costs human time. Thus, we usually only have one version of any given software for any given Nixpkgs revision and only make exceptions where it’s justifiable to maintain multiple. Integrating that one version with the one version of each other software is still necessary and the core of our job as distro maintainers.
Channels (plural)? We’d only need one channel if we were rolling-only.
I understand now that stable means stability against bugs, which is very different than what I’m used in other distros like Debian where, when something breaks, its sure that it has something to do with dependencies and the interconnection of packages.
But I couldnt understand what you said about dependency hell in Nix: you said nixpkgs revisions usually only gives one version for each package, and that maintainers have to work on nix expressions. I don’t know much about how nix works but whats the issue with using other nixpkgs revisions where the others packages versions are available, why nixpkgs revisions exists? and why is so hard to maintain a nix package expression, you still need to work on it after the package runs correctly? (I understand is hard work of maintainers to do the first nix expression, but dont understand the work after that).
Patches for different versions, ensuring deps’ current versions work, other testing, etc. DLL hell isn’t a thing (edit: MOSTLY) but binaries are still linked against libraries. And in NixOS modules we also create our own breaking changes that cannot be backported to stable.
I think in every distro the main point of stable releases is to get fixes for significant issues while minimizing any kind of incompatibilities (breakages). It’s not just about dependency hell (say, ABI compatibility).
No, it means stability against deliberate changes. I.e., you will not have to change your nginx config between updates, unless there is a bug (and in theory upstream promises to reverse any accidental changes to configuration formats in the next patch release).
This is usually what people who actually do software releases mean when they say “stability”, there’s no realistic way to guard against actual bugs - otherwise you’d just not release the buggy software in the first place.
NixOS/nix do mean that your recursive dependencies can be pinned to anything, but you still often want stability from the software you directly depend on, so NixOS needs versioned releases. You don’t want to have to figure out a new nginx config format when there’s a critical CVE that allows RCE through opening your home page.
Desktop users often care less because glossy GUIs can largely auto-convert configurations and do fun popups that tell you about significant changes and such, but that’d be wholly inappropriate for unattended servers, which are a big use case for NixOS (probably the more common and polished use case, in fact, we desktop users are frankly weird nerds).