Thunks & Thoughts

Yes - Cabal custom scripts do have uses

2026-05-21T11:45:00.000Z

This will be a quick one. I've been working on implementing replication in my Redis server. The first step for this, per the codecrafters challenge that I'm following, is to implement the INFO command, which I've done in this PR and may be the focus of a future blog post. The framework for the INFO command was pretty easy to implement (types ftw). What I found myself spending the most time on was figuring out where the information in the INFO response comes from.

For the challenge, the goal was to implement the Replication section with just the role field, but I decided to also take a stab at implementing the Server section. It was a bit of a tangent. It took a while to hunt down what each field of the section meant and how Redis acquired the field's value. GitHub Copilot was very helpful in navigating and tracing things around in the codebase. I'll spare you all the mundane details. Suffice it to say, I ended up translating the Redis code for the server section into this Haskell module.

I'm pretty proud of it overall, and through it I found a decent use for Cabal's custom script mechanism. I use the script to collect and generate static build/release information like the current git commit hash, current git dirty status, and server build ID for the redis_git_sha1, redis_git_dirty, and redis_build_id fields under the "Server" INFO section. Redis does something similar with its mkreleasehdr.sh script, which generates a header file with release info variables that it then uses to, among other things, seed those "Server" section fields I mentioned in its INFO command implementation.

I used Cabal's custom script mechanism to mimic this since I didn't want to have to bend over backwards to try to collect this information at runtime. The setup script creates a BuildInfo.hs module that is seeded with constants, which I think is more efficient than whatever runtime attempt at fetching the same data I'd have needed to concoct, which would have required shelling out to git or potentially generating a build ID on each INFO request. I also made it such that the BuildInfo.hs module is only regenerated when certain data points change, similar to what the Redis script does. The full setup script can be perused here.

Though Cabal custom scripts are deprecated, it was much easier for me to get set up with them than the newer recommended setup hooks API. There were also more examples on the former to draw inspiration from than the latter. I think this is because of how new the hooks API seems to be. I will add a TODO to migrate it over; who knows, I might even get to it someday. But since it is non-blocking, I plan to just move on for now.

An alternative approach would have been to use Template Haskell. Template Haskell could do compile-time generation too, but would push metaprogramming into the app code for a small amount of static metadata. It seemed a little overkill for this particular scenario.

In any case, that's all for this one folks. If you need to generate a module at compile time, Cabal custom scripts (or Hooks API) got your back. Till next time!

On maths and engineering

2026-05-21T11:44:00.000Z

I want to be dangerous with maths, at least, with regard to software engineering. I know math isn't necessarily a requirement for the field, but being competent never hurts. Moreover, time and time again I have found myself trying to read through some CS literature like Intro to Algorithms, or SICP, or (most recently) The Algorithm Design Manual only to find myself waylaid by the math weaved into the essence of the prose. Some of it, I am able to overcome, but often it ends up being a point of frustration that causes me to lose interest or take too long to make any meaningful progress.

When I was just starting out, I didn't really think much of this gap. I was more occupied with just learning programming, but now I think I want to do more to study computer science: do a little more theory rather than just practicals. I want to get good at the relevant math which, from my research, seems to just be mostly discrete math (plus linear algebra and statistics for ML). Maybe some Calculus, but that seems more useful in specific niches, if anything.

Oddly enough, I have taken a Calculus class, Calculus I specifically, back in community college (CC). However, since I wasn't able to complete a Bachelor's degree immediately after CC, I haven't taken a discrete math class. Well, that's not entirely true. I did do some study in the semester before my hiatus at WGU. Needless to say, for all intents and purposes, I haven't really taken a discrete math class, so I'm just gonna do that.

I've found the textbook, Discrete Mathematics with Applications by Susanna S. Epp, to be fantastic so far. Super accessible, and I hope to get through it cover-to-cover or close enough to achieve my ends. In parallel, I am also reading The Algorithm Design Manual for DSA practice. Yes, sure I could just take one of the many DSA/Leetcode courses geared specifically towards getting a person interview-ready, and I did start with that, but I guess I wanted something a little more comprehensive? I also wanted to make progress on this curriculum, so I figured reading TADM would be killing two birds with one stone.

I'm in a pretty good spot to dive into this, I think. Let's just hope it stays that way long enough for me to get to where I want to go.

Anyways, while I go through TADM, particularly the exercises, I find myself needing to do things like come up with counterexamples or prove algorithms. This stuff was never interesting to me, but I find it more and more fascinating as the days go by. I'm even looking to learn Lean to get better at formally expressing the proofs I write. I haven't gotten to the proof section of Discrete Mathematics with Applications yet, so the proof exercises in TADM are still a bit of a slog. I have found Claude to be particularly helpful, but I don't let it just give me the answers. I have system prompts that specifically disable this behavior. No, I have configured Claude to be a kind of tutor, and it's been working wonders in helping me get through the TADM exercises while I shore up my math.

A couple of days ago, Claude and I worked through a proof for Horner's method using loop invariants. Below is what I was able to come up with following Claude's assistance (all of this below is in my own words):

Horner's Method

Horner(a, x)
	p = a_n
	for i from n − 1 to 0
		p = p · x + a_i
	return p

What is/are the invariant(s) that directly assert on the expected end result of this algorithm? Horner's method is an algorithm for evaluating [[Polynomials]]. So it stands to reason that our invariant ought to be something related to the evaluation of polynomials. The algorithm returns a value $p$ which is probably the evaluated polynomial. Ok, then what is true about $p$ at every step (initialization, after each iteration, and after termination)?

Some scrutiny suggests that the invariant we care about here is that " $p$ always contains the evaluated polynomial up to $a_{i}$ ".

