Development and Coding Leftovers

posted by Roy Schestowitz on May 17, 2026

• Martin Chang ☛ Releasing Kiln - A CMake-compatible build system that can do what CMake can't

  The entire reason for having a build system is having compilers is not enough. You need an automated way to tell the compiler how to build your project. Most of us doing C and C++, when we started out have a programming homework scaled beyond a single file and needed a way to automatically compile and link multiple source files together. Usually we end up writing a shell script to automate the process. However, that has downsides that's obvious, it always compiles even if you didn't edit the source code, linking to external libraries is a major pain, etc, etc.. Most of the time people graduate to using Makefiles to avoid unnecessary compiles and switches to Linux so the package manager handles external package. And eventually switches to CMake to not think about the actual compilation process and be more declarative. "here's the source code and I want you think to this and that. Compile!" basically.

• University of Toronto ☛ Getting C code navigation even for Debian (or Ubuntu) packages

  Every so often, I want (or need) to make modifications to programs in an Ubuntu package, and often the programs are written in C (and these days I'm using dgit to manipulate the package). One of my challenges when I do this is that I generally don't start out knowing where and how to change the code to do what I want; instead, I have to navigate around an unfamiliar code base and work out enough of its structure to find the specific bit of code I need to change.

• Billjings ☛ Git Is Not Fine

  But you probably won’t if you think git is fine. And that’s unfortunate, because git is not fine.

  See, Git does two jobs: it’s a distributed store for source, and it’s a distributed workflow tool. It knocked the first job out of the park so far that most of us fail to see that its solutions for the second job were mostly an afterthought. And if you actually work in a meaningfully distributed way (and whether you know it or not, you do — across time, with yourself or others) then whether you know it or not you are feeling the pain. Because, like East River Source Control says, async development is table stakes.

• [Old] Efron Licht ☛ Starting Systems Programming, Pt 1: Programmers Write Programs

  This is the first of four articles on the fundamentals of systems programming. It will cover many of the essentials, such as bit manipulation, parsing, filesystems, input/output, syscalls, memory management, and signals. Like many of my article series, this is more of a grab bag than a comprehensive guide - but I hope it will be useful to you.

• [Old] Efron Licht ☛ 1. Starting Systems Programming: Part 2: Your program and the outside world: syscalls & files

  This is the second of four articles on the fundamentals of systems programming. In part 1, we wrote a bunch of programs to act as a toolset to investigate binary files, finishing with an overview of the ELF (Executable and Linkable Format) file format that defines executable binaries on linux systems. In this article, we’ll start diving in to how programs interact with the outside world. We’ll answer questions like: [...]

• Efron Licht ☛ Starting Systems 3: **Execution Counts**: Software Performance & Optimization

  Computers are physical machines that consume resources to create and operate. Using as few resources to create outputs from inputs as possible is what separates a real systems programmer from the dilettante. This is my third article on the fundamentals of systems programming and the first about the subject nearest and dearest to my heart: software performance. It can be read on it’s own and I’ll try not to make too many references to previous material.

  Software is a tool to produce output from input. More efficient, “high-performance” software produces that output cheaper, faster, or more reliably, with the minimum input possible. Doing so is easier said than done, but we can split the study of software performance into three parts: knowing your performance and finding bottlenecks (measurement), designing a system without any critical performance mistakes (architecture), and fixing the problems you can (optimization). We’ll cover all three, roughly in that order.

• Perl / Raku

  • Perl ☛ Installing Bit::Vector on Debian 13 (Trixie)

    The issue stems from modern Linux distributions upgrading their default compiler (like GCC 15+) to use the C23 (ISO C 2023) standard. In C23, false and true became official, reserved language keywords[cite: 2]. Because Bit::Vector is an older module, its internal ToolBox.h file explicitly tries to define them inside an enum block for legacy compatibility, which modern C23 compliance strictly forbids[cite: 2].

    A solution that worked was: [...]