20
GNU Guix: How to run foreign binaries (zie87.github.io)
submitted 1 week ago by csantosb@lemmy.ml to c/guix@lemmy.ml
17 comments fedilink hide all child comments
top 17 comments
sorted by: hot top controversial new old
[-] jaennaet@sopuli.xyz 3 points 1 week ago

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?

[-] rrobin@lemmy.world 4 points 1 week 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).

[-] jaennaet@sopuli.xyz 2 points 1 week ago

Right, yeah, so there's occasionally a bit more jumping through hoops, but the end result is a much more manageable system where eg. updating thing X won't clobber the fuck out of dependencies that thing Y needed, and in general you get a more "containerised" setup with a declarative way to set it up?

What's the upside of Guix vs Nix (except eg. the syntax that @tetris11@lemmy.ml mentioned)?

[-] tetris11@lemmy.ml 2 points 1 week ago

There's also the fully reproducible build starting from a 357 byte seed file (cpu-specific) + guile library, to generate a full blown fully reproducible OS

https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/

[-] jaennaet@sopuli.xyz 2 points 1 week ago

Huh. Not only is that pretty neat from a nerdy "they did what?" perspective, having a fully reproducible OS setup is definitely very useful in many contexts. No surprise that the first blog post of that series references the classic Thompson Reflections on Trusting Trust paper about his cc backdoor

[-] tetris11@lemmy.ml 2 points 1 week ago

Yeah, that trusting trust paper really opened my eyes on how compiler development works through a series of hacks

[-] tetris11@lemmy.ml 3 points 1 week ago* (last edited 1 week ago)

No, it's a common gripe.

I wish GUIX would just symlink libraries to standard paths instead of having to educate every single downstream tool where everything is with Env Variables

Is it such a big ask to expect bash to exist at /bin/bash?

[-] khleedril@cyberplace.social 4 points 1 week ago

@tetris11 @jaennaet This wouldn't work. You couldn't have users running their own choice of gcc version, for example, as they'd clobber each other. The way things work actually makes a lot of problems fade, such as DLL hell.

[-] tetris11@lemmy.ml 2 points 1 week ago

But you typically run different commands in different shells, so if you needed to run different gcc's, you could just create a customized chroot for each shell and make sure that all the tools are where they should be (/usr/bin/ /lib etc)

[-] khleedril@cyberplace.social 3 points 1 week ago

@tetris11 Typically but not always. Oftentimes guix runs on top of a foreign distribution, and then a chroot jail might be unhelpful.

[-] tetris11@lemmy.ml 2 points 1 week ago

how so? a chroot jail is a chroot jail. As long as you've got all your toys where they should be, what difference does it make to the distro?

[-] khleedril@cyberplace.social 2 points 1 week ago

@tetris11 Because guix as a general rule knows nothing about the underlying operating system, so you can't expect it to set things up as you describe.

[-] tetris11@lemmy.ml 1 points 1 week ago

oh, true. In my head chroot is just proc/sys/dev binding, but you're right that there are OS specific paths there too

[-] jaennaet@sopuli.xyz 3 points 1 week ago

That does sound like a reasonable ask.

What are the upsides of Guix – in your view, anyhow – that make people be OK with downsides like this? I mean, this does seem like a fairly major downside, so there's go to be fairly major upsides too, or at least I'd assume so

[-] tetris11@lemmy.ml 4 points 1 week ago

I just think the declarative syntax is cool, and is easier to read than Nix

[-] khleedril@cyberplace.social 4 points 1 week ago

@jaennaet @tetris11 Once you've got everything set up, you can run your binaries in special containers for system isolation, make Docker images for distribution, run your stuff on other machines which have #guix on them, and generally enjoy the fruits of your labours.

[-] majster@lemmy.zip 2 points 1 week ago* (last edited 1 week ago)

Very informative post. I ran stuff before in guix container but learned about patchelf. Also agree on rust ecosystem of sprawling dependencies. Brings all the drawbacks of Python and JS into systems domain.

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

Guix

447 readers
1 users here now

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

founded 5 years ago
MODERATORS
early_adapter@lemmy.ml