At initialization, $p = a_{n}$ which adheres to our invariant since, at this point, $i$ is not initialized, there is no $i$ but $p$ holds the first term of the polynomial.
After each iteration, we can see that our invariant holds true as with every iteration, $p$ still contains an evaluated polynomial up to $a_{i}$ .
- For iteration 1, we are 1 away from $n$ , so $n - 1$ . Thus, $p = (a_{n} * x) + a_{n - 1} = a_{n} * x + a_{n - 1}$ . Since at this iteration $i = n - 1$ , $p$ is also equal to $a_{n} * x + a_{i}$ , matching our invariant
- For iteration 2, we are 2 away from $n$ , so $n - 2$ . Thus $p = (((a_{n} * x) + a_{n - 1}) * x) + a_{n - 2} = a_{n} * x^{2} + a_{n - 1} * x + a_{n - 2}$ . Again, because at this iteration we are at $n - 2$ , $i = n - 1 - 1 = n - 2$ , thus $p = a_{n} * x^{2} + a_{n - 1} * x + a_{i}$ , matching our invariant
- For iteration 3, we are 3 away from $n$ , so $n - 3$ . Thus, $p = (((((a_{n} * x) + a_{n - 1}) * x) + a_{n - 2}) * x) + a_{n - 3} = a_{n} * x^{3} + a_{n - 1} * x^{2} + a_{n - 2} * x + a_{n - 3}$ . Once more, because at this iteration we are at $n - 3$ , $i = n - 1 - 1 - 1 = n - 3$ , a $- 1$ for each iteration. Thus, $p = a_{n} * x^{3} + a_{n - 1} * x^{2} + a_{n - 2} * x + a_{i}$ , matching our invariant
Notice how with each iteration, the polynomial held by $p$ increases by a term and all the exponents increase by 1? Also note that the exponent for the first time is equal to the number of iterations. At our first iteration the first term had an exponent of 1. At the second iteration, the exponent was 2, and in our third, it was 3. Likewise, at our first iteration $i = n - 1$ , at the second $i = n - 2$ , and at the third iteration $i = n - 3$ . Doing some quick algebra shows us that we could generalize our exponent as $n - i$ ( $i = n - 3$ -> $0 = n - 3 - i$ -> $3, the index = n - i$ ). And because each subsequent term has an exponent that is 1 less than the exponent of the previous term, the second and third terms will have an exponent of $n - i - 1$ and $n - i - 2$ respectively. Thus we can state our invariant more algebraically as $p = a_{n} * x^{n - i} + a_{n - 1} * x^{n - i - 1} + a_{n - 2} * x^{n - i - 2} + a_{n - 3} * x^{n - i - 3} + \dots + a_{i}$ . Notice how this is more or less equivalent to what we got as the value of $p$ after each iteration.
At termination, that is, when $i = 0$ , $p = a_{n} * x^{n} + a_{n - 1} * x^{n - 1} + a_{n - 2} * x^{n - 2} + a_{n - 3} * x^{n - 3} + \dots + a_{0}$ . This is equivalent to our invariant, so the invariant holds all through.

Aside

Note that $a_{i}$ is the last term since only after the last iteration is $i$ fixed at 0. Using it as the index in any other term wouldn't be correct once we start adding more terms. So, on the first iteration, $a_{n} * x + a_{i}$ is correct because on the first iteration $i = n - 1$ . However, it would be incorrect to say $p = a_{n} * x^{2} + a_{i} * x^{1} + a_{i - 1}$ for the second iteration because now $i = n - 1 - 1$ , so the indexes for the second and third terms of our polynomial would be wrong. Instead we want to reference $n$ directly somehow, since $n$ 's value never changes with each iteration.

Look at how beautiful that is. It's enough to make a grown man cry! Though I think what I have here is accurate, I'm always open to correction.

Learning about loop invariants and using them for this proof took me a while, and there was a lot of stumbling and fumbling, but I managed it. My goal now is to make it easier for me to do these kinds of things, and by extension open myself up to more CS literature. Not all of it, mind, but enough to help broaden my engineering capabilities. Let's see how it goes.

Numbers? Numerals? Oh Boy

2026-05-21T11:44:00.000Z

So a while back I was attempting to do some data marshalling for the persistence of the store in my redis server implementation per the RDB file specification. It turns out that when you attempt to get the char code for a character in Haskell, it'll give you a decimal number. This stumped me for a bit since in the example I was testing out (getting the char code for the character 'R') I was expecting to get 52 per what I saw in the docs, but I was getting 82 instead?

Then while I was having a friendly chat with some of the gods at the functional programming discord, I was told that those numbers are the same, wtf? I was expecting 52, which, it turns out, is the char code for 'R' in hexadecimal, while 82 is the char code in decimal. For some reason, my brain somehow didn't even consider that those two symbols (52 and 82) could be the same in any way. If you too are a little confused, read on.

You see, it turns out that we all conflate the idea of numbers and numerals because the distinction tends not to have any practical significance for the most part. Numbers are in reality not a sequence of symbols, but are abstract mathematical objects. They exist independently of any base system, they just are, like the concept of 'distance' or 'quantity'. They are a pure mathematical concept that transcends notation (like a soul), independent of the symbols we typically associate them with/use to represent them. These symbols are actually numerals.

Think about it, when you have three apples, the "threeness" exists whether you write it as 3, III, 三, or 11 (in binary). The quantity itself is the number; how we write it down is the numeral.

A helpful analogy here might be the game Mortal Shell. Great game btw, though a little too tedious for me. Anyway, this game makes a great analogy because it follows a sort of spirit (number) that can be taken into combat with different shells (numerals). Just like in the game where the same spirit can inhabit different shells, the same number can be expressed through different numeral systems.

Numerals are what we mean when we typically refer to a "number" in everyday speech. If numbers are the soul, numerals are the physical shells with which we interact with said soul in everyday life. Numerals are a representation of numbers in the form of some base (10 for decimal, 16 for hex, 2 for binary, etc.) using an available sequence of digits. They're the physical manifestation of the abstract mathematical idea for practical use.

