> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release.
It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
It seems that it doesn't build with releases of GCC from April 2025 onward, at least with default settings, because it doesn't build with the C23/C++23 standards.
Looking at the build log in the linked Debian issue, there is an argument setting -std=c++11. It seems as though an implicit inclusion of <cstdint> had been provided by libstdc++ in the past and was removed as of GCC 15.
it would be nice if g++ had an --implicit-includes=[foo,bar] option that would make it easier for a distro to shotgun fix such incompatibilities with CXXFLAGS rather than doing real work.
I recently custom-built Guile for my Arch system, and found that it won't build with GCC 15, but will with 14, which is the only other version in the Arch repository. I think that the Guile maintainers will need to get busy fixing the incompatibilities in question, before GCC 16 appears.
But most people using Debian turn popcon off. I don't at all doubt that Guix is not used by most people, but I'm quite certain the number of users is well above 230.
Besides the point already made about firefox-esr being the default package for Firefox, here are a couple of other points. First, that also means there are 5749 installations of non-default Firefox compared to 231 of guix.
Secondly, popcon works on servers and headless systems without X or Wayland. Those systems still use a package manager, and sometimes several. A graphical web browser like Firefox is unlikely to be installed without a GUI. I’ve seen plenty of systems with Snap, Flatpak, or Nix installed besides the OS-related apt, aptible, apt-get, rpm, yum, dnf, and language-related tools like pip, EasyInstall, rubygems, Bundler, cpanm, npm, cargo, OPAM, Composer, go get, or sbt with no GUI.
That is still more than an order of magnitude higher (2.17% rather than 0.09%).
And FF ESR is the more common by far (44.5%) as it is the default, people only install the other FF package if they have specific need to be closer to the leading edge. The build environments for the two will be very close, at least compared to the oddities being reported in the Guix requirements, so the hassle of maintaining FF and FF-ESR compared to just one of them is not going to be comparatively large compared to maintaining packages for just one of the pair.
Or just to take the raw data with a grain of salt because some people care about privacy and haven't had time to read up on what the privacy policy is for example. That doesn't automatically mean these people stop being worth considering as legit users of the software
You just have to assume that the install balance between those with it on is not massively different to the install balance between those who do not. This might not be the safest application of statistics, but it is the best available.
If more Guix users want to be seen and counted, to show how much of a need there might be to keep it despite the current issues, then there is a simple thing they can do… Or a less simple thing: the “without a community nor help” part seems rather significant to me in “But the Debian package maintainer has the almost impossible task to backport all the security fixes without a community nor help behind [maintaining it] and as things are going, this will probably lead to the Debian guix package being removed”.
Perhaps, but there is a certain charm in a single individuals obsessive devotion to a problem nobody else sees. I like that the Linux ecosystem is weird.
I've been meaning to share these results in a more appropriate place, but for what it's worth, the proof-of-concept script for the recent Guix CVEs bisects to a Jan 2023 commit, so it's not clear that released versions are affected.
why not bring Debian's guix version to closely follow vanilla guix's releases? Is it because Debian wants to guarantee that a Debian release (such as trixie) only provides packages that stick to at most bugfix versions such that there are no breaking changes introduced?
It could have been possible to upload something like a 1.4.0+git2025mmdd package, if not for the timing of the CVE announcement with regards to Debian's release freeze.
It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.
> It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part,
I'm not even sure it's mismanagement, just incompatible approaches. Debian ships a coherent system, with a minimal (preferably one) versions of each library per version of the distro, and each version of the distro is maintained together for a fairly long time with as close as possible to only bug fixes as changes. And that's 100% valid in its own context. Guix apparently prefers rolling release. That's also 100% valid in its own context. But those two contexts don't mix well, through no fault of either party.
> although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place,
While I also see the appeal to going pure guix, the cross pollination is good for both projects, especially (IMHO) guix. This provided a gentler on-ramp to using guix at a smaller scale without the flying leap that is switching distros outright, and (per the article) the Debian maintainer(s?) have found reproducibility problems while doing their work which is quite valuable to guix.
> OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.
Subhurds are really cool, but I would argue there are lots of practical uses that don't really need to go that far.
Curious, what is your need / use case? I typically just stick to the package manager for whatever OS I install, if I don't like theirs, I find a new OS.
Not the GP, but: For Guix in general? That's easy to answer:
(1) Making things reproducible. That is one of the main reasons. And not only installed system packages. You can also use it to build reproducible projects you develop, if the dependencies are available on Guix.
(2) The other one is installing software, that your distribution doesn't have in standard repos.
Just using Guix requires a pretty substantial amount of administrative work. I'd imagine maintaining it is even more intense and that's why they're running into issues like this.
You have to be pretty slow to be outrun by Debian of all distros.
It's not the slowness of releases, it's the fact they don't release any stable version with just security fixes. They only make new cumulative releases. Debian's model is to fix a version for their release and do security patches on that, not to push out the latest version.
I would guess this is the same reason why one can't change git repo history without affecting people working with the repo. Merkle tree all over the store.
What do you mean by "Just using Guix requires a pretty substantial amount of administrative work."
Like, as a user downloading packages, or a person packaging an application?
As a user downloading a package, it's been super easy for me and it's been years of running Guix with little to no issue (yet the benefits of rolling release, rollbacks, installing multiple versions of a given software etc.).
As for using it to package an application, I found the challenges mainly in the documentation. This was years ago and a lot of work has gone into improving the docs.
FWIW, not the OP but doing a guix pull after getting it from APT took several hours to crash out every time I wanted to just try using guix for something, and the ISO to install it from upstream was multiple gigabytes which seemed wild. I put a couple days into it and never actually got to try it.
It's hard to have an opinion of a platform you haven't used but based on how bloated just starting it seemed to be I was unimpressed.
> For example, he has had to maintain various Guile dependencies, and deal with the fact that Guix uses ""fairly old"" GCC versions whereas Debian usually ships the latest GCC version available for a given release.
It's odd that guix is both rolling release but also uses older GCC versions; usually I'd expect those from very different cultures.
It seems that it doesn't build with releases of GCC from April 2025 onward, at least with default settings, because it doesn't build with the C23/C++23 standards.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1096790
Maybe such changes are more substantial than the typical differences between GCC releases?
Surely if that's all they would just build with an explicit -std=whatever setting?
Looking at the build log in the linked Debian issue, there is an argument setting -std=c++11. It seems as though an implicit inclusion of <cstdint> had been provided by libstdc++ in the past and was removed as of GCC 15.
https://github.com/bpftrace/bpftrace/pull/3407
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176...
Looks like they did in fact add the header detail to the porting guide:
https://gcc.gnu.org/gcc-15/porting_to.html#header-dep-change...
Just closing some tabs and followed this trail a bit further, it looks like guix fixed the issue too:
https://codeberg.org/guix/guix/commit/7b66b41ce5cee48b14eb6c...
it would be nice if g++ had an --implicit-includes=[foo,bar] option that would make it easier for a distro to shotgun fix such incompatibilities with CXXFLAGS rather than doing real work.
That seems like kicking the can down the road in a way that's worse in the long run IMHO
Isn't the --include option basically that?
Ah, you learn something new everyday, thanks!
Isn't that what AI/Vibe coding is for? ( I am kidding a lot)(Ducking thrown paper balls)
I recently custom-built Guile for my Arch system, and found that it won't build with GCC 15, but will with 14, which is the only other version in the Arch repository. I think that the Guile maintainers will need to get busy fixing the incompatibilities in question, before GCC 16 appears.
> According to Debian's popularity contest (popcon) statistics, there are not quite 230 systems with Guix installed.
But most people using Debian turn popcon off. I don't at all doubt that Guix is not used by most people, but I'm quite certain the number of users is well above 230.
The locales package has over 265k installs in the same recent report that lists 231 copies of guix. That’s less than 0.09% or so.
By the same virtue, https://qa.debian.org/popcon.php?package=firefox only lists 5749 installs of firefox. I'd take it with a grain of salt.
Firefox-esr seems to be much more common (~118k): https://qa.debian.org/popcon.php?package=firefox-esr
It lists 118698 installs of firefox-esr.
https://qa.debian.org/popcon.php?package=firefox-esr
Yes, and these numbers have been established as what we in the industry call "invalid".
Besides the point already made about firefox-esr being the default package for Firefox, here are a couple of other points. First, that also means there are 5749 installations of non-default Firefox compared to 231 of guix.
Secondly, popcon works on servers and headless systems without X or Wayland. Those systems still use a package manager, and sometimes several. A graphical web browser like Firefox is unlikely to be installed without a GUI. I’ve seen plenty of systems with Snap, Flatpak, or Nix installed besides the OS-related apt, aptible, apt-get, rpm, yum, dnf, and language-related tools like pip, EasyInstall, rubygems, Bundler, cpanm, npm, cargo, OPAM, Composer, go get, or sbt with no GUI.
That is still more than an order of magnitude higher (2.17% rather than 0.09%).
And FF ESR is the more common by far (44.5%) as it is the default, people only install the other FF package if they have specific need to be closer to the leading edge. The build environments for the two will be very close, at least compared to the oddities being reported in the Guix requirements, so the hassle of maintaining FF and FF-ESR compared to just one of them is not going to be comparatively large compared to maintaining packages for just one of the pair.
Can't really complain if their usage stats aren't taken into account then, I'd say?
Or just to take the raw data with a grain of salt because some people care about privacy and haven't had time to read up on what the privacy policy is for example. That doesn't automatically mean these people stop being worth considering as legit users of the software
FYI, privacy questions are here if you ever get the time: https://popcon.debian.org/FAQ
It's not a complaint, it's just a fact to consider.
For comparison, git has ~155,000 installs and the common base packages have ~266,000:
https://popcon.debian.org/index.html
You just have to assume that the install balance between those with it on is not massively different to the install balance between those who do not. This might not be the safest application of statistics, but it is the best available.
If more Guix users want to be seen and counted, to show how much of a need there might be to keep it despite the current issues, then there is a simple thing they can do… Or a less simple thing: the “without a community nor help” part seems rather significant to me in “But the Debian package maintainer has the almost impossible task to backport all the security fixes without a community nor help behind [maintaining it] and as things are going, this will probably lead to the Debian guix package being removed”.
Perhaps, but there is a certain charm in a single individuals obsessive devotion to a problem nobody else sees. I like that the Linux ecosystem is weird.
I've been meaning to share these results in a more appropriate place, but for what it's worth, the proof-of-concept script for the recent Guix CVEs bisects to a Jan 2023 commit, so it's not clear that released versions are affected.
4cf1acc7f30 + cherry-picked 71171538e12 + 1c78f71beb3 + a49536e3200 + 7f237f3e6ca
why not bring Debian's guix version to closely follow vanilla guix's releases? Is it because Debian wants to guarantee that a Debian release (such as trixie) only provides packages that stick to at most bugfix versions such that there are no breaking changes introduced?
It could have been possible to upload something like a 1.4.0+git2025mmdd package, if not for the timing of the CVE announcement with regards to Debian's release freeze.
It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part, although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place, OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.
I say this as a long-term guix user.
> It's a shame that yet another project (bcachefs in Linux kernel) and now guix are getting ostracized out of mismanagement... on whoever's part,
I'm not even sure it's mismanagement, just incompatible approaches. Debian ships a coherent system, with a minimal (preferably one) versions of each library per version of the distro, and each version of the distro is maintained together for a fairly long time with as close as possible to only bug fixes as changes. And that's 100% valid in its own context. Guix apparently prefers rolling release. That's also 100% valid in its own context. But those two contexts don't mix well, through no fault of either party.
> although in all honestly, and this is a hot take mind you; guix should either be run on bare metal, to take advantage of its bootstrap-from-source, thus avoiding debian in the first place,
While I also see the appeal to going pure guix, the cross pollination is good for both projects, especially (IMHO) guix. This provided a gentler on-ramp to using guix at a smaller scale without the flying leap that is switching distros outright, and (per the article) the Debian maintainer(s?) have found reproducibility problems while doing their work which is quite valuable to guix.
> OR be running as guest, in some fantasical gnu hurd environment, thus forgoing linux.
Subhurds are really cool, but I would argue there are lots of practical uses that don't really need to go that far.
> I say this as a long-term guix user.
Curious, what is your need / use case? I typically just stick to the package manager for whatever OS I install, if I don't like theirs, I find a new OS.
Not the GP, but: For Guix in general? That's easy to answer:
(1) Making things reproducible. That is one of the main reasons. And not only installed system packages. You can also use it to build reproducible projects you develop, if the dependencies are available on Guix.
(2) The other one is installing software, that your distribution doesn't have in standard repos.
So its similar to Nix? I've heard similar of Nix.
Nix and guix ("geeks") are close cousins, and both can be an entire OS or be used just to manage a single workspace/project on another OS.
There was a solid piece on here a few weeks ago comparing the two, written by someone with in-depth knowledge of Nix: https://news.ycombinator.com/item?id=44569032
If you install guix as a user, it augments or overrides the software available on your base system.
It helps a lot on Chromebooks, where it's not straightforward to get a recent release.
It also helps to get up-to-date packages if you're a regular user and your admin doesn't have them for some reason (maybe RHEL or Ubuntu LTS.)
Or even just if your admin doesn't have the packages installed.
I feel like that brew, or better yet, nix are great options for userspace applications in Linux and macOS
Sure, there are other options for this. But this is certainly a use case for guix, which is what the poster was asking about.
Just using Guix requires a pretty substantial amount of administrative work. I'd imagine maintaining it is even more intense and that's why they're running into issues like this.
You have to be pretty slow to be outrun by Debian of all distros.
It's not the slowness of releases, it's the fact they don't release any stable version with just security fixes. They only make new cumulative releases. Debian's model is to fix a version for their release and do security patches on that, not to push out the latest version.
I would guess this is the same reason why one can't change git repo history without affecting people working with the repo. Merkle tree all over the store.
Merkle trees don't prohibit release / patch-only branches. Or multiple heads in general.
What do you mean by "Just using Guix requires a pretty substantial amount of administrative work."
Like, as a user downloading packages, or a person packaging an application?
As a user downloading a package, it's been super easy for me and it's been years of running Guix with little to no issue (yet the benefits of rolling release, rollbacks, installing multiple versions of a given software etc.).
As for using it to package an application, I found the challenges mainly in the documentation. This was years ago and a lot of work has gone into improving the docs.
I'm curious what your experience has been.
FWIW, not the OP but doing a guix pull after getting it from APT took several hours to crash out every time I wanted to just try using guix for something, and the ISO to install it from upstream was multiple gigabytes which seemed wild. I put a couple days into it and never actually got to try it.
It's hard to have an opinion of a platform you haven't used but based on how bloated just starting it seemed to be I was unimpressed.
> the ISO to install it from upstream was multiple gigabytes which seemed wild.
For the record, the Guix System install media is less than 1 GB. And the Guix installer from upstream looks to be 100 MB right now.