Where is the Reliabitity ? Losing users to BlueBuild?

Development
1

I’ve been a Linux enthusiast for a long time, and I’ve been using NixOS daily on several machines for around five months.

At first I loved it, but now I’m constantly bothered by stability issues. My lock screen froze, text in Thunderbird and Firefox simply disappeared, AI-agent plugins crashed, cloud platform apps crashed, etc.

What I love about NixOS is the incredibly easy reproducibility. I need a program, I add it to my configuration, rebuild, and pouf, all my computers can have it. I really don’t want to lose that.

But now I’m wondering where NixOS is going.

I’m looking at projects like BlueBuild, where I can have something similar with a recipe.yml, but this time based on Fedora and hopefully with the stability and compatibility of a more mainstream distribution.

I’m not saying BlueBuild is better than NixOS. Nix is much more powerful. But as a desktop user, I’m starting to wonder: what keeps users like me on NixOS if other distributions can offer reproducibility while being more stable?

1 Like
2

I’m not really sure what you want to hear here…

If you just care about reproducible packages, using the Nix package manager should be sufficient.

If you’re unsatisfied with the level of stability, i would recommend you switch to a more stable branch.

NixOS is different since it allows you to reason about your OS, since many aspects of it are known at build time. Hell, you can even reason about the other computers in your fleet. NixOS unifies many different configurations into the Nix language, making it possible to map and fold and abstract easily.

If you’re wondering whether it’s right for you, branch out and try something else too. If you’re worried about the future, see if you can contribute back!

P. S. as far as i know, we really dont care about ‘losing’ users. NixOS does not need to convince people to use it…

10 Likes
3

I’m sorry you’re having an unpleasant time of it! Because NixOS is so configurable (and nixpkgs so large), it’s hard to give a useful answer to this–it might be the ecosystem’s issues, it might be a configuration issue.

Can you give a better idea of how things are set up?

4

I doubt that random applications glitch or crashes have something to do inherently with the way software is built in Nixpkgs or how NixOS manages the file system. They’re more likely to be upstream problems (so you would see them also on another distro) or some hardware problem, depending on how often they occur.

4 Likes
5

I’m on 26.05. That is the latest stable branch, right?

I also run nix flake update daily to keep my applications updated. Maybe that’s part of my problem and not the recommended way to use the stable branch. If stable NixOS is intended to be used differently, that’s also something I’d like to understand.

I’m using KDE on Wayland, and several times I’ve had freezes or crashes around the lock screen, waking from sleep, etc.

The most annoying case for me was a cloud-folder application. A newer upstream version was available that fixed crashes I was seeing, but I couldn’t update to it easily because that version wasn’t available in my nixpkgs branch yet.

That’s the part I’m trying to understand.

Why couldn’t we have an additional layer where I can declare something conceptually like:

some-app = "latest"
some-other-app = "3.2.1"
another-app = "release"

while Nix still locks the exact source, hashes and dependencies afterward?

Something similar in spirit to package.json + package-lock.json.

Then a small upstream company could release version 3.2.2 without having to care about updating nixpkgs itself. A user who explicitly wants a version that isn’t in nixpkgs could simply request 3.2.2.

Nixpkgs would still contain the curated version selected for the stable release.

The main idea is to keep nixpkgs as the huge trusted catalog of applications, but allow each user to select another upstream version when they need it, without requiring that version to already exist in nixpkgs.

Maybe there could even be an optional way for users to report which locked versions they’re successfully using. That could help the Nix community discover which newer versions are widely used before promoting them into nixpkgs.

I’m not suggesting replacing nixpkgs. Quite the opposite: I would keep nixpkgs as the trusted, curated tree.

This could also reduce the number of simple version-bump PRs and let maintainers focus more on which versions should actually be considered stable for a NixOS release.

It also occurred to me that packages could potentially have different stability expectations.

For system components, I actually prefer old and boring over new and occasionally broken. I’d rather have an older lock screen that works every single time than a newer one that randomly breaks after 5–10 locks.

