I have been using cgit1 for the web frontend at git.0x1b.me ever since I started self-hosting my own git repos. It’s a great project, and, as someone who -is- used to be quite comfortable with nginx, easy to setup. My only complaint is that it has been difficult to debug, which probably wouldn’t be true if I ever bothered to compile it myself. Otherwise, it’s difficult to troubleshoot changes in the config settings when I try to make changes that I am no doubt getting wrong.

The Zig Build System1 can be used even for projects without a single line of Zig code. I am far from an expert in complex build systems, having mostly used language tooling or contributing to projects that already chose a tool such as GNU autotools. I probably can’t do a better job of explaining the general motivation for introducing Zig than Loris Cro2 or Andrew Kelley3. In my specific case, I’m working on a tool for building Linux disk images and booting them in virtial machines using QEMU4.

I want to run my own network gear. I suppose that’s just because my day job is writing network software for Linux, and I feel like I should be able to do it. I’m not great at hardware, but I know a decent bit about using Linux networking, for moving packets around. And it shouldn’t be much harder than iproute2 and nftables, right? I don’t care too much about speed; I remember dial-up and live in a household of two.

I have three computers on my desk: a Lenovo M710q Tiny, a Rock Pro 64, and a Dell XPS laptop. They all run Linux (of course). But I only have a single keyboard and mouse to share between them, so I plug the peripherals into whichever machine I’m using at the time. I’d really like to have a button to push that switches which machine they are wired to. The common solution to this is a USB switch or KVM.

I have been tinkering with Zig for awhile now, and so far been in the habit of simply copying code around between projects as I need to reuse it. Now I know what a library is, but I also tend to err on the side of code duplication over building the wrong abstraction. In practical terms, I find that I often write a better library if I first copy code around, edit it to each project’s needs, and eventually design the library code that fits all my uses.