Trying Guix: A Nixer's impressions
9 comments
·July 15, 2025idlip
kwk1
Guix recently moved from Savannah to Codeberg, which hopefully will help move the needle on infrastructure and volunteer quantity concerns.
tempfile
The major con is in the article, it is super slow to update. Half an hour is just crazy, nobody will move to that if they know.
positron26
Important question is if its fixable.
Nix is pathologically recursive, lazy, and uses fixed points, things that are very apt to changing something that cascades through a bunch of dependents. Nix's runtime is not magic. Guile should be able to expose a language and evaluate it in a similar way.
For my part, I've not opted into Guix because it's a GNU project, and I've decided to avoid anything in the FSF sphere of influence. Their orthodoxy turns off contributors and they have a history of taking insular hard-liner approaches that are utopian. Outside of coreutils that are about to be fully subsumed by rewrite-it-in-Rust (which has a community that is not a fan of the GPL), what has had FSF backing and been successful? Linus starts two of the most influential pieces of software in human civilization and RMS wants to name the awards. The pragmatic culture that shifted away from the FSF has I think largely adopted Nix, and it shows. Nix is open for business, available on lots of platforms, has commercial entities built around its success.
kwk1
Agreed on the assessment, but for me, part of the appeal of Guix is a way to turn that ship around.
nbf_1995
From the article:
> My goal was to take my Unchartevice laptop with its strange Zhaoxin x86_64-compatible CPU...
> Sure, this is a laptop with a CPU broadly equivalent to old Intel Atom CPUs...
Yes, guix pull is slow, but the author is using some old/exotic hardware. The last time I tried guix on a 5th gen dual core i5, the initial pull was not that slow. And as other commenters have pointed out. The first pull is the slowest by far.
kyoji
I play around with a Guix install in a VM, and with less than half of my system resources, a `guix pull` with a `guix system reconfigure ...` takes about 10 minutes. That said, if a pull happens to include a kernel update it can take much longer. I think pinning large packages (like the kernel) that may not need incidental updating is key to keeping pull times lower.
tadfisher
10 minutes is still an order of magnitude slower than a nixos-rebuild if you're hitting the cache, and there's no issue with forgetting to rebuild the guix profile. If you include nonguix (as is required for the 99% of users who need nonfree blobs) you get the 30-50 minutes as described in the article. I believe Nix-the-language being lazily evaluated is a big part of this; you can even inadvertently evaluate nixpkgs multiple times and not notice.
kwk1
It doesn't usually take that long, but the first `guix pull` is quite slow, and what should be a no-op of running it a second time immediately afterwards also takes too long.
Edit: Just to provide a measurement, on my Framework 13 with AMD Ryzen 5 7640U, a `guix pull` which pulled in 1 nonguix commit and 64 guix commits took 2m10s, and a subsequent no-op `guix pull` took 1m18s.
Its nice read. We need more of comparative posts by user familiar with both nix and guix.
We see bias with most discussions.
Only cons with Guix I see is, lack of infrastructure and less volunteers to work on guix eco-system. If its solved, I can imagine guix can improve exponentially.