Reader

Okay so, I had this idea just now.

You know how the fedi is powered by activitypub? It's the protocol that lets servers send stuff to each other, and store it.

The thing is, when I was reading the spec it noted that there isn't much difference between client-server and server-server communication. Basically the same protocol.

So like, could we do something weird with that idea?

Spin up a bunch of different fedi services (mastodon, pixelfed, bookwrym, etc). They don't talk to each other, or the rest of the fedi. Then, spin up a server that those services can federate with. The rest of the fediverse can talk to that gateway server, but they can't reach the ones behind the gateway.

Since the gateway just aggregates the stuff on the backend servers, it means the rest of the fediverse can interact with the backend server indirectly, thinking that it's just one server.

Then, you can spin up and shutdown different servers when you feel like it. The data mostly lives in the gateway. So the backend servers are basically interchangeable.

I like interchangeable parts.

Basically, have all the servers act like the client, and the gateway as the server.

Oh hell yes. Now I've got one too.

Gooooood. >:)

Hey, I am here now too.

Gonna write up some info about how I converted a digital ocean Ubuntu system to guix.

Really liking guix so far, btw. Deciding that with this box, I will be avoiding using docker or podman, and specifically using the guix shell to run all my services and such.

First item that I am working on is setting up a synapse server, for myself. Might set up something for solarpunk.moe at some point. Right now getting my own server running is what I am gunning for. :3

Are you a Boy or a Girl?

The question is not always so simple, not least because most people are neither. In fact, it's unlikely anyone would ask such a question, but I suppose that if one were lost, it could be difficult to tell. Boys, as they are often called, are dug out of the ground by miners and masons in the employ of such groups as Praveen Nair's Expert Stonecutters Company. Really, any folks who handle rocks and minerals and gemstones would be at least passingly familiar with the existence of Boys.

Rambunctious little stone figures, they scarcely have the dirt wiped from their eyes before they begin bellowing and thrashing! Oho, what rascals! It may be frightening at first, but their raucous laughter is often enough to discourage any thieves who may find themselves inclined to rob miners or jewelrymakers or gemcutters.

And Girls, might I say, are often just as excitable! They are assembled from sturdy hardwoods by such craftsmen as those associated with R.S. Rajeshwari's Furniture Company. The screaming of their large circular saws and the clinking of their heavy chains and towing hooks can make it difficult to understand them, but they are universally beloved by woodworkers.

However, I will note that it is not so simple a delineation as that! Some Boy-like creatures proudly perform woodcutting, as noted upon my most recent trip to the Honorable Rajeshwari's furniture workshop. I met a little stone figure who held an incredible blade and had a sharp, menacing smile. The woodcutter erupted into excited shrieks and proudly introduced itself as Akhila before driving the flat blade – and its own body – across a length of wood to produce a perfect plane. And likewise, a great many Girl-like creatures are employed as guards! I have heard many a story of robbers bringing a mere wooden shield to rebuff a fast-tumbling Boy, only to be beaten and shredded and minced by one with chains and a saw.

In fact, most would not know how to answer the question of whether they would be a Boy or a Girl. You are more likely to hear that they are a dragon, a diver, a courier, a street goblin, a paper wraith, a lamplighter, a cello player, a screamer, a shouter, a yelper, a hero, a villain, a pen-maker or a pencil pusher or a penny polisher – all manner of things, in each their own way commonplace, perhaps. But never ordinary or normal or “just” anything.

This post is a sort of “fresh in my mind” walkthrough of setting up a Guix channel. Most of the information I'll go over is from or alluded to in that section of the Guix manual, but I found the ordering and wording to be a bit confusing. Plus, none of the PGP signing or git steps are covered. This will instead be a step-by-step recap of what I did, both for myself and the broader community. Note that for unsigned repositories, the order doesn't actually matter; for signed repositories, this is the simplest order.

I plan to eventually write a series of blog posts on what Guix is and why it rocks, but if you're reading this you probably don't need it. Still, I wrote some preliminary thoughts a while back. While some things mentioned there have changed in the months since, including my understanding of Guix, it's still a decent overview.

Step 0 (optional): PGP Setup

You don't actually need to sign your Guix channel if you don't want to. I did it just because I thought it would be cool. If you expect other people to use your channel (I do not), it's the polite thing to do.

Note that the information in this section was learned from a friend. Thanks, friend! (Any incorrect terminology or inaccurate descriptions of what is going on are on me, not said friend.)

Step 1: Get GnuPG

