Trying Guix: A Nixer's impressions

by todsacerdoti • 1 year ago

201 89 1 year ago

idlip• 1 year ago

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.

kwk16• 1 year ago

Guix recently moved from Savannah to Codeberg, which hopefully will help move the needle on infrastructure and volunteer quantity concerns.

tempfile• 1 year ago

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.

kyoji• 1 year ago

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.

kwk16• 1 year ago

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.

nbf_1995• 1 year ago

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.

positron266• 1 year ago

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.

davexunit2• 1 year ago

Regular updates do not take anywhere near a half hour.

tazjin• 1 year ago

There's a few points to make here, actually, based on discussion of the article in the weeks before it hit HN:

Two major and immediate reasons why the pulling is slow are clear and fixable:

1. Guix will try to substitute from unreachable caches for a LONG time before giving up, and Guix infrastructure is less developed than Nix. When I kept experimenting after this post I set up https://mirror.yandex.ru/mirrors/guix/ eventually which fixes the substitute problems for me (Guix mirror on bigcorp infra).

2. Guix by default pulls its channel from GNU Savannah which, for some reason, is incredibly slow in serving git. The project moved over to Codeberg, and setting the URL to there significantly speeds up pulling.

In NixOS, channels (esp. the unstable ones) advance when CI finishes building a certain subset of packages successfully (this is what https://status.nixos.org/ shows). CI populates the binary cache, so this means that a channel HEAD always has a large number of packages available in the cache. Guix has no such guarantees, so updating to any latest commit might even yield one where you end up rebuilding all of its Scheme from scratch or whatever. Picking a commit that's a few days old helps with this.

I eventually switched to a laptop with a "normal" Intel CPU, and pulling did not magically turn fast. In fact, some of the slowest stages (there's one where it says "Computing Guix derivation") don't seem to exercise the CPU much at all. I haven't spent time looking at why (yet).

Guix System does a lot more per-user stuff than NixOS by default, which means that you'll likely end up pulling multiple times.

Pulling remains a much slower operation than Nix evaluation in any case.

There's a few ways to make this all more palatable (e.g. the `guix time-machine -C $channels` setup), but those might be for a follow-up post in the future.

rolandog• 1 year ago

I think that also one needs to be familiar with modifying the guix daemon service to allow substitutes be downloaded so that you don't have to build derivations [0], [1].

Once you modify the guix daemon service and approve the substitute server keys with `guix archive`, your experience should be much faster.

[0] https://guix.gnu.org/manual/en/html_node/Substitute-Server-A...

[1] https://guix.gnu.org/manual/en/html_node/Getting-Substitutes...

msgilligan• 1 year ago

We need more of comparative posts

The article focuses on a comparison between GUIX _system_ and NixOS. It would be interesting to see an equally thoughtful comparison that just focuses on GUIX vs. NIX as package managers used on another Linux distribution (e.g. Debian.)

In this case, GUIX might fare better as you won't have to worry about the complexities introduced by binary blobs needed for boot, etc.

spease• 1 year ago

Personally, I’d really like a crossplatform declarative package manager in a mainstream or mainstream-style language, where the nixpkgs equivalent can be JITed or AOTed including the shell scripts, so it isn’t painful to work with and can switch into an environment almost instantly.

Though nix the language syntactically isn’t that complex, it’s really the way that nixpkgs and things like overrides are implemented, the lack of a standard interface between environments and Darwin and NixOS, needing overlays with multiple levels of depth, etc that makes things complex.

The infuriating thing about nix is that it’s functionally capable of doing what I want, but it’s patently obvious that the people at the wheel are not particularly inclined to design things for a casual user who cannot keep a hundred idiosyncrasies in their head memorized just to work on their build scripts.

exe342• 1 year ago

Would it be possible to automate nix->guix for packages? A lot of nix packages (e.g. python) I think are handled automatically. If guix could build on that huge package repo, it would really help.

amelius• 1 year ago

I suppose an LLM could easily translate the build scripts. It will not be perfect, but probably will save a lot of work.

CBLT• 1 year ago

I had a similar experience. After running `guix pull` a couple of times on an ancient laptop I shelved the project until I made a distcc cluster (I never did).

pkulak2• 1 year ago

why flakes are nonsense

Oh wow, I want to hear more about that. I love flakes, but I've known they are controversial, and never really heard why.

realo• 1 year ago

I like flakes... I use flakes.

You love flakes... keep using them!

The rest is politics.

pkulak2• 1 year ago

For sure. But I find other people's opinions interesting.

hamandcheese3• 1 year ago

- flakes perform very poorly in large repos. This might be changing soon with lazy-trees, but I've been waiting for that for 2+ years.

- flake inputs are not fetched lazily.

- flakes are somewhat restrictive in that you can't override an input with an arbitrary value. This matters if you want to pass in, say, a specially configured nixpkgs object. In practice, for non trivial use cases, flakes fail to solve the problem they set out to solve. Most flakes expose lib functions for these advanced use cases but that's pretty much equivalent to what you get with non-flakes.

dawnofdusk• 1 year ago

I mean they get evaluated in a weird way: for example you cannot use the `rec` keyword when declaring inputs.

ethan_smith• 1 year ago

Flakes are controversial primarily because they create a parallel ecosystem that breaks compatibility with the traditional Nix workflow, introduce additional complexity without solving core reproducibility issues, and were developed with limited community input despite representing a fundamental shift in how Nix works.

peterldowns• 1 year ago

Very interesting writeup, as a long-time Nix user I've always been interested in trying guix but never gotten around to it. Great post overall.

The thing is, I'm not actually sure if Guix's better documentation helps smooth the onboarding in any way because you have to already know Scheme, which is a more complex language than Nix.

LMAO absolutely not. Nix-the-language is the worst programming language I've ever had the misfortune to interact with. I picked up Scheme in about 1 day during a class in college. It's night-and-day different.

otabdeveloper42• 1 year ago

Nix-the-language is the worst programming language I've ever had the misfortune to interact with

Nix-the-language is just a subset of Javascript with built-in laziness and a slightly different syntax. An absolute bog-standard and mainstream way of thinking about programs in 2025.

That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development.

grep_name• 1 year ago

That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development

That must be it. The GP's comment really resonated with me, in that learning scheme felt like no task at all whereas I STILL feel uncomfortable with the nix programming language and ecosystem despite using nixOS exclusively on my personal laptop for two years and on my work machine for about half a year now. I've always fumbled over frontend / javascript development though, and avoid it as much as I can at work although I still end up working in it every year or so.

Nix only won out for me because of the mac compatibility, without which I can't really use it at work

fake-name• 1 year ago

I mean, that's a distinction without a difference.

I've not written nix, but javascript is a ugly, terrible language. It would make sense that if nix derives from it (whyyyyyy) it would also be terrible.

yencabulator4• 1 year ago

Yes, clearly every general-purpose language like Javascript has specialized the string type for the business domain of text-templating for bash scripts.

For example: https://shealevy.com/blog/2018/08/05/understanding-nixs-stri...

positron266• 1 year ago

Nix-the-language is the worst programming language I've ever had the misfortune to interact with.

I feel the same.

The multi-line strings and string interpolation are both really nice. Unfortunately a lot of the text being munged is bash and usually already ugly, so the result is double-ugly.

The functional aspects are okay. However, as an expression language and being primarily used in a declarative way, it is frequent to have almost no idea what's going on in Nix. Reading the code and understanding the evaluation are extremely far apart.

callPackage... It's something I thought would be cool in a language until I actually experienced the depth of disorientation it can cause.

The remaining syntax has a lot of "but why?" where it just seems to do its own thing relative to other languages, which makes it harder to get into a rhythm.

Some of the subject matter is the real culprit. The cross compiling sliding window thing... I've studied it several times. If I had to actually do something with it, straight to the LLM. Compilers have targets.

sshine3• 1 year ago

The remaining syntax has a lot of "but why?" where it just seems to do its own thing relative to other languages

Like what?

My list of Nix language nits is relatively small, would like to understand.

One thing that seems under-developed is smart merging. There is // at language level, but then if you want datatype-specific merging, you use functions. That itself is just the power of functional programming. But as it is with untyped languages, you end up doing the same thing slightly different in several places, and a fractal of accidental complexity starts to appear.

0x4572• 1 year ago

So I found some LLMs are wonderful at Nix. A few times I just prompted "port this <github link>" and got a pull request with nix package exactly how I would have written it. One time even manager to implement multiple missing dependencies as well.

xrd• 1 year ago

I gotta admit, I stopped reading when I saw nix with scheme. If it was scheme plus nix and it was sorted, I might have continued.

hamandcheese3• 1 year ago

The main thing holding me back from trying guix is that, as far as I know, there is no support for macOS.

umanwizard2• 1 year ago

Correct, Guix is Linux and Hurd only.

agumonkey2• 1 year ago

Are people using Hurd still ?

kwk16• 1 year ago

It's still pretty early, but there's a "macOS Subsystem for Guix" project:

https://superkamiguru.org/projects/msg.html

hamandcheese3• 1 year ago

If I understand correctly, that seems to virtualize a Linux system to work, which makes it quite different from nix on macOS.

guilhas4• 1 year ago

I like them both, both interesting, quite similar, both with corner cases

Annoyingly both fail at basic stuff like falling back the graphics card, something Debian had solved 10 years ago, no configs needed, no matter Intel/NVIDIA/AMD. Even without the correct driver or firmware falling back to VESA or fbdev should be a given. Never had so many black screens as now. Even Windows has done better job at giving you a basic resolution while you install the drivers

Or maybe it's just the state of the Linux ecosystem, with the introduction of Wayland and NVIDIA open drivers, causing regressions

Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default

Which increases the amount of bugs, having frequent updates to a stable system

To make it better you can add 2 channels, and call them nixos-stable v24 nixos-latest v25, keeping most of the system one version down increases stability a lot

Of course the incorporated Grub boot build choices is great to revert back to a working system

I really like the the separation Guix makes on having close source being a concern of a separate project

But both of them are equally easy to install open source only or include proprietary

yjftsjthsd-h2• 1 year ago

But both of them are equally easy to install open source only or include proprietary

Unless it really dramatically changed recently, I don't think that's true. Look, here's the official manual page that describes exactly how to enable use of the non-free packages that are right there in the main nixpkgs repo:

https://nixos.org/manual/nixpkgs/stable/#sec-allow-unfree

And here's the guix equivalent, maintained in a completely separate repo that you're not allowed to talk about, document, or refer to in any official channels: https://gitlab.com/nonguix/nonguix

These are not equal.

guilhas4• 1 year ago

These are not equal.

Of course they are. Copy and paste a text snippet to your configuration, and run the cli to refresh

Being a separate repo is absolutely OK. Just like installing Nixos's own Home-Manager

Or add other people channels, like adding PPA on Ubuntu/debian. Or run flakes...

Nixos is possibly makes it more confusing by having the documentation recommend `nix-channel --add` instead of the declarative approach. Having the standard declarative, and having flakes on top

And you should probably want to create your own channel. On the week I installed Guix immediately created my channel and packaged ZimWiki

qiine• 1 year ago

Also the unintuitive inverse of traditional package management, where if you want to update one package, all the system updates by default

What do you mean? ins't that exactly the arch way ? (no partial update supported)

guilhas4• 1 year ago

In Arch if I needed something updated today you would have done

pacman -Sy
pacman -S package_name

Leavig the rest system unchanged

In Nixos

nix-channel --update
Add package to /etc/nixos/configuration.nix
nixos-rebuild switch

Which would update everything

Maybe we could do

nix-channel --update
nix-env -iA packagename

But I am not sure which version would be installed. And it would definitely go against the purpose of using nixos

nix-shell -p package_name

It is also quite cool for trying packages without installing permanently

hardwaresofton3• 1 year ago

Guix SD will never catch on as long as they force non-systemd management. I don’t care to try Shepherd. Systemd is good enough and it has won.

I had to use nonguix to get internet working on the machine, which had very immediate technical effects that bring me to

Stuff like this will

The main reasons I’m interested in guix:

- it uses a known-good language (lisp)

- IIRC it is more repeatable (the contents used in derivations play into the hash).

- It has a full source bootstrap

Maybe someone with a focus on improving UX needs to build one of these afresh.

medstrom• 1 year ago

I don't know if importing systemd would make any difference to the system declaration file that you write, where you'd still declare services in the Lispy way. Does it matter if it translates to systemd services under the hood or not?

hardwaresofton3• 1 year ago

Does it matter if it translates to systemd services under the hood or not?

I think so, because that's what most people are familiar with maintaining/configuring. Systemd at this point is quite robust, and it's sprawling ecosystem has a lot of functionality. Perhaps more importantly, this is the stuff you'll find the most support/integrations for.

bjoli2• 1 year ago

After getting used to systemd, I decided to put my toes in the water and try guix. From a user's perspective you never really don't have to care much. Even complex services are pretty simple, and it is really not like you are doing anything different.

The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later.

My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.

hardwaresofton3• 1 year ago

The downside is, of course, that more and more of the linux userland depends on systemd. That is bound to become a problem sooner or later.

This is the main problem. Systemd has the most eyes, and the most active development, and I just don't want to spend innovation tokens on that as well.

My biggest gripe is that I would like to have a simpler way to install it onto my computer. I need nonguix to even boot on one of my computers, but I really really hate doing that because doing a system install from nonguix has a tendency to break things for me later on.

That's a huge issue. Which also reminds me, this kind of requirement is dead in the water for the GPU era, at least until there are sufficiently F/OSS high quality drivers (which may be never).

Maybe the answer here is to just use only guix the package manager

guilhas4• 1 year ago

I also don't care to try Wayland. Xorg has already won

A lot of people would argue avoiding systemd bloat as a plus

The end user interface for shepherd and systemd are very similar. And probably the least of your worries migrating to a declarative distro

Geezus_42• 1 year ago

Xorg won? I mean, it has a larger install base probably, but it's also been around significantly longer.

abrookewood• 1 year ago

I'm actually more interested in the Niri "A scrollable-tiling Wayland compositor". It never occurred to me that a valid desktop/windowing paradigm would be one with an infinite horizontal strip. Not sure if I want it, but it's pretty unique.

https://github.com/YaLTeR/niri?tab=readme-ov-file

evgpbfhnr• 1 year ago

I've switched from wmii (old suckless tiling wm) to niri a couple of months ago and I've been happier with it than with sway/i3 -- give it a shot :)

cenamus• 1 year ago

Is it similar to the Gnome plugin PaperWM?

emaro• 1 year ago

Yes, Niri is inspired by PaperWM afaik.

sunshine-o• 1 year ago

Scrollable-tiling is the best. Especially if you have two wide monitors side by side.

nicman23• 1 year ago

i used to do something like that with i3. binding meta+tab to go to the next workplace and some combos to move the windows with the same base.

then i realized that it is basically just want i did with compiz or kwin and moved back lol

yencabulator4• 1 year ago

Think of it less as an "infinite strip" (with implications of windows being lost in the mist, far away) and more as "each workspace is laid out in a strip".

Most of my workspaces have 2-5 columns, with 2-3 fitting on an ultrawide monitor at once.[1]

It's more like "what if tiling window manager, but with even less time spent on adjusting window sizes".

[1]: Let's agree not to talk of the insanity that contains my open browser windows. That is as near infinite as 96 GB RAM lets me have..

rekado• 12 months ago

I'm using it on Guix via the Rosenthal channel: https://codeberg.org/hako/rosenthal.git

I quite like it because it's more predictable than automatic tiling window managers and generally less work than manual tilers. (I've used tilers since maybe 2010 with xmonad.)

Trying Guix: A Nixer's impressions

Related Stories