1 Like
6

I’m on 26.05. That is the latest stable branch, right?

Correct.

daily to keep my applications updated. Maybe that’s part of my problem

No, you can update it as often as you like. The stable channel is updated fairly often (like every 1-2 days typically), but it only receives security fixes or minor bug fixes that are being backported manually by maintainers.

Why couldn’t we have an additional layer where I can declare something conceptually like:

If you enjoy the stability of NixOS releases (you don’t want to deal with non-backward compatible changes continuous, but once every 6 months) you can still choose to pick a program from the unstable channel.

Since you mentioned using flakes, you can just define an additional nixpkgs-unstable input and pick what package you want from that (and set the relevant *.package = option, or add them to environment.systemPackages, etc.). See this, for example.

You can also do this for entire modules with something like this:

disabledModules = [ "path/to/old/module.nix" ]
import = [ "${nixpkgs-unstable}/nixos/modules/path/to/new/module.nix" ]

but it’s more risky.

Alternatively, you can maintain you own branch that tracks the release-* branch but with some commits on top that you cherry-pick from master.
Or, you can directly apply your patches on top of Nixpkgs using pkgs.applyPatches.

The main idea is to keep nixpkgs as the huge trusted catalog of applications, but allow each user to select another upstream version when they need it, without requiring that version to already exist in nixpkgs.

Almost all packages are overridable, and you can overlay your changes on top of the existing package set, but there’s no gurantee that updating it will not break either the build itself or some dependent package, unless you’re doing some minor update. So, it can’t be as simple as some-app = "version", not always, at least.

Maybe there could even be an optional way for users to report which locked versions they’re successfully using. That could help the Nix community discover which newer versions are widely used before promoting them into nixpkgs.

I’m not sure I understand. New versions are typically discovered using repology and update PRs are already mostly automated (see this PR, for example). But, not everything is safe to be backported, so the stable branch may be using an older version.

3 Likes
7

To me this seems as if you were confusing “reproducibility” and “declarativity”.

A lot of poeple do, and it is probably the biggest missunderstanding in the NixOS world, right after “flakes are mandatory”.

If you only need the declarative part, plenty of alternatives to NixOS exist, and they do for several years.

Though NixOS is the only system where it is deeply integrated (I can not say anything about this bluebuild thing, never looked into it) and even enforced to huge parts.

The mentioned alternatives I am aware off, still allow to do massive changes manually just by using the regular file manager.

Those tools I am talking about are chef, ansible, puppet, salt, and what else there might exist.

1 Like
8

i feel like you are running into hardware/firmware issues.

a bunch of extra configurations for your hardware may be set in other distros, but in nixos even proprietary firmware/drivers is not enabled by default.

a lot of per-hardware settings exist in nixos-hardware flake, that makes a system much more stable and fixes/works around different known issues

1 Like
9

guix wants a word … but I know you know that and I guess you’re counting it as the same thing.

4 Likes
10

As Sir Phobos suggested, many DE bugs are hardware/firmware issues, which is not easy to discover prior to deployment.
Even as a seasoned NixOS user and Nixpkgs contributor, these bugs still bring me a lot of frustration.

As for updating, maintainers and reviewers typically trust upstream for documenting breaking changes and maintaining backward compatibility on patch releases and minor version updates.

In an ideal world, we could have dedicated teams to monitor the deployment. I’m not sure how feasible it is for a project with 5000 developers, 100k packages, and a full-fledged Linux distro.

1 Like
11

Guix builds with Nix store derivations, so maybe it counts as a Nix variant.

1 Like
12

Maybe I didn’t mean “same thing” … probably the point in this context is that guix is not significantly simpler than NixOS, and it has fewer packages and way LESS hardware compatibility. I know it has some advantages over NixOS, but they don’t seem particularly relevant here.

13

If you’ll humor me, switch back to X from Wayland, and I bet the lock screen situation might get better. I was having trouble with mine on Cinnamon until I switched back to X.

