Nemin's Blog

Guix System - One Month Later

2026-03-02T08:58:00Z

1. Community
2. Packaging wows and woes
3. System ups and downs
4. Conclusion

It's been about a month since I installed Guix System on my PC and now that I had some time to play around with it more seriously, I figured I'd record my additional thoughts, positive and negative, and why I ultimately chose not to stick with it.

1. Community

1.1. IRC

I am happy to report, that the IRC chat of Guix is both surprisingly active and very welcoming. I was able to join in and participate in discussions as a complete newcomer and I never once felt like people were ignoring me or valuing my opinion less due to my newness. This is excellent and a high standard for any other community to strive for.

My general impression was that there is plenty of good-hearted banter, people helping each other figure stuff out, people discussing their configs and such. Hell, I even got a few shout outs for my previous post, which was super encouraging as a new author.

1.2. Mailing lists

I feel like it's much harder to engage with Guix discussions on a longer-term scale. By this I mean that there are a few mailing lists, which seem quite active, but as someone who grew up after mailing lists were cool, they're a bit intimidating to me. This doesn't mean I cannot find my way around (with some effort), but it's definitely a barrier compared to having a conventional forum.

However, I recognise that this is a me / my generation problem and that likely for many others forums would prove just as cumbersome. Mailing lists are a very common thing in GNU/FSF related projects and, without even looking at the larger GNU projects and just by perusing the Guix archives, it's very clear that they're an effective way of communication, that requires no account and is compatible with a ton of configurations.

I just wonder if there could be a better way of handling them, that doesn't feel as daunting to people who didn't grow up with this form of communication. I think even something as simple as a bit of CSS applied to the online interface of the mailing list could make it immediately a lot more appealing, but perhaps I'm simply being shallow.

1.3. Subreddit

r/GUIX is not an official community, but it doesn't seem bad. People generally seem to only post questions, with the exception of the occasional screenshot of their config. It is a little barren, with only a couple posts a month, but Guix System is a niche distro and most communication happens on either the mailing list or IRC (or on the Codeberg issue tracker), which leaves only a small subset of people who are both interested enough in Guix too want to talk about it, but are also willing to put up with a closed and not exactly sqeaky-clean platform like Reddit.

1.4. Fediverse

Guix has a presence on Hachyderm, which is one of the more known Mastodon servers out there. I have little experience with the Fediverse (I've never even used Twitter much, which is the mainstream equivalent to Mastodon), but I'm glad that it exists. The account seems quite active too, the team running it is diligently sharing Guix-related posts and even makes some posts of their own.

They actually shared my own article on their page, which I'm super happy about. If you're reading this, thank you very much! Interactions like this make me want to look deeper into this corner of the internet.

2. Packaging wows and woes

After my success with packaging WezTerm, I decided to jump into upgrading some other packages too. These upgrades were mostly minor stuff, not really worth their own posts, but they did come with recurring issues and notes, that I figured would be worth collecting here.

2.1. I really love the go-getter attitude of Guix

You want to upgrade a package? Go ahead, do it. With the exception of trying to do something so big that it requires a team consensus or is so huge that it requires a dedicated team (think GNOME or KDE), nobody will say "That's not your authority!". You can just open a PR, get some eyes on your change and that's it.

At the time I was writing this, I was packaging the Odin language for Guix. Apparently nobody did it before me, their compilation guide seemed simple enough, so I went and did it myself. As someone who works in a corporate environment, this sort of freedom is exhilarating, especially since you're not just simply helping yourself, but all the other people who might want to try this language in the future and happen to be using Guix too.

This is very much unlike Nix, where every package has one or more so-called maintainers, who have first say in how a package is developed and upgraded. On one hand, this does provide a bit of accountability. People will feel stronger about keeping stuff up to date and tidy if it's at least superficially "theirs". On the other hand, it's yet another hurdle for those who would like to help out, but aren't yet in the maintainers list and it makes Nix feel more private than it really is.

2.1.1. A side-note about speed

The only real negative part of this whole contributing experience is the speed of reviews. There are PRs open from eight months ago. While such is not unusual in corporate environments (hell, make it years), I believe it's not healthy for a rolling release Linux distro, except in very specific cases (projects of such magnitude that you really need a year-ish time to develop them).

By the time people actually take a look at the PR, the project had moved on and is substantially different from when the PR was opened. At best this will result in headache-inducing merge conflicts, at worst the PR is no longer relevant, because some other development had obsoleted it. While I haven't experienced such myself yet, I bet it'd be a pretty disheartening feeling.

Now, I'll freely admit, my PRs so far had generally speedy review processes, so I personally don't have anything to complain about. My point more is that this is not a given thing, but rather something that comes down to the maintainers free time and available effort. And long delays can result from something as mild as some irritation to actual breakages (see the section about Thunderbird of this article).

This is nothing new though. The Guix team itself identified the slowness of reviews as one of the main things people find cumbersome about the project. This presentation is from a year, so hopefully the gears are turning in the background as I'm writing this and soon enough this problem will be a thing of the past. Until then, any prospective packagers should be aware that they are more than welcome, but they should also come prepared for long waits of up to a week or more, before their package is considered.

2.2. Debugging is an unpleasant experience

In my experience, errors messages in Guix are not very helpful. This is not super surprising seeing Guix is a massive build system built on a completely dynamic language, but regardless it makes debugging a real pain in the neck. Which is a shame, because one of the main selling points of Lisp(likes) is the fact that their REPL experience is unparalleled and that all other languages lag behind with their tacked-on / simplistic debuggers.

In Guix' case, while it is possible to use the Guile REPL to interface with the build system, so far I didn't find it useful enough to replace the basic "Edit in editor -> Compile in terminal -> Try to figure out errors" loop.

The three most confusing issues I've experienced so far were:

2.2.1. Missing parentheses

For this first example, I'll include the entire stack trace. In the other two, it will be truncated, but be aware that with each error we get this much on our screen.

  /home/nemin/programming/projects/guix/gnu/packages/guile-xyz.scm:7973:1: unexpected end of input while searching for: )
error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

error: libusb: unbound variable
hint: Did you forget a `use-modules' form?

error: make-lld-wrapper: unbound variable
hint: Did you forget `(use-modules (gnu packages llvm))' or `#:use-module (gnu packages llvm)'?

error: tcc: unbound variable
hint: Did you forget a `use-modules' form?

error: cross-gcc-toolchain: unbound variable
hint: Did you forget `(use-modules (gnu packages cross-base))' or `#:use-module (gnu packages
cross-base)'?

error: gnu-make: unbound variable
hint: Did you forget a `use-modules' form?

error: tar: unbound variable
hint: Did you forget a `use-modules' form?

error: gcc-toolchain: unbound variable
hint: Did you forget a `use-modules' form?

error: xdgpp: unbound variable
hint: Did you forget a `use-modules' form?

error: cross-binutils: unbound variable
hint: Did you forget `(use-modules (gnu packages cross-base))' or `#:use-module (gnu packages
cross-base)'?

Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f)'.
Backtrace:
In guix/status.scm:
    842:4 19 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   504:37 17 (thunk)
   1119:8 16 (call-with-build-handler #<procedure 7f6d9e2ab390 at g���> ���)
In guix/scripts/build.scm:
    646:2 15 (_)
   695:42 14 (loop _ _ ())
In gnu/packages.scm:
    512:2 13 (%find-package "haunt-next" "haunt-next" #f)
    392:6 12 (find-best-packages-by-name _ _)
   322:56 11 (_ "haunt-next" _)
In unknown file:
          10 (force #<promise #<procedure 7f6d9e306700 at gnu/packag���>)
In gnu/packages.scm:
   244:33  9 (fold-packages #<procedure 7f6d9d90b778 at gnu/package���> ���)
In guix/discovery.scm:
   158:11  8 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  7 (fold #<procedure 7f6d9e3437e0 at guix/discovery.scm:1���> ���)
In guix/discovery.scm:
   148:19  6 (_ _ ())
    115:5  5 (scheme-modules _ _ #:warn _)
In srfi/srfi-1.scm:
   691:23  4 (filter-map #<procedure 7f6d9e343680 at guix/discove���> . #)
In guix/discovery.scm:
   123:24  3 (_ . _)
In guix/ui.scm:
    365:2  2 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f))'.

Admittedly in this case it's not too bad, because Guile does actually inform you that a closing parenthesis is missing, but the error is still buried under a load of completely irrelevant error messages.

Additionally, if this happens, guix edit no longer works and you need to manually open the file that contains the issue and find the package. Not a big deal, but a bummer.

2.2.2. Non-existent variables

error: reversion: unbound variable
hint: Did you forget a `use-modules' form?

error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

<... a lot of other stuff ...>

It happened to me once or twice that I was either still referencing a variable that I previously cut or I made an accidental typo.¹

Just like with the missing parentheses, you technically get an error, but it's buried and blends in with all the other completely irrelevant errors (which are actually not even legitimate errors, they're just caused by the process buckling on itself).

Of course, it's hard to blame Guix here. There is no programmatic way of telling if the user was just silly or if there really is a variable somewhere in some yet unused module. But it'd still be so much better if the error stopped right after the first (and only legitimate) missing variable.

Also guix edit breaks as before.

2.2.3. Circular dependencies

This one in my opinion is the most problematic common issue a package author might face. Chiefly because the error message you get in this case is not even useful:

error: gcc-toolchain: unbound variable
hint: Did you forget a `use-modules' form?

error: xdgpp: unbound variable
hint: Did you forget a `use-modules' form?

error: cross-binutils: unbound variable
hint: Did you forget `(use-modules (gnu packages cross-base))' or `#:use-module (gnu packages
cross-base)'?

Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f)'.

<... a lot of other irrelevant junk ...>

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f))'.

The untrained packager might start pulling in stuff like gcc-toolchain or xdgpp, not understanding why they even need these or start poking around (gnu packages freedesktop) to no avail. As far as I know, there is no good method for figuring out what is causing a circular dependency beyond good intuition and bisecting your code until you find the culprit.

I've struggled quite a bit with this while packaging Hare 0.26.0 and, while I did manage to solve the issue I faced there, I wasn't extremely happy with the solution:

(build-system hare-build-system)
(native-inputs
   (list scdoc
         (module-ref (resolve-interface '(gnu packages hare)) 'harec)
         qbe))

In this instance, as you may have guessed, harec is the culprit. I'm still not 100% on all the details, but I believe the problem is caused by hare-build-system pulling in the hare module (which harec belongs to) and so when we're trying to import it in the package definition, it can't work out the right order.

Whatever's the reason, the solution isn't super difficult, but it is also not exactly obvious. Firstly, we need to get the module "behind Guix's back":

-- Scheme Procedure: resolve-interface name [#:select=#f] [#:hide='()]
        [#:prefix=#f] [#:renamer=#f] [#:version=#f]
   Find the module named NAME as with ���resolve-module��� and return its
   interface.  The interface of a module is also a module object, but
   it contains only the exported bindings.

Next, we need to extract harec from it:

-- Scheme Procedure: module-ref module name
   Look up the value bound to NAME in MODULE.  Like ���module-variable���,
   but also does a ���variable-ref��� on the resulting variable, raising
   an error if NAME is unbound.

What we're ultimately left with is the same as if we simply imported the module normally and then put harec into the list. The trick here is that the various inputs Guix takes (including native-inputs) are thunked. This means the code inside these forms isn't immediately run, but is instead delayed to a later moment, unlike the build system which is already resolved during the start of evaluation.

In effect, by only ever referring to harec in a thunked environment, we've completely side-stepped the whole "where should we import the module" problem by forcing the package definition to wait.

I'll freely admit that I would have not figured this out had there not been many other packages whose authors have faced this exact problem before and before the kind help of tinystar, who guided me towards targeting the native-inputs instead of my original idea.²

2.3. A cornucopia of styles

Guix is a very flexible system. This is usually a great thing, because the last thing you want is your build system to constrain you from including a package that otherwise fits into the repo. However, this also bring with itself the fact that (beyond what the linting script offers) there is little guidance on how your package should be organised.

This shows up both in small and big things. A good example is that the order of fields in the package definition is arbitrary. People generally put name first, but there is nothing actually stopping you from putting it last. Sure, this probably wouldn't pass peer-review, but with other fields, the situation is far less obvious.

For instance, should you introduce all static metadata first or should you go by the usual order and put arguments before the description and license? How do you break lists aesthetically? Do you use (arguments (list stuff)) or (arguments `(stuff))?

And then there's the even larger differences:

Path construction: When it comes to constructing paths,
Listing 1: Do you use format?
```
(format #f "~a/path/to/bin" #$output)
```
Listing 2: Or string-append?
```
(string-append #$output "/path/to/bin")
```
Listing 3: Or perhaps in-vicinity?
```
(in-vicinity #$output "path/to/bin")
```

Code repetition: When installing completions,

Listing 4: Do you spell out each shell?

(with-output-to-file bash-file
  (lambda _ (invoke "binary" "output-bash")))
(with-output-to-file zsh-file
  (lambda _ (invoke "binary" "output-zsh")))
(with-output-to-file fish-file
  (lambda _ (invoke "binary" "output-fish")))

Listing 5: Or do you just delegate it to a for-each-match-lambda pair?

(for-each
 (match-lambda
   ((file-name . command)
    (with-output-to-file file-name
      (lambda _ (invoke "binary" command))))
   '((bash-file . "output-bash")
     (zsh-file . "output-zsh")
     (fish-file . "output-fish"))))

Environment variables: If you need to set environment variables,

Listing 6: Do you make a whole phase just for this purpose?

(modify-phases %standard-phases
  (add-before 'build 'set-environment
    (lambda _
      (setenv "VAR1" "VALUE1")
      (setenv "VAR2" "VALUE2")))
  (replace 'build
    (lambda _ ...)))

Listing 7: Or do you use setenv inside the build phase?

(modify-phases %standard-phases
  (replace 'build
    (lambda _
      (setenv "VAR1" "VALUE1")
      (setenv "VAR2" "VALUE2")
      ...)))

Post-processing: If you need your built binary for post-processing (e.g. installing completions, generating extra files, etc.),

Listing 8: Do you call it from your build folder?

(let ((bin "./build/folder/your-binary"))
  (invoke bin "postprocess"))

Listing 9: Or your output folder?

;; Also, do note that the whole previous debacle of which
;; path joining method to use still applies!
(let ((bin (string-append #$output "/bin/your-binary")))
  (invoke bin "postprocess"))

Listing 10: Do you even call it straight or do invoke it indirectly to account for cross-compilation?

;; Taken from gnu/packages/rust-apps.scm, "just" package
(let ((just (if ,(%current-target-system)
                (search-input-file native-inputs "/bin/just")
                (string-append out "/bin/just"))))
  (with-output-to-file
             (string-append bash-completions-dir "/just")
             (lambda _ (invoke just "--completions" "bash"))))

I'm sure there's a lot more, but these are the stuff that I personally experienced. The issue is that for most of these you might feel like one or the other is the obvious answer, but if you scroll through the package definitions, I'd bet money on it that you'd find multiple examples of all of them.

Now, don't get me wrong, I'm not pointing fingers at anybody. Guix is a volunteer project to which hundreds, if not thousands of people contribute to. You cannot expect perfect coordination from so many people, especially volunteers who might just want to see X or Y package in the registry and don't necessarily care about digging super deep into how things work. Not to mention, having ten different similarly good ways of doing something is a known Lisp curse. When you have barely any syntax and very convenient tools to mess with ASTs, all hell breaks loose.

But I think it'd still make sense to codify some basics at least. Have a given order where package fields should go. If someone strays from this, have them justify it with a solid reason. Give pointers on divisive styles like the examples above, providing reasons why Guix recommends one over the other.³

This would serve two important purposes:

Firstly, with less noise in the code, it'd be much easier for everyone to study the code, make changes, and review others' changes. Mundane code beats smart code when it comes to working together and with Lisp(likes) one already needs discipline to write "standardised" code.
Secondly, with these things codified, newcomers would have one less thing to be stumped by. I was so surprised when during my first PR my usage of string-append was replaced with in-vicinity, not only because I had no idea that this function existed in the first place, but because I was working based on another package where string-append was used and didn't even consider it's not the only option.

2.4. ChangeLog is confusing

I briefly touched on ChangeLog in my WezTerm post, but I wanted to bring it up again, because despite my best efforts at trying to build "muscle memory" for it, I still feel nearly as lost as I did at the start.

Okay, that's not entirely fair. I was able to get the provided Emacs's yasnippet templates loaded, which automate some of the tedium that comes with the ChangeLog commit message style. I've also been made aware that there is a file under etc called commiter.scm, which practically writes all the boilerplate for you.

However, it's not really the tedium that bothers me. If ChangeLog were really just a very rigid and verbose system where each possibility is set in stone and obvious from a glance, I probably wouldn't mention it or, hell, maybe even would have put it in as a positive.

But that isn't the case, because where these templates cannot help is the nuanced parts. It is not entirely obvious how involved you need to make your commit messages and, even from my very limited experience, it differs greatly between maintainers who accepts what.

For instance, with Rust applications you are expected to import all dependencies into the registry. So far so good. But how does one reflect this in their commits?

For one, you must include your note about the crate import in the same commit as the one that introduces your package. This goes against the usual convention where each change gets their own commit, but (while I don't remember it mentioned in the guide) it's obvious enough to figure out based on a quick git log.

What's far less obvious, however, is how to phrase this import. To keep everyone in the loop, an entry in a ChangeLog-formatted commit message looks like the following:

An asterisk to denote a new entry,
The name of the file that was edited,
Then the name of the variable / function that was edited in parentheses,
Then, only if what you were editing is a struct with multiple fields, the name of the field in square brackets,
Then, if said field has its own sections, the name of the section in curly brackets,
Finally, after a set of colons, you add a short textual description of what you've done.

For example:

* foo/bar/baz.scm (example-struct)[section]{subsection}: Frobnicated some walruses.

Now that we're on the same page, let's try to construct a line like this for our Rust imports. The start of the line is easy: * gnu/packages/rust-crates.scm. But what comes right afterwards and especially in the description field is nontrivial and wildly varies between authors.

From what I can see, there are two bigger schools of thought:

* gnu/packages/rust-apps.scm ($PACKAGE): Init at $VERSION.
* gnu/packages/rust-crates.scm (lookup-cargo-inputs): Added imports.

This variant only records the essentials. "We're handling $PACKAGE, which is a Rust application" and "We've imported a given number of crates". The pros of this is that it's extremely short and simple, and it conveys intent without going into the details. The con is that it doesn't mention anything about which crates exactly were imported.

And that is exactly what the second variant focuses on:

* gnu/packages/rust-apps.scm ($PACKAGE): Init at $VERSION.
* gnu/packages/rust-crates.scm ($CRATE1, $CRATE2, $CRATE3, ...): New variables.

This is the polar opposite of the first version. Very specific, clearly spells out what crates were imported into the registry and at what version, and fits more into the usual commit message schema.

On the other hand, it occasionally produces monsters like this:

Figure 1: This goes on for four more pages, by the way.

In my personal and, indeed, just as subjective opinion, Variant 1 is the clear winner. The point of a commit message is to convey intent or, as the ChangeLog manual puts it:

ChangeLog Concepts: People can see the current version; they don��t need the change log to tell them what is in it. What they want from a change log is a clear explanation of how the earlier version differed.

Yes, spelling out the whole list is "clear" in a certain sense, but since these crates were imported by a script and (beyond a couple of cases) aren't really touched by human hands, I believe the only relevant thing worth recording is that the importing process happened.

But, while I have laser-focused on a single pain area, it's not the only place where disagreements like this happen. I've been given recommendations to rephrase several of my commit messages and it's not that I'm lazy to do this (in fact I've followed this advice most of the time), I just feel like the system is both rigid enough not to be very pleasant to use, but also loose to be truly automated.

Again, Guix is a very flexible system, so maybe this "looseness" is actually a sheep in wolf's clothing. Better this than constant overrides in case the rigid system doesn't quite cover all the needs of maintainers.

3. System ups and downs

While the previous section was about my experience with packaging stuff, this will be about using others' packages.

3.1. Stability of my config

One thing I found interesting is how stable my config files ended up being while using Guix. Beyond the occasional addition to my home configuration, I found that I didn't have to touch my system config file at all.

While this is obviously partly because I already experimented a bunch on NixOS before finding the right subset of applications that I need to be productive, I also feel like Guix is generally the less fiddly system of the two (in this particular aspect).

Even more notably, I haven't had to touch Shepherd, Guix System's service manager once yet. Everything Just Works��, including changing over to PipeWire (my preferred audio server), which is both very well documented and only required a couple of lines in my home config:

Listing 11: All you need to switch over.

(service home-dbus-service-type)
(service home-pipewire-service-type)

If everything was this simple in the Guix world, I'd have nothing to complain about. This is a gold standard.

3.2. Interfacing with my phone

I wanted to move some files from my phone to my PC. On every other distro I've tried before, all this took was plugging it in and clicking on "Mount filesystem". Or, perhaps if it was a more frugal distro, I had to issue lsblk, find the right disk drive, and manually mount it at a folder of my liking.

With Guix System, I was unable to do this. I plugged my phone in, KDE Plasma offered to mount it. I clicked on it and all I got was a really confusing error. Finally, after quite a bit of digging on Google, I found a topic on the Arch Linux forums where someone mentioned kio-extras and kio-fuse. By adding these to my profile, the phone was finally able to connect.

This particular instance wasn't a huge ordeal, but it is an annoying paper-cut, that makes Guix System feel slightly less polished. I believe the existence of a "Guix Wiki" (in the spirit of the Gentoo and Arch wikis) would help a lot in situations like this.⁴

3.3. Blunderbird

I generally use Thunderbird (or, since Guix doesn't provide Mozilla-branded binaries, Icedove) to handle my mail. It's a far more pleasant process in my opinion than constantly having a tab open in your browser.

Well, as it turns out an update recently broke Icedove, because it implicitly relies on the other Mozilla-packages being the same version. Because of this, none of the build servers were able to build the package. This ultimately resulted in me being unable to update my system (without removing Icedove), because the moment I tried, Guix would notice that there is no pre-built package and began building it on my PC.

This would be fine in most other cases. I do have a 12 core Ryzen CPU and 32 GBs of RAM,⁵ so it's not like I don't have the hardware usually. However, in this particular instance, even such mighty specs failed to cope with all of Icedove's dependencies (I believe it's webkit-gtk that fails specifically, but I'm not 100% sure), so after my PC crashed twice trying to update, I decided to try to pursue different avenues.

My first attempt was using GNOME's Evolution mail client. No luck. No matter what I tried, it couldn't connect GMail using OAuth2 and all the errors I've got were very cryptic.

Fine, whatever, I use KDE Plasma anyway, so why not give KMail a shot? I installed KMail and…

Well, that's annoying. Neither the link, nor the button worked. I tried looking up what's going on and was led to believe the issue is caused by another dependency named akonadi missing. It's packaged in Guix, so I added it to my profile, reconfigured the environment, restarted KMail and… Nothing. Still the same error.

A bit more investigation later, I found that running akonadictl status should give me a bit more insight:

So it's unable to connect to MariaDB (which I've also added to my profile off-screen). At this point I was kind of stuck and abandoned this experiment.

I don't know, maybe there was an easy solution and I was merely a step away from making KMail work, but manually pulling in 5-6 dependencies for an application on a declarative distro is kind of above my tolerance. I get that not everything can work out of the box, but this style of debugging fits Slackware⁶ a lot more than it does a modern Linux distro.

Well, with the obvious alternatives ruled out, I was left with figuring out what to do with the Icedove situation. At the time I started writing this article, the fix was yet unmerged⁷ so there were only a couple of options someone who uses the package could take:

Not update:
- Pros: Requires no actions.
- Cons: No upgrades until the situation is resolved.
Remove icedove from your profile:
- Pros: Very simple to do. You get other upgrades for everything else.
- Cons: You have to use another method to manage your mail. As seen above, if you don't want to use the browser route, this isn't necessarily an easy process.
Use an Inferior: (a.k.a. instruct Guix to pull in an older channel's package)
- Pros: You still have Icedove (even if it's an older version) and upgrades for everything else.
- Cons: Requires tracking down the last commit that still worked, setting up the inferior, and then eventually removing it once the upgrade is done.

Ultimately I chose option #3 and made an inferior for Icedove. In this instance, it was thankfully super easy to find the last good commit, because someone else already did the dirty work. Despite the warning in the manual, it didn't even take particularly long to compute the new Guix derivation.

On one hand, I suppose it's another praise towards Guix's flexibility to be able to "patch" the package lookup with an arbitrary older (or even completely separate) channel. Doing so on a traditional, imperative package manager would be a giant pain.

On the other hand, it's an unfortunate situation to see a mainstream application breaking people's systems and no urgent action being taken for nearly a week, when a PR is already ready and waiting.

This is, of course, the blessing and curse of a volunteer project. Just as you can jump into any task that you fancy, nobody is obligated to check out your work, which can (in unfortunate cases, such as this) cause disruptions.

For some more positive news, this seems to be going to be at least partly addressed soon as Guix is considering a grant system, which would financially support certain developers working in key areas.

3.4. NVIDIA drivers and non-LTS kernels

Massive disclaimer here: This is a Nonguix "issue". And in-fact it's not even an issue, it's more just a case of "things could be explained much better". Still, it was something that caused me quite a bit of pain and if I can spare only one other person from experiencing it, it was already a win in my book.

After one of the updates, my system started being unable to properly start up my desktop environment. I was able to get to GDM, enter my login info, press login, and then it'd either hang there or I'd get my windows stuck in the top left corner, without any of the usual Plasma UX decorations.

Thankfully, as Guix is a generation-based declarative distro, I was able to roll back to an older version and have a working PC, but I found it really annoying that no matter how much I upgraded my system, it never quite seemed to help.

I was quite close to giving up and going back to Nix or some other distro, when I finally found a lead. By reading the dmesg logs, I found out that the problem was the kernel module not finding certain functions:

Listing 12: This is not my exact kernel logs (source), but I saw the same error messages.

[   95.122493] nvidia: loading out-of-tree module taints kernel.
[   95.122503] nvidia: module license 'NVIDIA' taints kernel.
[   95.122507] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[   95.122508] nvidia: module license taints kernel.
[   95.595636] nvidia-nvlink: Nvlink Core is being initialized, major device number 508
[   95.596880] nvidia 0000:01:00.0: enabling device (0406 -> 0407)
[  101.074782] nvidia_drm: Unknown symbol nvKmsKapiGetFunctionsTable (err -2)
[12407.716914] nvidia_drm: Unknown symbol nvKmsKapiGetFunctionsTable (err -2)

While this didn't quite solve the issue yet, it gave me a vital pointer, leading back to the Nonguix README. I gave the NVIDIA section a closer look and lo, the culprit was found:

nonguix-transformation-nvidia [#:driver nvda]
                              [#:open-source-kernel-module? #f]
                              [#:s0ix-power-management? #f]
                              [#:kernel-mode-setting? #t]
                              [#:configure-xorg? #f]

Return a procedure that transforms an operating system, setting up
DRIVER (default: nvda) for NVIDIA graphics card.

OPEN-SOURCE-KERNEL-MODULE? (default: #f) only supports Turing and later
architectures and is expected to work with 'linux-lts'.

S0IX-POWER-MANAGEMENT? (default: #f) improves suspend and hibernate on systems
with supported graphics cards.

KERNEL-MODE-SETTING? (default: #t) is required for Wayland and rootless Xorg
support.

CONFIGURE-XORG? (default: #f) is required for Xorg display managers.  Currently
this argument configures the one used by '%desktop-services', GDM or SDDM.

Use 'replace-mesa', for application setup out of the operating system
declaration.

Can you see it? If not, here's the line of note: "and is expected to work with 'linux-lts'". Yup, that's all the warning you get that "if you use the usual linux package as your kernel, it can crash on you at any time."

Obviously, this doesn't mean that the Nonguix team hasn't done their due-diligence. After all, the solution is there. But I definitely think it'd be worth a stronger emphasis on the fact that you can and will break your install if you don't use the LTS kernel with a newer card / open-source driver.

I'm also certain I'm not the only one who fell for this as there is already an issue on Nonguix' Gitlab, where the ticket opener's phrasing strongly implies they had to figure out the linux-lts solution themselves as well.

3.5. No easy way of seeing what is updated

One thing I sorely feel is missing (though Nix is no better in this regard) is the fact that there is no easy built in way to see what upgrading will do to your system.

There are approximations, sure. You can either pass --dry-run to Guix and get something along the lines of work items. There is also a new project by LiterateLisp's author Wilko, which allows you to diff two derivations, which is super cool and I hope one day it'll be upstreamed into Guix proper, but (unless I massively misunderstood things) it's a tool for after the fact. That is to say this only tells you what changed once the update is done.

Now, of course, there is an argument to be made that, due to the way declarative distros work, you don't really have to care what's what version and it's not a huge deal to just roll back if you're not happy with the changes. But every imperative distro manages to give you a list of "here's what's gonna happen" and give you a choice if you consent to the upgrade or not, and I really miss it from here.

3.6. Sleep causes crashes

I don't know if it's me doing things wrong or the driver not being good enough or something completely different causing it, but I am unable to use the Sleep function of the PC. The moment I press it, the PC freezes and requires a hard restart.

What this means is that, if I know I need to go away for some time, I either leave things on (which wastes a lot of electricity) or I turn my PC off (not a huge deal, but a bit more inconvenient than just continuing from where you've left off).

It's not exactly a vital feature, but all previous distros I've used had this working out of the box, so Guix System struggling with it is really unfortunate.

3.7. Odd freezes and crashes

I cannot effectively quantify this, but Guix System doesn't really feel stable in my experience. In this ~1 month of use, I've experienced at least 4-5 spontaneous freezes and choppy performance while not doing anything particularly strenuous on the PC, which does not inspire confidence when it comes to working uninterrupted.

I had freezes during listening to Youtube, browsing files in Dolphin, writing text in Emacs. Usually these issues went away on their own after a while, but not only does it make me worry that something (physical or digital) will end up damaged, I also get completely thrown out of my flow state.

I definitely can't rule it out that some (perhaps even all) of these were caused by the notoriously finicky NVIDIA drivers. But it is the unfortunate reality, that I cannot swap GPUs for the sake of a distro, no matter how much I like it and none of the other distros I've tried had produced instability this bad before.

4. Conclusion

On a conceptual level, I love Guix and Guix System. I much prefer writing Scheme over Nix's language and I really like that there is far lesser of a divide between the builders and the package definitions.⁸

I also love the low barrier of entry when it comes to contributing to the ecosystem. I'd wager Guix might be one of the easiest distros to have packages accepted for, if you have a bit of Scheme experience and are willing to oblige the maintainers.

But, and I'm sad to say this 'but', both still feel unpolished to me. Ever since I've grown accustomed to Linux in a way that no longer makes me want to distro-hop, my journey was always about finding a distro that maximises stability and package freshness, and settling for it.

Guix System sadly neither fulfilled the stability (due to all the crashes), nor the freshness (due to many of the packages lagging far behind upstream) in the way I was hoping for and I am unlikely to stick with it much longer. I will likely still have Guix present on whichever distro I go back to, but for now I'm buying out of the GNU dream.

Now, I don't want to sound entitled and talk down a project I'm otherwise very much aligned with. I recognise the gargantuan effort that went into getting things this far, especially considering that Guix isn't just aiming towards x86 and ARM, but also to be a host and accelerator for HURD. I also recognise and respect that most of this effort was accomplished with no monetary gain expected and on what is considered (at least in corporate terms) a shoestring-budget.

Even more importantly, things aren't happening in a vacuum and, while Guix's current state didn't prove to be quite what I was looking for, it doesn't mean it's not going to continue developing. Not only are they pulling in fresh funds to fund infrastructure and projects, there's also a lot of ideas floating around how to make things better.

I will only bring one example, but it will be comprehensive: The Shared Cryptpad of Guix Days 2026. This is the loose log of a couple of brainstorming sessions of Guix veterans and core developers, which touches on a massive amount of potential ways to make Guix more approachable including:

How to manage secrets declaratively (this is not simple even on Nix),
How to communicate between the teams better,
How to introduce breaking changes in a way that won't cause pain for everyone,
Bringing a new GC to Guile, that should speed everything up (especially multi-threaded code),
What they could learn from Nix,
How to make the substitution situation better,
How to automate PRs,
How to make package breaks rarer and how to respond to them quicker,
And (this was the one I found most interesting) thoughts about breaking with the GNU hardline: The possibility of enabling installing firmware in the installer, breaking the self-imposed wall between Guix and Nonguix, and even vaguely alluding towards the option of dropping the GNU label as a whole, while still retaining their best qualities and the commitment to free software.

The list goes on. Obviously, all of these exist only as ideas and plans so far, but the important part is that the maintainers aren't sitting on their laurels and doing nothing. They're smart people trying their best to make Guix an even better experience than it already is.

I wanted to end my post on a positive note, especially since much of my post has been anything but. Even though Guix System as it is today didn't quite live up to my expectations, I have no doubts that in a couple years time, if the project continues with this fervour and dedication, it will be a very serious contender. Perhaps still a niche one, because its commitments to Scheme and only free software severely limits its audience, but a well-polished and incredibly powerful system for those that can live within these bounds.

In fact, I've read some comments of people who have been using Guix System for over a decade. You cannot get that amount of dedication, if you yourselves (i.e. the maintainers) aren't dedicated yourself, and Guix's clearly are. I wish them nothing but the best and it's not like I'll completely remove myself from the project's orbit, as I still have a couple packages I'd love to see merged and I'm still interested in the project's future developments.

Thanks for reading!

Footnotes:

At work I happen to use Django, which has an extension called "reversion". It allows reverting objects in your database to a previous revision. Pretty clever name, but it burnt into my mind so much, I accidentally mixed up the two.

I immediately went gung-ho and put both harec and qbe (which doesn't even cause a dependency issue) into hare-build-system.

In hindsight, while I can justify my actions (my reasoning was that harec and qbe are used by the compiler, therefore it makes sense to have them present in the build system), it wasn't the right course of action.

Especially because this issue only really came up with a single package. Just like with any other project a big blast radius has to make sense. In this case, it didn't.

Obviously the best would be if the guix lint script was able to identify and fix these, but let's be real, making a script to rewrite an arbitrary input to something that conforms to a given output is a fool's errand.

⁴

In the strictest sense there is already one or rather two. There is Libreplanet, which has a Guix page, but it's pretty much only used by direct maintainers for storing information that doesn't directly belong in the Guix Manual. For the sake of completeness, there is also the System Crafters Wiki, which at the time of writing hasn't seen any contributions in two years.

⁵

Before you ask, my toilet isn't made from gold. I bought my sticks before the price increase for a third of what they cost now… I'm not rich, just lucky.

⁶

No disrespect towards Slackware or its users. It's a very cool distribution and the fact that it is still going strong is nothing short of impressive. But it's "do it yourself" approach is exactly the opposite of what I'm looking for in a declarative distribution. In an ideal world, your entire setup would be a couple files of Scheme code and you'd practically never have to "figure things out".

⁷

The fix was ultimately merged after six days and I have since removed the inferior from my install.

⁸

In Nix, you're expected to write Bash snippets in your build stages with some rudimentary substitution of variables provided by the system. This works, but is (in my opinion) far less ergonomic or elegant than Guix's all or nothing approach to Scheme.

LLMs Are Taking the Joy Out of Our Lives

2026-02-11T16:50:00Z

1. Job
2. Hype-driven death march
3. Art-robbery
4. Post-truth society
5. We're burning our planet for… this?
6. I'm not fully innocent, but at least I care

This website does not, will not, and has not willingly used AI for its creation. I write every word myself and rely on traditional methods to publish it to the internet.

That means I correct my spelling using Hunspell in Emacs with its convenient flyspell-mode checker. I do not generate pictures for my articles, I either create them myself or take them from the Internet with proper credits.

Obviously, I use tools like LSPs and linters gratuitously, but I write the code I present in my articles by hand. I don't even look at AI output.

If I don't know something, I go on the internet and search. If that doesn't work, I go to a community and ask. You'd be surprised how kind and helpful people are, if you show them a modicum of politeness.

Note: This is a largely unedited rant. You've been warned.

1. Job

I don't like AI. Not because I feel like it's endangering my job—even though for many others, including people I hold dearly—it is a very real possibility. I am embedded nicely into my team and my manager is level-headed enough to understand you cannot pass off our job to a machine and expect things not to collapse eventually.

I don't like it, because the code produced using LLMs are at best laughably bad tangles of over-complicated boilerplate and cookie-cutter repetition of code that could very easily be DRY-d. At worst they generate a simulacrum of what a person might write, causing your intuition (trained on how real people think and what real people write, and which would otherwise help you catch bugs and issues) to become unreliable.

And with how much less effort it takes for an AI to spit out a thousand lines, than it takes a person to review said thousand lines, we have no chance of inspect code with nearly as much care and scrutiny as before.

Projects, both professional and hobby-driven, are suffocating under vibe-code pushed onto them both by people meaning well and people intending to profit. Because of the aforementioned ease of generating more code and how convincingly AI can masquerade as a person, the ever-increasing load of dealing with the crap-deluge is added atop the already thankless workload of these contributors, wasting valuable hours and manpower. cURL may have been the first, but it sure as hell won't be the last.

The solution? Just use AI to filter out the AI! This is untenable. Models made specifically to suss out LLMs written text aren't at all reliable. With code you have even less to rely on, because professional code generally doesn't have "character".¹

So we're left with rudimentary tools, like:

"All PRs above X thousand lines are blanket banned",
"PRs committed by an LLM are blanket banned",
"PRs where the author, after a lengthy questioning, cannot answer questions in a satisfying way are banned".

It's an awkward cat-and-mouse game of developers chasing down more and more convincing models and conniving people, while the reliability of code isn't improving at nearly the same rate.

And this is just programming. In many companies CEOs and boards are using AI as an excuse to lay people off:

Oh, who needs a new generation to replace the old one? We'll just do it with the AI!

And when that old generation ages out and there's nobody to train new people, what will happen then, huh?

Oh, but AI won't make everyone jobless, you'll just be able to do 20 people's job alone!

First, that's bullshit. Second, you can be grateful it's bullshit, because the job market is already terrible. Imagine if suddenly there were 20x less jobs. It'd be catastrophic.

A friend of mine studied visual arts. After many years in university, he entered a job market, that no longer had a need for him. He wasn't a "pro" (despite being skilled), so he had no foot in the door. And he couldn't become a "pro", because all the jobs he tried to apply to declined, saying they'll just use GenAI to make stuff! How do you build a portfolio that way?

He had spent a couple years living off odd jobs and now is re-educating himself as a programmer. While I'm glad he found something else that also interests him, I think it's still tragic he wasn't able to get work doing his dream job. Potential greatness dying at the feet of "eh, good enough."

Or there is that funny story where a business owner didn't bother to hire customer support. Their AI offered a customer an 80% discount. In this instance, the owner was extremely lucky, because they weren't obligated to fulfil the order, but imagine if they were. We might intuitively think a chatbot's responses aren't legally binding, but why not? If companies think they can offload customer complaints to these bots, surely they are created to offer only company-sanctioned information.

2. Hype-driven death march

I don't like AI. Not because I'm a Luddite², I'm not. For most of my childhood and early adult years, the march of technology was something I beheld in awe.

I was born right before smartphones as we know them today were a thing. I saw mobiles go from bricks to hand-held supercomputers. While this too has its own detriments (unchecked social media exposure has made the childhood experience much more stressful than it needs to be), it also brought with itself undeniable benefits.

A minimal smartphone nowadays is affordable to just about anyone, who isn't completely destitute. It won't be fast, won't do most of the stuff a top-of-the-line model can, but it can give you access to a lot of things. Banking, applying to work, handling your communication (both synchronous and asynchronous), entertainment, even security through 2FA/MFA.

Smartphones are indeed so convenient, the idea of life without them is almost unthinkable to many of us. Whether or not that's a good thing is arguable (and you can probably argue towards "it's not" easier), but what nobody can deny is that smartphones are an utter financial and cultural success.

With AI, meanwhile, companies are still figuring out how to even make it profitable. You know, when it's actually AI and not just An Indian. It's not particularly good at coding, you cannot trust important choices on it, because someone has to be responsible for them, it cannot really innovate, just repeat variations. Last year OpenAI lost $11.5 billion. Things are fine, trust us. And all that keeps this bubble of kinda-sorta-works-trust-us cycle alive is five or so companies slipping money into each others' pockets.

When this pops, and I frankly see no possibility that it won't, everyone will suffer. Maybe it will be another 2008 even. My tech ETFs are 25% up since I bought them a year ago. That kind of growth is unnatural and I dread the day the debt catches up or the investors wisen up to the ploy. I'm sure many of them already have, but it's more profitable to keep up the charade.

3. Art-robbery

I don't like AI. Not because I'm good at art. I can barely draw stick figures. For people like me, Generative AI is supposedly a boon and the great equaliser that allows even us to materialise our dreams.

Except all of these models were trained on artists who did not consent to their works being chewed up and regurgitated in a thousand different, yet eerily similar ways, losing all the emotion and originality, that these people poured into each and every piece.

And then there's all the authors, whose books were scraped and fed into LLMs. That resulted in a lawsuit or two, yes, but the damage is already done. You cannot exactly "untrain" a model. You can only put safeguards and rules on it, that clever people will always be able to dodge.

And even if you could selectively remove all this knowledge from them, who in their right mind would? In this rat race, only the smartest, most knowledgeable AI wins, everyone else loses big. Sans comprehensive governmental crackdowns, no company would willingly cripple their own chances. And governments won't crack down on it, because then other, less copyright-concerned countries' AIs will take the lead. That does not make the line go up.

Art is an inherently sentient thing. I originally considered saying it is a "human thing", but there are instances of animals making art too. The loftiest art-piece down to the raunchiest fetish-art is all made because someone wanted someone else to feel something. The actual art-piece may not appeal, but the sentiment is universally beautiful.

So when you delegate this to a machine, that has no understanding of anything more than "what pixel usually goes next to what other pixels", everything you make is hollow. It might be very technically impressive (though, it wasn't you who impressed, but the machine), but there is no intent behind it.

I feel nothing, but disgust when I look at AI "art". It's always the same. Shrimp-Jesus, hyper-sexualised big tiddy anime waifus, diabetes-inducing sugary-cute animals with eyes as big as fists, comically obese people falling through glass bridges, buff gigachads with glowing red eyes telling you that you're not sigma. I will not bring examples, I'm sure you've seen all of these already. Just writing this list down makes me exasperated.

4. Post-truth society

I don't like AI. Not because I'm not tired of Google giving terrible results or because I enjoy digging into ancient threads that much. I don't like it, because you can never be quite sure if what you're reading is true or not without putting in your own research and that the LLM will go out of its way to convince you to trust it.

I can begrudgingly accept that chatbots can be a good springboard, if you have no idea how to start researching something. By demanding sources and justifications, you can get by, perhaps even achieve more than if you were left to use Google alone.

However, many people think it's a miracle-machine and trust its output blindly, leading to at best embarrassment, at worst death. AI struggles with the 'r'-s in "strawberry". LLMs will swear functions that never existed are parts of API-s. People, places, events, just about anything can be hallucinated. Chatbots melt into sobbing messes, if you ask about seahorses. It drove a man to drink Bromine and nearly end his own life.

Hell, forget about "nearly", there is now a list on Wikipedia to count the amount of suicides and deaths attributed to LLMs. At the time of writing fourteen people could be still alive. AI is not just a tool to kill people, but also to make the living more miserable.³ But trust us, just 50 billion more parameters and it'll be perfect!

And even when things don't end so grimly, AI is still a tool for radicalisation. It has never been easier to make up legit sounding hogwash. Claude, give me a 200 page PDF about how my political opponent will bankrupt old people, raises taxes to unprecedented levels, and send off all young men to war. You think that's a ridiculous example, it happened in my country.

Old and/or tech illiterate people not only have no idea if what they're looking at is legit or not, they might not even realize it's a question that needs to be asked. Ten-fifteen years ago something happening on video was either legit or very obviously fake. The few hoaxes that reached the mainstream were memorable exceptions. Today generating stuff that's not outrageously obvious and can easily fool many is an everyday occasion.

Even I get occasionally fooled and that terrifies me, because I'm supposed to be tech savvy. Technology is my livelihood. I've been banging bits together since I was eight years old. And yet every once in a while my judgement lapses and I read a comment or watch a video, and I don't spot the obvious. The whiplash I feel when other comments inform me that I was engaging with slop without knowing is always stinging.

5. We're burning our planet for… this?

I don't like AI. Not because, it's the sole cause for climate change. It existed before AI. Arguably AI isn't even the biggest contributor, global shipping and the private flights of billionaires probably cause magnitudes more problems than Joe Schmoe asking the magic answering machine if he should invest into NFTs in 2026.

But the fact that we're wasting perfectly good land and, far more importantly, perfectly good water to waste on dystopian giga-complexes for AI loads that haven't even materialised yet, while also shipping off nearly all future RAM and GPUs for these same hypothetical AI loads. Now that both baffles me and infuriates me.

This is pure line-go-up mindset. Tomorrow be damned, today we have to shovel a few extra cents into $NVDA. Meanwhile, from June to August, we can barely go outside for a few hours, because temperatures are more often closer to 40°C than they are to 25°C. When I was a child (and I'm in my mid-twenties at the time of writing this, I'm not exactly old!) winters had snow for weeks. Summers were balmy, but never asphalt-melting hot.

Is providing more means of generating zero-views slop really our first priority? Is that really what we need right now?

6. I'm not fully innocent, but at least I care

I don't like AI. And yet, strictly at work, I do occasionally use AI-enabled code completion. Or sometimes make the AI generate me boilerplate for unit tests, that practically any templating system could also generate, just perhaps a bit more rigidly. And every couple of months I toy around with the freely available models online and run a few queries out of curiosity. And for that, it's fine.

I cannot hate people for wanting to use a tool, nor would I want to. It's a shiny toy, with some uses (albeit with caveats). My problem is with this dogged insistence on growth towards some vague faraway goal that seems to shift between AGI, replacing workers, enhancing workers, enhancing processes, replacing processes, etc. ad nauseam. It's gross, it does nothing but generate profits for a very tiny fraction of people out of thin air, while also causing pain on several scales. And it's just plain emotionally and mentally draining.

And for that, as long as I'm able to, I'm keeping AI out of my hobby. Thanks for reading.

Footnotes:

Of course, this isn't universally true, there's definitely eccentric and unusual coding styles out there, that AI has no hope of replicating. However, such style is generally frowned upon in professional contexts, because you're not writing for yourself, rather for a team, that might one day contain people, who you'll never meet.

The actual historical Luddites get a really bad rep. While their methods were destructive, it's hard to seriously blame them. It was never about "uhh, machines bad!" More "this new technology is rapidly causing mass unemployment and that's endangering tons of livelihoods."

Considering how similar this is to today's situation (though one may wonder if AI truly brings as much benefit to society as the mechanic looms did), maybe I am a bit of a Luddite. At least in spirit, since I cannot exactly bring a hammer against a program.

Yes, this is intentionally mimicking the usual AI slop marker of "It's not just X, it's Y". If you're gonna think this whole text is AI generated too just because of this, I'm going to send you a very mean stare.

Adventures in Guix Packaging

2026-02-01T15:58:00Z

1. Introduction
2. Baby steps
3. Enter WezTerm
- 3.1. A mediocre first attempt
- 3.2. A brief second attempt at packaging locally
4. Third time's the charm
5. And yet, some stuff is still better left to the Professionals
6. Conclusion

1. Introduction

Having freshly jumped into Guix System, it didn't take long for me to want to attempt packaging something for the distro.

Unlike the usual, "imperative" distributions, whose build scripts mostly interact with your system directly, Nix and Guix "recipes" provide a set of instructions for the build environment how it needs to compile your package's contents "from zero" and then where to place each of the resulting files.

My first choice was Gamescope, Valve's home-brewed compositor that enabled HDR gaming under Linux.¹ However, I quickly realized I bit bigger than I could chew. It took me less than an hour of trying to run into a wall that was (at least at that time) seemingly completely insurmountable.

The errors I received were somewhat vague, the system couldn't find the necessary dependencies, and I really wasn't sure what I was doing. In hindsight, it really wasn't the right approach and had I went about this project with more planning, it may have gone much better. Luckily dropping this thread allowed me to pick up a similarly interesting, but much more fruitful project, which I'd like to showcase to you in this article.

TL;DR: I spent about a week packaging WezTerm and learning the ropes of being a Guix contributor along the way.

During the packaging process I stumble many times, only to stand back up and figure out a solution. I also explain some of my complaints about the peculiarities of the process, but also provide plenty of praise about of how much the system tries to enable you to do your job. Finally, I also touch on how positive the experience of the code review was.

If you just want to use WezTerm, do a guix pull and guix install wezterm.

2. Baby steps

Being somewhat disappointed in how quickly I failed with my initial attempt, I decided to instead start small and work my way up. To do this, I picked one of Gamescope's dependencies, OpenVR, and updated its package to its newest version.

This might sound impressive without context, but in reality it was little more than me just replacing a hash and a version number in a package definition someone else already wrote:

Listing 1: My massive changes.

  diff --git a/gnu/packages/game-development.scm b/gnu/packages/game-development.scm
index 56f147f956..5cecbf6963 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -3294,7 +3294,7 @@ (define-public instead
 (define-public openvr
   (package
     (name "openvr")
-    (version "1.26.7")
+    (version "2.12.14")
     (home-page "https://github.com/ValveSoftware/openvr/")
     (source
      (origin
@@ -3304,7 +3304,7 @@ (define-public openvr
              (commit (string-append "v" version))))
        (file-name (git-file-name name version))
        (sha256
-        (base32 "09rvrja3pz6ggs41ra71p4dwjl4n0rpqrqw8jiy92xl33hhxbsmx"))))
+        (base32 "0i85awq7w669j0x091chma8rcx1zqwn1j4v0d42bcjcvhqa6iv0v"))))
     (build-system cmake-build-system)
     (arguments
      ;; No tests.

Even though the changes I made are trivial, to get here, I had to set up the development environment, I had to set up a fork of the repository, learn about the project's committing rules, how opening PR-s for Guix works, and how I could test my changes locally. (I'm only making a tally here, all of these will be elaborated on in more detail in the rest of the article.)

I'd really encourage anyone interested in how the packaging process works to seek out similar low hanging fruits to get down the basics in an environment where you have basically no chance of failing.

You walk away with knowledge and a basis to build more involved stuff and in turn some members of the community might just get an update to a package they've been waiting for or someone might get inspired to add yet another package that they couldn't until now.

3. Enter WezTerm

WezTerm is one of the many GPU-accelerated terminal emulators out there, distinguishing itself with a fairly broad Lua-based configuration API and having tabs as a built-in feature among other things.

I admit, I haven't really used or interacted much with it previously. If I remember correctly, I tried it years ago before quickly moving on to other applications for my terminal needs, which begs the question: Why even bother to spend quite a few days on packaging it?

Well, I've basically been nerd-sniped into it. While I was still figuring out my own woes with Guix System's installation, I was frequently reading r/Guix in hopes of getting a bit further. And it just so happened that one of the posts on the front page at the time was a plea from a prospective Guix user for a native WezTerm package for Guix. What I quickly discovered is that there was none. I couldn't even really find discussions about it. This felt like a call.

Note from the future: Along the post, you'll occasionally see little boxes like this one. While the main body of the article documents my thinking and justifications during development, in these I'll bring attention to parts where I've either did things in a not entirely idiomatic way or where there's a much better / easier solution.

The point of this post is less "How to write a 100% correct package definition that will get immediately merged into Guix" and more "What sort of journey would someone face, who has some declarative packaging and Scheme knowledge, but is still quite new to the whole topic".

While the final code is indubitably much better than what I started with, I believe there is more merit in showcasing my iterative process instead of simply going through the merged package, as it doesn't really give any insight into how one would go about packaging something from zero.

3.1. A mediocre first attempt

To start out, I wanted to try to compile WezTerm in an ad-hoc environment to get an idea what it'd need. I cloned it using git clone https://github.com/wezterm/wezterm and created a new shell environment using guix shell rust cargo… Except this didn't actually work, as Guix immediately spit the following error: guix shell: error: cargo: unknown package.

Oh, right. With a cursory read of the Rust package, it quickly turned out Cargo isn't a separate package, but rather an output of Rust. Outputs in Guix are basically separate "sub-packages" of packages, that maintainers can use to group related artifacts together, without all of them having to be installed at the same time in case the user doesn't need them.

For instance most packaged libraries include both dynamic variants under out (which is the default output) and statically-linked ones under static. With Rust, we have the following options (you can find these using guix search):

name: rust
version: 1.85.1
outputs:
  + rust-src: [description missing]
  + tools: [description missing]
  + cargo: [description missing]
  + out: everything else

For our purposes, we need out, which contains the Rust compiler rustc, and we also need cargo. To instruct the shell to load both, the command we actually need is guix shell rust rust:cargo. We could have also explicitly used rust:out for rustc, but if we leave it out, the shell uses it by default anyway.

Armed with the right toolchain, I issued a naive cargo build and for a while things seemed to be in order, only to suddenly come to a crashing halt with the following error:

error occurred in cc-rs: failed to find tool "cc":
No such file or directory (os error 2)

It might come as a surprise, but due to the expectation that most things will be handled using declarative configuration, Guix System doesn't set the CC environment variable (nor CXX, though we won't be using that in this project).

In fact, there isn't even any C compiler toolchain installed by default. This causes any programs that expect Autoconf/Makefile-like conventions to not be able to compile stuff. We can really easily solve it by adding gcc-toolchain to our shell and setting CC to gcc:

guix shell rust rust:cargo gcc-toolchain
export CC=gcc
cargo build

Moments later we experience a new error (which, just like before, I'll abridge by a lot, because it's several pages long):

Could not find openssl via pkg-config:
Could not run `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags openssl`
The pkg-config command could not be found.

The issue here is twofold, though both come from the same source. The compiler is looking for OpenSSL using pkg-config, but our environment doesn't contain either. While we could do what we previously did and exit the shell, add pkg-config and openssl, go back, call Cargo, and fail again at the next missing dependency, there is a slightly better way.

Note from the future: Look, I'll be honest, the first time I did this process, I was actually doing this completely "manually" as described above. That is to say, I tried compiling and when it eventually failed with an error about a missing dependency, I just added it to the list, rinse and repeat.

It's a horribly inefficient method and I didn't want to drag this post down by emulating it.

Though WezTerm has no Guix package (we're working on it right now!), it does come with a Nix flake and, though Nix and Guix have diverged quite a bit, it's still very helpful to see the list of packages spelled out for us by someone else:

nativeBuildInputs =
  with pkgs;
  [
    installShellFiles
    ncurses # tic for terminfo
    pkg-config
    python3
  ]
  ++ lib.optional stdenv.isDarwin perl;

buildInputs =
  with pkgs;
  [
    fontconfig
    openssl
    zlib
  ]
  ++ lib.optionals stdenv.isLinux [
    libxkbcommon
    wayland

    xorg.libX11
    xorg.libxcb
    xorg.xcbutil
    xorg.xcbutilimage
    xorg.xcbutilkeysyms
    xorg.xcbutilwm # contains xcb-ewmh among others
  ]
  ++ lib.optionals stdenv.isDarwin ([
    libiconv
  ]);

Obviously we cannot use this 1:1 as the two systems have different packaging conventions, but we can at least extract a good first approximation of the dependency list:

guix shell rust rust:cargo gcc-toolchain pkg-config openssl wayland libx11 \
     libxcb xcb-util libxkbcommon xcb-util-image freetype fontconfig
export CC=gcc
cargo build --bin wezterm

And, guess what, the application builds. Victory! Or so we think until we actually try to run it using cargo run --bin wezterm:

ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed:
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory,
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

Bummer. WezTerm is a GPU-accelerated terminal emulator, so it (unsurprisingly) needs to communicate with our GPU. Under NVIDIA , this happens with the help of a library called libEGL², which our binary cannot locate without some additional help. The reason for this is that Guix isn't using the standard Linux filesystem hierarchy, so libEGL is nowhere to be found on the list of places the library loader checks by default.

The "fix" I used to circumvent this is really ugly, but for a quick attempt it sufficed. Firstly, I needed to figure out where libEGL.so even is. Thankfully all this took was a simple guix locate libEGL.so (this command is case-sensitive, I learned it the hard way), which spits out a list such as this:

fhs-union-32@0.0     /gnu/store/wr6kq2ixxcnh4nidg64ivsns19k7ynnn-fhs-union-32-0.0/lib/libEGL.so
fhs-union-64@0.0     /gnu/store/9jn31ksjz3frkhwdk5f72s65lrn3gbs7-fhs-union-64-0.0/lib/libEGL.so
mesa@25.2.3          /gnu/store/4kp4rn5vnnaj57464k72wqpg45k45x56-nvda-580.12/lib/libEGL.so
nvda@580.12          /gnu/store/d7vln3cxysi04wf7p8nzwgwabjysznjd-nvda-580.12/lib/libEGL.so
libglvnd@1.7.0       /gnu/store/qhc0y0xzmdmh38bpr9yv2il8alrv5l4g-libglvnd-1.7.0/lib/libEGL.so
mesa@21.3.8          /gnu/store/7rn2s4ip6926sdn8h23qbdyhsr4lj4xk-mesa-21.3.8/lib/libEGL.so

As you can see, due to the way Guix works, multiple versions of the library can coexist without conflicting with each other. As I'm running an NVIDIA card, I picked the line for nvda. Next, I had to set the special environment variable LD_PRELOAD to this file's path and then call wezterm. What this does is instruct the dynamic library loader to add the contents of the environment variable to its load path³ and thus the library is finally visible to the application.

LD_PRELOAD=/gnu/store/d7vln3cxysi04wf7p8nzwgwabjysznjd-nvda-580.12/lib/libEGL.so \
    ./target/debug/wezterm

Et voila, we have WezTerm running. Reddit thread solved. Well, kind of. Our victory is a bit of a hollow one. While we did compel Cargo to build the terminal and it technically works, we have not made a package. Guix isn't aware of WezTerm and anyone else who wants to build the application has to follow these haphazard steps, including overriding a "potentially dangerous" environment variable.

3.2. A brief second attempt at packaging locally

To turn our fickle experiment into a proper package, we need to create a build recipe, which we can later integrate into the guix/guix Codeberg repository. The customary filename for such recipes in Guix is, perhaps unsurprisingly, guix.scm. Inside this file you're expected to return a (package ...) form as your final value, which Guix can then process and turn into a derivation⁴ for you.

 1: (define-module (wezterm))
 2: 
 3: (use-modules (guix git)
 4:              (guix git-download)
 5:              (guix packages)
 6:              ((guix licenses) #:prefix license:)
 7:              (guix build-system cargo)
 8:              (gnu packages)
 9:              (gnu packages commencement)
10:              (gnu packages tls)
11:              (gnu packages freedesktop)
12:              (gnu packages xorg)
13:              (gnu packages xdisorg)
14:              (gnu packages fontutils)
15:              (gnu packages autotools)
16:              (gnu packages guile)
17:              (gnu packages pkg-config)
18:              (gnu packages sdl)
19:              (gnu packages texinfo))
20: 
21: (package
22:   (name "wezterm")
23:   (version "05343b3")
24:   (home-page "https://wezterm.org/")
25:   (synopsis "TODO")
26:   (description "TODO")
27:   (license license:expat)
28:   (source (git-checkout (url "https://github.com/wezterm/wezterm")
29:                         (commit version)))
30:   (inputs (append (list gcc-toolchain pkg-config openssl wayland
31:                         libx11 libxcb xcb-util libxkbcommon xcb-util-image
32:                         freetype fontconfig)))
33:   (build-system cargo-build-system))

Let's go through our code, section by section. We begin by declaring a module for our package. This is not strictly necessary, but it's common practice with Guile code and (as you'll soon see) it won't really matter in the long run anyway. Next we import a bunch of utilities and packages. A common rule of thumb is that packages under guix are utilities, while gnu packages are packages.

We import stuff like methods for importing from a Git repository, definitions of software licenses (more on that below), and Guix's Cargo-based builder preset. The observant might notice that we don't pull in rust, rust:cargo, and gcc-toolchain. All of these are handled by the preset.

Next comes the main package definition. We declare some static metadata, such as the name of the package, its version number (I'm using the current commit of the repository, as WezTerm hasn't had a release since 2024), the project's website, and we leave the synopsis and description empty for now, as I'd rather first have the package working before wasting time on bookkeeping busywork.

Finally we set the package's license. In Guix (and Nix too), licenses aren't simple text fields, so we can't simply say "MIT" and move on with our lives. Rather they are objects of their own. This both allows recording any necessary to fully specify the license and also removes a lot of guesswork from the packagers' workflow such as:

"Do I specify 'MIT'? Or 'Expat'? Or 'MIT/Expat'?"
"Is the field case sensitive?"
"Is it 'GPL-3' or 'GPL3' or maybe 'GPLv3'?"
And so on and so forth.

To access these license objects, we need to pull in the (guix licenses) module and specify from it the exact variant we need. In our case this is license:expat, the MIT license's other name. As you can see, in the imports section I specified license: as the license module's prefix. This means all the identifiers exported from this module are automatically renamed to contain license: in the front. This is done to prevent overshadowing unrelated names and prefixing licenses this way is an idiomatic practice in Guix.

This is followed by the actually interesting stuff. First we declare the source of our package's code. This can be many things, an archive downloaded from the Internet, a Git repository like we see in this case, or even a local folder as seen in this excellent tutorial. We declare our commit to be the same as what we set for our version, i.e. the Git commit with the (short) ID 05343b3.

Next we declare our "inputs", these are all the packages that we either need to use to build our package or we need at runtime. Note the vagueness of the word "use" here: Inputs may not just be source code dependencies. For instance, as with the manual method, pkg-config is used to find other sources' locations and won't actually be part of the final executable. But we might also include tools that generate files. Or we might request assets, like fonts. It's best to think of inputs as not just the ingredients, but the entire kitchen supply.

After that comes the build system. Just like our source, this too can be many things and it is what primarily decides what our build process is going to look like. Since we're trying to make a Rust package, we use cargo-build-system, which itself is based on the gnu-build-system (which is a smarter codification of the good old ./configure, make, make install ritual), except with all the GNU-specific build tools replaced with calls to Cargo.

Well, let's give it a shot. Surely, things cannot be much more complex than this.

Listing 2: Crash and burn…

error: failed to get `finl_unicode` as a dependency of package `termwiz v0.24.0 (/tmp/guix-build-wezterm-05343b3.drv-0/source/termwiz)`

Caused by:
  failed to load source for dependency `finl_unicode`

Caused by:
  Unable to update https://github.com/wez/finl_unicode.git?branch=no_std

Caused by:
  can't checkout from 'https://github.com/wez/finl_unicode.git': you are in the offline mode (--offline)
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "cargo" arguments: ("build" "--offline" "-j" "24" "--release" "-p" "wezterm-gui" "--features" "distro-defaults") exit-status: 101 term-signal: #f stop-signal: #f> 
phase `build' failed after 0.0 seconds
command "cargo" "build" "--offline" "-j" "24" "--release" "-p" "wezterm-gui" "--features" "distro-defaults" failed with status 101
build process 18 exited with status 256
builder for `/gnu/store/nllax38xh9v0hcsc3g9vviw5mqnrj5x0-wezterm-05343b3.drv' failed with exit code 1
build of /gnu/store/nllax38xh9v0hcsc3g9vviw5mqnrj5x0-wezterm-05343b3.drv failed

Things can't be as simple as we'd like, huh?

4. Third time's the charm

The main reason we failed is because Guix is very particular about the way it allows source code to be fetched⁵ and, though Cargo has an ecosystem of its own, Guix wants to have the final say. If packages, such as the previously seen finl_unicode aren't known by Guix, then even though Cargo could fetch it for us, the build system will refuse to proceed.

The good news is that Guix has built in features to allow mass-importing crates, so we don't have to manually go through every single of WezTerm's dozen crates. The bad news is that, for this to work, you need to be working inside Guix's primary repository or else you're unleashing an unreasonable amount of extra work on yourself. Since our end goal is to upstream the package definition anyway, it really is the right choice to just bite the bullet and do it properly.

So, back to tabula rasa, let's create a package inside the actual Guix package repository.

4.1. Setting things up

I'm going to assume at least a bit of Git knowledge, as this post will be long enough as-is without starting from the very basics. Due to my previous tiny contribution with OpenVR, I already had a fork repository of guix/guix, so that's one hurdle down. Next, we do the usual, update the master⁶ branch, create a new branch, switch to it, then prepare our working environment:

git pull
git switch --create add-wezterm
guix shell -D guix -CPWN
./bootstrap  # runs autoreconf, creates configure
./configure  # creates Makefile
make

The first two git commands are fairly trivial, but the third command is worth talking about a little. The interesting thing about Guix development is that it happens 90% inside Guix itself! Isn't that cool? By issuing guix shell -D guix -CPWN, we are:

-C: are transported into a container, a fully isolated environment, in which only the source tree is available,
-D guix: with the development inputs of the guix pacakge included,
-P: with the profile initialized to the source tree's environment,
-W: with the guix executable available,
-N: and finally we request network access.

But, before we can throw ourselves into writing our package with wild abandon, we have one more preliminary thing to take care. We need to set up our development environment by first running ./bootstrap, followed by ./configure. These two commands generate the necessary Makefiles and are a one time cost (unless you're nuking your entire repo checkout and recreating it from scratch, you don't really have to call these ever again). For more info about this part of the process, please see the appropriate manual chapter.

Then, by issuing make⁷, the development environment does several things at once:

It compiles all existing Scheme files into .go files, which aren't Golang source files, but rather Guile byte-code. This speeds up execution as instead of interpreting source code, Guile can work based on pre-chewed binary data,
It compiles all documentation. To our purposes this isn't hugely relevant, but it's a one-time cost, so there's not much point in figuring out elaborate ways to avoid it,
Finally, and most importantly, it places a new script into our workspace named pre-inst-env. The name stands for "[run with] pre-installation environment" and it is the primary driver of our Code->Compile->Test loop.

By prepending all our guix invocations with ./pre-inst-env, we can instruct Guix to use the workspace package registry as its source and thus we can build and test our package without the horribly slow process of manually doing guix pull on our work directory and guix build <package>.

What's even better is that this works even outside the container, so we can use all our usual tools while testing or build in the restricted environment to make sure we're not introducing any external dependencies.

After a couple minutes of wait, our workspace is finally ready for action. Now we can finally handle the actual Guix stuff. First order of business is figuring out where even our package should go. The Guix repository's folder structure is logical, but it is still occasionally non-trivial to figure out where some packages might be located.

A good rule of thumb is that usually things go into general categories (e.g. emulators.scm), but if a set of packages only make sense together (an example being django.scm for all the Python Django stuff out there), it can go into a category, and thus, a new file of its own. For us, there are two possible candidates:

rust-apps, whose purpose I'm still not 100% sure about, since the only thing that connects the stuff inside it seems to be that it's all Rust-based applications,
and terminals.scm, which is for terminal emulators. This is the one I ultimately went with, as it already had Alacritty inside, which is also a Rust-based terminal emulator, just like WezTerm.

So, let's just plop our previous package definition (extended a little bit) into this file and give it a whirl.

(define-public wezterm
  (package
    (name "wezterm")
    (version "05343b387085842b434d267f91b6b0ec157e4331")
    (source
     (origin
       (method git-fetch)
       (file-name "wezterm")
       (uri (git-reference
              (url "https://github.com/wezterm/wezterm")
              (recursive? #t)
              (commit version)))
       (sha256
        (base32 "0q3f1y3bx3g2k21yzp6wkws6kyxsmk4pscmvd8gqmjbbss8az9ap"))))
    (native-inputs (list pkg-config))
    (inputs (append (cargo-inputs 'wezterm)
                    (list openssl wayland libx11
                          libxcb xcb-util xcb-imdkit
                          libxkbcommon xcb-util-image
                          freetype fontconfig libssh2
                          libgit2 sqlite `(,zstd "lib")
                          mesa)))
    (build-system cargo-build-system)
    (home-page "https://wezterm.org/")
    (synopsis "Powerful cross-platform terminal emulator and multiplexer")
    (description
     "A GPU-accelerated cross-platform terminal emulator and
multiplexer written by wez and implemented in Rust.  Features:

@itemize
@item Runs on Linux, macOS, Windows 10, FreeBSD and NetBSD,
@item Multiplex terminal panes, tabs and windows on local and
remote hosts, with native mouse and scrollback,
@item Ligatures, Color Emoji and font fallback, with true color
and dynamic color schemes,
@item Hyperlinks.
@end itemize
")
    (license license:expat)))

There's only really three things of note:

Instead of simply doing a "bare" package form, we wrap our package definition into a define-public form. This is how we ensure that multiple package definitions can coexist in a single file.
Secondly, the package source form was rewritten to use origin instead, which allows for a lot more flexibility in how we download stuff from the net.

Among other things, it allows us to rewrite parts of the source, delete unnecessary files, create wholly new files, and (as can be seen here) it also allows us to cryptographically check whether the source files we get really are what we expect them to be. Packages meant for the main Guix repo all must have their hash checked, so adding it wasn't merely my frivolousness.

Note from the future: As it turns out, as helpful as this step was during development, it is entirely possible to make WezTerm work without recursive cloning and, in fact, this option is only allowed in extraordinary cases.

I also enabled recursive cloning of the repo as there are some submodules involved and once we're past the source-fetching stage, the network is disabled and we wouldn't be able to download them anymore.
Thirdly you may wonder about the weird `(,zstd "lib") form in our inputs. As inputs are actual other packages, not strings-based specifications, we can no longer do the previous "package:output" way of referring to alternative outputs.

For that, we need to create a two-element list, where the first is the dependency and the second is the textual name of the output. So, really, this is just the packaging way of saying zstd:lib.

4.2. Importing Cargo crates

Still, with all this work, if we run this using ./pre-inst-env guix build wezterm, we will be met with the previous error about Cargo not being able to fetch finl_unicode. Which shouldn't be surprising, since as mentioned earlier we haven't imported our Cargo dependencies into Guix yet.

To do this, we will need to issue guix import in our previously checked out WezTerm Git repository in the following way:

guix import -i <path to Guix repo>/gnu/packages/rust-crates.scm \
     crate -f <path to Git repo>/Cargo.lock \
     wezterm

What this does is go through every individual Cargo dependency in the Cargo.lock file and compares it to the list found in rust-crates.scm. If a matching entry is found, nothing is done, if not, the importer adds a new entry to the file. If a crate has a matching crates.io page, an entry such as this is generated:

(define rust-libssh-rs-0.3.6
  (crate-source "libssh-rs" "0.3.6"
                "11f6fj59dqpy7n0g74s7vnnyrbpxbrcyxhnrvfnsb5dvsq8f2rih"))

If not, however, then we get a slightly bigger variant:

(define rust-finl-unicode-1.3.0.a1892f2
  ;; TODO REVIEW: Define standalone package if this is a workspace.
  (origin
    (method git-fetch)
    (uri (git-reference (url "https://github.com/wez/finl_unicode.git")
                        (commit "a1892f26245529f2ef3877a9ebd610c96cec07a6")))
    (file-name (git-file-name "rust-finl-unicode" "1.3.0.a1892f2"))
    (sha256 (base32 "0g9lqwrzm7ca54vlq8sgix3wvbsxwp7glkx3dzjdd591grfbmi6z"))))

It bears resemblance to our own package's origin field and it also has a foreboding comment about how we need to review this generated package to check if it's a "workspace". Elaborating on what a workspace is in Rust is beyond the scope of this article, but the long story short is that a single Cargo project may contain multiple, related subprojects and the importer is not able to untangle these by itself.

If you're packaging something that depends on such a project, you must manually make sure every single subproject gets its own definition, which call back to the main workspace. finl_unicode isn't such a project, however, so we can safely ignore the warning for now.

Where we cannot ignore the comment, however, is with the bindings for OpenSSL, rust-openssl-sys-0.9.111. If we were to leave things as-is, we'd soon find that our project does not build due to not finding openssl-src.

Thankfully, we don't have to figure it out how to fix this issue ourselves, as the package already has several other versions in the Guix repo. We simply have to copy someone else's solution and we're one step closer to making WezTerm build:

diff --git a/gnu/packages/rust-crates.scm b/gnu/packages/rust-crates.scm
index 74fba63cd8..213882b4a2 100644
--- a/gnu/packages/rust-crates.scm
+++ b/gnu/packages/rust-crates.scm
@@ -13605,9 +13605,19 @@ (define rust-openssl-sys-0.9.110
                     (copy-file "Cargo.toml.orig" "Cargo.toml"))))

 (define rust-openssl-sys-0.9.111
-  ;; TODO REVIEW: Check bundled sources.
   (crate-source "openssl-sys" "0.9.111"
-                "08f3mpsabivfi3fd0qv9231qidqy68lr8a4qi32y6xda43av5jl2"))
+               "08f3mpsabivfi3fd0qv9231qidqy68lr8a4qi32y6xda43av5jl2"
+               #:snippet
+               #~(begin
+                   ;; Remove dependency on boringssl and vendor openssl source.
+                   (substitute* "Cargo.toml.orig"
+                     (("vendored = .*") "vendored = []\n")
+                     ((".*bssl.*") "")
+                     ((".*openssl-src.*") "")
+                     ;; Allow any version of bindgen.
+                     (("(bindgen = \\{ version =) \".*\"," _ bindgen)
+                      (string-append bindgen "\"*\",")))
+                   (copy-file "Cargo.toml.orig" "Cargo.toml"))))

Once the importer has gone through every dependency, it also generates a lookup table entry in rust-crates.scm in the form of package-name => (list <list-of-dependencies>). This is ultimately the mechanism that pairs user defined Rust Guix packages to their Cargo defined dependencies. For instance, since we entered wezterm⁸ in our cargo import query, we get the following list:

(wezterm =>
       (list rust-addr2line-0.25.1
        rust-adler-1.0.2
        rust-adler2-2.0.1
        rust-adler32-1.2.0
        rust-ahash-0.8.12
        rust-aho-corasick-1.1.4
        rust-aligned-vec-0.6.4
        ... and like 600 more crates ...
        ))

And somewhere in this list, finl_unicode can also be found. Finally, we are able to provide all our dependencies to the build system:

Listing 3: The build system has access to all the crates that we automagically imported from the Cargo lockfile.

;; cons* takes an arbitrary amount of elements and a list and prepends the former to the latter.
;; E.g. (cons* 'a 'b 'c '(d e)) => (a b c d e)
(inputs (cons*
         openssl
         wayland
         libx11
         ... our previous list of packages ...
         (cargo-inputs 'wezterm)))

We issue ./pre-inst-env guix build wezterm… and run into the same error. What gives?

4.3. Patching Cargo.toml

Though the code itself is fairly trivial, understanding the solution to this issue was perhaps the most difficult part of the entire process to me. Largely because there is almost zero indication what and how you need to do, and the docs barely touch upon the existence of this issue and its fix either. I had to resort to reading other packages' definitions, which worked, but definitely wasn't the smooth-sailing as things had been up to this point.

To finally reveal this hidden menace that has been keeping us from compiling this poor application till now, let's take a look at two different dependencies from WezTerm's Cargo.toml:

finl_unicode = { version = "1.3",  git="https://github.com/wez/finl_unicode.git", branch="no_std" , default-features=false, features=["categories", "grapheme_clusters"]}
fixed = "1.23"

For dependencies like fixed, there is no issue, the build system can match them with their imported package no-problem. However, for some reason that I still don't quite understand, if there is a git field in the dependency list, then that completely breaks the proces, as Cargo will always try to download it from the internet, which then fails due to the build environment not having network access.

The solution?

finl_unicode = { version = "1.3", default-features=false, features=["categories", "grapheme_clusters"]}

Yep. That's it. We just have to instruct Guix to rewrite this one line (well, actually two, because there's two such dependencies in the project, but I'll not bore you with the exact same process) and everything else will magically work.

To do this, we introduce a new section to our package definition, arguments. The role of this field is to override certain aspects of the build system preset, such as the build flags or what so-called "build phases" we wish to execute on the code.

A build phase can be practically anything from setting environment variables, to compiling code, to editing files. We would like to do the last one, so let's introduce a new build phase:

(arguments
 (list
  #:phases
  #~(modify-phases %standard-phases
      (add-after 'unpack 'use-guix-vendored-dependencies
        (lambda _
          (substitute* "Cargo.toml"
            ((",  git.*default-features")
             ", default-features")
            ((", git.*, rev.*}")
             ;; This is added to ensure a different dependency
             ;; uses libraries provided by the inputs instead
             ;; of relying on bundled files.
             ", features=[\"use-system-lib\"]}")))))))

This code adds a new phase after unpack (which is the phase responsible for extracting the actually usable files and folders from our origin) named use-guix-vendored-dependencies. The name of the phase that we're adding is arbitrary, but you're expected to pick something informative and truthful, so please don't try do-stuff or thing.

The magic happens inside substitute*, which takes a filename and a list of regexp => replacement pairs, and then executes the replacements. It's kind of like having a lispy sed in your arsenal.

Careful readers may have noticed the weird #~ symbol in front of the modify-phases function call. This is a Guix-exclusive extension to Scheme's syntax, called G-expressions (abbreviated as "gexp").

Their job is to facilitate working with files as data, therefore whenever we need to directly affect our source code (be that creation, deletion, or modification) or call out into the operating system, we need to do so inside a gexp. This isn't the only place where we'll need to do so, so I'll call into attention when it happens.

In more important news, if we were to issue ./pre-inst-env guix build wezterm now, we'd find that the package actually builds… before failing again:

error: crates-io is replaced with non-remote-registry source dir /tmp/guix-build-wezterm-05343b387085842b434d267f91b6b0ec157e4331.drv-0/source/guix-vendor;
include `--registry crates-io` to use crates.io
error: in phase 'package': uncaught exception:
%exception #<&invoke-error program: "cargo" arguments: ("package" "--offline" "--no-metadata" "--no-verify") exit-status: 101 term-signal: #f stop-signal: #f> 
phase `package' failed after 0.1 seconds
command "cargo" "package" "--offline" "--no-metadata" "--no-verify" failed with status 101
build process 18 exited with status 256

The actual error is a little vague, but the gist is that by default the cargo-build-system attempts to install the sources of all the dependencies we used. For us, this is neither desirable, nor does it actually allow the build to finish, so by adding the following to our arguments, we disable it (along with tests⁹):

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 476e2b743e..84f52b24f8 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1702,6 +1702,8 @@ (define-public wezterm
       (build-system cargo-build-system)
       (arguments
        (list
+        #:install-source? #f
+        #:tests? #f
         #:phases
         #~(modify-phases %standard-phases
             (add-after 'unpack 'use-guix-vendored-dependencies

Call build again, and…

4.4. We have liftoff… Almost

No errors. Our build was successful.

successfully built /gnu/store/h8d2igkg4vlg687ixgj6hizyd4gbzl64-wezterm-05343b387085842b434d267f91b6b0ec157e4331.drv
/gnu/store/h99jlsdism6jxn3x02fv7jig61r6ydv2-wezterm-05343b387085842b434d267f91b6b0ec157e4331

Let's celebrate by starting a shell that contains our newly built terminal in it and start it up:

guix shell wezterm -- wezterm
guix shell: error: wezterm: command not found

Sadly we're still no quite there, but there is only one step separating us from the same spot as we were with the original "ad-hoc" implementation. If we list the files in our built derivation, we would find that it doesn't contain anything useful:

/gnu/store/h99jlsdism6jxn3x02fv7jig61r6ydv2-wezterm-05343b387085842b434d267f91b6b0ec157e4331
└── share
    └── doc
        └── wezterm-05343b387085842b434d267f91b6b0ec157e4331
            ├── ANGLE.md
            ├── LICENSE.md
            └── README.md

What happened? Simply put, we only told Guix to build our executables, not that we actually need them. The built package contains several different binaries, of which we're primarily interested in one: wezterm-gui.

To access it, we will a phase called install which is supposed to put everything in its rightful place. Let's modify arguments and override it to install our file:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 84f52b24f8..8f54a79dbe 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1712,7 +1712,16 @@ (define-public wezterm
                   ((",  git.*default-features")
                    ", default-features")
                   ((", git.*, rev.*}")
-                   ", features=[\"use-system-lib\"]}")))))))
+                   ", features=[\"use-system-lib\"]}"))))
+          (replace 'install
+           (lambda* (#:key inputs native-inputs #:allow-other-keys)
+             ;; Binaries
+             (with-directory-excursion "target/release"
+               (for-each
+                 (lambda (name) (install-file name (string-append #$output "/bin")))
+                '("wezterm" "wezterm-gui"
+                  "wezterm-mux-server"
+                  "strip-ansi-escapes"))))))))
       (home-page "https://wezterm.org/")

Note from the future: Binaries aren't the only thing that need to be installed for a package like this. You also need to copy over stuff like icons, .desktop files, and any other various assets a package might need.

I abridged the package definition here quite a bit, because much of the process is just more of the same and I see very little educational value in repeating 95% the same code.

This snippet of code enters ./target/release, which is the folder where Cargo places our compiled binaries, walks through our supplied list of executable names and copies each to #$output/bin. In Bash terms, you could think of this as cp ./target/release/wezterm $OUTPUT/bin/.

You may wonder what #$output even is. It's actually two separate things combined:

#$ is a so-called reader extension specific to Guix. Reader extensions are a user-defined extension to the usual syntax extensions, which are in turn special characters that affect the behavior of Lispy languages and are mostly used because spelling out the entire form they shorten would be quite unwieldy.

Listing 4: Some examples of common syntax extensions to all Lispy languages.

(+ 1 2)         ;; => 3        (Form is evaluated as usual)
'(+ 1 2)        ;; => (+ 1 2)  (Form is "quoted" and returned as-is)
`(+ 1 2)        ;; => (+ 1 2)  (Form is "quasiquoted" and returned as-is)
`(+ 1 ,(+ 1 1)) ;; => (+ 1 2)  (Form is "quasiquoted", the third element is "unquoted")

