About

Why this site exists.

Terminal Stupidity is a working archive, not a résumé. I am a systems programmer working out of the Pacific Northwest, and for several years I have been accumulating small command-line programs — some deliberate, some accidental, some written in a fugue state at 2am to answer a question I could no longer avoid. This site is where I keep the ones I do not want to lose.

The name is sincere. Many of these tools are stupid in the technical sense: they solve a problem in a way that is obvious, direct, and unembarrassed by how the problem is normally solved. A shell script with a histogram loop. A profiler that refuses to draw a flame graph. A disassembler you point at a stream. Most of the good tools I have ever used were like this, and most of the bad ones were not.

How I work

I build small programs that do one thing, run on any Unix I can reach, and avoid dependencies that outnumber the source files. I prefer C99, Rust stable, and POSIX sh, in that order, and I will write Python when Python is what the problem is asking for. I read the manual page before I write the program, and I write a manual page before I publish the program. Every tool on this site has a roff-formatted man page checked in next to the Makefile; this is a discipline, not a flex.

I do not ship telemetry. I do not require accounts. I do not assume a terminal wider than 80 columns unless it pleases the output to assume otherwise. None of these are ideological positions; they are consequences of having been on the receiving end of tools that made the opposite assumptions.

The bench

Physically: a FreeBSD workstation (gen-3 Threadripper, bought used), a Linux laptop running Debian stable, a NetBSD mips box I keep alive mostly out of spite, and a small pile of SBCs for when the program has to run on something nobody patches. Everything on this site is verified to build on the first three. The SBCs exist to catch the programs that secretly assume a 64-bit long.

Editorially: plain text. I keep each project in a single directory with a src/, a man/, a NOTES file, and a Makefile. When a project grows a second directory, I start asking it uncomfortable questions.

Background

Before this, fifteen years of infrastructure work at various scales — a trading firm that preferred not to be named even internally, a storage startup that was acquired and then largely dismantled, two stints in research labs where the computers were interesting and the politics were worse. The through-line is always the same: small sharp tools, written close to the problem.

I have maintained sift since 2021 and pingprint since 2019. I have written and then abandoned roughly twice as many tools as are listed in the gallery. The ones that got abandoned were abandoned for cause.

Engagements

I take on a narrow band of consulting work, almost always through someone I have already worked with. The sweet spot is: "we have a weird performance problem in a system that has been running for five years and nobody currently on the team wrote the original version." I have also done a fair amount of expert witness and technical diligence work, which I enjoy more than I expected to.

New engagements are considered by introduction only. If you arrived here without one, the Notes page is probably what you want — most of what I would say in a first meeting is already written down there, and some of what I would say that I shouldn't is in Broken by design.

What this site is not

It is not a tutorial site. It is not a comprehensive log of everything I have ever written. It is not kept current to the day; I update it when I update it. There is no RSS feed because I do not want to commit to that cadence, and no mailing list because I do not want to be responsible for your inbox.