I mean, how else can a notion of equality between completely disparate symbols like "42", "101010", and "2A" even exist without some sort of common denominator to refer back to? In this case, that common denominator is a number in the mathematical sense.

Although computers represent numbers using binary numerals for practical reasons (hardware limitations, to speed up bitwise operations, etc.), what we deal with as engineers are numbers in the mathematical sense because that's the level of abstraction we think in. The fact that it's binary beneath the covers is irrelevant to us, so for all intents and purposes (excluding maybe systems engineering), numeric types are a digital representation of numbers not numerals.

So in essence, numbers are abstract mathematical objects that represent quantity. Numerals are the symbols we use to represent/concretize said objects. Crazy right? Who would've thought numbers to be like spirits? What if they're the ghost of some vengeful mathematicians? Anyway, understanding this helped clarify my confusion while giving me a cool concept to explain when I want to sound smart, so it's a win win.

NixOS, the start of something new (part 1)

2026-05-21T11:44:00.000Z

I am really digging this Nix thing. I've known about Nix for a while now. It didn't really seem like much, especially since I already had my distro-setup repository for reproducing my Fedora system. I considered Nix to be needless complexity until I started using it at work and my eyes were opened.

I realized that most, if not all, of the things I have scripted in my distro-setup repository could easily be expressed as Nix configuration, and because NixOS operates as a function of your configuration, the only way to modify your system would be to modify your config.

I figured that kind of workflow would be the solution to a problem I'd been having with distro-setup where, over time, my scripts would drift from the state of my system because I'd neglect to update them as I modified things. By default, however, with NixOS, this undesirable state becomes harder to reach, because, again, by default, you must update your configuration if you want to modify your system. Pretty neat, right!?

Nonetheless, I still kinda held off on doing all this because I really didn't want to learn a whole new abstraction and the common sentiment of Nix being a particularly obtuse language with terrible error messages and a steep learning curve only put me off further. But as I continued to consider the potential benefits (lower likelihood of drift and easier reproducibility), I decided to give it a proper shot. I opted to start by learning the meanings of what I think are the most common terms:

Info

The Nix language can be thought of as JSON with functions.
A revision is a Nix term for a Git commit hash. Most commonly, revisions tend to refer to a specific Git commit hash from the Nixpkgs repo, but it can also refer to a commit hash from any Git repo.
A derivation is a build recipe/blueprint for a "package". With a derivation, we describe how to build a "package": what inputs it needs, what commands to run, and where the output should be placed.
- I put the term "package" in quotes above because in Nix, the term is used pretty loosely. Usually a package refers to something like a program from a repository or something, but in Nix a package may refer to:
- a derivation itself (confusing, I know).
- the result of a derivation.
- a program or tool (like usual).
- a library (like those libutils or whatever packages you'd typically spy in a distribution's repo).
- a font, config, man pages, really any software artifact I think.
The Nix "store", distinct from /usr/bin, is located at /nix/store and it is where everything that Nix builds ("packages") is stored. Items are stored at a unique path based on the hash of their inputs. This way different versions of an item can exist without collision.
A channel is a named, stable URL that points to a revision, the latest one among a collection of revisions like nixos-24.11 or nixos-unstable. It is similar to a Git repo where you can subscribe to receive updates when new commits are pushed through. We point a channel to its latest revision using nix-channel --update or nixos-rebuild --upgrade. Channels make it easy to get started with Nix and NixOS.
- However, it is important to note that this mechanism isn't reproducible in the same way a package.json without a package-lock.json isn't reproducible. Channels can point to different revisions across machines. In other words, two systems with the same channel-based config could be working with different revisions of the same channel.
- Channels only ever work with the latest revision they are aware. There is no way to rollback or pin to a revision as far as I know
An overlay is a mechanism for extending a package set without needing to fork the package set. It allows for the overriding of a package in a package set or adding a new package.
An override allows for rebuilding a package with different dependencies or options. For example, you want to build a package but do so with a specific flag enabled or swap out an out-of-date dependency with something more recent, etc.
A NixOS module is a reusable piece of system (NixOS) configuration like in /etc/nixos, having a configuration.nix and a hardware-configuration.nix and importing the latter in the former. Both are modules.
A generation is a bootable snapshot of your system configuration. Generations are listed for you to select from before booting. Every time you rebuild, NixOS creates a new generation and adds it as a boot entry.
A profile is a collection of installed packages and configuration for a given user or system.

I also took the time to get at least a partial intuition for what a flake is and how it differs from a channel. The benefits it offers in terms of reproducibility were the main reason I opted to have my config be flake-based as you can see in the repo.

[!aside] Why "reproducibility"
I value reproducibility because I like being able to get back up and running quickly should anything happen to my device and I need to spin up a new one, or need to do a fresh install. Like with my games, I hate losing my progress :). Even on Fedora, which supports version upgrades, I prefer to do a fresh install as it reduces the chances of things not working right.

[!aside] What is a "flake"
A flake is a relatively new approach to defining nix projects. A flake can be thought of as any directory with a flake.nix and flake.lock at its root. In a flake.nix file we define two things: inputs and outputs. Like in a function, the inputs are the dependencies of the flake, the things required to generate the output. The outputs can be multiple things, a package, a development environment, a library, a NixOS configuration or any other kind of software artifact. Flakes offer us more reproducibility thanks to the flake.lock file where dependencies, inputs are explicitly "pinned" similar to what a package lock file does in any other programming language

AI has also been a huge boon, particularly as a collaborator. I am playing with all of this on a VM (as anyone should) before I opt to replace Fedora on Boreas.