1 Like
14

Say you’re on some-app version 1.2.3, and you would like to use 1.2.4.

Sometimes, this is a trivial version bump. In which case:

  • You can always add the version bump yourself, as an overlay. The exact notation for this sometimes varies, but it’s usually as ‘simple’ as:
      some-app = super.some-app.overrideAttrs (finalAttrs: prevAttrs: {
    version = "1.2.4";
    src = prevAttrs.src.override {
      tag = "v${finalAttrs.version}";
      hash = "you have to fill this in yourself";
    };
  });
    This is more ceremony than you probably want, but it isn’t difficult. There are several little things in this incantation that need to change from package to package, which is a big reason why there isn’t some fire-and-forget bumpVersion function that does most of this ceremony for you. But we could probably make this better. Why haven’t we? Well, mostly because:
  • If it’s this easy, the version updater bot will do it for you. It still takes time for the bot to notice, for the PR to be prepared and approved, and for the build system to publish built versions of both the bumped packages and every package that depends on them. That last step in particular is something other distributions can shortcut, resulting in faster updates. We’ve chosen as a culture to accept the other side of that tradeoff — we ensure that everything builds together, and that any automated tests on any distant dependency will pass, before we release any bumps to users.

But other times, real intelligence needs to get involved, because something about the build system changes in between 1.2.3 and 1.2.4, or because a patch previously incorporated into the Nixpkgs definition of a package no longer cleanly applies to upstream, or dozens of other similar manual maintenance tasks. Short of passing this problem along to an LLM[1], there isn’t a tool that could sit on top of things and solve this class of problems, and they arise frequently enough that I fear that such a tool would frustrate its users more with this case than it would reward users who find themselves in the other case.

  1. Which sounds like an interesting experiment to try, if you have tokens burning a hole in your pocket or a very robust local model — automating temporary upgrade overlays for a single impatient user who is willing to accept some weird decisions is one of the rare uses to which I would feel comfortable applying a vat-grown programmer substitute ‘made with 100% real coder’. ↩︎

2 Likes
15

Also since you’re on stable, someone has to backport the commit (usually automatically, via marking the PR with a label). I don’t generally backport my PRs since I don’t use stable, maybe others do, but stable will tend to lag even in the best of cases.

1 Like
16

That was meant to be a joke. Sorry for causing confusion.

1 Like
17

By saying updating in my previous comment, I mean backporting the version bumps.

We have some guidelines about whether to backport changes in CONTRIBUTING.md. (Link updated, thanks for @Shawn8901)
In my experience, though, reviewers tend to be more conservative toward backporting compared to what the guidelines suggest.

18

I was about to ask about that.

I only maintain a very small number of (I assume) unpopular packages, but got recently asked for a backport, which I hadn’t really done before.

After reading contributing.md again to make sure I did things right, I got the impression that basically all my version bumps should have been backported, whereas the impression I got before was that stable was much more conservative.

Is the consensus that stable is receiving too few version bumps for leaf packages and I was unwittingly contributing to that?

19

That is just explaining how a back port is done and not giving any hints what is backportable.

IMHO that is a better ref on what can be suggested as backport nixpkgs/CONTRIBUTING.md at 044bc0d4118b226a00fe53b6cf4c7c87ba18a8ce · NixOS/nixpkgs · GitHub

eG it’s saying everything with breaking changes should not be backported unless the application is unusable if not doing (including some example ls)

But in general I agree that we could backport more prs. For me I am just backporting it it has a test, because I am not running stable, so w/o tests I can not judge.

3 Likes
20

Idk about consensus but it’s a commonly-reported problem. Hard to say in general if that’s actually true, or if people just don’t know what stable vs unstable is meant for, as every package is case-by-case.

I personally don’t backport, because I don’t want to have to keep track of every minor breaking change and attempt to support a system I don’t use, as I’d only notice the larger breakages anyway. If other people use stable, I invite them to add the label where needed!

3 Likes