Hugo has a really way of hooking into the rendering process that I’m using to automatically generate scaled down thumbnails of referenced images. I structure each blog post as a page bundle and render images via ![](image-name.jpg) in the markdown files. By default, hugo will render an image tag with the full sized image which can be rather heavy if it’s a large image. So instead, I set up a render hook for images in layouts/_markup/render-image.html:

In an effort to understand Postgres better I’ve worked my way through how a Postgres database is structured and executes queries.

Process Model

Postgres uses a process-per-worker model. That means every connection is handled by a separate operating system process forked off the initial process.

Subsystem Overview

Postgres consists of several components that all work together to process data and ensure it’s reliably written and can be looked up efficiently. The following are the most important components, but there more, other components that are beyond the scope of this post.

Let me tell you how I was an idiot, ignored best practices, and luckily didn’t lose anything of value. And yes, this is a story about backups.

In my homelab I now have a few machines that run NixOS. This came to be because I wanted the ability to quickly rebuild machines from scratch without having to fiddle with individual settings. Thanks to NixOS I now have a repository that holds a flake that can build bootable images and perform remote nixos-rebuild switch.

It’s this time of the year again. I’ve recently set up this little page, and I really didn’t want it to be on Github or hosted by Github Pages.

In my homelab I run many different single board computers, among them Odroid M1s. However, there’s various versions of Raspbian, Armbian, and Debian, each of them using some custom tweaks. And that’s a lot of time to maintain them. So I really like the idea of NixOS and read that it can be used to build bootable images for computers. I haven’t fully built intuition for all parts in this so it took me a while to get this working. Here’s my notes.

I enjoy reading books. I very much enjoy reading printed books, but they’re heavy, you can’t read them in the dark, and unlike my phone or ereader, I don’t have them on me all the time. So, I read a lot of ebooks. And with most ereaders, reading novels is fine, at least if you read reflowable document types like epubs. But as soon as you start reading PDFs, all bets are off. At least, until I discovered KOReader

I’m hacking on a small Zig application with a GTK frontend, and part of using GTK is passing around ?*anyopaque pointers and you never quite know if it’s working. In my app I’m passing around a struct that holds a string []const u8 to various GTK callbacks. However the string was empty. This led me down a rabbit hole of trying to figure out if my pointers were correctly passed, even going as far as stepping through it with a debugger. Turns out, the pointers are all correct. Even my string []const u8 was there with the correct length, except every single byte was set to 170 and I realized I was looking at undefined memory. Zig in debug mode sets undefined memory to 0xaa which is 170.

Recently I’ve been working on updating my blog a bit (you might have noticed?). I keep the hugo sources in a git repository and the built site in a separate repository. That repository is added as a submodule to the sources repo and during the build, the generated HTML is written into the submodule. Except the submodule kept getting messed up; git would be unable to track the changes or they’d be added to the parent repository. It was truly maddening, but as it is so often, the problem was not git but me.

Zig’s package manager is still a bit rough. It only supports fetching tarballs, but many github projects don’t have them unless they have a release. There’s a trick to fetch any commit as a tarball though: