←back to thread

137 points 6581 | 1 comments | | HN request time: 0.001s | source
Show context
tucnak ◴[] No.45105862[source]
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.

replies(3): >>45106195 #>>45106805 #>>45106938 #
msgodel ◴[] No.45106938[source]
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.

replies(2): >>45107785 #>>45108980 #
terminalbraid ◴[] No.45107785[source]
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.
replies(1): >>45108669 #
guga42k ◴[] No.45108669{3}[source]
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.
replies(1): >>45111076 #
1. lmz ◴[] No.45111076{4}[source]
Merkle trees don't prohibit release / patch-only branches. Or multiple heads in general.