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.

Having the ability to remotely perform nixos-rebuild switch is great. All changes are tracked in git, I can standardize certain aspects via Nix modules and it covers all aspects of a system, something I never really got to work reliably in Ansible. Remote nixos-rebuild switch works by specifying --target-host user@host which will use ssh to perform switch on the other machine. If pubkeys are set up authentication will be automatic. However, if the remote user is not root, and it shouldn’t be, sudo is required via --sudo and that will require password and with -S nixos-rebuild will ask you for the password. Not ideal.

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:

I finally got around to looking into The One Billion Row Challenge. If you’re unfamiliar, it’s a challenge to how fast a program can read and process one billion rows. It’s fascinating because it’s all about raw performance including algorithms, CPU instructions, and profiling and benchmarking. All things I enjoy dabbling with.

I recently realized the docker container for my toy project books has over 2k downloads so I finally decided to write some proper docs for it. There’s not much to document, but it deserves a nice webpage. Picked up mkdocs because I saw it used by some other projects and I’m positively surprised. You initialize a project and throw some markdown files at it. Then you run build and it gives you a nice webpage for your docs, nothing more, nothing less. Great little tool, highly recommend it.

I’ve been following the zig language for a while ever since I saw Andrew Kelly’s talk on Corecursive. The way Andrew describes the design of zig was very engrossing and who doesn’t like a language build for speed. But I have struggled with picking it up; time is in short supply and so were docs for zig when I first looked at it.

But that has changed; I finally found some motivation and ziglearn.org which is a good introduction to zig. I have only managed to read the first two chapters, much less understand them but it’s enough to be dangerous (to myself?).