I love NixOS but does it not update too often? Or is it the ability to pin to specific package versions in isolation that would make it a selling point to CentOS (for Reasons) users?
The only thing that makes always-ancient RHEL and CentOS attractive is that enough other people are using identically the same image, exploring its bug envelope thoroughly and sharing the costs of necessary updates.
NixOS is a great idea, but after using it for a couple months last year I migrated away. Too many of their packages are broken (as in, can't even be installed). Somebody cited a lack of testing resources, resulting in publishing packages whose builds haven't been tested.
The worst was finding that a package I absolutely rely on (I can't remember which one, unfortunately) had been reported as broken something like two weeks earlier, and hadn't yet been fixed.
I hope something changes there, even if it means cutting 80% of the packages out of the official repo. Nix is too good an idea to have a broken flagship distro.
For stable releases, there is an RFC [1] that proposes to push back the .03 releases to .05 and the .09 releases to .11. This will align the release cycle of NixOS after that of Ubuntu and Fedora. Hopefully, this will lessen the load on testing/fixing high-profile package sets (systemd, GNOME, KDE) and as a consequence leave more time/manpower fixing the longer tail.
even if it means cutting 80% of the packages out of the official repo
There are different opinions on that. Some contributors believe in a large, single monorepo, while others think nixpkgs is too large.
Personally, I have moved from the first group to the second. There are many packages with probably only a handful of users, but they clog up the PR stream. Even worse, many of those packages do not have active maintainers, so they end up being maintained by people who are long-term nixpkgs maintainers/committers (and typically have a high maintenance load anyway).
It's kind of interesting that nixpkgs grew so large, because it's one of the distributions that makes it the easiest to add third-party package sets. I guess it's because the bar for contributing a derivation is low (you basically open a PR and wait until somebody merges it) and because committers rarely reject packages for being to much of a fringe package.
Thank you for the detailed response. I wonder if the Arch User Repository approach of relegating anything not guaranteed in any way to a separate repo, with some well-understood promotion/demotion process related to how many active maintainers it has, how often/how long the build is broken, etc.
10 comments
[ 3.4 ms ] story [ 35.9 ms ] threadProbably people spooked will make sure that Rocky is permanently well funded, because they never want to be spooked again.
The only thing that makes always-ancient RHEL and CentOS attractive is that enough other people are using identically the same image, exploring its bug envelope thoroughly and sharing the costs of necessary updates.
The role of NixOS would be to reduce those costs.
Broken as in cannot be installed should not happen too often. PRs are built in CI and failing builds on Tier 1 should be a reason to reject PRs.
Hydra currently lists ~4700 out of ~91000 packages failing to build on master. However, most of these are on AArch64 or Darwin.
I hope something changes there, even if it means cutting 80% of the packages out of the official repo. Nix is too good an idea to have a broken flagship distro.
For stable releases, there is an RFC [1] that proposes to push back the .03 releases to .05 and the .09 releases to .11. This will align the release cycle of NixOS after that of Ubuntu and Fedora. Hopefully, this will lessen the load on testing/fixing high-profile package sets (systemd, GNOME, KDE) and as a consequence leave more time/manpower fixing the longer tail.
even if it means cutting 80% of the packages out of the official repo
There are different opinions on that. Some contributors believe in a large, single monorepo, while others think nixpkgs is too large.
Personally, I have moved from the first group to the second. There are many packages with probably only a handful of users, but they clog up the PR stream. Even worse, many of those packages do not have active maintainers, so they end up being maintained by people who are long-term nixpkgs maintainers/committers (and typically have a high maintenance load anyway).
It's kind of interesting that nixpkgs grew so large, because it's one of the distributions that makes it the easiest to add third-party package sets. I guess it's because the bar for contributing a derivation is low (you basically open a PR and wait until somebody merges it) and because committers rarely reject packages for being to much of a fringe package.
[1] https://github.com/NixOS/rfcs/pull/80