Seeking Feedback: Paid Long-Term Support (LTS) for NixOS starting with 24.05

Announcements
21

My experience is as a package maintainer and as a downstream maintainer of Lix: we target the current release version in CI and unstable gets tested by users.

Even the release version of nixpkgs is very annoying to maintain. I think as nixpkgs we have it hugely worse than most distros: most distros have reasonably independent packages, no in-tree lib, etc. Because we target the release version in Lix, all the bugs in nixpkgs we find get fixes backported because we want the bugs gone on all supported releases. Sometimes these backports require modification to work without renamed internals.

The worst period is the month where there’s three releases technically supported (n+1, n, n-1), and the correct move there is to just move Lix to n about two weeks in and let everyone on the old version can just deal with 2 weeks old Lix HEAD.

I’m saying this to illustrate: this job of maintaining old branches sucks a lot more than the average distro and more closely resembles maintaining 500k lines of Python than a Linux distro. I don’t think the community is really sufficiently resourced to care about the 6 month old release, especially at the end of its lifecycle, let alone a two year old release. At the end of the cycle backporting anything is very annoying because of conflicts and architectural changes.

Another difficulty with a longer supported release than 6 months is upstream support: upstreams may reasonably just not want to deal with old stuff.

I personally look forward to deleting all the janky Lix workarounds for fixed things in stable after each release, and personally I would push back strongly on supporting Lix whatsoever on an older release of nixpkgs than 6 months because it requires that we would have an LTS branch, or tolerate old toolchains (and old nixpkgs infra), or build with new toolchains on the old nixpkgs (still old nixpkgs infra). Though I think we are the absolute worst case scenario because our internal CI depends on nixpkgs test internals in a manner that makes us effectively a detached part of nixpkgs, alongside a wide array of packages among other details (example breakage: xonsh changing how their unwrapped derivation works in 24.11).

At worst we’d have to have a Lix LTS branch but again someone should be paying for maintaining that, it’s very labour intensive to backport things and is equally expensive when bug reports show up that don’t affect stable, something which “too bad, upgrade your nixpkgs” avoids. For an evergreen project with extensive beta usage of HEAD builds, that’s wasted effort that could be put into simply rolling a new major release.

So an LTS scheme would likely be doing security backports.

7 Likes
22

After reading @jade’s notice I feel like adding that what I personally would rather consume and maintain is a rolling release branch, but faster and more thoroughly tested than nixos-unstable; more specifically, I’d love to see a merge train, roughly in the form that @samuela had described in his sustainability thread a while back. I’d very much like to maintain less

I’m getting off-topic though

8 Likes
23

As a user, I’d love to have a LTS. My main concern is stability, not of nixpkgs itself, but on packages that are shipped with it. For instance, since I upgraded to 24.11, I had 2 very annoying bugs with plasma/wayland/ or any interactions of these 2 and possibly other apps:

  • one with libreoffice font scaling (fixed since last week, yeah!) when having several monitors
  • one with disappearing windows when I disconnect an external monitor (they get the wrong screen coordinates)

I’m only mentioning bugs related to dual monitors setup, but there were others. Yes they are fixed or are going to be, but there will be more in the next release, in whatever software that eleased a major version in the meantime. These are not problems with nixpkgs, but with the broader ecosystem and the fact softwares take time to stabilize (that’s why big projects often have several supported branches). Right now, I like to get more stability for at least my work desktop.

In the past, I targeted Ubuntu LTS. On NixOS, I’d like to do the same, and occasionally install more recent softwares when needed (which nixos makes it very easy to do).

If I focus more on my company context, to answer OP’s question:

  • Would LTS be useful for your company?

Not only useful, an absolute necessity for us to push nixos to our customers, so that nixos is not just an internal toy for our own needs. Our customers absolutely needs this LTS concept, for more or less the same reasons stated above + a bigger focus on security.

  • Would you / your organization consider signing up to a paid long-term support subscription?

We’d be more willing in participating in the effort by being LTS maintainers. I doubt I can sell this internally when Ubuntu or Debian LTS is free of charge. That being said, we have a number of customers using RHEL, and they would probably pay for it.

  • What concerns or challenges do you see with this approach?

Challenges: time and effort obviously, especially initially to get the tooling needed.

Concerns : as said above, I’d strongly advocate for the broader community to be involved, for pragmatic reasons. We need a public LTS branch and an identified team for this branch. The broader community wouldn’t need to bother about it if they don’t want to.

The right economical model could be a commitment on bugs and security fixes timing (“we’ll follow and deploy every fixes in those packages, in less than X workable hours”).

  • What specific features would make LTS most valuable for you?

Using stable softwares.

5 Likes