In our case #$ is a lot like , (also known as unquote), which is used in conjunction with ` (quasiquote). It allows us to "unquote" (i.e. execute) code inside a gexp, which itself acts as sort of a quasiquote (i.e. a form that isn't evaluated by default, only the parts that are explicitly unquoted). For more information about the concept, Guile has an entire page dedicated to it.

Meanwhile, output is simply a variable provided implicitly in our install phase, that points to the directory where our derivation will be built into. This folder acts similarly to a filesystem root folder (what you may know as /), but it only contains files that either we explicitly placed into it or are automatically copied by the build phases.

When we install a package, the files from its output are made available in our general environment. You can see this by calling ls /run/current-system/profile/bin, which will list out most¹⁰ of the binaries available to you in the current environment. One thing of note is that none of these files here are the actual executables, but rather symlinks to binaries found in the Guix store, which is the organized collection of all built derivations.

Circling back to our package, now that our executables are copied over to the output's bin folder, they will be available to use if we were to install the package. Let's do so:

guix shell wezterm
wezterm

This time the terminal runs, but then immediately crashes…

4.5. GPU maladies

Note from the future: The method shown below might be a viable path for some particularly stubborn libraries, however, it is not a good first approach. As it turns out in this case we can get rid of this entire build phase by simply instructing Cargo to link libEGL using the RUSTFLAGS environment variable.

