this post was submitted on 15 Jul 2025
19 points (100.0% liked)

Guix

445 readers
3 users here now

Guix is an advanced distribution of the GNU operating system developed by the GNU Project

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 2 points 2 days ago (11 children)

As someone who doesn't use Guix, reading this made me wonder why a "consumer" (ie. not someone running eg. corporate infrastructure or whatever) would want to use it, if something as seemingly trivial as this requires that much work.

What I mean is that I'm obviously just missing something, since there's got to be upsides to the system that make cases like this worth it.

Anybody feel like educating a dunce?

[โ€“] [email protected] 3 points 2 days ago

It is a long article covering a bunch of things. But I'll try to cover the items in the comments.

GUIX puts things in different location, making it incompatible with fhs standard. This important for guix to be able to implement its core features, namely these TWO

  • guix can install/run multiple different versions of the same package (bash, firefox, whatever)
  • guix can run/rollback your system/packages to a previously known state by swapping a link (and loading some settings)

The problem for the "consumer" here happens when they try to drop a binary they download from the internet and it fails to run because:

  1. it will not run because it cannot find the link loader lib/ld-linux-x86-64.so.2
  2. it cannot find something else where it expects (/bin/bash, /usr/lib64/libgtk.so, etc)

The article covers two solutions for this problem: the first is patchelf (but is only meaningful for link loader and libs) and the second is to run inside a container (guix shell --container --emulate-fhs). I should note here the container solution is not that different from e.g. flatpak or similar.

Now for my personal (and very biased) opinion. I do like that guix enforces this and that random binaries from the internet don't simply run here.

Historically distros packaged software for various reasons - but one side effect of this is that package maintainers (i.e. your distro volunteers) vetted changes/updates, tested new releases and reported issues upstream (or patched it). For me this is an important part of Linux distros not being a monoculture.

Finally on a hopeful note. I don't think this is insurmountable. The article mentions two things that already exist 1) guix packages that wrap binaries in containers and 2) guix import that does auto imports for libraries. In principle there could be a tool that glues these two to automate it but this will probably happen in one of the projects that packages binaries (nonguix probably).

load more comments (10 replies)