Programming Leftovers

posted by Roy Schestowitz on Apr 06, 2026

• KittenLabs ☛ Casiomania

  The first ever demoscene release by KittenLabs. Written in C, released at Revision 2026

• [Old] Scott Dubinsky ☛ S Dubinsky

  There’s a lot you can do in Linux via a GUI (graphical user interface), and if that’s how you like using a computer, more power to you. Every once in a while, though, you’re going to want to run a program that doesn’t have one, or has options you can’t access via the GUI. Generally, when you run into one of those, you’ll look around for help. The help will come in the form of advice to “run this command” followed by an arcane invocation. I’m going to teach you how to understand those invocations by teaching you the basics of the conventions used to create them.

• [Old] Luke Rissacher ☛ Optimizing Your Web App 100x is Like Adding 99 Servers

  It may sound obvious, but - optimizing your app to fulfill a request in 1/10 the time is like adding 9 servers to a cluster. Optimizing to 1/100 the time (reducing requests from say 1.5 sec to 15ms) is like adding 99 servers.

  That's a 1U server doing the work of two 42U server racks, formerly busy turning inefficient code into heat.

• Michael Stapelberg ☛ Stamp It! All Programs Must Report Their Version

  Recently, during a production incident response, I guessed the root cause of an outage correctly within less than an hour (cool!) and submitted a fix just to rule it out, only to then spend many hours fumbling in the dark because we lacked visibility into version numbers and rollouts… 😞

  This experience made me think about software versioning again, or more specifically about build info (build versioning, version stamping, however you want to call it) and version reporting. I realized that for the i3 window manager, I had solved this problem well over a decade ago, so it was really unexpected that the problem was decidedly not solved at work.

  In this article, I’ll explain how 3 simple steps (Stamp it! Plumb it! Report it!) are sufficient to save you hours of delays and stress during incident response.

• Ruslan Osipov ☛ AI, Vim, And the illusion of flow | Ruslan Osipov

  Here’s the thing most people get wrong about Vim: it isn’t about speed. It doesn’t necessarily make you faster (although it can), but what it does is keep you in the flow. It makes text editing easier — it’s nice not having to hunt down the mouse or hold an arrow key for exactly three and a half seconds. You can just delete a sentence. Or replace text inside the parentheses, or maybe swap parentheses for quotes. You’re editing without interruption, and it gives your brain space to focus on the task at hand.

• [Old] Loïc Carr ☛ Calcification of Technology

  One thing to notice when studying the history of tech or the internet is the winner takes all trend that results in slowly making tech a higher and higher tower of complexity.

  Here, I call tech calcification the observed principle that once a technology is sufficiently widespread, new capabilities of a technology are built on top of it instead of next to it. Here are a few examples: [...]

• Perl / Raku

  • Arne Sommer ☛ Max Conflict with Raku

    We get the highest possible value by placing all the 1s before the 0s. An odd number is achieved by placing a 1 at the very end. As the input number has at least 1 of them (the 1s), we can take the leftmost value and insert it at the right.

• Java/Golang

  • Vikash Patel ☛ Part 1: Data-Oriented Design in Go: Why [][]Tile Destroyed My Game Engine

    The textbook answer for a 2D grid in Go is a slice of slices. In a systems-level game engine running at 60 FPS, this innocent data structure becomes a performance landmine. This post explores pointer chasing, CPU cache lines, and how flattening a 2D map into contiguous memory creates massive performance gains through Data-Oriented Design.