6 ms·

Is there a reason neither Guix nor Nix have made an LTS-type repo? A rolling release seems at odds with the stability granted by reproducible builds. Maybe I

by geokon 5y ago

Is there a reason neither Guix nor Nix have made an LTS-type repo? A rolling release seems at odds with the stability granted by reproducible builds. Maybe I have a miopic view, but what's nice with Ubuntu LTS is you know everyone and their mothers has built and tested their packages/libraries/executable against the lib versions provided by Ubuntu 18.04 or 20.04 or whatever. You also know those libs, at their given versions, will get patched as issues come up. If all your libraries are constantly churning then you have no idea of the quality of the libs you're linking to (and that lib's dependencies are also churning in turn). You can pin versions, but there is no guarantee what you're pinning to will be patched and fixed as issues come up

choeger 5y ago
I'd guess a lack of hands. Maintenance is the expensive and boring part of a distro. And seriously, why should an unpaid volunteer help to maintain a stable foundation for all the companies that rely on, e.g., Ubuntu 18.04? I wonder if one could create a business out of supporting such distributions against a comparatively small fee.
- massysett 5y ago
  I doubt it, folks interested in long-term support can already use Debian, Ubuntu, Red Hat, etc.
solatic 5y ago
Nix has a stable channel (six-month release cadence, with one month of support overlap), which isn't LTS, and even just the stable channel is "expensive" enough to be difficult for the project to justify. Supporting LTS has a genuine non-trivial cost in engineering man-hours. Nix has the technological underpinnings to make it easier to support LTS, in theory, but in all likelihood there won't be an LTS channel without corporate sponsorship providing funding to employ LTS maintainers, akin to Red Hat / IBM, Canonical, SUSe, etc. Consider threads like https://discourse.nixos.org/t/what-should-stable-nixos-prioritize https://discourse.nixos.org/t/what-should-stable-nixos-prior...
- geokon 5y ago
  I guess what I don't get is, wouldn't an LTS be way way easier to maintain than a rolling, constantly breaking, release. Heck, id even prolly go through the effort of maintain my own software as a package if it's something I could do once every few years over a stable base. They could even make life easy and match version numbers with whatever the latest Ubuntu LTS is using. And people that'd need newer libs/bins could statically link whatever they need or provide whatever they want separately on top of that stable base (sorta like what PPAs do)
  - otabdeveloper4 5y ago
    No. LTS is much more prone to breakage. LTS means you're porting yesterdays's security patches onto code that has been abandoned five years ago. And usually you have package maintainers doing this, not actual software developers. There's no reason to run LTS unless for corporate insanity purposes.
    - pxc 5y ago
      > And usually you have package maintainers doing this, not actual software developers. This is a weird thing to say. The package maintainers doing substantive backporting work for any distribution absolutely are actual developers. > There's no reason to run LTS unless for corporate insanity purposes. LTS releases also give you stability of behavior, which can be valuable even outside of corporate environments. Plus six months is really short. There's plenty of space between that and the full lifecycle length of a major RHEL release, or an Ubuntu LTS. NixOS releases that lasted two years would be awesome. I'd love to try to use a more long-term NixOS release for a downstream project, if it ever got the kind of corporate backing necessary to sustain that kind of release.
      - seoaeu 5y ago
        > The package maintainers doing substantive backporting work for any distribution absolutely are actual developers. The maintainers doing the backporting are affiliated with the distro rather than being developers of the software they're doing backports for. That is a big distinction because it determines who has to incur the costs of compensating them/recruiting them to volunteer
Gentil 5y ago
Good points made by others. But another thing is you don't have to? Nix(OS)/Guix installs packages and dependencies separately instead of replacing packages like other OS/package managers do. This means you have multiple versions of a package installed in your system and that you can use them simultaneously for different applications if I understand it right. You can move back and forth between versions if one breaks without effecting the rest of the system. Also if I remember, nixos-update rebuild switch (or something very similar to this command) which is usually fired after installing new packages or when a major change is made to the nix configuratino file creates a new boot entry and hence a snapshot for you to go back to if something in NixOS breaks. So there is no necessity for an LTS version to be present for stability's sake. Garbage collection is also left to the end user to deal with. There is a garbage collector command in Nix package manager which will clean up when you push the command so that new packages are not flooding your storage space. NixOS's stable channel can be very loosely compared to Manjaro in the sense that just like Manjaro, NixOS's Stable repo does opinionated changes/interferences/fixes. And NixOS Unstable is like Arch linux with latest and greatest upstream stable versions of the packages.
- nicce 5y ago
  Rolling release cycle is enabled by this indeed. A major benefit what other distributions can’t have without containers. You just nees to know which versions introduce major API changes etc. and you are fine.
- geokon 5y ago
  Right, you can fix your versions if you care, but you don't have a million keyboards "tuning" a fixed version set to be play well with each other - so you don't get the same robustness I know I can get any software to run on Ubuntu 18.04. Everyone supports those packages as their specific versions Having multiple versions or the same package sounds like a disaster. That's the diamond problem. LibA depends on LibB and LibC. Those both depend on LibD at different versions... What then? These rolling distros generally target one arch and one kernel bc the whole thing is fragile. Things like OpenSSL have bugs even between minor versions numbers once you start looking bigger
soraminazuki 5y ago
Nix may not have a LTS release, but it certainly does have stable releases. The biannual releases are there precisely for this reason [1]. What's more, the issues you have with package pinning are more of a problem with traditional package managers. The situation is better on Nix and Guix because it provides you with more control and flexibility over packages. With traditional system-level package managers, you can't really pin a subset of installed packages. Since all packages are installed into a shared location and depend on each other both explicitly and inexplicitly, packages in a distro release are tightly coupled together. It's just not possible to swap out or pin a subset of packages without the risk of breakage. As a result, a dedicated distro release consisting of old packages is needed to keep using older versions of packages. This is not the case for Nix and Guix, which installs different packages in their own isolated locations. Packages are more loosely coupled, and you can mix packages from stable channels, unstable channels, and even specific git commits of those channels. Using pinned versions of critical system package is also less of a risk because different versions of the same package can coexist on a single system. Even if something does break, you can always roll back. Finally, Nix and Guix provides ways to fix issues for pinned packages. With Nix/Guix packages, you're not stuck with whatever the distro provides you with. They're more flexible and allows you to create your own custom packages out of existing ones. For example, here's how you can backport patches for a pinned package on Nix: existingPackage.overrideAttrs (old: { patches = old.patches ++ [ (fetchpatch { url = "..."; sha256 = "..."; }) ]; }) So while the lack of a LTS may be a bit disappointing, I wouldn't consider it a complete dealbreaker because the features and tooling makes up for it. [1]: https://nixos.org/blog/announcements.html https://nixos.org/blog/announcements.html
ayushnix 5y ago
> Is there a reason neither Guix nor Nix have made an LTS-type repo? Nix and Guix are already esoteric enough to scare people away, I don't imagine how these projects would be able to reliably manage LTS releases unless they get serious financial support or enough manpower willing to deal with backporting security and bug fixes. You might wanna look at Fedora Silverblue and the OSTree technology making its way into RHEL/CentOS/Rocky/ALMA etc.
nh2 5y ago
There are pros and cons of the LTS approach. A big CON is that even on Ubuntu LTS, lots of softare is incredibly out of date and full of unpatched security vulnerabilities. Consider Roundcube, probably the most popular PHP email web client. On Ubuntu 18.04 LTS the last update is from, well, April 2018: https://packages.ubuntu.com/bionic/roundcube https://packages.ubuntu.com/bionic/roundcube Now consider the amount of CVEs (remote code execution and XSS) published for Rouncube since then, which are all unpatched in that Ubuntu: https://www.cvedetails.com/vulnerability-list/vendor_id-8905/Roundcube.html https://www.cvedetails.com/vulnerability-list/vendor_id-8905... If you are running Ubuntu LTS on your server, that's a big problem. The `roundcube` package is in the `universe` repository, meaning "community maintained". In this case for this LTS that meant "no security updates at all for 3 years". The newer LTS, 20.04, doesn't seem to have those CVEs fixed either.
podiki 5y ago
To add to what others have said, a benefit of this type of distro is you can always go to a specific point in time of your configuration and packages. So if it has worked, it will continue to work, while you can upgrade or change other parts in a separable manner. In a more interesting note, I wrote an aside about grafts, which are a way of providing changes to packages without rebuilding (often to graft in a security fix to a library the package uses). So you can keep a configuration of packages you like and graft on security fixes while staying on the same version. There are some caveats about when you can do this of course (ABI compatibility mainly), but is some cool technology, to me.
pxc 5y ago
> A rolling release seems at odds with the stability granted by reproducible builds. GuixSD and NixOS aren't subject to some of difficulties of traditional rolling release Linux distributions. You are exposed to upstream behavior changes and upstream bugs more or less as soon as they arrive, just like on Arch Linux or something like that. But most of the other risks and maintenance burdens of ‘running a rolling release’ aren't borne by GuixSD and NixOS users. This is not so much due to the reproducibility of Nix builds as to the hermeticity and statelessness of Nix and Guix builds. The hermeticity means that you don't have to worry about ABI breakages in the same way, since packages that need incompatible versions of the same library will each find their respective version of that dependency sitting safely isolated from one another in the package store. This spares you from a few maintenance burdens: • installation of new packages causing/requiring upgrades of ‘unrelated’ packages because they share some dependency with the new one (this one affects standalone package managers like Homebrew as well as rolling releases of entire operating systems like Arch) • having to upgrade before installing new things, every time you update your package sources • having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan https://github.com/flyingcircusio/userscan ) The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly. For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’. It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable. But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.

by geokon 5y ago

choeger 5y ago

I'd guess a lack of hands. Maintenance is the expensive and boring part of a distro. And seriously, why should an unpaid volunteer help to maintain a stable foundation for all the companies that rely on, e.g., Ubuntu 18.04? I wonder if one could create a business out of supporting such distributions against a comparatively small fee.

massysett 5y ago
I doubt it, folks interested in long-term support can already use Debian, Ubuntu, Red Hat, etc.

solatic 5y ago

Nix has a stable channel (six-month release cadence, with one month of support overlap), which isn't LTS, and even just the stable channel is "expensive" enough to be difficult for the project to justify. Supporting LTS has a genuine non-trivial cost in engineering man-hours. Nix has the technological underpinnings to make it easier to support LTS, in theory, but in all likelihood there won't be an LTS channel without corporate sponsorship providing funding to employ LTS maintainers, akin to Red Hat / IBM, Canonical, SUSe, etc. Consider threads like https://discourse.nixos.org/t/what-should-stable-nixos-prioritize https://discourse.nixos.org/t/what-should-stable-nixos-prior...

geokon 5y ago
I guess what I don't get is, wouldn't an LTS be way way easier to maintain than a rolling, constantly breaking, release. Heck, id even prolly go through the effort of maintain my own software as a package if it's something I could do once every few years over a stable base. They could even make life easy and match version numbers with whatever the latest Ubuntu LTS is using. And people that'd need newer libs/bins could statically link whatever they need or provide whatever they want separately on top of that stable base (sorta like what PPAs do)
- otabdeveloper4 5y ago
  No. LTS is much more prone to breakage. LTS means you're porting yesterdays's security patches onto code that has been abandoned five years ago. And usually you have package maintainers doing this, not actual software developers. There's no reason to run LTS unless for corporate insanity purposes.
  - pxc 5y ago
    > And usually you have package maintainers doing this, not actual software developers. This is a weird thing to say. The package maintainers doing substantive backporting work for any distribution absolutely are actual developers. > There's no reason to run LTS unless for corporate insanity purposes. LTS releases also give you stability of behavior, which can be valuable even outside of corporate environments. Plus six months is really short. There's plenty of space between that and the full lifecycle length of a major RHEL release, or an Ubuntu LTS. NixOS releases that lasted two years would be awesome. I'd love to try to use a more long-term NixOS release for a downstream project, if it ever got the kind of corporate backing necessary to sustain that kind of release.
    - seoaeu 5y ago
      > The package maintainers doing substantive backporting work for any distribution absolutely are actual developers. The maintainers doing the backporting are affiliated with the distro rather than being developers of the software they're doing backports for. That is a big distinction because it determines who has to incur the costs of compensating them/recruiting them to volunteer

Gentil 5y ago

Good points made by others. But another thing is you don't have to? Nix(OS)/Guix installs packages and dependencies separately instead of replacing packages like other OS/package managers do. This means you have multiple versions of a package installed in your system and that you can use them simultaneously for different applications if I understand it right. You can move back and forth between versions if one breaks without effecting the rest of the system. Also if I remember, nixos-update rebuild switch (or something very similar to this command) which is usually fired after installing new packages or when a major change is made to the nix configuratino file creates a new boot entry and hence a snapshot for you to go back to if something in NixOS breaks. So there is no necessity for an LTS version to be present for stability's sake. Garbage collection is also left to the end user to deal with. There is a garbage collector command in Nix package manager which will clean up when you push the command so that new packages are not flooding your storage space. NixOS's stable channel can be very loosely compared to Manjaro in the sense that just like Manjaro, NixOS's Stable repo does opinionated changes/interferences/fixes. And NixOS Unstable is like Arch linux with latest and greatest upstream stable versions of the packages.

nicce 5y ago
Rolling release cycle is enabled by this indeed. A major benefit what other distributions can’t have without containers. You just nees to know which versions introduce major API changes etc. and you are fine.
geokon 5y ago
Right, you can fix your versions if you care, but you don't have a million keyboards "tuning" a fixed version set to be play well with each other - so you don't get the same robustness I know I can get any software to run on Ubuntu 18.04. Everyone supports those packages as their specific versions Having multiple versions or the same package sounds like a disaster. That's the diamond problem. LibA depends on LibB and LibC. Those both depend on LibD at different versions... What then? These rolling distros generally target one arch and one kernel bc the whole thing is fragile. Things like OpenSSL have bugs even between minor versions numbers once you start looking bigger

soraminazuki 5y ago

Nix may not have a LTS release, but it certainly does have stable releases. The biannual releases are there precisely for this reason [1]. What's more, the issues you have with package pinning are more of a problem with traditional package managers. The situation is better on Nix and Guix because it provides you with more control and flexibility over packages. With traditional system-level package managers, you can't really pin a subset of installed packages. Since all packages are installed into a shared location and depend on each other both explicitly and inexplicitly, packages in a distro release are tightly coupled together. It's just not possible to swap out or pin a subset of packages without the risk of breakage. As a result, a dedicated distro release consisting of old packages is needed to keep using older versions of packages. This is not the case for Nix and Guix, which installs different packages in their own isolated locations. Packages are more loosely coupled, and you can mix packages from stable channels, unstable channels, and even specific git commits of those channels. Using pinned versions of critical system package is also less of a risk because different versions of the same package can coexist on a single system. Even if something does break, you can always roll back. Finally, Nix and Guix provides ways to fix issues for pinned packages. With Nix/Guix packages, you're not stuck with whatever the distro provides you with. They're more flexible and allows you to create your own custom packages out of existing ones. For example, here's how you can backport patches for a pinned package on Nix: existingPackage.overrideAttrs (old: { patches = old.patches ++ [ (fetchpatch { url = "..."; sha256 = "..."; }) ]; }) So while the lack of a LTS may be a bit disappointing, I wouldn't consider it a complete dealbreaker because the features and tooling makes up for it. [1]: https://nixos.org/blog/announcements.html https://nixos.org/blog/announcements.html

ayushnix 5y ago

> Is there a reason neither Guix nor Nix have made an LTS-type repo? Nix and Guix are already esoteric enough to scare people away, I don't imagine how these projects would be able to reliably manage LTS releases unless they get serious financial support or enough manpower willing to deal with backporting security and bug fixes. You might wanna look at Fedora Silverblue and the OSTree technology making its way into RHEL/CentOS/Rocky/ALMA etc.

nh2 5y ago

There are pros and cons of the LTS approach. A big CON is that even on Ubuntu LTS, lots of softare is incredibly out of date and full of unpatched security vulnerabilities. Consider Roundcube, probably the most popular PHP email web client. On Ubuntu 18.04 LTS the last update is from, well, April 2018: https://packages.ubuntu.com/bionic/roundcube https://packages.ubuntu.com/bionic/roundcube Now consider the amount of CVEs (remote code execution and XSS) published for Rouncube since then, which are all unpatched in that Ubuntu: https://www.cvedetails.com/vulnerability-list/vendor_id-8905/Roundcube.html https://www.cvedetails.com/vulnerability-list/vendor_id-8905... If you are running Ubuntu LTS on your server, that's a big problem. The `roundcube` package is in the `universe` repository, meaning "community maintained". In this case for this LTS that meant "no security updates at all for 3 years". The newer LTS, 20.04, doesn't seem to have those CVEs fixed either.

podiki 5y ago

To add to what others have said, a benefit of this type of distro is you can always go to a specific point in time of your configuration and packages. So if it has worked, it will continue to work, while you can upgrade or change other parts in a separable manner. In a more interesting note, I wrote an aside about grafts, which are a way of providing changes to packages without rebuilding (often to graft in a security fix to a library the package uses). So you can keep a configuration of packages you like and graft on security fixes while staying on the same version. There are some caveats about when you can do this of course (ABI compatibility mainly), but is some cool technology, to me.

pxc 5y ago

> A rolling release seems at odds with the stability granted by reproducible builds. GuixSD and NixOS aren't subject to some of difficulties of traditional rolling release Linux distributions. You are exposed to upstream behavior changes and upstream bugs more or less as soon as they arrive, just like on Arch Linux or something like that. But most of the other risks and maintenance burdens of ‘running a rolling release’ aren't borne by GuixSD and NixOS users. This is not so much due to the reproducibility of Nix builds as to the hermeticity and statelessness of Nix and Guix builds. The hermeticity means that you don't have to worry about ABI breakages in the same way, since packages that need incompatible versions of the same library will each find their respective version of that dependency sitting safely isolated from one another in the package store. This spares you from a few maintenance burdens: • installation of new packages causing/requiring upgrades of ‘unrelated’ packages because they share some dependency with the new one (this one affects standalone package managers like Homebrew as well as rolling releases of entire operating systems like Arch) • having to upgrade before installing new things, every time you update your package sources • having to rebuild some packages that are not part of your main OS configuration because you upgraded your main OS (e.g., Arch updates breaking AUR packages, or system upgrades breaking software you compiled manually or your Python virtualenvs, etc.). (You do have to inform the package manager that you don't want these externally-depended-on packages garbage collected, though. For Nix, for example, you can do that automagically by running fc-userscan against your project directories: https://github.com/flyingcircusio/userscan https://github.com/flyingcircusio/userscan ) The statelessness is related to reproducibility in that it's a result of the functional package management approach to reproducibility. Since every version of your whole system is generated without reference to previous versions (indeed, from scratch!), the OS never has to navigate state transitions for its packages. It doesn't have to worry about converting configuration files from one format to another, or replacing defaults, or the implicit dependencies of your system undergoing name changes or being replaced. Nix and Guix don't need Debian-style transitional packages and similar tricks. That means you aren't punished, on a per-package basis, for not updating your system constantly. For example, I recently took some neglected, non-internet-facing NixOS servers and updated them from an early 2018 release of NixOS to the latest NixOS unstable rolling release. While I did have to first work a forward incompatibility issue in Nix itself, the rest of the upgrade was a single step, and I didn't have to worry about finding a valid ‘upgrade path’. It's worth noting that in a strict sense, the reproducibility is all still there, even for NixOS releases that no longer receive updates. If you need to use an old version of some piece of software for compatibility reasons, in a safe environment, you can use the latest and greatest Nix to install packages from NixOS releases that are 2 or 4 or 6 or 8 years old— including on top of a bleeding edge system running NixOS Unstable. But you have a point: it would be awesome if there were long-term releases, you would get a different kind of reproducibility— one which is less strict but more useful in some ways. For example, you could take a Nix expression that someone posted in a Gist on GitHub 4 years ago, for what was back then the latest NixOS stable release. If that release were also an LTS, you could not just reproduce what they actually had, but apply it against the latest version of the same LTS to get a system that should be totally compatible in terms of behavior, but suitable for running in production without modification, thanks to up-to-date security patches.