You may also be wondering: "hmm, if you're using Fedora, why not use one of the atomic spins?" Well, anon, that's because atomic spins don't provide the same reproducibility guarantees as NixOS. From what I understand, with atomic spins, we'd all more or less start with the exact same OS base version, but that's it. Changes are still made imperatively using package managers, and though those changes are underpinned by a reproducible base image, transactional updates (via rpm-ostree), rollbacks, etc…, the potential for drift between my setup scripts and system state is still high.

So here we are, NixOS. I've been with Fedora since v34, but now it's time for a change. I've got this PR that migrates my DE/WM-agnostic packages onto Nix. Take a look, and let me know what you think!

Part 2!

NixOS, the last milestone (part 3)

2026-05-21T11:44:00.000Z

Alrighty! Since part 2, I've handled the hardware configuration for my NixOS setup. Specifically, the configuration for an Intel CPU and Integrated GPU, and an NVIDIA GPU. My initial plan was to make reusable modules for each component, so I could plug'n'play across hosts. I wanted separate modules for an Intel CPU & GPU, separate modules for an AMD CPU & GPU, and a module for an NVIDIA GPU. However, as it turns out, all that is already covered by the nixos-hardware project. In fact, all I needed to do was find the module corresponding to my host model and just import and hook it up to get all the hardware configuration I was looking for, or at least a baseline to work up from. Pretty neat I say.

Beyond that I also added configuration for some other miscellaneous items. To check those out, feel free to peruse the PR

In part 2, I spoke about how helpful LLMs were in standing all this up. So, I figure it's only right to now show you, or at least, offer up a snapshot of the kinds of interactions/conversations I have with them within the context of this project.

On the branch for this work, I started with the following prompt:

Alright, the final milestone before I test this in a VM would be setting up hardware integration, things like NVIDIA GPU support, Intel support, AMD (CPU & GPU) support. Boreas has an intel cpu and integrated gpu with an NVIDIA GPU. So it makes sense to directly have options for that in its configurations. However, capturing those options in a module would allow for reusability which I think is much more valuable. I also plan to get a framework in the near/distant future with potentially an AMD CPU and Nvidia GPU, but having separate modules for each makes sense. One for AMD CPU and another for AMD GPU. What do you think? We're just brainstorming here

Ignoring the grammar for a bit, I find myself increasingly asking the LLM for its "thoughts" in my prompts. I think the reason I do this is to force brainstorming in some form. To make interactions with it more "interactive", rather than just telling it what to do and having it "go forth". I like to think that I am taking advantage of the fact that LLMs have knowledge they've gleamed from the huge amount of text and code they are trained on. So it makes sense to want to learn from/query that a bit. LLMs, for all their faults (and the faults of the people behind them), know things. Thus, it only makes sense to want to leverage that knowledge by having them check my reasoning against their vast repository.

Nevertheless, that does not mean that their answers should be trusted by default. It does, however, make them useful as a kind of reasoning surface: I can explain what I'm thinking, ask for pushback, and then check the response against real/alternative sources.

Now, from that initial prompt, the LLM came back with a useful framing:

AI Text

I think your direction is good: split by hardware capability, not by machine.

For Boreas, the host config should basically say:

my.hardware.cpu.intel.enable = true;
my.hardware.gpu.intel.enable = true;
my.hardware.gpu.nvidia.enable = true;
my.hardware.gpu.nvidia.hybrid.enable = true;

Then the reusable modules own the messy details.

...

One caveat: this is a good milestone before a VM test for module evaluation, builds, and option shape, but a VM will not meaningfully validate NVIDIA/AMD/Intel hardware behavior. It can tell you “the config composes”; the real machine tells you “the driver stack behaves.” Still worth doing now, just don’t overestimate what the VM proves.

See how it responds like a "coworker" and not a "yes master, of course master" slave. There is also a bit of push back. I then follow up by saying

This all tracks with what I was thinking about. And yes, there will absolutely be host specific configuration not suitable for a reusable module, but that's out of scope for now as those kinds of things tend to pop up as one goes. For the reusable hardware modules, I want to give it a shot myself first, but some inspiration in the form of real-world repo examples would be helpful

I like how it feels like a conversation. I'm speaking to what the LLM has told me and suggested. I am looking for code examples I can learn from and indirectly grounding the LLM to actual factual code samples on GitHub in the process.