If you're on GuixSD (which you should be if you're using Guix tbh in my imho opinion lon tawa mi), you should have the gpg commandline tool available already. But! It doesn't work. You need pinentry in the same profile. For whatever reason that I didn't want to debug at the time, sticking GnuPG and pinentry in my home profile didn't work, so I ultimately just did guix package -i gnupg pinentry and things worked. I also tried using Seahorse, but I couldn't use the generated key without gpg and pinentry anyway, and the CLI gives more power. I'll be covering the CLI approach here.

Step 2: Generate a Key

First, run gpg --full-gen-key --expert. You'll be presented with a dialog asking you to select your key type. I went with ECC on my friend's suggestion, but RSA with >=3072 bits should be equally strong. The rest of this description assumes you chose ECC. Make sure whatever you choose, you can both sign and encrypt with the key.

After choosing your key type, you'll be prompted to choose the elliptic curve. Curve25519 is what I went with, though Curve488 should be fine as well. Some others apparently have weaknesses known to at least the NSA and presumably others. (Edit: this wording is inaccurate; there is not known to be a backdoor in these algorithms, but it is provably possible that there is a backdoor. I have no idea what this means, but this Wikipedia article may help.)

Next you'll be prompted to choose an expiration for your key. I chose no expiration just because this channel should exist for an arbitrarily long period of time and I don't want to deal with updating keys, but setting an expiration period is probably a better idea and is what was advised to me.

Penultimately, you'll be prompted to fill in information associated with the key, like your name and email address. I was advised not to include a comment, but didn't realize that until just now and did it anyway. Oops! You probably want to make the name and email match whatever your git name and email are, just for consistency.

Finally, gpg will open a pinentry prompt asking you to fill in a password. If you want to copy this password, do it before pressing enter; the pinentry prompt blocks keyboard and mouse input. Fill in your password, press enter, and your key will be generated!

gpg will echo back the information you entered once it generates your key. Copy the string of random characters under the “pub” heading because you'll need it a few times going forward. This is the fingerprint of your public key.

This all sounds much more complicated than it is. Your shell history will basically look something like:

gpg --full-gen-key --expert
# following prompts...
<output>

Step 3: Setup Git Signing

Create the directory where you'll setup your Guix channel if you haven't already. Initialize a git repository, then turn on commit.gpgsign and set your key fingerprint for user.signingkey. That looks like so:

mkdir example
cd example
git init
git config [--local] commit.gpgsign true
git config [--local] user.signingkey <key fingerprint>

You can optionally enter your key fingerprint for each commit, but this is simpler and will throw errors if you try to commit without signing, so I advise this method.

And that's it! Your PGP setup is ready to go. We'll come back to the signatures again later, but everything else is directly related to Guix.

Step 1: Git Setup

Step 1: Create the Repository

Skip this step if you're following the signed channel instructions.

If you haven't already, make a git repository. That goes something like,

mkdir example
cd example
git init

Boom, done.

Step 1.1 (optional): Create Keyring Branch

Skip this step if you're not signing your channel.

This and the next two steps can be done in any order, but doing this in an empty repo saves some effort. All you need to do is create an orphan git branch named “keyring” and export your PGP key, either binary or “ASCII armored” (the -a switch), to a “<identifier>.key” file committed there. The Guix convention seems to be “<name of committer>-<first 8 characters of key fingerprint>.key” so that's what I did. You can name this branch anything you want, but for simplicity I advise using “keyring”; see the documentation if you want to do that. Here's what that looks like all together:

git checkout --orphan keyring
gpg --export [-a] > <identifier>.key
git add <identifier>.key
git commit [-m "Initial commit"]
git checkout <main branch>

Step 1.2 (optional): Create Guix Authorizations File

Skip this step if you're not signing your channel.

This part is covered fairly well by the official documentation, but here's a quick summary.

Create a file in the root of your git repository called “.guix-authorizations”. In that file, enter the following code:

(authorizations
  (version 0)      ; version for the file format, not your channel
  (("Paste Your Key Fingerprint Here"
    (name "Your Name"))))

The name entry is optional and does nothing at the moment.

Step 2: Create Channel File

This is it! This is the big moment! This is where your git repository becomes a Guix channel! All you do is create a file called “.guix-channel” that is potentially as simple as:

(channel
  (version 0))

And you're done!

If you are signing your repo and didn't use “keyring” as your keyring branch name, you'll need another entry in addition to version called keyring-reference with a string for the name of your branch, like so:

(channel
  (version 0)
  (keyring-reference "your-keyring-branch"))

Step 3: Commit!

You're ready to commit to your main branch! git add your “.guix-channel” file and, if you're signing, your “.guix-authorizations” file. Here's what that looks like:

git add .guix-channel [.guix-authorizations]
git commit [-m "Initial commit"]

Step 4: Advertise Your Channel