If you're thinking of making your own package, please be sure to check whether you can simply instruct your linker before you attempt to hack apart the code you're working on.

21:59:33.533  ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed:
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory,
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

You might remember, that we've seen this error already. This time, however, we'll do it right and instead of relying on a random build string extracted from a command, we'll rely on our build inputs.

To figure out what we're supposed to do, let's grep for libEGL.so to find all the places the library is used. There are some irrelevant results, but there is some promising code under ./window/src/egl.rs. The definition of the function named with_egl_lib reveals how exactly we're trying to load the library:

fn with_egl_lib<F: FnMut(EglWrapper) -> anyhow::Result<Self>>(
    mut func: F,
) -> anyhow::Result<Self> {
    let mut paths: Vec<std::path::PathBuf> = vec![
        #[cfg(target_os = "windows")]
        "libEGL.dll".into(),
        #[cfg(target_os = "windows")]
        "atioglxx.dll".into(),
        #[cfg(all(not(target_os = "macos"), not(target_os = "windows")))]
        "libEGL.so.1".into(),
        #[cfg(all(not(target_os = "macos"), not(target_os = "windows")))]
        "libEGL.so".into(),
    ];

This piece of code tries to simply look for libEGL.so without any path associated with it. Therefore the dynamic library loader will try all known search places. However, since Guix doesn't put libraries in the normal search paths, this will fail.

So, what if we were to replace this string by an exact path to the library provided by one of our inputs? Turns out that's exactly what we need to do.

As you might have guessed, we need yet another phase:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index f7eb633624..34758f238e 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1713,6 +1713,10 @@ (define-public wezterm
                    ", default-features")
                   ((", git.*, rev.*}")
                    ", features=[\"use-system-lib\"]}"))))
