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.

▲

yjftsjthsd-h a day ago | parent | next [-]

> 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.

▲

giancarlostoro a day ago | parent | prev | next [-]

> 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.

▲

zelphirkalt a day ago | parent | next [-]

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.

▲

giancarlostoro a day ago | parent [-]

So its similar to Nix? I've heard similar of Nix.

	▲	mikepurvis a day ago \| parent [-]
		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

▲

trelane a day ago | parent | prev [-]

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.

▲

felixg3 a day ago | parent [-]

I feel like that brew, or better yet, nix are great options for userspace applications in Linux and macOS

	▲	trelane a day ago \| parent [-]
		Sure, there are other options for this. But this is certainly a use case for guix, which is what the poster was asking about.

▲

msgodel a day ago | parent | prev [-]

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.

▲

terminalbraid a day ago | parent | next [-]

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.

▲

guga42k a day ago | parent [-]

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.

	▲	lmz 19 hours ago \| parent [-]
		Merkle trees don't prohibit release / patch-only branches. Or multiple heads in general.

▲

spit2wind a day ago | parent | prev [-]

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.

▲

ocdtrekkie 19 hours ago | parent [-]

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.

	▲	pxc 15 hours ago \| parent [-]
		> 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.