Now that you have an initial commit, you can setup a signed or unsigned channel advertisement equally easily. If you aren't signing, you can add the advertisement in the initial commit. Basically, all “advertising your channel” means is putting the channel definition a user needs somewhere public. I stuck mine in my README since git forges display this by default. Here's what a basic channel definition looks like:

(channel
  (name 'your-channel-name)
  (url "https://example.com/channel-git-repo.git"))

If your main branch is not called “master” (and it really shouldn't be), you'll need to specify that in a branch entry, shown below:

(channel
  (name 'your-channel-name)
  (branch "main-branch-name")
  (url "https://example.com/channel-git-repo.git"))

If you are signing your repo, you'll also need an introduction entry with your first signed commit; this is whatever commit you added “.guix-authorizations” with. You can get that by eg git log and copying the commit hash. You'll also need the key fingerprint in a openpgp-fingerprint entry. It'll look like this:

(channel
  (name 'your-channel-name)
  (branch "main-branch-name")
  (url "https://example.com/channel-git-repo.git")
  (introduction
   (make-channel-introduction
    "commit-hash"
    (openpgp-fingerprint
     "pgp-key-fingerprint"))))

If you need to get your gpg key fingerprint again, that's done with gpg --list-keys and copying the random characters under the “pub” heading.

Step 5: Push!

All that's left is to add your advertisement and push to your remote git repository! Create a skeleton repo in your git software of choice (I use gitea, which is like a lightweight, self-hosted GitHub) then add the url as a remote origin and push your branches. Here's that procedure for completeness:

git add README.md
git commit [-m "Add README"]
git remote add origin "https://example.com/channel-git-repo.git"
git push -u origin <main branch>
[git checkout keyring]
[git push -u origin keyring]
[git checkout <main branch>]

Congratulations! You now have a Guix channel of your very own!

Wait! Fuck! We didn't add any packages! I guess that means we need to...

Step 3: Add Packages

Adding Guix packages is “as simple as” creating a Guile module with them in it. I didn't use Guile before switching to Guix, so the procedure was non-obvious to me. It is fairly simple once you know how it works, but many of the overlaps of Guix and Guile are fuzzy. For absolute clarity, I'll break it down into steps.

Step 1: Create Directory Structure

On the main branch of your git repository, make a directory with whatever name you chose for your channel; that is, the name entry you used in your channel declaration. Under that, you'll probably also want a “packages” directory or similar. That's as simple as mkdir -p your-channel-name/packages.

Step 2: Create Guile Files Declaring a Module

This is simple. Just make a file ending in “.scm” and, at the top, declare a normal Guile module. Here's what that looks like with the standin names we've discussed: (define-module (your-channel-name packages filename)). Note that filename is the name of the file without the “.scm” bit. If you need other modules (and you probably do), you'll use standard #:use-module declarations. A more robust example:

(define-module (your-channel-name packages filename)
  #:use-module (guix packages)
  #:use-module (...))

You can find more information about Guile modules and how to use them in the official documentation.

Step 3: Define Packages!

If you're going to the effort of setting up a Guix channel, I'm going to assume you're already at least vaguely familiar with package definitions; if not, get intimately familiar with your new best friend, the Guix programming interface. You also probably want to check out some official Guix package definitions, either via guix edit <package> or by looking through the Guix git repo (they're defined under “gnu/packages”).

One non-obvious aspect of package definition is, again, modules, namely their names. To get access to a package name, you can use guix show <package> and modify the “location” value to use as the module value by replacing slashes with spaces and dropping the “.scm”. So for the package “hello”, the location value is “gnu/packages/base.scm” and the module import would be (gnu packages base). Here's one last module example showing what using that would be like:

(define-module (your-channel-name packages filename)
  #:use-module (guix packages) ; or whatever
  #:use-module (gnu packages base))

Now you can refer to “hello” in your package definition. Some packages have different in-code names than their commandline names; you can find the exact name of a package with guix edit <package> which will open an editor at the beginning of the package definition. Just copy the value after the define-public bit and use that in your inputs.

There's a lot more gotchas and intricacies to package definition, but this should be enough to get you started. Hopefully my series on Guix will include some discussion of packaging (that could be a whole series on its own...) and I'll link to that here if and when I write it.

Conclusion

Fuck, my eyes burn.

If you want to see what this actually looks like in a git repository, you can check out my new Guix channel or the more mature (and actually useful) flatwhatson Guix channel.

Well, that's it! Go forth, newly empowered, and happy hacking!

Señoras y señores, venimos a contar, aquello que la historia no quiere recordar.

To all of you who are here, we have come here to share that which our history does not want to recall.

Pasó en el Norte Grande, fue Iquique la ciudad, mil novecientos siete marcó fatalidad, allí al pampino pobre mataron por matar.

It happened Farthest North Iquique was the city, nineteen oh seven – the year year of the atrocity, where the poorest pampinos all were slain in vain

Seremos los hablantes, diremos la verdad, verdad que es muerte amarga de obreros del salar.

We will be the narrators we will tell you the truth, the truth, was the most bitter of truths workers' deaths on the salt flats

Recuerden nuestra historia de duelo sin perdón por más que el tiempo pase no hay nunca que olvidar

Recall this our grieving story that no one should forgive, even as the time keeps going by, it shall never be forgotten.

Ahora les pedimos que pongan atención. Ahora les pedimos que pongan atención.

Now we ask of you all listen please carefully Now we ask of you all listen please carefully

I guess my next few posts will be the about the translation of a cantata I said I'd do.

I will throw in some comments about the process. Translating anything that has rhythm is weird, to say the least.

Taking some time to write a bit about my hobbies in this blog! Since I can't really think of what else to write about... :) And I have so many, that sometimes I forget them! I do write about them in my personal notes but sometimes it's nice to share.

This post will be about music. Music is a long-time special interest of mine. I've been mucking around with various forms of music for ages, but more recently (let's say, the past few years or so) I've really started to get into it more seriously.

My strengths and weaknesses

I have a lot of weaknesses when it comes to music. I tend to be clumsy on realtime instruments, and try as I might I really struggle to play what I want to play on a keyboard. So, the music I enjoy making the most is the kind that can be put together without having to play in real time. Any time I have to synchronize to a clock, I end up psyching myself out and messing up, and it's a whole tedious thing. But give me a grid or a sequencer and I can figure things out much more easily because I can go at my own pace.

I think this is why I tend to gravitate towards either generative music, or sequencers. And on that note...

Modular synths

I started getting super excited about modular synths after falling down one of those YouTube rabbitholes that happen sometimes. While I never plan to actually purchase modsynth hardware, I love how it sounds, and find it to be the perfect music to listen to while coding or otherwise focusing. I guess it makes me fit into a very particular stereotype, but it's not something I did to be 'trendy'. I've been into synths ever since I discovered the Casio keyboard as a kid and was excited about the songs it could play on its own.

But there's something special about modular synths, in how fundamental the creation of sound can be. And yet, it also can do a lot for you, which I appreciate. Having to go deep into sound design just to create a basic sound is something I want to choose to do rather than be forced to do it.

One of the coolest things I discovered was that VCVRack lets you play with a virtual modular synth. It's relaxing to create weird, or floaty, or just... bouncy tunes with it. It's been quite an intuitive way to work with sound.

Generative stuff is fun because it's really just like writing a program. You tell the modules what they need to do, and they do it!

The Digitone

For me, this has been one of the coolest devices to make music with. I bit the bullet and opted to get one of these, because I felt that it would be useful to have something physical to work with, which would allow me to create things quickly. And I believe it has!

While I found the interface to be quite intuitive, I am still getting my 'sea legs' so to speak. Sometimes I fumble. But ultimately it does make it easy to quickly throw together sounds.

I will have to spin up a personal SoundCloud-like instance to share music stuff. Yes, I do have a SoundCloud, but they are quite restrictive on how much you can upload so I'm considering stopping using them.

Projects

I only really have one large, cohesive music project right now, and it's for a video game I am working on with my partner Sara! It's quite a challenge to compose music for a game, but I do like giving myself challenges. So far I have one track mostly worked out (might still fiddle with it) and I have another that I have an idea of what I want, which I've sort of mumbled to myself on a voice recorder.

It's been fun to listen to tracks Sara provides as examples of what wants the game to sound like, and try to synthesize the styles, chord progressions, and moods into something unique. I feel like I've learned a lot already, even though I've barely scratched the surface of it.

I have this cute little blue and green resin owl.

I didn't ask to keep the little resin owl because I wanted to remember her. I chose to keep it, because it reminds me of that time nothing mattered.

I don't feel safe in my memories because of you. I feel safe in my memories because I can't tell all of you apart.

I've been using Guix for almost six months now. I figured it was about time for me to compile my thoughts and experiences for others. In this post, I'll provide a brief backgrounder on Guix, then talk about how I use it.

What is Guix?

Guix, pronounced like “geeks,” is two things (well, three. well, four. well... we'll get there). Firstly, it is a functional package manager inspired by Nix, pronounced like “nicks”. Secondly, it is a GNU/Linux system defined using that package manager in a strategy called “declarative system configuration.” You can run the package manager on any distribution. Historically, the Guix distro itself was called “GuixSD,” but that seems to have fallen out of favor these days. Instead, people just say “Guix” or “the Guix system.”

Now, unless you're a big nerd like me, none of that means anything to you. Assuming you know what a Linux distribution is, you should also know what a package manager is (apt, dnf, pacman, etc.), so let's start there. What is a functional package manager? Essentially, it brings the functional programming ideals of immutable state and “purity” (no side-effects; code only acts on the input you give it and produces some output that is always the same for that input) to package management. This means, in practice, that upgrades are stored in “generations,” snapshots of sets of packages after some package management operation, which can be switched between at will. It also allows for declaring packages and profiles (sets) of them much like one would data structures in a functional language, manipulating values as needed along the way. So for example, if you want to change the version of some library a program you use relies on, you can simply write a bit of code to switch out that library in its dependencies, no need to edit the package definition used by the rest of the system. Declarative system configuration extends these principles to cover the entirety of the system configuration, from base packages up. And Guix recently introduced home, which manages home directories and their so-called “dotfiles” (configuration files) as well. Nix was the first package manager designed around these ideas.

Nix and Guix

People, including myself, often hand-wave about Guix by saying it's like Nix, a much more popular, much older project which inspired Guix. In my mind, at least, this will be more likely to lead them to resources that understand and can explain better than I what functional package management and declarative system configuration are. If you're still confused, it might be worthwhile to do that; there are lots of examples of how these ideas are useful that I probably won't cover. Once you have a grasp on functional package management, or if you don't really care, we'll continue.

Similarities

At its core, Guix uses Nix. Its build daemon – the background progam that puts together packages and, if necessary, compiles the programs in them – is just the Nix build daemon, written in C++. Guix also provides a functional language for package declaration in addition to its functional approach to package management, and it offers a Linux distribution and includes system configuration. All of this is also the case with Nix. I think Nix may even offer home configuration. Despite these points of crossover, however, Guix and Nix are very different beasts.

Differences

The first and most important difference to discuss is the nature of the projects. The Nix project is its own independent thing, focused on Nix. It publishes Nix itself under the LGPL 2.1 and nixpkgs package definitions under the MIT license. Guix, by contrast, is a GNU project, under that umbrella and, by extension, the umbrella of the Free Software Foundation, with all the concomitant foibles and issues that implies, including the ideological purity. In practical terms, this means Guix by default only offers free software and absolutely no binary blobs. Getting most computer hardware setups to work and downloading any nonfree software requires the Nonguix package repository, which is thankfully easy to add and provides installation images. There are a lot more implications of this that I won't discuss, but if you know you know. Suffice it to say, I do not endorse the FSF or GNU so long as their founder remains involved. And even then, I've got some notes.

Unlike Nix, Guix doesn't invent a language for users; it uses the existing GNU Guile Scheme variant. However, for package management and system configuration, Guile provides domain-specific languages, DSLs, written as extensions to Guile, to make everything nicer. As such, Guix is also a set of Guile modules (analogous to a library in other languages, with some caveats that aren't worth discussing here). Again unlike Nix, Guix itself is written in the language it uses for all of this. That is, excepting the build daemons shared with Nix, all of Guix is written in Guile. The guix program is Guile, your home configuration (optional) is Guile, your package profile manifests are Guile, where you get your packages is defined with Guile, if you're on the Guix system even your default init system, default process 1, and system configuration are written in Guile.

This is the main technical difference between Guix and Nix, if only because the implications of it are so far-reaching, and is a big factor in my choosing Guix. Nix uses a language inspired by the ML family of functional languages, whose members include the functional heavyweights Haskell and OCaml, for its declaration langauge. However, the Nix language is its own special thing, with its own quirks and peculiarities. It is legendarily difficult to grock, especially for those unfamiliar with ML languages, and mastering it sufficiently to do all but the simplest package maintenance is considered something of a dark art. Additionally, it uses multiple languages through its stack, from C/C++ for its build daemon, to bash scripts for its builders, to the Nix language for user definitions. Guile, by contrast, is at every level, and the entirety of Guix is in one almost-pure-Guile (except patches and build scripts for Guix itself) repository.

To give an example of how this helps, I didn't know Guile before using Guix, but I knew enough of Scheme that it didn't matter. I've successfully packaged almost a dozen programs in the last months with relatively little effort (though I have run into issues I'll discuss later). I've opened up default system configuration values and messed around with their innards (a normal part of Guix usage). I've looked at source code for the Guix CLI to borrow some of its functionality elsewhere. And because Scheme is so simple and small, the relevant aspects of the language can be picked up pretty quickly compared to ML-style languages (although if you're unfamiliar with functional languages or Lisps, you may want to follow a book like How to Design Programs for a bit to get the basics down).

My Guix Journey

So let's get into the nitty-gritty. What is using Guix actually like? I'll try to give a chronological recounting of my experience, noting pain points or areas of particular niceness as they come up. First of all, though: why?

Why GuixSD?

When I finally got another drive for my otherwise Windows desktop (a condition of my ownership thereof being that I cannot overwrite Windows), I decided it was my chance to try the functional package management paradigm I'd heard so much about. Up to then, I had only been using relatively low-power laptops and knew that functional package management was more resource intensive. The above discussion has probably made it fairly clear that Guix and Nix are extremely similar systems. One could just as well use Nix as Guix for most of the things that might attract a person to either distro. I chose Guix for this because I already knew Scheme and was quite confident I could quickly grock Guile. Guix has a reputation for being slow, and this holds true – though I feel it more than most because of how I do system management. If you're not on a beefy machine, it may be worth investing in learning Nix.

System Installation

Installation is a fairly straightforward and simple process, if you're using a computer with libreboot, only hardware with open source drivers, and no graphics card (!). In order to get the installer booting, I had to edit the Linux commandline from GRUB to disable the kernel's efforts to load a binary module for my graphics card. I also had to tether my phone to my computer with USB to get access to a network (if I had ethernet, it'd've been fine). You can use the Nonguix ISO to avoid these issues, though I haven't personally done so.

Once you have paid penance for your heresy against Free Software (!), the installer simply walks you through a few configuration options, much like Debian, before showing you the config.scm file it has produced for you. Approve it and it will begin the process of downloading packages, building derivatives, and installing the system.

This is gonna take a while. Guix is extremely slow for no apparent reason. I have a Ryzen 5 5600 and 16 GB of RAM, and I still make sure to upgrade when I won't need my computer for at least an hour, just to be safe, because I garbage collect regularly (it goes faster if you garbage collect less often). Installation takes even longer. So, go start reading the manual. I recommend reading it in order because otherwise you may find a page assuming you know about something you've never heard of. Linearly, though, it's great documentation, and once you get familiar with where general ideas or aspects of Guix are discussed, you can jump around no problem. You don't need to read the whole thing, but at least skimming each section and looking at its subsections is a good idea

Now that you have a base system installed (and assuming you didn't use the Nonguix ISO), you now need a functional kernel and drivers for your dirty, sinful hardware without free drivers (!). Nonguix has your back; just follow their instructions and you'll be good. Get to configuring your system!

Configuration and Daily Use

You did read that documentation, right? If not, go read at least Getting Started and Package Management. If you're on the system, you should also read at least the beginning of System Configuration and keep the rest handy for reference. Finally, I'd advise checking out Home Configuration because it's cool. It might be a good idea to break these out into separate reading periods as you're actively using what you're reading, though again going in order is advised. You'll also likely need to look at Programming Interface if you want to mess around with packages. Yes, it's a bit complex, and yes, you really do need to understand at least parts of all of the above.

For me personally, the above paragraph summarizes my first couple days with Guix. I was constantly in the documentation, making sure I was setting things up right, trying to prod and nudge without breaking things. Fortunately, if you do break things, Guix's rollback functionality means you can just revert and check what you did. And, I've had to use that relatively rarely. It's much more likely you'll get an error during an upgrade or install than that you'll get one during use.

That brings me to a major enduser painpoint. Since I've started using Guix, some package or other seems to be broken upstream and prevent me from upgrading about once a month. This isn't too big of an issue as one can simply wait a few days for the issue to be resolved – it might also help to report it in the IRC or open a bug report – or rollback Guix or use an older version of some packages for a bit. But even as I write this, a recent change in the build system leaves me unable to reconfigure my system or home at all. This means the packages they use sit stagnant and I can't change my active configuration with a new Guix release (though I could use an older version of Guix if I really needed to, something I've done before). To be fair, most other package managers would have similar issues if they were rolling releases where users pulled directly from the main branch of a git repository. However, other rolling release distros get around this by having strict commit requirements and extensive pre-commit test suites – see the Void Linux package repository for a good example. Hopefully Guix will implement such strictures in the future to reduce the number of these incidents. Reputedly, they used to be less common.

But what does it actually look like to, say, install a program? guix install <package>. Remove it? guix remove <package>. Roll back a generation? guix package --roll-back. Huh, that looks a lot like every other package manager. And it is. For traditional usecases, Guix is basically the same to the end user. But underneath, it's taking advantage of all that functional goodness. Every profile has a set of files that define it in its entirety stored right in them. You can export profile manifests to send to other machines. You can create profile manifests and install them separately.

How I use Guix is much different than the simple, straightforward workflow presented above. I'll try to explain it, but just looking at my .config/guix directory is probably better. Firstly, I use both system and home configurations. I decide what, if any, packages I want to be available to everyone who might use my computer and put them in the system configuration. I also put fonts and other system-related packages here. I put everything else in the home configuration. If there are sets of related packages in my home configuration, I may break them out into a specific profile. I use my default profile (that accessed by guix install <pkg>, guix upgrade, etc) for packages whose definitions I have written locally and which therefore can't be upgraded with upstream sources. In order to load in packages at login, I add a loop to my .bashrc (see the home directory of my Guix config dir) to source all the profiles. I also prefer to completely rebuild profiles rather than simply upgrade them (so guix package -p <profile> -m <profile-manifest.scm> instead of guix upgrade -p <profile>) to mirror the functionality of home and system. All of this together creates a rather messy upgrade process, so I wrote a Guile script to help (there are shell equivalents in my Guix config dir).

In order to add packages, I open up the relevant configuration file, add a package, and rebuild the profile. With minor changes, this is relatively quick thanks to cached packages and configuration files and whatnot. If this also requires reconfiguring my home or system, that's only a few edits away, usually in the same file, and it takes about the same amount of time as just installing packages. I've noticed this being particularly handy for things like switching to Wayland or setting up a Pipewire home service, things that would require editing several files and installing several packages by hand on another system.

Making Packages

Frankly, packaging in Guix is a breeze compared to any other package definition system I've seen. It particularly shines for strict build systems with well-defined interfaces. For example, there are a variety of third-party package repositories from which guix import can automatically generate Guix package definitions (though they sometimes need tweaking). There are some headaches, however, for less standard build systems, but even these are comparatively nice to deal with. Entire phases of the build process can be added, removed, or replaced in Guile, much like writing a lambda expression (and often using actual lambda expressions). Unfortunately, this has to be done fairly often, and there seems to be one main issue. Guix doesn't use the traditional Unix filesystem hierarchy, so shebang lines and hardcoded paths often have to be edited. There are automated steps that usually handle this without intervention, but in the body of source code or build system configurations they sometimes fail. Aside from this, most packages only face the same issues as they would in any other package manager.

I have packaged a variety of relatively small programs with little to no issue so far. Notably, my own upgrade helper; the pb tool; and qpwgraph. These are the current contents of my default profile. I also updated the driver for my wifi dongle (I simply changed the version and the hash) and did most of the work for packaging the Haxe programming language, including successfully packaging all of its dependencies (which I lost through insufficiently careful file management, entirely unrelated to Guix or any software). It's worth noting that I've also done analogous amounts of package definition on Void, packaging gdc for all supported architectures (before the PR was rejected for overcomplicating the bootstrap target, a position I agree with; I've yet to return to getting it merged separately) and updating Racket so that its 8.x releases would cross-compile (which I'm particularly proud of because it was the first time Racket 8.x was offered as binary packages for musl libc for any platform besides x86*). I say this to provide context to my comments on the packaging process. I'm quite inexperienced, but I know enough to actually do it.

There are two main bottlenecks in packaging for Guix that do not exist elsewhere. I mentioned the first above, patching file paths to handle Guix's immutable filesystem. But there's another issue created by the way Guix handles files: it's really hard to execute arbitrary programs. Now, this is overall a good thing: no one can execute a malicious binary on your computer, and since Guix is 100% open-source by default, you can theoretically manually verify every single line of code your computer ever executes. But this makes things tricky when you want to package, say, a package manager. Or, say, a game client. Like the kick-ass Minigalaxy. I never managed to get Minigalaxy packaged because I remembered it's available through the already-packaged Flatpak, but I got just far enough to realize that actually installing games was going to introduce several hurdles. The Nonguix Steam package, for example, bootstraps a temporary environment to run in. Do note, I haven't actually run into issues with this during packaging, it's just something I can see being an issue.

Development Environments

One thing that got me interested in finally trying out Guix was using some Python environment management tools. So naturally, one of the first things I decided to use Guix for was setting up development environments. The Guix command is guix shell and it can be passed a list of packages. With the -D flag, it collects development dependencies for the following package; with -f it evaluates a file to a package; with -m it accepts a profile manifest; and with -p it accepts a profile directly. You'll often see configs for this in project root directories as either manifest.scm or guix.scm. They seem to be more or less equivalent, though by convention guix.scm seems to be a package definition for the project which can be used to generate a development environment by guix shell -Df while manifest.scm gets fed to guix shell -m.

Assuming all your dependencies are in Guix, setting up a development environments (and packaging your own programs) is pretty simple. You can even pin versions. If you need to, packaging dependencies is usually straightforward, and these definitions can be included in the config file. I did run into issues once where I needed a specific version of Python which was never packaged, an issue I never managed to overcome. Times like these are rare, however, and using a later version of Python worked fine anyway.

Home Environments

I've mentioned home environments a couple times, but I haven't discussed them in any depth yet. Let's do that now. If you want to setup a home configuration, you should check out the blog post on the topic. Essentially, you define your shell and its settings using a configuration much like that for system, setup any home services, import any dotfile code not handled by Guix directly, add any packages, and that's it. You can import an existing home environment to get most of this automatically. Once that's done, modifying the login environment is handled by Guix. I really like this functionality of Guix as I find manually keeping track of my dotfiles to be a bit of a hassle.

Notable Quirks

I tried getting into Julia recently and found some issues with Guix. Firstly, the Julia package manager doesn't work without p7zip being installed in the same profile. Secondly, some major Julia libraries aren't yet available in Guix (and though there is a Julia build system in Guix, there's no import handler for its packages yet). These are both issues related to the raw amount of effort that is available for Guix, and not reflections on the system itself per se. Regardless, package availability may sometimes be lackluster, especially if you're habituated to Debian-based distributions. This can cause issues since on GuixSD, it's impossible to run programs that haven't been packaged appropriately, by Guix or a Guix-installed package manager. Theoretically the ease of packaging mitigates this issue, and in practice this often holds true, but it's still annoying.

Tidbits and Goodies

One neat feature of Guix that I'm very excited about but haven't had the chance to really use is guix pack. It allows the production of binary tarballs, Docker images, SquashFS images, or deb packages from any Guix package definition. I haven't tried it yet, and there are caveats, but it sounds promising.

You can ship off configuration files from one Guix system to another to reproduce package profiles. Combined with channel listings, which I haven't discussed, this allows arbitrarily reproducable (theoretically bit-reproducable) systems. You can also use guix archive to share binary images back and forth.

Conclusion

Guix provides an immense amount of power, and that comes at a cost. I've definitely complained a fair deal about various aspects of the system. Regardless, I find the exchange to be overall worth it. It really does provide a much nicer, more understandable interface to package management. Instead of package management being something I avoid, it's something I dig into because I have learned enough of my system to be able to manipulate it the ways I want. This kind of power would not be possible on any other system without a much, much more complex set of overlapping interfaces. If any of this appeals to you, try it. You might just like it.

Is this thing on?

Hey y'all, now that we're all starting to settle in, I just want to go over some housekeeping stuff. Any similar posts will also be made on this blog in the future, so you may want to give it a follow.

First, a notice: the default post privacy is Public. There seemed to be issues with changing a blog to Public when the default was Unlisted. If you don't want your posts to show up on the Reader, make sure to set your blog to Unlisted or something stricter. We can change back to Unlisted and/or turn the Reader off if y'all want, but I think it's neat.

Secondly, you can send trusted friends the invite link. As a friend of mine used to say when throwing parties, “You're cool, and your friends are cool, but not your friends' friends.” If the link expires, ping me for a new one. For the time being, only I can create invite links, and there may be a hard limit on users at some point. There are two reasons for this. Mainly, I want this to be a cozy space; I'd like to know everyone here. More practically, the server hardware and my finances are limited. If invite access is an issue, let me know and we can address it.

Thirdly, we shouldn't need community rules because we're all friends with similar ethics, but I want to make one request. Please use Excerpts to warn about and hide potentially triggering topics on Public blogs. Besides that, if any moderation issues come up, we can handle them interpersonally, ideally communally. If you have specific requests, or if we decide together we need rules, we can make additional posts to this blog or add rules to the About page.

Fourth, some rules for me. I won't look at any of your data unless I need to for moderation or administration reasons, or you ask me to. What I mean by this is, each user has a page in the administration dashboard. I won't be accessing this except for the above reasons. The same applies to all data WriteFreely stores, whether or not it exposes an interface to it. I won't take any action on your account whatsoever except for the same reasons. The spirit of this is mentioned in the Privacy Policy.

Do note that other people potentially have access to data on this instance. This server is not encrypted on-disk, I do not have control over the physical drives, there are backups made daily, and it's hosted near Atlanta, Georgia, USA. Keep all of this in mind when deciding what to post. There is a gag order canary in the Privacy Policy just because that's cool and cyberpunk; I don't expect it to ever be needed. Unfortunately, we live in interesting times.

Other than that, just let me know if there are any issues, technical or otherwise, on the instance. Y'all know more about administration than me, so I may also come to y'all if I have issues. If you want to change the name or public pages of the instance, or if you look at the documentation and think our instance should have different settings, let me know that, too. Overall, I just want this to be a cozy little writing space we build together!

it's post

Howdy there this is write freely

Now I can write pretty freely...

Rats rock – feel free to write about them here!