+            (add-after 'unpack 'fix-libegl-so
+              (lambda _
+                (substitute* "./window/src/egl.rs"
+                  (("libEGL.so") (string-append #$mesa "/lib/libEGL.so")))))
             (replace 'install
              (lambda* (#:key inputs native-inputs #:allow-other-keys)
                ;; Binaries

Let's rebuild and run our package again.

Success! Well, mostly. If we really wanted to, we could stop here. Our package technically "works" and can be installed. However, in its current state, it'd never be accepted into the registry for two main reasons (and a myriad of small ones, see the final part of this story).

4.6. Finding fonts

Note from the future: WezTerm actually bundles four different fonts. During the development of the package I only packaged JetBrains Mono and Roboto, because those two are considered vital for the terminal to function.

However, by the time the package was merged, one of the contributors added the other two fonts too and replaced this entire phase with much more elegant code.

Of these two big issues, one is that we are still relying on fonts bundled by the source repository. This is a no-go, especially since most of the fonts we wish to use are already packaged in Guix.

By looking into the source files, we find that WezTerm's font-loading code is found in wezterm-font/src/parser.rs:

/// In case the user has a broken configuration, or no configuration,
/// we bundle JetBrains Mono and Noto Color Emoji to act as reasonably
/// sane fallback fonts.
/// This function loads those.
pub(crate) fn load_built_in_fonts(font_info: &mut Vec<ParsedFont>) -> anyhow::Result<()> {
    #[allow(unused_macros)]
    macro_rules! font {
       ($font:literal) => {
           (include_bytes!($font) as &'static [u8], $font)
       };
   }
   let lib = crate::ftwrap::Library::new()?;

   let built_ins: &[&[(&[u8], &str)]] = &[
       #[cfg(any(test, feature = "vendor-jetbrains"))]
       &[
           font!("../../assets/fonts/JetBrainsMono-BoldItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Bold.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraBoldItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraBold.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraLightItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraLight.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Italic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-LightItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Light.ttf"),
           font!("../../assets/fonts/JetBrainsMono-MediumItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Medium.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Regular.ttf"),
           font!("../../assets/fonts/JetBrainsMono-SemiBoldItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-SemiBold.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ThinItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Thin.ttf"),
       ],

As you guessed, we need yet another phase, this time to replace all instances of ../../assets/fonts to the font package's own path:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 13e690e11f..a2a5a71a07 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -67,6 +67,7 @@ (define-module (gnu packages terminals)
   #:use-module (gnu packages sqlite)
   #:use-module (gnu packages elf)
   #:use-module (gnu packages vulkan)
+  #:use-module (gnu packages fonts)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix build-system cargo)
   #:use-module (guix build-system cmake)
@@ -1702,7 +1703,9 @@ (define-public wezterm
                             patchelf
                             vulkan-loader
                             `(,zstd "lib")
-                            mesa)))
+                            mesa
+                            font-jetbrains-mono
+                            font-google-roboto)))
       (build-system cargo-build-system)
       (arguments
        (list
@@ -1721,6 +1724,17 @@ (define-public wezterm
               (lambda _
                 (substitute* "./window/src/egl.rs"
                   (("libEGL.so") (string-append #$mesa "/lib/libEGL.so")))))
+            (add-after 'unpack 'fix-font-load-path
+              (lambda* (#:key inputs #:allow-other-keys)
+                (substitute* "wezterm-font/src/parser.rs"
+                  (("../../assets/fonts/JetBrains")
+                   (string-append
+                    #$font-jetbrains-mono
+                    "/share/fonts/truetype/JetBrains"))
+                  (("../../assets/fonts/Roboto")
+                   (string-append
+                    #$font-google-roboto
+                    "/share/fonts/truetype/Roboto")))))

A rebuild confirms that the terminal still launches as before, only this time it's using fonts from Guix, not the ones bundled in the repository.

4.7. It's Vulkan, not Vulkan't

Note from the future: Just like with libEGL, this isn't the best way to ensure WezTerm (or any other Rust-based package) can see Vulkan and is only shown because this is what I stumbled upon while reading others' code and what any other complete beginner might reasonably reach out for without knowing better.

In this case too, you can simply just instruct the linker, which both helps us get rid of patchelf and any manual mucking with the load paths and is a lot more idiomatic.

While the terminal is functional at this point, if we were to inspect the parent terminal where we started wezterm, we might notice a suspicious error message:

libEGL warning: pci id for fd 20: 10de:2f04, driver (null)

pci id for fd 21: 10de:2f04, driver (null)
kmsro: driver missing
libEGL warning: egl: failed to create dri2 screen
pci id for fd 21: 10de:2f04, driver (null)
kmsro: driver missing
libEGL warning: egl: failed to create dri2 screen

This is in fact the other big issue foreshadowed two sections ago. While we have fixed the situation with libEGL, there is another library we need to really get WezTerm working. This library is libvulkan, also known as Vulkan, OpenGL's successor. WezTerm uses it to enable GPU hardware acceleration and, without it, we're left with an embarrassingly slow CPU-accelerated rendering pipeline, that even stuff as old as the original xterm beat by magnitudes of speed.¹¹

However, this time around, unlike with EGL, there is no hard-coded filename to patch, no matter how hard we're looking. So the usual trick of rewriting won't work here. Instead, we are going to add libvulkan.so to the library loader's search path in another way. Enter patchelf, a handy tool that can manipulate the ELF header of a binary.

ELF or "Executable and Loadable Format" is the Unix solution to storing the metadata of executables. It is a small header that defines (among many other things, this is just a taste) what sort of machine this code is expected to run on (32-bit or 64-bit, x86 or ARM, etc.), what memory location our program code starts at, and most importantly for our purposes, the libraries linked to the executable.

By changing this header table, we are able to slip in a reference to libvulkan.so, without it ever being mentioned directly in the code:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 34758f238e..13e690e11f 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -65,6 +65,8 @@ (define-module (gnu packages terminals)
   #:use-module (gnu packages fcitx5)
   #:use-module (gnu packages version-control)
   #:use-module (gnu packages sqlite)
+  #:use-module (gnu packages elf)
+  #:use-module (gnu packages vulkan)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix build-system cargo)
   #:use-module (guix build-system cmake)
@@ -1697,6 +1699,8 @@ (define-public wezterm
                             libssh2
                             libgit2
                             sqlite
+                            patchelf
+                            vulkan-loader
                             `(,zstd "lib")
                             mesa)))
       (build-system cargo-build-system)
@@ -1717,6 +1721,12 @@ (define-public wezterm
               (lambda _
                 (substitute* "./window/src/egl.rs"
                   (("libEGL.so") (string-append #$mesa "/lib/libEGL.so")))))
+            (add-before 'install 'patch-libvulkan-so
+              (lambda* (#:key inputs #:allow-other-keys)
+                (invoke "patchelf"
+                        "--add-needed"
+                        (string-append #$vulkan-loader "/lib/libvulkan.so")
+                        "./target/release/wezterm-gui")))
             (replace 'install
              (lambda* (#:key inputs native-inputs #:allow-other-keys)
                ;; Binaries

invoke as the name suggests is Guix's mechanism to call out into a different application during build time. Because we're inside a gexp, our code is ensured to only be actually executed when we're done with the building and just before the installation is attempted. Since we added patchelf to our inputs, we don't have to worry about finding it, invoke will sort it out for us.

Another minor, yet important thing to note is that this time we used add-before instead of add-after. We don't really care when exactly patchelf runs, only that it happens before the installation process is finished, as we'd first like to change the ELF header.

With this step done, libvulkan.so is finally visible to the library loader and the system can start using Vulkan to drive its graphics pipeline:

Figure 1: The different GPUs (real or emulated) WezTerm sees, now that Vulkan is enabled.

4.8. A short aside: Committing is hard!

Listing 5: An example of the "ChangeLog" format.

gnu: Add wezterm.

* gnu/packages/terminal.scm: (wezterm): New variable.
* gnu/packages/rust-crates.scm (lookup-cargo-inputs) [wezterm]: New entry.

This was a topic I wanted to mention, but couldn't really find a better place for, so I'll just stick it here before the epilogue.

Guix, like most other GNU projects, follows the so-called "ChangeLog" style of commit messages. The idea is to have all contributors provide mostly consistent descriptions to their commits, based on a set of rules that makes understanding what exactly changed easier and in a sense "algorithmic".

You can basically go through a list of possible commit message formats and figure out what the current change fits most. Was it an addition, a modification, a deletion, a fix? After you nailed down the action, you can extract the exact file, section, and sometimes even subsection that was modified. And then there's still the "free form" part of the commit message, that elaborates on exactly what happened.

Thing is, while this sounds excellent on paper, I found it really difficult to properly follow this style. With every commit I was double guessing myself whether what I'm writing is succinct enough and fits the style, or if I'm making subtle errors and just think it's correct because it looks mostly fine.

Unlike most other things in this article, I have no "and then it all clicked" moment to share here. I basically limped to the finish line, stealing turns of phrases from other contributors and then most of my commit messages disappeared when my submission was overhauled (see below). The rest that remained are such simple messages, that they don't really contain any of the actually iffy stuff, that confused me.

Don't get me wrong, this is still better than total anarchy and I imagine with time you get a "feel" for how to do it right, but it sure as hell didn't inspire much confidence in me while I was working on this project.

5. And yet, some stuff is still better left to the Professionals

So, at this point we have a pretty well-functioning package. In fact, what you're seeing above is 90% the same as what I've submitted to guix/guix, with the high hopes, that the contributors there would accept it and I'd have a proper foot in the ecosystem.

The reality is both a little disappointing and, in a sense, very reassuring. As it turned out, my package definition was lacking in quite a few things:

Instead of handling all dependencies correctly, I relied on (recurisve? #t), which is considered an anti-pattern. Instead, I should have unbundled all dependencies properly.
I missed some bundled files that could've been deleted from the source folder, as they're completely unused during the compilation process.
My install phase didn't quite install all the files necessary. I accidentally left out stuff like shell completions and integrations.
I didn't install the Terminfo files for WezTerm. This caused a lot of subtle errors with command line applications, that rely on these files to know how to manipulate the state of the terminal.
The version string I came up with was incorrect both per the Guix rules and WezTerm's own. The final version conforms to both.
Turns out WezTerm reads a file called .tag to figure its own version out. I didn't include this in my initial submission.
The way I patched libEGL and libvulkan are considered unidiomatic and can be replaced with a much simpler snippet, which just instructs Cargo to link these libraries as you'd usually do:
```
(setenv "RUSTFLAGS"
      (string-join
       '("-C" "link-arg=-lEGL"
         "-C" "link-arg=-lvulkan")
       " "))
```
The description I came up with was not quite up to snuff either, due to some sensationalized words that I didn't manage to cut.
And I had quite a few stylistic gaffes that weren't strictly wrong, but could be expressed much better. For a couple of examples:
- I used string-append to concatenate folders, even though Guile has a dedicated function for it called in-vicinity.¹²
- I kept referencing packages directly in places where search-input-file would have sufficed.
- I destructured lists using car and cdr, when match-lambda works much nicer for these purposes.

Yet, the story doesn't end on a sour note. I had three different contributors jump in and offer help and feedback, turning my package into one that truly deserves to be in the repository.

Of these three people, I'd like to specifically call out and thank hako, who also happens to be the person running and developing "Guix Moe", a project which includes a powerful build farm / mirror, and a hand-crafted, Nonguix-enabled LiveCD, which allows for much easier installation of Guix System.

Hako jumped in fairly early after I opened the PR and practically revamped my code from the ground up. Obviously much of the code remains mine, but the remaining extensions and refactors made the whole thing a lot more readable and correct and, without their help, I don't think my package would have made it in or at least not nearly as easily. They also went the extra mile to include all of the recommended fonts for WezTerm, which further fixed some failing test-cases and issues.

Being a software developer, I was already familiar with the experience of facing a code review, so having my PR thrown back for several days didn't feel too daunting. On the contrary, it was actually quite great to see the amount of care put into and attention given to my work. That's the beauty of free software and people acting out of genuine enthusiasm and willingness to help.

I hope my experience might assuage some worries of potential packagers: Your code doesn't have to be perfect! As long as you're willing to communicate and address change requests, you'll be fine and if things really are above your level, there will be others who will bear that load for you.

6. Conclusion

So ends about a week of coding around and finding out. As I happen to have some Nix experience, the process wasn't nearly as harrowing as it might seem from a first glance, but Guix definitely has a couple of rough edges.

One thing that I found a bit frustrating for example was how the manual can occasionally be outdated, causing people (like myself) who aren't "in the know" to commit mistakes that could've been easily avoided otherwise. For instance, it stipulates that you should use guix style to provide a consistent styling to your code. I've been following this advice and religiously formatting my code with each commit, only to be told by hako, that I actually shouldn't use the formatter at all, because it cannot cope with complex code.

Still, despite all this and even if Guix isn't quite as powerful from an infrastructure-perspective as, say, Nix, I believe the enthusiasm of its community still carries the experience hard and because of that, I came away from the experience with quite a positive impression while Guix came away with a working WezTerm package.

If you're reading this, you're only a guix pull away from being able to add wezterm to your manifest or guix install it and have it available on your system. If you happen to be a WezTerm user, I hope my package will serve you well.

Thank you for sticking with me in this quite long post! Till next time!

Footnotes:

I was trying to play Portal RTX and I was a bit annoyed that even though both that and KDE support HDR, I still cannot make the two work due to Gamescope not being present on Guix System.

I'm being intentionally vague here. The actual trip graphical data takes to your monitor is convoluted and varies by several factors including driver, manufacturer, whether you're using Xorg or Wayland, etc. Because of that I'm not very comfortable talking about it in any authoritative way and so I won't. It doesn't really matter in the context of this blogpost anyway.

Specifically LD_PRELOAD adds libraries to the front of the search path. This can be used to override libraries which can be used for things like injecting debug messages, using alternative memory allocation, etc.

It's an extremely powerful tool and a great attack vector if you happen to load in a tainted library. Since we're working with Guix-packaged stuff, we're fine, but it's not something to use without care and good reason.

⁴

In case you're unused to declarative lingo, you can think of a "derivation" as a deterministic result from a build script. Usually this is a software package (like WezTerm's in this particular instance), but the system is flexible enough to be utilized for basically anything that results in files.

For instance, the Guix home manager allows you to manage your dotfiles in a declarative way. The contents of the derivations built by Guix home are the files that are placed into your home folder including configuration files, scripts, and whatever else you may need.

⁵

Specifically what this means is that by the time the build system is engaged, you're only allowed to access data you've specified either in your inputs or the source of your package. The actual build itself happens inside a sealed off container without even network access. This is both for security reasons (a malicious package has a far smaller attack surface if it cannot talk to the cloud, nor even see your files) and to ensure reproducibility.

While Guix is primarily known for its FSF/GNU affiliation, one of their major goals is to provide a system that can be bootstrapped from the ground up using nothing more than a tiny binary seed and a long-long chain of programs of increasing complexity. It is an utterly fascinating topic and if you find it as fascinating as I do, I really suggest giving this website a read.

⁶

It's completely unrelated to the packaging journey in the post, but I found it really interesting, that Guix had a consensus vote about doing away with the recently controversial "master" name for the base branch.

It was nice to see the kind of pragmatism and forward thinking involved in this process: The maintainers weighed how much effort it'd take to update everyone from one branch to another, how difficult it'd be to undo, what other possible actions they could take, etc. Ultimately, the vote fell through in its infancy, due to not achieving majority support and master was kept.

Whether or not you agree with the outcome, I hope you're similarly pleased to see that this project takes its democratic values seriously. If I happen to stick with Guix for a longer while, I hope to one day join the decision making myself, even if only as a minor voice in the choir.

⁷

If you happen to be following along or thinking of writing your own package, please don't forget about the -j flag. It allows multiple parallel jobs to run and Guix's source is very well decoupled from each other. I have a 24-core Ryzen processor and it's a joy to see how fast make -j24 chews through the build process compared to the utter sluggishness of a single-core run.

⁸

It is worth noting that you have to get the package name right. When I first tried importing my crates, I didn't realize I had to use the final package's name and just entered finl_unicode, since I assumed I have to provide the name of the crate I wanted to import.

This ultimately sent me down a painful side-track that led nowhere until I finally read the docs better and realized I actually need to use wezterm. Learn by my mistake!

⁹

I'm actually not quite sure what's Guix's policy regarding tests. Some packages have them disabled, some enabled, some selectively disable some tests. In my variant of the package, I disabled them following other packages' example, but in the final variant, that other contributors helped out with, the tests are once again enabled.

¹⁰

There's also your personal profile's bin and sbin folders, current-system's sbin folder, stuff managed by guix home, etc.

¹¹

I'm not 100% sure if Vulkan is needed on AMD hardware. I have a sneaking suspicion that the error is at least partly caused by the fact that on Guix System NVIDIA hardware requires a small magic incantation to work with most packages. Still, whether the error is caused by the lack of Vulkan or not doesn't really matter, as the library is still a needed dependency of WezTerm, so adding it wasn't just for kicks.

¹²

In my defense in-vicinity is a fairly horrible name for a function that joins paths. I mean, yeah, sure, it technically means what it does, but surely path-append or construct-path would've worked a lot better.

Guix System First Impressions as a Nix User

2026-01-26T18:09:00Z

1. My Journey to Guix System
2. Installer Impressions
3. I Can't Find my Way-land
4. Sympathy for the Devil
5. Goals
6. Results
7. Overall
8. Notes

1. My Journey to Guix System

Feel free to skip this section if you don't really care about backstories. I just figured it makes sense to recap how and why one might start having an interest in declarative distros before tackling the main topic.

I've been a Linux-only¹ user for about ten years now and, like many others, I too embarked on the arduous journey of distro-hopping. I started with Mint and when that felt too slow, I switched to Ubuntu. When Ubuntu felt too handholdy², I switched to Arch, which proved to be my main driver for well over five or so years. And when I couldn't resist the Siren's call, I moved on to Gentoo, thinking surely "harder is better". Which resulted in severe burnout in a few months, so I capitulated and switched to Fedora, which was very stable and honestly an all around excellent system. But once more, my interest was piqued, and (before today's adventure) I finally switched to NixOS.

I've always had a passing interest towards Nix ever since I've first heard about it, but until fairly recently, I always dismissed it as a tool for DevOps guys. The syntax was weird, the need for reproducible environments seemingly irrelevant, and stuff like the oft-recommended Nix Pills seemed anything but newbie-friendly.

So then why would someone like me, who's so adamant about not needing Nix eventually choose to go all-in? I guess it was at first less about Nix being better and just the rest being worse.

Of the two big reasons for the switch, one was that I realized that having per-directory environments for your projects is actually a very handy thing to do when you like to toy around with many technologies. I used to generate my other blog using Jekyll and, no matter which distro I used, it was always a pain in the neck to have a good Ruby environment set up. bundler install didn't really want to work without privileges and I wasn't really a fan of unleashing sudo on it, but usually that was the only way I could get things to work.

With Nix, however, it was a matter of just describing a few packages in a shell and boom, Ruby in one folder, no Ruby (and thus no mess) everywhere else. I was hooked! I started adding shell.nix files to all my little projects, hell, I started planning projects by first adding a shell.nix with all the dependencies I would reasonably need.

The other reason, which ultimately cemented that I need to commit, was that I was getting tired of my installed packages slowly drifting out of control. Sure, every package manager has some method of listing what's installed, but these are usually cumbersome and completely ephemeral (in the sense that any listing becomes invalid the moment you change anything).

With NixOS, the equation is flipped on its head: No longer did I query the system to tell me what's installed and what's not, it was now the system that worked based on files that I edit. The difference sounds small on paper, but for me it was an extremely liberating feeling to know that I could edit my system configuration in a versionable, explicit, and centralized way.

But NixOS isn't the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme, GNU's sanctioned configuration language. I've been following Guix for a bit, but it never felt quite ready to me with stuff like KDE being only barely supported and a lot of hardware not working out of the box.

However, now that (after three years) Guix announced its 1.5.0 release with a lot of stuff stabilized and KDE finally a first-party citizen, I figured now is the best time to give it a fresh shot. This post captures my experiences from installation to the first 3-4 days.

2. Installer Impressions

Plug your USB in, dd the file onto the drive, reboot, nothing unusual. If you've ever installed a Linux system, it's more of the same.

After selecting the pendrive in my BIOS settings, the monitor began to glow in a deep, radiant blue as the Guix System logo appeared on my screen… only to suddenly switch to a menacing red: My CPU's integrated GPU is not supported by free firmware. A helpful popup gave me a gentle nudge about picking free hardware next time (buddy, have you seen the PC part prices these days?) and off I went into the installer proper.

Figure 1: Picture of the installer graciously borrowed from the Guix installer manual.

The installer itself is refreshingly barebones and I mean this in a positive way. It asks all the necessary questions and provides a nice basic configuration file, all done in a retro Ncurses-based TUI. I was really happy to see that, unlike my last attempt at using Guix System in the early 2020-s, KDE Plasma is now a first-party choice during installation. I never really vibed too much with GNOME and the other options didn't appeal either, so the choice was obvious.

Now, I'm not sure if I just picked the worst possible time or if the Guix servers were facing unusual load or whatever may have happened, but after such a breeze of a setup, the moment I pressed install, my PC became unusable for the next 2.5 hours. Which is unacceptable for an installation process these days in my opinion. I am lucky enough to live in a household with fiber-optic internet, that merely shrugs at bandwidth of up to a gigabit per second and yet nearly all packages downloaded with a whopping 50 kilobit per second, meaning even small-ish 5-10 megabyte packages took long minutes to download.³

A reboot later my issues only got worse.

3. I Can't Find my Way-land

I was assuming I'd get SDDM after having chosen KDE Plasma, but (what a later, closer read of the manual made me realize is the expected outcome for a default config) it was GDM that loaded in. I entered my name and password, and I was greeted with the familiar Plasma 6 spinner. The first hint that something might be off was that it loaded a bit longer than usual, but I was not going to get mad at waiting 10 seconds instead of 3. After all, I did just wait magnitudes longer to get here.

With practically nothing installed beyond the very basics, I clicked on Konsole, hoping to start prodding around my config and add some of my day to day apps. To my horror, it opened in the top left corner, without a titlebar and without any borders. What's more, no matter what I did, I couldn't move it. It also didn't show up on the menu bar, despite the application launcher still being completely usable. At this point I was fairly exhausted by these antics, but I figured,

Well, it's a brand new release, perhaps this just snuck in. Let's give updating a shot and see if that helps.

So I issued guix pull… The download whizzed by with speed quite unexpected after what I experienced with the installer… Only to crash into the brick wall that's indexing. Okay, whatever, another 10-12 minutes down the drain, at least now I have newest version.

Figure 2: Better than before download speeds

Except I didn't. Because, unlike Nix, the guix executable is not an omnipresent, unique thing that anyone and everyone uses on your PC. Not only does every user have their own instance, if you don't issue a certain set of commands, you won't start using the new version, despite updating it.

To Guix's credit, the CLI does scream at you to update your environment or else you'll keep using the old version, but I still find this system very disorientating compared to Nix. I'm certain experienced Guixheads are long past being tripped up by this sort of stuff and might even struggle to remember that there was a time they had to do these special steps too, but as a new user it felt a bit rough, especially consdering this is Guix System, i.e. the system whose whole purpose is to be integrate Guix as much as it can.

Back to our issue at hand. I issued sudo -s and guix pull-ed again. Once more 10-12 minutes passed indexing. But at least I could finally call guix system reconfigure /etc/config.scm. Interestingly things are much faster this time around, I saw speeds up to 30-50 Mbps. Before long the system was updated to the newest commit and I rebooted with high hopes.

High hopes, that were immediately dashed when Plasma loaded in the same messed up way. At this point I started to suspect this might be an issue with the GPU driver, so I enabled the LXQT desktop environment and rebooted once more. Thankfully that one worked like a charm and I was able to boot up both Emacs (editing Scheme with GNU Nano is a pain I do not wish on anyone) and LibreWolf (Firefox's de-Mozilla-d variant).

Not having found anything too useful in the docs, I decided to make my problem someone else's so I fired up ERC⁴ and connected to Libera.chat's #guix channel. After around half an hour of wait, a user by the name of Rutherther stepped up and offered me some help. We were able to figure it out that Nouveau wasn't able to drive my GPU (an RTX 5070), so his recommendation was that I should try booting with nomodeset. I did, but it sadly didn't help much either.

4. Sympathy for the Devil

At this point I was out of ideas. Ideas of solving this using pure-Guix System, that is. There was still one option I wanted to avoid as long as I could, but alas, it seemed like the only option, that still had a realistic chance of working.

Figure 3: Nonguix's official logo, self-described to be "dark and evil".

Enter Nonguix, the Mr. Hyde to Guix's Dr. Jekyll, the shady guy who offers you a hit and first time's for free, the… Erm, in a nutshell, it's the repository for non-free applications and drivers packages for Guix System, basically. Interestingly enough, by Guix's own findings about 64% of users utilize the Nonguix channel, which is perhaps not "literally everyone", but it does paint a picture that there is still stuff out there that you simply cannot replace with FOSS software yet.

Listing 1: At the time of writing, this is all one has to do to enable Nonguix.

 1: (cons* (channel
 2:       (name 'nonguix)
 3:       (url "https://gitlab.com/nonguix/nonguix")
 4:       ;; Enable signature verification:
 5:       (introduction
 6:        (make-channel-introduction
 7:         "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
 8:         (openpgp-fingerprint
 9:          "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"))))
10:      %default-channels)

Enabling the repo wasn't exactly difficult. You just paste the short excerpt from above (also found in the README) into your ~/.config/guix/channels.scm, guix pull, let it index to its heart's content again, and then you have access to all that is nasty (yet occasionally useful) in the world.

I figured perhaps if Linux-libre and its free firmware couldn't deal with my GPU, then surely Linux proper with its binary blobs could. Hell, for good measure I threw in the NVIDIA transform, which is supposed to automagically translate all dependencies to use the proprietary drivers.

Figure 4: What haste and half-reading manuals gets you…

Turns out my eagerness was a mistake. Not only did the process take yet another half an hour (if not more, I stopped counting), upon reboot all I was met with was a kernel panic about the driver not being able to cope with the GPU it found and a massive spew of FSCK logs.

Figure 5: 'FSCK' was indeed very close to the first words that came to my mind at this moment.

With no better ideas in mind, I took out my pendrive again and burned Nonguix's own pre-built ISO on it using my partner's PC. While it ultimately did get me a working system, this version has three unfortunate hindrances:

It was built in 2022, far before Guix's migration to Codeberg, meaning it still attempts to pull content from the unfathomably slow GNU Savannah mirror. I had to manually override my channels.scm to point at the Codeberg repo instead, but with no easy means of finding its "channel introduction"⁵, I had to pass in --disable-authentication to Guix when updating my system. A bit scary, but I trust the Codeberg repo.
Because of its age, I got a lot of somewhat intimidating errors about hardware not being recognized and other stuff I couldn't even decipher, but ultimately the system booted to the installer without issue.
For some reason while the installer itself does include Nonguix stuff, it actually does not include the repo in the resulting channels files, nor the substitution server for the project. The README has a warning about this, but if you happen to miss it, you could accidentally install a non-Nonguix Guix System (say that three times fast).

None of these were particularly hard to fix, however, and soon enough I was back where I started. That is to say, in a nomodeset X11 session, except this time running i3, as LXQT wasn't an available option on an installer this old. There was certainly a bit of a hacker-ish vibe to messing with code files in an environment like that, but I was honestly much more looking forward to finally having a usable desktop.

Having learned from my hastiness, this time I was smarter. I only enabled the full kernel and firmware blobs, without going anywhere near the NVIDIA transform. I issued another guix system reconfigure and, after having time for another tea session, my update was finally finished.

I rebooted with tentative nervousness and… Success? Huh.

5. Goals

Obviously there is little point in throwing Guix System on my PC and declaring success. I wanted to be able to at least reproduce the kind of workflow I'm used to using NixOS. For that, I need the following:

A browser: preferably Firefox, as I'm not a huge fan of Chrome / Chromium,
An E-mail client: preferably Thunderbird,
A basic office suite: preferably LibreOffice,
Dev environments: for Rust, Zig, Scheme, and TypeScript (with the option for more, if possible),
Emacs: I do almost all my text editing in it these days, falling back to Neovim for quick tasks,
Discord: for chatting with friends,
Telegram: for chatting with family,
Steam: for the very rare occasions I want to game,
NVIDIA drivers: I prefer to offload day-to-day usage to my CPU's integrated GPU, as it cuts my energy usage in half.

Of these it was obvious that two would be relatively hard and one "outright impossible". The two being Steam and the drivers (as both are non-free and thus not in Guix's default repos) and the "impossible" one being Discord (which not even the non-free repo has packaged). But I was ready to compromise a little bit since I am requesting stuff that's explicitly against Guix's goals.

6. Results

Figure 6: My desktop running Wezterm packaged by me and Emacs.

While there has been occasional bumps and hitches along the ride, I must say I'm very impressed with Guix System so far. Let's go through this list in order:

Browser: So far I'm really enjoying LibreWolf. It feels a lot snappier than Firefox and I'm really baffled how much speed I was apparently missing out on.
E-mails: I installed Icedove, which is basically just Thunderbird without Mozilla branding. It works as expected.
Office suite: LibreOffice is available as expected. Not much to say about it. I guess it's interesting that Guix isn't following the usual -stale / -fresh packaging schema, but I don't really mind not having cutting edge versions of an office suite :)
Dev environments: I've only briefly toyed with development environments so far, but to me it seems like for simple use-cases it might be even easier to use than shell.nix (you don't need any sort of ceremony, just a manifest.scm file with a (specifications->manifest <list of packages>) form inside and you have a dev env ready to go.)
Emacs: Installed just fine. I had to install emacs-vterm to make Vterm work, but all that took was the very simple process of adding the library to my home configuration and then referencing it in my Emacs config as per this Reddit post.
Discord: I decided to just use Discord's browser version, which works just as fine (if not better). It's trading a tiny bit of convenience in return for not having to figure out how to manually add a package for it from some random third-party source. From what I've read elsewhere Flatpak is also an option, but I prefer having just one package manager at a time.
Steam: Installed shockingly easily. I have to really give props to the Nonguix team. I tested Portal 2 with the Nouveau driver, it is a little disheartening to see a 15 years old game⁶ lag, but I understand the people's hands are tied when it comes to the free drivers. After I managed to install the proprietary drivers, I was able to play even Portal RTX, which is something I never managed to get to work using NixOS.
NVIDIA drivers: This time I actually read the docs properly and it didn't take long for me to realize the initial problem that caused my previous install to be unbootable was of course found between the chair and keyboard. This time, after making sure I enabled the open drivers and kernel mode-setting, I crossed my fingers, issued a reconfigure and it works beautifully!

6.1. The Good

Helpful community: While I do feel like Guix's community could be much larger (see below), the one that exists is very helpful and nice from my limited experience. In all places I've looked so far (Libera's #guix, /r/Guix, and the guix/guix Codeberg repository) I was met with genuinely kind and helpful people.

That is not to say I haven't seen some bad eggs, especially in posts from years ago, but I don't think there is any community without those, so I'm not going to cite this as a negative.
Home configuration: Having guix home be a built-in, first class citizen, instead of a community made "extension" is excellent. Instead of needing to consult a third-party resource like Home Manager's documentation you can simply use what you already know about Guix and, if you happen to hit a wall, you can just read the official handbook which is guaranteed to always stay up to date with the rest of the system.
Package availability: As long as you largely use FOSS stuff (which is much easier than one might think), the amount of choice is awesome. I could basically just copy over the list of packages from my Nix config and practically everything had an equivalent.
Scheme: I'm not really a seasoned Schemer, but I have dabbled in the language previously and it feels so much better to me than Nix (the language) ever did. One great benefit of this is that it's a lot easier to start digging into package definitions to figure things out for yourself.

This is "Freedom 1" of GNU's Four Essential Freedoms in effect. Since the code is pretty much just Scheme and the different mechanisms available are fairly well documented (see caveat below), the barrier to entry is much lower than with Nix in my opinion.⁷

Another nice benefit of this is that you can use Emacs' extensive Scheme support to help your configuration. Tools like Geiser can plug right into Guix and help you find package and function names and, once you're experienced enough, debug your config/packages on the fly. I personally haven't yet achieved mastery of such level yet, but having the REPL confirm if I've entered names in correctly before running the code is already a boon.
Ease of hacking: In the "to tinker on" sense, rather than "being insecure". With Nix, merely pulling in Nixpkgs is an effort, due to the repository being massive. My otherwise beefy machine struggled to switch between branches and make commits, which doesn't exactly inspire confidence in contributing, even though it was otherwise something I was excited to do. Meanwhile, with Guix I was able to get a fully functioning development environment in 15 minutes tops, which includes cloning the repo, authenticating all commits, generating bytecode for the entire repository, and getting Emacs set up to work nice with the codebase.

Not to mention, at the time of writing my Nixpkgs PR of guile-colorized is still not accepted, despite being open since October, 2025. Which is kind of disheartening, when the package is really trivial and has a very low blast-radius. With Guix I got an answer to an extremely noobish question on my first PR in mere hours.

On a separate, but related note, I also found it a lot easier to test my package in a "live" environment as guix pull supports a parameter called --url which you can easily point to a folder on your own PC. So once I was confident my code should work, I could just "check out" my local repository clone and build it like I was an end user. This let me make sure it really does work.

6.2. The Ambiguous

Search: guix search not taking an extra parameter like nix search is both very convenient and a bit of a bummer.

Its absence is not a deal breaker, but I really loved how with Nix, you could search in anything, that has a flake. Be that Nixpkgs, a repo you downloaded, a repo that's on a git forge, etc. I remember being awestruck that I could just do nix search github:mozilla/nixpkgs-mozilla and search for their builds of Firefox without having to manually check out anything.
The documentation: Oof, this one is a bit hard to pass definite judgment on.

On one hand I love the thoroughness of it all. You can get a fairly decent idea of what Guix, what it can do for your, how to use it, and how to extend it, just by reading the manual. It is evident that the Guix team and GNU in general takes its mission to educate using free software very seriously. Stuff like the Packaging tutorial make it very easy for complete beginners to hack together package definitions without needing to consult any other resource.

On the other hand, it really is just a manual, not a tutorial. What I mean by this is that concepts that could belong together aren't placed near each other. A simple example would be services and customizing them. Assuming, you're in one of the sub-pages of Services and you suddenly realize you want to replace/modify one of the services, you are left completely clueless how that works. You have to go to a completely different chapter and find one particular function's description and then apply what you learn there. The Guix Cookbook has some examples, but you have to know about the cookbook in the first place.

And before anyone misunderstands me, I'm fine with RTFM, but in my opinion one of the preconditions of mass-appeal is having "pre-chewed" solutions for common problems, that don't require perusing multiple chapters.

6.3. The Bad

Substitute server stability: I imagine this is an issue that only a massive bag of money could fix, but the CI/CD servers could definitely use some more processing power. It's really annoying when you're trying to test something and you're suddenly forced to wait 10-15 minutes because the server can only spare 50-100 kbps for you.
Content out there: Clearly this isn't the Guix team's fault (and it's something I'm trying to lessen with this post, even if just a tiny bit), but it's really hard to find good quality material when it comes to Guix.

I mean, sure, there is the excellent System Crafters tutorial series, and the odd gems like DThompson's dev env tutorial, but as a whole you're largely left to your own to trawl through the manual, IRC logs, Reddit threads, Codeberg and the previous issue tracker, etc. It's not an impossible task, especially if you're used to doing Linux things "the hard way", but it's certainly a far cry from such one-stop shops as the Nix Flakes book or Wombat's Book of Nix.
Guix's own build speed: Nix excels in speed, so I was hoping Guix would be the same. Yet stuff like guix pull really bog things down. Doubly so, if you want to update not just your own guix instance, but also root's.
Clarity of commands: The fact that all concerns are lumped together (unlike Nix's many utilities) means that to the new user the many commands such as guix pull, guix {system, home} reconfigure, guix update can easily feel overwhelming and unclear what's updating/changing what. With time I'm sure you obtain a sort of mental muscle memory and you never think about it again, but starting out it's definitely a confusing part.

7. Overall

Listing 2: My current, fairly barebones Guix home config.

 1: (define-module (guix-home-config)
 2:   #:use-module (nongnu packages)
 3:   #:use-module (gnu packages)
 4:   #:use-module (gnu home)
 5:   #:use-module (gnu home services)
 6:   #:use-module (gnu home services shells)
 7:   #:use-module (gnu services)
 8:   #:use-module (gnu system shadow)
 9:   #:use-module (guix gexp))
10: 
11: (define %packages
12:   (list "git" "openssh" "librewolf" "ripgrep"
13:         "bat" "eza" "fd" "zoxide" "bc" "gimp"
14:         "libreoffice" "jujutsu" "starship" "direnv"
15:         "okular" "gwenview" "bitwarden-desktop"
16:         "icedove-wayland" "telegram-desktop"
17:         "emacs-vterm" "ispell" "hunspell" "wezterm"))
18: 
19: (define %nonfree-packages
20:   (list "steam-nvidia"
21:         "mpv-nvidia"))
22: 
23: (define home-config
24:   (home-environment
25:    (packages (specifications->packages (append %nonfree-packages %packages)))
26:    (services
27:     (append
28:      (list
29:       (service home-bash-service-type
30:                (home-bash-configuration
31:                  (aliases '(("ls" . "eza")))
32:                  (bashrc (list (local-file "./bashrc.sh")))))
33: 
34:       (service home-files-service-type
35:                `((".guile" ,%default-dotguile)
36:                  (".Xdefaults" ,%default-xdefaults)))
37: 
38:       (service home-xdg-configuration-files-service-type
39:                `(("gdb/gdbinit" ,%default-gdbinit)
40:                  ("nano/nanorc" ,%default-nanorc))))
41: 
42:      %base-home-services))))
43: 
44: home-config

In a nutshell I'm very positively surprised by Guix System. After struggling so much with it years ago, this time everything just clicked after a much shorter battle. So much so that I'm happy to make it my daily driver for the foreseeable future. Beyond the slightly slower execution speed, I'm getting a comparable experience to NixOS, with all the usual pros a declarative environment brings and without having to put up with Nixlang.

My only recurring issues so far are the occasional slow download speeds and that I have to start my kernel in nomodeset because otherwise the graphical environment crashes without me being able to switch to a TTY. It's a bummer, but honestly, I'm not too bothered by it so far. I'm trusting a driver update will fix it soon enough and, if not, it's not exactly difficult to throw in a kernel parameter into your config.

I'm hoping to do a followup post about packaging in Guix, because I've been dipping my toes into it by trying to package Wezterm and the journey there was similarly arduous as installing the system itself.

Till then, thank you for reading and see you next time!

8. Notes

The stuff you see below are all I managed to write down mid-process. Some of these I threw it into the file from Nano, some from half-broken X11 sessions. Because of this, it's not exactly well-edited, but I hope it might provide a glimpse into my mind at the time.

The installer is decently simple

I appreciate the warning about incompatible hardware

2.5 hours at least to install (mirrors throttle connection to 50kbps)

KDE is simply not working out of the box (titlebars are missing)

It seems to also default to X11, when I'm looking for Wayland

The first guix pull is horrendously slow

Wayland continues to elude me, seems to be an Nvidia issue

IRC recommends nomodeset, doesn't help

Try enabling Nonguix, system no longer boots

Try installing using the Nonguix ISO

Lots of errors, terribly old release

Having to guix pull myself to the present day again

Also I'm missing the introduction, so I have to run it using --disable-authentication, not great, but I trust the Codeberg repo

At least the download speed seems to have normalized

It isn't entirely clear when you have to use sudo

Running i3 on a shitty low-res has a certain vibe to it, but I'd prefer a system working out of the box

Footnotes:

Well, if only life was so easy. What I mean here is that on my personal computer, I've not had Windows since about 2015. For work purposes my hands are currently chained to MacOS (though even there I use a Debian-based container).

No disrespect to Ubuntu-users, past and present! My opinion at the time was quite ignorant and nowadays I far more appreciate an easy to maintain system as you'll see from the rest of this post.

It's merely a hunch, but it feels to me that the servers are far slower during the (Central-European) night. During midday, I get really good download speeds, but after around 8 PM, it slows to a crawl.

⁴

Which, for the uninitiated, is an IRC client built into Emacs. This editor continues to wow me every day.

⁵

I probably could have figured it out in time. But at this point I was a bit exasperated and I really didn't want to type in an 10x4 character hexadecimal code by hand.

⁶

Goodness gracious, Portal 2 is almost 15 years old…

⁷

That being said, my Nix experience was still very much helpful here. Understanding stuff such as build phases, why packages need to be patched and how this usually works, and what the different build flags mean is pretty much a must if you want to attain an understanding deeper than just "kinda getting it."

Implementing Perlin Noise in TypeScript

2026-01-20T19:25:00Z

1. Introduction
2. Basic outline
3. Implementation

1. Introduction

Ever since I first started programming, I was always fascinated by noise functions. The idea that you can take a relatively simple algorithm and generate realistic-looking textures of clouds, fire, cloth, etc. is really cool.

However, as simple as the concept is, I still found myself struggling with putting it into code, until the idea one day clicked and I was able to finally implement it. To help others, who might wonder how this algorithm works, I'd like to share a small tutorial here how one might go about implementing a simple variant of Perlin noise in TypeScript.

One caveat of the code below is that it focuses more on readability, without paying much attention towards performance and optimization, and thus isn't exactly fast, despite the algorithm being Embarrasingly Parallel. For more serious implementations one should consider following the original algorithm's permutation lookup table-based approach, use WebGL with a fragment shader that can easily compute every point's noise value at the same time, ~~or just use a better language than JS…~~

2. Basic outline

Given an arbitrarily sized rectangle, we need to do the following steps to fill it with noise:

First we divide the rectangle into a grid of squares. The size of these squares is freely adjustable by us and it determines the general "roughness" of the result.
For each of these grid points, we generate a so-called gradient vector. In the context of Perlin noise, these are little more than vectors whose magnitude is 1 and which point in random directions.
Then, for every pixel inside the original rectangle, we gather the four closest grid-points and their accompanying gradients.
We calculate the dot product of the vector formed by the pixel's coordinates and each of the gradients.
To smush these values into one, we take a proportional part of both the upper and lower corners' values based on the X coordinate of our pixel and then calculate a final value from that based on the Y coordinate.

3. Implementation

3.1. Vector class

 1: class Vector {
 2:   x: number;
 3:   y: number;
 4: 
 5:   constructor(x: number, y: number) {
 6:     this.x = x;
 7:     this.y = y;
 8:   }
 9: 
10:   static random_gradient(): Vector {
11:     const angle = Math.random() * 2 * Math.PI;
12:     return new Vector(Math.cos(angle), Math.sin(angle));
13:   }
14: 
15:   sub(other: Vector): Vector {
16:     return new Vector(this.x - other.x, this.y - other.y);
17:   }
18: 
19:   add(other: Vector): Vector {
20:     return new Vector(this.x + other.x, this.y + other.y);
21:   }
22: 
23:   dot_product(other: Vector): number {
24:     return this.x * other.x + this.y * other.y;
25:   }
26: 
27:   toString(): string {
28:     return `(${this.x}, ${this.y})`;
29:   }
30: }

We begin by defining a very rudimentary Vector class. Usually we'd define more operations, like multiplication, length, etc., but for our purposes this suffices.¹

You may wonder why we bother to define toString, when our end result will be graphical anyway. The reason is simple: We are going to associate data with our coordinates, using JavaScript's built-in Map. However, because these don't support indexing by objects, we need to first convert our Vector into a string, which does work as a key.²

3.2. Interpolation function

In our algorithm, every pixel's value comes from four different values, but the end result needs to be only a single value. Therefore we need a function that, when given two numbers, allows us to pick a third, that is a mix of a given percentage of one of our numbers and a complementary percentage of the other. For this we utilize Linear interpolation:

31: function lerp(percent: number, start: number, end: number): number {
32:   return start + percent * (end - start);
33: }

This function takes a [start, end] range and a percentage, and has the following properties:

lerp(0, start, end) = start + 0 * (end - start) = start,
lerp(1, start, end) = start + 1 * (end - start) = start + end - start = end,
Otherwise, lerp(x, start, end) = ((1 - x) * start) + (x * end).

Example: Let's say our inputs are 0.25, 1, and 5. We add to 1 a fourth of the difference between 5 and 1, thus get 1 + 0.25 * (5 - 1) = 1 + 0.25 * 4 = 1 + 1 = 2. If we were to pick 0.5 as our percent instead, our result would be 3 which is the exact middle between 1 and 5.

This already works, but it's less than ideal because the edges of the interpolation function are very sharp leading to very obvious artifacts on the edges of grid cells:

Figure 1: Noise full of visual artifacts.

It's easy to see why this happens if we take a look at how interpolating between some random values looks like:

Figure 2: Sharp peaks and valleys that show up as visible lines in our noise.

Thankfully fixing this is fairly simple. If the issue is that the endpoints' connections are too sharp, we simply have to smoothen them out. Enter the "Smoothstep" function:

34: function smoothstep(x: number): number {
35:   return 6*x**5 - 15*x**4 + 10*x**3;
36: }

Figure 3: The Smoothstep function visualized in the range [0, 1].

Given a number between [0, 1], this function returns another value between [0, 1], but "smoothened out". To provide a better visual explanation of what this means, let's see the previous interpolation, after we ran our percentages through Smoothstep:

37: function interpolate(percent: number, start: number, end: number): number {
38:   const smooth_percent = smoothstep(percent);
39:   return lerp(smooth_percent, start, end);
40: }

Figure 4: The peaks and valleys are gone.

As you can see, the end result looks a lot more "natural" as one curve flows nicely into the next, without any obvious edges.

3.3. Noise function

With all the groundwork finally done, we reach the main algorithm. Let's take it in parts:

41: const gradients = new Map<string, Vector>();
42: 
43: function get_gradient(vec: Vector): Vector {
44:   const key = vec.toString();
45:   let gradient: Vector | undefined = gradients.get(key);
46: 
47:   if (!gradient) {
48:     gradient = Vector.random_gradient();
49:     gradients.set(key, gradient);
50:   }
51: 
52:   return gradient
53: }

First we initialize a Map to hold our calculated gradients. This both serves as an optimization (we only need to calculate a gradient for every grid cell corner once) and also ensures that every corner always gets the same gradient (our random_gradient function has no knowledge about the outside state of our function, so it'll happily generate as many random vectors as we ask for).³

55: const offset_vectors: Vector[] = [
56:     new Vector(0, 0),
57:     new Vector(1, 0),
58:     new Vector(0, 1),
59:     new Vector(1, 1),
60: ];

We then create four offset vectors, which will help us address the grid cell's corners.

62: function noise(x: number, y: number): number {
63:   const coordinate_vector = new Vector(x, y);
64:   const floored_vector = new Vector(Math.floor(x), Math.floor(y));
65:   const fraction_vector = coordinate_vector.sub(floored_vector);

Our function takes in an X,Y pair representing the coordinates of a pixel. This pair is turned into three separate vectors:

one for the raw coordinates (coordinate_vector),
one for the grid cell (floored_vector),
and finally the relative position of the coordinates inside the grid cell (fraction_vector),

66:   // top left, top right, bottom left, bottom right
67:   const [tl, tr, bl, br] = offset_vectors.map((offset_vector) => {
68:     const corner_vector = floored_vector.add(offset_vector);
69:     const gradient = get_gradient(corner_vector);
70:     
71:     return coordinate_vector.sub(corner_vector).dot_product(gradient);
72:   });

Next we calculate the dot products between the vector of our pixel's coordinates and each corner's gradient. get_gradient ensures we always get the same gradient for a given corner.

73:   const upper_interpolation = interpolate(fraction_vector.x, tl, tr);
74:   const lower_interpolation = interpolate(fraction_vector.x, bl, br);
75: 
76:   const noise_value = interpolate(
77:     fraction_vector.y,
78:     upper_interpolation,
79:     lower_interpolation,
80:   );
81:     
82:   return noise_value;
83: }
84:

Finally we do a 2D interpolation using the function we defined earlier. We first interpolate between the ranges of [top left, top right] and [bottom left, bottom right] using the pixel coordinate's relative X position, and then, with one final interpolation using the coordinate's relative Y position, we get our noise value.

3.4. Main loop

 85: function generate_noise(
 86:   width: number,
 87:   height: number,
 88:   resolution: number
 89: ): Float32Array {
 90:   gradients.clear();
 91: 
 92:   const values = new Float32Array(width * height);
 93: 
 94:   for (let y = 0; y < height; y++) {
 95:     for (let x = 0; x < width; x++) {
 96:       const x_percent = x / width;
 97:       const y_percent = y / height;
 98: 
 99:       const value = noise(
100:         x_percent * resolution,
101:         y_percent * resolution,
102:       );
103: 
104:       // Map [-1, 1] => [0, 1]
105:       values[y * width + x] = (value + 1) / 2;
106:     }
107:   }
108: 
109:   return values;
110: }

First we clear the gradients map, as we don't want any previous data to interfere in case this isn't the first time we run the function.

Then we iterate through every pixel in our rectangle and calculate its coordinates, mapping [0, width] and [0, height] to [0, 1]. We also take a parameter called resolution, this determines how "zoomed in" our noise looks like:

Figure 5: Noise with high resolution value.

Figure 6: Noise with low resolution value.

Finally, our noise function returns values in the range of [-1, 1], but we need [0, 1], so we add one to our result, mapping it to [0, 2] and then divide it by 2, thus end up with [0, 1].

111: document.getElementById("button").addEventListener("click", () => {
112:   const canvas = document.getElementById("canvas") as HTMLCanvasElement;
113:   const ctx = canvas.getContext("2d");
114: 
115:   const maxFactor = Number(
116:     (document.getElementById("factor") as HTMLInputElement).value
117:   );
118: 
119:   const baseFrequency = Number(
120:     (document.getElementById("frequency") as HTMLInputElement).value
121:   );
122: 
123:   const width = canvas.width;
124:   const height = canvas.height;
125:   const imageData = ctx.getImageData(0, 0, width, height);
126: 
127:   imageData.data.fill(0);
128: 
129:   for (let factor = 0; factor <= maxFactor; factor++) {
130:     const values = generate_noise(width, height, baseFrequency * (2 ** factor));
131: 
132:     for (let y = 0; y < height; y++) {
133:       for (let x = 0; x < width; x++) {
134:         const idx = y * width + x;
135:         const value = values[idx];
136:         const color = Math.floor(Math.max(0, value) * 255 / (2 ** (factor + 1)));
137: 
138:         imageData.data[idx * 4 + 0] += color / 1.5;
139:         imageData.data[idx * 4 + 1] += color / 1.3;
140:         imageData.data[idx * 4 + 2] += color;
141:         imageData.data[idx * 4 + 3] = 255;
142:       }
143:     }
144:   }
145: 
146:   ctx.putImageData(imageData, 0, 0)
147: });

Since I don't want to cause lag immediately on page load, I bound the noise generation to a button that you can find below. We request the underlying image data from our canvas element and zero it out. This is done as a precaution in case the user presses the button multiple times. Without this reset, the += operations below would quickly oversaturate our output image.

For this demo, I added two user-controlled variables, these being factor, which determines how many layers of noise we generate and baseFrequency, which determines the initial resolution (i.e. roughness) of the noise. For some examples, try a factor of 8 and frequency of 1 for a gentle fog and 4 and 16 for a fuzzy carpet.

We generate a noise array with the given iteration's frequency and fill in the current pixel based on the value of the noise. I skewed the numbers a little to get a pleasant blue color, without any modification, we'd be left with a grayscale image.

Factor: Base frequency:

Thank you for reading this post and I hope you may have learned something fun! If you'd like to read the code as a whole, you can access it here.

Footnotes:

In fact, we could easily get away without a class and just use inlined operations with either {x: number, y: number} objects or [x, y] arrays, but I believe the class-based version provides most pedagogical clarity, so that's the one I went with.

Technically the Map really doesn't care what we pass in as key. But since all keys are coerced into primitives, all of our Vector-s would be turned into strings in the form of the dreaded "[object Object]" and lose their identity, which would pretty much defeat the point of a hash-map. To avoid this, we override toString and instead return a sensible and, more importantly, unique string representation, that our map can take with no issue.

Those who are already familiar with the algorithm (or just read its Wikipedia page before continuing this article) might have realized that this is a vastly different way of generating gradients compared to the original version.

In the original we only have a handful (8 or 16) pre-generated gradient vectors and we pick one of them based on a somewhat involved process of hashing the current coordinate and then chopping off the lower 4 bits of the resulting number. While this most likely results in faster code, I find that it somewhat obscures of what we're really doing.

Nemin's Blog

Guix System - One Month Later

Table of Contents

1. Community

1.1. IRC

1.2. Mailing lists

1.3. Subreddit

1.4. Fediverse

2. Packaging wows and woes

2.1. I really love the go-getter attitude of Guix

2.1.1. A side-note about speed

2.2. Debugging is an unpleasant experience

2.2.1. Missing parentheses

2.2.2. Non-existent variables

2.2.3. Circular dependencies

2.3. A cornucopia of styles

2.4. ChangeLog is confusing

3. System ups and downs

3.1. Stability of my config

3.2. Interfacing with my phone

3.3. Blunderbird

3.4. NVIDIA drivers and non-LTS kernels

3.5. No easy way of seeing what is updated

3.6. Sleep causes crashes

3.7. Odd freezes and crashes

4. Conclusion

Footnotes:

LLMs Are Taking the Joy Out of Our Lives

Table of Contents

1. Job

2. Hype-driven death march

3. Art-robbery

4. Post-truth society

5. We're burning our planet for… this?

6. I'm not fully innocent, but at least I care

Footnotes:

Adventures in Guix Packaging

Table of Contents

1. Introduction

2. Baby steps

3. Enter WezTerm

3.1. A mediocre first attempt

3.2. A brief second attempt at packaging locally

4. Third time's the charm

4.1. Setting things up

4.2. Importing Cargo crates

4.3. Patching Cargo.toml

4.4. We have liftoff… Almost

4.5. GPU maladies

4.6. Finding fonts

4.7. It's Vulkan, not Vulkan't

4.8. A short aside: Committing is hard!

5. And yet, some stuff is still better left to the Professionals

6. Conclusion

Footnotes:

Guix System First Impressions as a Nix User

Table of Contents

1. My Journey to Guix System

2. Installer Impressions

3. I Can't Find my Way-land

4. Sympathy for the Devil

5. Goals

6. Results

6.1. The Good

6.2. The Ambiguous

6.3. The Bad

7. Overall

8. Notes

Footnotes:

Implementing Perlin Noise in TypeScript

Table of Contents

1. Introduction

2. Basic outline

3. Implementation

3.1. Vector class

3.2. Interpolation function

3.3. Noise function

3.4. Main loop

Footnotes: