I tend to follow things further than I probably need to.

When I wanted to understand how htop gets its CPU numbers, I didn’t stop at the answer — I kept going until I learned that /proc isn’t a real filesystem, that the kernel generates its contents on the spot from live memory, that the whole thing is an illusion the kernel maintains so that programs have something familiar to read. That probably wasn’t necessary. But once I started pulling on that thread, I couldn’t leave it alone.

That’s roughly how most of what I do gets started.

I work in Linux, close to the hardware. Not because I think it makes the work I do more serious, but because I find what’s down there genuinely interesting. The kernel is full of things nobody told me about — tc netem, which has been able to simulate a ’terrible network’ since the early 2000s and ships on virtually every Linux system. This tool enables network engineers to create programs that can compensate for that common condition where a user has an unreliable or intermittent internet connection. Another tool is PSI, which measures not how busy a machine is but how often tasks are actually stuck waiting; and another - the /proc/net files that expose every open socket in fixed-width hex if you know how to read them. I stumble across these things and can’t help writing about them.

The tools I’ve built come out of the same curiosity. newtop started because I wanted a system monitor I could fully read and understand — four Go files, nothing external, every number on screen tracing back to a specific /proc or /sys read. netsock came from wanting to answer one question at a glance: what’s listening on this machine, and how exposed is it? stall came from noticing that CPU% was hiding something — a machine can sit at 30% utilization while tasks are quietly grinding, blocked on IO, and you’d never know unless you looked at the pressure stall numbers. core-probe came from collecting old Linux machines and wanting a fast, honest answer about whether they were worth reviving.

I don’t think of these as products, exactly. They’re more like notes I write down in a form that runs.

I experimented with running small language models locally for a while — CPU-only, bare metal, no GPU. That constraint forced me to learn things I wouldn’t have otherwise. Compiling llama.cpp from source with -march=native instead of using a prebuilt binary, like ollama, lmstudio or jan.ai - not because those aren’t good runners, but because without them I got measurably faster inference - not by upgrading hardware but simply by removing a layer.

The limitations of SLMs led me to abandon experimenting with them, but led me somewhere I didn’t expect: testing the ‘famous’ online models: ChatGPT, Gemini, KIMI, Qwen and others. I started with a simple question — what happens if I give a model a logic puzzle with a contradiction built in? — this ended up leading me into a rabbit hole I’m still in. The results truly surprised me. Some models will smooth over the contradiction to produce a confident answer. Others catch it and refuse. A few catch it and then answer anyway, which is its own kind of interesting. I don’t think I’m the first person to notice any of this, but working it out myself, from scratch, with my own puzzles and prompts, taught me something that reading about it wouldn’t have.

The distinction I kept coming back to — solver vs. judge, helpful vs. truthful — isn’t really about which models are better. It’s about knowing which mode a model is in before you trust it with something that requires precision. That feels like a practically useful thing to understand.

I also spent some time on a question that seemed almost too obvious to bother with: is an AI model actually software? The answer I arrived at — that a model file is data, not software; that it becomes part of a software system only when an inference engine interprets it. This isn’t conclusive, but working through it at the level of how a systems programmer would define software was useful for me and brought out another perspective in how to regard LLMs. It helped clarify where correctness responsibility actually rests, and that’s not a trivial question.

I’m an advocate for the Linux OS, for FOSS and the Right to Repair movement. As a technician who loves machines, I cannot stand to see unnecessary e-waste - ie - perfectly capable machines that end up in landfills just because the proprietary OS on them is no longer supported. I’ve been making a case, quietly and probably to a small audience, that software ought to respect the hardware that already exists. There are literally billions of devices in the world right now with a Windows OS that has expired, that would thrive with a Linux OS installed on them.

I run only Linux - CrunchBang++ with the Openbox window manager on my HP i7 PC - hardware that could easily run a full desktop environment. That’s a choice — to not use a desktop environment. I prefer having my CPU cycles available for the tasks I’m using the system for.

So, these two philosophies come together as one for me. Software that runs well on constrained hardware tends to run better everywhere. And I want people to resurrect those millions of capable machines already extant in our world, that have been declared obsolete by company policy (Microsoft) rather than any failure of their physics. I find this idea worth saying out loud, even if most people using and building software aren’t particularly interested in hearing it.

I’m learning Go, and I’ve tried to put together methods of teaching it to myself in the way I want to learn it — starting with a working program, not a syntax drill. The idea is that you understand what a language is for by seeing it do something real, not by watching it print variables to a terminal. I don’t know if that approach is right for everyone, but it’s the one that works and makes sense to me.

I’m curious about a lot of things. I make connections between them without ever trying. Most of what ends up here is just me following something further than I needed to, and writing down what I found.

Ben Santora - March 2026