[!aside]
I like getting inspiration from GitHub because a lot of code lives there (it's current reputation aside). Seems like a great place to learn from others. Pre-AI I'd make good use of the search feature. Now I just describe what I'm looking for and have GitHub Copilot pull up results. It's a pretty neat practice.

The LLM then replies with

AI Text

Yep. Here are the examples I’d study.

Best Reference

nixos-hardware is the main one: common/cpu and common/gpu. What to steal:
- Intel CPU has both default.nix and cpu-only.nix; the default imports CPU + Intel GPU, but the CPU-only escape hatch exists.
- AMD CPU is tiny: it mostly sets hardware.cpu.amd.updateMicrocode.
- AMD GPU uses mkDefault for modesetting, hardware.graphics.enable, enable32Bit, and hardware.amdgpu.initrd.enable.
- Intel GPU is richer: it exposes options for i915 vs xe, compute runtime, media runtime, VAAPI driver, and kernel-version assertions.

That last point is the big architectural lesson.

Other Useful Patterns

nixos.system.gpu.maker = "amd" | "intel" | "nvidia";

...

Now, this part might sound a little hand-wavy, but the nixos-hardware it mentions piqued my interest. It sounded like something to take a look into, and so I did. What I found was something that already handles what I was trying to do. Something I could integrate rather than try to replicate, so that's what I did. I replied by saying

Or maybe I should just use nixos-hardware outright. No sense duplicating work. Or have my own integration based on it

Then from there we got around to integrating nixos-hardware. Fortunately, there is a module for the 2022 version of my host device that still holds with the 2023 version, so I could use it without any modifications. It would have been cooler/nicer if the LLM straight up told me from the start, "No bro, just use nixos-hardware". I think if it truly understood what it is I was trying to do, it would have made that suggestion. Then again, perhaps if I had asked it to suggest the best/most conventional way of going about what I wanted to do, it might have made the "nixos-hardware" suggestion more immediately.

I think this interaction is a good reminder that whatever "understanding" we think these systems have is brittle and prompt-dependent. Codex only had nixos-hardware as an answer to my query despite it being the answer to what I was trying to accomplish. It didn't and perhaps wouldn't have made the connection unless I set it up to do so. But that's fine because I was there to do that. For me, this is yet another strong case for keeping a human in the loop: the model can surface options, but someone still has to recognize which option actually fits the job.

Nevertheless, from there, we worked to port over things like cron jobs to systemd timers, handle dotfiles symlinking via home-manager, and improve the overall cohesion of the configuration, which just means consolidating and having less duplication.

Since writing this blog post I have two other branches based off this one for refinements from testing and Hyprland ricing. I plan to make PRs for those and may even write accompanying blog posts if there's anything to share.

With that, thanks for stopping by. Till next time!

NixOS, the journey continues (part 2)

2026-05-21T11:04:00.000Z

Since part 1, I have done work to configure and make configurable the GUI for my budding NixOS setup. If you're interested in the code, the PR for it can be found here. Comments and feedback welcome!

Now, getting into some detail, AI, specifically Codex, has been really valuable thus far with this project. It's been a useful collaborator in discovering config options, understanding how they work (standalone or with others), figuring out best practices, and reviewing my work. One particularly interesting application has been using GitHub Copilot to search for real-world examples of derivations that I could draw inspiration from. I mainly did this to help with writing derivations for things not available in Nixpkgs; these can be found in the pkgs directory.

It turns out that there are different strategies for writing a derivation depending on the kind of software you're looking to package. So far, I've got one for a binary program, a Go program, and a Python program. None of them look like the others. Codex was useful in ensuring I was on the right track and in offering suggestions.

Generally, being able to prompt Codex with "could you take a look at this, am I on the right track?", or "is this the best way to do this?" took a lot of frustration out of things. I think having these kinds of interactions is a great way to learn and get ramped up quickly because you aren't just letting the AI do all the work; you're pair programming with it. I, for one, believe this approach has helped me get up to speed at a much faster pace than I would have otherwise. I'm still fuzzy on a couple of things, like inherit for instance, but I have come away with a better understanding of and greater appreciation for the configurability and level of control Nix offers.

The work behind the PR also taught me a few things:

Using lib.fakeHash in place of hashes you want NixOS to correct/fill in for you. This is relevant to my project because I'm working on my setup on a Fedora system and then testing it in a VM.
Some of the different ways a derivation can be made to package software and the different options available to simplify the process based on the kind of software you want to package. For instance, with a Go program, you may want to use something like buildGoModule; for Python, you may want to reach for python3Packages.buildPythonApplication.
Derivations by default attempt to do a make build, but you can instruct them not to do that by setting the dontBuild option to true. This was useful with the rxfetch derivation since its repo already contained the binary.
You can section off configuration into modules and create interfaces to create a more focused public "API" for those configurations. See desktop.nix.
Nix supports imperative scripts using writeShellApplication. Scripts written in this way won't be run automatically but act more like shell scripts defined in a .zshrc or .bashrc file. They will be made available for you to invoke in your shell.
Not everything can or should be configured with Nix. DE settings, sure, cloning stuff from GitHub? Setting up an SSH connection with a server? Probably not, unless you wish to do so with a Nix script. My intuition for this is still nascent so I don't really have a concrete heuristic to share.
Whatever you have configured in dconf in GNOME can probably be configured in Nix
It's just like software engineering. Group and encapsulate related configurations. Expose them using abstract interfaces. The Nix language has support for defining your own options.
Nix flakes have this requirement where files/modules must be checked into Git before they are evaluated. To circumvent this, you can use the git add -N command, which signals the intent to check in a file.

From here, I plan on creating modules for integrating with NVIDIA GPUs, AMD hardware (CPU & GPU), and Intel. I think that will be the last major piece before I start testing this in my VM. Let's see how it goes. Till next time!

Part 3

Implementing Redis INFO in Haskell

2026-06-16T17:38:00.000Z

In a previous blog post, I talked about how I used Cabal's custom setup script to generate a module with build info at compile time. As mentioned in that post, the custom setup script work was but a piece of what went into implementing the INFO command for my Redis server. Let's talk about it.

As always, if you want to peruse the code, feel free to check out the accompanying PR

Ok. Implementing INFO.

The Redis INFO command was actually rather straightforward to build out, at least, relative to some of the others like SET or BGSAVE. For context, INFO is a command for retrieving data on the current state of a Redis server. Thus, its implementation can be broken down into roughly two parts:

Finding the information to be displayed
Displaying said information in the appropriate format

First, I will say that the "Finding the information" piece was definitely the more involved of the two. "Displaying the information" was far more mechanical. Once I got the overall structure for the command down – Info.hs as the central coordinator/dispatcher, with a module per INFO section handling the retrieval and formatting of its own data – things fell into place. For example, for the Server section, I have a Server.hs module specifically for defining, organizing and formatting all the data relevant to that section. Likewise for the Replication section there is Replication.hs module, and so on.

Info.hs is a command module. Command modules are responsible for:

Defining the handler for their associated command request
Defining the domain types for their associated command request
Defining how to parse their associated raw RESP request (more specifically, an intermediate representation of the raw request) into their defined domain types

I find things easier to manage when related stuff is co-located like this. For INFO, the Redis docs define its request as optionally containing one or more output section filters. There are also some special section filter keywords like all, everything, and default.

Per my testing with an official Redis server via Docker, all == everything. Perhaps there are options that make them behave differently, but I opted not to pry into that right now. If a section filter is omitted or, for some reason, they are all invalid, then default is assumed.

In Info.hs, the mkInfoCmdArg function parses an intermediate representation of the raw Redis request (a list of bulkstrings) into the appropriate domain type: InfoCmdArg.

Modeling the individual sections as a sum type was a choice. I could have gone with strings, but types made all the subsequent pattern matching easier, particularly the dispatching on line 109. Plus, there are a finite number of section keywords anyways and they probably won't be changing anytime soon, so it wasn't a big lift.

handleInfo on line 92 is the, well, handler for this command, synonymous with an API request handler in your favorite backend framework. All command modules have one. In Info.hs all it does, besides gathering the necessary information, is:

Process the parsed section filters (the actual parsing happens elsewhere using mkInfoCmdArg), which boils down to handling the special section filters I mentioned earlier. See processInfoSectionsToShow
For each section to display, generate its section string; a part of the final response. The function that handles this comes from the module for that section (e.g. genReplicationInfoSectionStr and genServerInfoSectionStr)
Put all the section strings together
Send the response

That's it.

Now, to pass the challenge step, all I actually needed was for my server to be able to handle an INFO replication request and output just the "role" field specifically. But, the go-getter I am, I figured why not take a stab at the "Server" section too. Turns out the "Server" section's got hands:

Implementing the "Server" section was an ok learning experience, but it took way longer than expected, mostly because I had to understand what its different fields were about and how their values were sourced. This meant a lot of navigating through the Redis codebase and I am not particularly well versed in C. GitHub Copilot was immensely helpful in getting me up to speed.

Some items were trivial to source once I understood what I was looking at. Also, once I got my Cabal custom script thingy working, redis_git_sha1, redis_git_dirty, and redis_build_id became straightforward as well. On the other hand, there were some items I couldn't or didn't want to spend the time trying to implement, fields like lru_clock, hz, and configured_hz. Those I just stubbed. My implementation isn't 100% faithful to the official anyways. I added comments to all the Server section fields, so feel free to check those out and perhaps point out any misconceptions I may have had.

Next up on the list was testing. I won't go into much detail on how I've set up my test harness since that's out of scope for this blog post. Though, if you're curious you can check Test.hs. I can also write something up about it if there is enough interest. In any case, what I do want to touch on are the tests for the INFO command specifically.

To start, my personal philosophy on testing is as follows

Write tests that make you confident that your system works as expected. "Works" here doesn't necessarily mean internals, though there are cases where ensuring the internals could be important. I, however, consider "works" to mean that "from the perspective of the user, the software does what it is supposed to." As in, given some input or scenario we get the expected outcome. What happens in the middle is rarely of importance. Essentially, "what happens" > "how"

For the INFO command, it seemed like snapshot/golden testing would work best to achieve what I described above. The issue, though, was that parts of the INFO response would change on each request or over time. Fields like redis_git_sha1, redis_build_id, uptime, etc… I like to let my tests run in as close to a production environment as is reasonable. I don't like to mock, but mocking here to avoid snapshot churn seemed justifiable.

Well, mocking is a bit of a misnomer, what I decided to do was mask the volatile values with a string while in a test environment, which I signal using environment variables. You can check out the snapshots in the PR to see this in action. The function that handles this is called maskFieldWhenNecessary. Pretty neat!

I think those are all the interesting bits in this PR. I've done some other things like building out RDB support, but that predated this PR-blogpost style of writing I've got going on here. Implementing that was way more involved and far more thought-provoking. If y'all would be interested in a blog post about that, let me know!

That's it. Thank you for reading. Till next time!

IO in Haskell, an epiphany

2026-05-21T11:45:00.000Z

It seems to me like IO is Haskell's way of modelling/representing the general concept of a statement (an action/impure operation, an operation with side effects that may or may not return a value). We know why statements are important. They allow our programs do useful things at the cost of non-determinism (changes to the world state tend not be consistent across invocations) and ordering (we tend to require that effects occur in a certain order).

In mainstream languages, there is often little to no effort to meaningfully distinguish between statements and expressions (at least in my experience), as a result, expressions and statements tend to be interleave-able allowing any sub-program the ability to perform arbitrary side effects. Haskell, on the other hand, seems to have taken a stance against this by making explicit the notion of a statement at the type level through the IO type (it's technically a type constructor but for the sake of explanation we'll consider it a type). This way, the implicit interleaving of statements and expressions becomes non-standard while the explicit demarcation of statements and expressions becomes enforceable by the type system.

Though, this isn't to say they can't be mixed in any way as expressions can still return a type of IO a while IO actions can also trigger the evaluation of expressions, but in standard, idiomatic Haskell, the extent of this mixing is very strictly controlled and purposefully limited though escape hatches do exist for those who know what they're doing.

With all that said, it might be accurate to consider Haskell's IO a not as a value like String, Either e a, or Int, but rather as a representation/description of an action/statement that when executed at runtime (given the current world state) yields a value of type a potentially performing side effects along the way. This perspective also aligns somewhat with how IO is defined as a state function (s -> (a, s)) under the hood

How to produce multiple executables from a stack project

2026-05-21T11:46:00.000Z

Ever wondered how to produce multiple executables from your stack project? Neither did I until I found myself unable to do so in an experiment I was playing with. I've figured it out now though, and for future reference, whenever things of this nature come up you'll probably want to look at how it's done in Cabal then extrapolate for Stack making use of the hpack repository for reference, or just use Cabal. I don't want to yet cause I'm in too deep

[!aside] Aside
It is common for you to hear executables be referred to as "targets".

Anyway, with that said, When you want to generate multiple executables from your stack project, you do so by defining additional entries under the executables stanza in your package.yaml file. The snippet below is an example. In it, we've defined two executables that our project may produce. You'll notice that the main module for each entry is under the same directory.

executables:
  initial-exe:
    main: Main.hs
    source-dirs: app
    ghc-options:
      - -threaded
      - -rtsopts
      - -with-rtsopts=-N
    dependencies:
      - package-name

  scenario1:
    main: Scenario1.hs
    source-dirs: app
    other-modules: [] # Prevents hpack from auto-discovering `main` modules listed in the other executable entry within the same directory. If we don't add this, stack will try to compile those modules while compiling the project to create this executable
    ghc-options:
      - -fprof-auto
      - -threaded
      - -rtsopts
      - -with-rtsopts=-N
    dependencies:
      - package-name

Note that in this case, the module in app/Scenario1.hs must be named Main, not Scenario1. This is because GHC expects the entry point module to be named Main and export a main function. You can work around this using the -main-is ghc-option like so

executables:
  initial-exe:
    main: Main.hs
    source-dirs: app
    ghc-options:
      - -threaded
      - -rtsopts
      - -with-rtsopts=-N
    dependencies:
      - package-name

  scenario1:
    main: Scenario1.hs
    source-dirs: app
    other-modules: [] # Prevents hpack from auto-discovering `main` modules listed in the other executable entry within the same directory. If we don't add this, stack will try to compile those modules while compiling the project to create this executable
    ghc-options:
      - -fprof-auto
      - -threaded
      - -rtsopts
      - -main-is Scenario1 # This allows us avoid needing to set the module name to `Main` in `Scenario1.hs`
      - -with-rtsopts=-N
    dependencies:
      - package-name

Personally, I prefer to give each executable its own directory. This way, there's no need to manually set the other-modules field of each executable entry to [], plus I think it allows for more modularity/greater separation of concerns; if you've got different executables, you probably have a different use case for each. Should you decide to go with this approach, you'd structure your directory like so:

.
├── app <- Holds one executable module
│   └── Main.hs
├── scenario1 <- Holds another executable module
│   └── Main.hs
└── src <- project lib

Then your package.yaml configuration ought to look something like

executables:
  initial-exe:
    main: Main.hs
    source-dirs: app
    ghc-options:
      - -threaded
      - -rtsopts
      - -with-rtsopts=-N
    dependencies:
      - package-name

  scenario1:
    main: Scenario1.hs
    source-dirs: scenario1
    ghc-options:
      - -fprof-auto
      - -threaded
      - -rtsopts
      # - -main-is Scenario1
      - -with-rtsopts=-N
    dependencies:
      - package-name

By placing the main module of each of our executables in a separate directory, we no longer need to add the other-modules: [] field to each entry since cabal (which stack uses under the hood) becomes smart enough to know that the Main.hs module in the app directory has no relation to the Scenario1.hs module in the scenario1 directory.

Now, if we wanted to execute one of these "targets", we could do

stack run scenario1 -- <options-to-pass-to-executable>

stack run will first compile, then run the resulting executable. If you don't pass an executable name, stack run will compile and run the first executable listed under your project's executables stanza.

stack run  -- <options-to-pass-to-executable>

# Synonymous with

stack run initial-exe -- <options-to-pass-to-executable>

There is also stack exec, but it will only run the executable. It does not re-compile it.

stack exec scenario1 -- <options-to-pass-to-executable>

If you wanted to just compile/build a specific target without running it, you'd need to use the stack build

stack build my-package:exe:my-executable
stack build my-package:exe:my-executable-2
stack build other-package-in-proj:exe:exe3

And there you have it, now go do stuff

Endianness, WOOT!?

2026-05-21T11:46:00.000Z

So there I was programming some binary serialization and deserialization logic to add persistence to my Redis server. I was in the zone then the docs I was referencing began to mention this "endian" thing, what the heck does that mean? I mean, I know it has something to do with how bytes are parsed but the rest of that thought was a little fuzzy ngl. It is at this point, dear reader, that I wish to inform you that I did it, for you, I fell right into the rabbit hole so you don't have to. Here's what I learned:

TLDR

Assuming the following sequence of bytes:
[0x01, 0x02, 0x03, 0x04]

Big-endian (most significant byte first):
0x01020304 = 16,909,060

Little-endian (least significant byte first):
0x04030201 = 67,305,985

Again,

Reading a 16-bit value from a file:
bytes = [0x12, 0x34]

Big-endian system interprets this as:
value = 0x1234 // 4660

Little-endian system interprets this as:
value = 0x3412 // 13330

If that doesn't suffice as a complete and holistic explanation, read on

Endianness refers to the direction/order in which computers parse/store sequences of bytes, as the order influences what ends up being interpreted from said bytes.

Note that this isn't the same thing as the bit order. AFAIU, endianness does not affect the order in which individual bits are stored and parsed. Bit order is somewhat consistent across systems but there are instances where bit order does matter namely in contexts where one finds themselves splitting bytes or doing some bit manipulation on not-so-neat chunks, which tends to be the case when working close to physical mediums/hardware. Ethernet is a good example of this. Nevertheless, with bit order it's typically alright to assume the largest binary place value as being at the leftmost position like in denary (base 10)

To better grasp the concept of endianness, it might be best to first discuss the concept of most and least significant byte. You see, one might consider that numerals (why am I calling them numerals they're numbers!?) are often made up of sub numerals, for example, in base 10 the numeral 912 is made up of the sub numerals 900, 10 and 2. Now which of this sub numerals would you say contributes the most to the whole value of 912, the 900 right? This then would be the most significant decimal numeral while the 2 would be the least significant. See where I'm going with this?

When dealing with a byte sequence, it's similar. Within said sequence there exist a byte that contributes most to the overall value represented by said sequence and there exists a byte that contributes the least. The positions of these bytes is determined by the endianness with which we parse such a sequence. If we were to use big endian, then we assume that the most significant byte is the leftmost byte similar to our decimal example. This kind of endianness feels more natural in that it allows us to parse byte sequences from left to right as we would decimal numbers. This kind of endianness is most common in network communications specifically network protocols.

On the other hand, there is little endian which is the opposite of big endian. With little endian the leftmost byte in a sequence of bytes is considered the least significant byte while the rightmost byte is considered the most significant. It is like reading decimal numbers from right to left. It's not as intuitive as big endian, but is commonly used within processors like the ubiquitous x86_64 Intel processor and most modern ARM implementations (though ARM processors can actually operate in either mode).

The notion of endianness is important because it influences how data, in this case byte sequences, are interpreted. Like our decimal example 912 is representative of a completely different quantity than 219. The former is what we get with big endian whilst the latter is what we interpret using little endian.

Now that's all well and good but why should you care about this? Frankly, I don't know but I reckon this information will in real handy when you find yourself dealing with a web protocol that communicates using a binary format or if you happen to be into systems programming in which case you probably already know all this stuff why are you here?

Nevertheless, how's that for a productive Saturday! That wasn't so bad, right? (I need to get a life…)

Dotfiles Reorg

2026-05-21T11:46:00.000Z

I did some spring-cleaning on my dotfiles. Since I am planning on moving to NixOS, I figured now was as good a time as any to renovate. I've had my current setup for a long time. It has served me well, but nothing lasts forever, I suppose.

The layout up to this point was basically an answer to the question: "what's the simplest thing I could do?".

I first opted to have all my dotfiles grouped by function and listed out at the top-level. Following that, I adopted having a .config parent directory.

It was all well and good until I got a Mac for work. I then had to scope my dotfiles by OS: one for my Mac and one for my Fedora system. I deleted the mac directory in this PR since I don't have a Mac anymore (should've done that sooner). Now I just have the remaining out-of-place top-level nixos directory that I use on my work Framework. It shouldn't be too much effort to move it over, though I'd need to give it a name.

In any case, if you took a look at the PR, you'll notice that boreas is now a top-level directory with a fedora and nixos sub-directory. This is me embracing the Nix convention of organizing configuration per-host.

[!aside]
Boreas is the name I have bestowed upon my current device, my 2023 ASUS ROG Zephyrus M16 (the product line has, unfortunately, been abandoned by ASUS AFAICT).

I will exclusively be adopting names from ancient Greek mythos for my devices.

Moving forward, each host directory will have sub-directories for each OS used or planned for it. This lends itself to dual booting too. In addition to those, there is the option for a sub-directory called common where stuff that's, well, common among at least two OS sub-directories is kept and symlinks are created between it and the relevant OS sub-directories. This way, I no longer need to copy-paste to ensure parity across OSes. I can just edit the files in common and the changes will propagate.

There's also some added cognitive benefit to having hosts as the top-level entity and OS directories as sub-directories: co-location. All the dotfiles relevant to a host are grouped together.

This co-location is what allows for the common sub-directory I just described. Doing it the other way, with the OS as the top-level entity and the hosts nested within just seemed suboptimal to me. We'd end up with configurations for a given host scattered across different directories. Nope.

One interesting thing I did with this renovation was make sure to use "relative" symlinks. That way, the symlinks are never tied to any one host filesystem. It makes them portable and independent of the structure of the filesystem outside the repository.

All in all, I'm happy with how it's all turned out and hope to get myself over to NixOS soon. Lots of things to learn. Let's see how it goes. Oh and feel free to add a comment to the PR if you've got anything to say!

Docker Compose variable interpolation...weirdness

2026-05-21T11:46:00.000Z

Maybe not weirdness but I ran into something rather strange today. It looks like variables used in interpolation don't get pulled from the env files defined under the env_file option for a service. Essentially

  db:
    image: postgres:16
    env_file:
      - path: ./backend/.env.something
        required: true
      - path: ./backend/.env.dev
        required: false
    environment:
      POSTGRES_DB=${POSTGRES_DB} # The variable for this will always be pulled from the shell env and .env specifically rather than from the env files defined as part of the service's `env_file` option
      POSTGRES_USER=${POSTGRES_USER}
    ports:
      - "5432:5432"
    volumes:
      - postgres_data:/var/lib/postgresql/data

As you can probably tell from the example, this means the variables used in interpolations won't be sourced from the service's associated env_file env file(s), but rather will always be sourced from the shell and the .env file. So you can't mix env_file and environment with interpolation in the same service definition and expect things to work properly.

Our options then seem to be:

Have separate .env files per service with no interpolation, so you'll have to copy stuff (like port numbers) and remember to update across files
Put everything in a single .env file, but prefix accordingly to avoid name-collision and allow for interpolation

[!aside] Aside
Name collisions can happen when different services have the same env var requirements, like a service for a dev db and test db. Both will accept the usual Postgres env variables. So if you're using a single .env file, you'll need prefixes to differentiate and avoid collisions

A third option might be to put the variables used in interpolations in the .env file and everything else goes into the per service env_file(s). You'll still need to watch out for name collisions and prefix accordingly

What do y'all think? Is there a better option? Since this blog of mine doesn't support comments, @ me on BluSky with your commentary instead. Link to this post too, so I know what you're talking about, heh

Be deliberate

2026-05-21T11:46:00.000Z

Reading through the backlog of James Clear's 3-2-1 newsletter and came across this:

[!quote] Quote
"Create your life rather than live it."

To me this reads simply as "be deliberate." Don't just let yourself drown in mundane routine. Let each act be, as much as possible, a step towards the life you want for yourself

This can be a difficult thing to do but as is the case with most things, starting one step at a time, little by little, can be immensely helpful. Another way to interpret this quote might be to ask yourself "what actions can I consistently take to create the life I want for myself".

Part of this is also introspection to, that is, being able to sit down with yourself and probe for what you really want out of life.