https://nemin.hu/guix.html
Logo for my website.
Nemin's Blog
Guix System First Impressions as a Nix User
2026.01.26.
Tags: programming, guix
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
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^1 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^2, 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.
installer_partitions.avif
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 gigabyte per second and yet nearly all
packages downloaded with a whopping 50 kilobytes per second, meaning
even small-ish 5-10 megabyte packages took long minutes to download.^
3
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.
downloads.avif
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^4 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.
logo-screen-light.svg
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 and /etc/guix/channels.scm files, 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.
nvidia_first_shot_crash.avif
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.
fsck.avif
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:
1. 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"^5, I had to pass
in --disable-authentication to Guix when updating my system. A
bit scary, but I trust the Codeberg repo.
2. 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.
3. 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
desktop.avif
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 ) 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^6 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.^7
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
o 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)
o 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
o IRC recommends nomodeset, doesn't help
+ Try enabling Nonguix, system no longer boots
+ Try installing using the Nonguix ISO
o Lots of errors, terribly old release
o Having to guix pull myself to the present day again
o Also I'm missing the introduction, so I have to run it
using --disable-authentication, not great, but I trust
the Codeberg repo
o 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:
^1
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).
^2
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.
^3
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.
^4
Which, for the uninitiated, is an IRC client built into Emacs. This
editor continues to wow me every day.
^5
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.
^6
Goodness gracious, Portal 2 is almost 15 years old...
^7
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."
From with l. This site was last updated on 2026.01.31.