Blog
Welcome to the Blog.
Interrupts as User Interface
2026-02-22
In modern systems, user interface usually means windows, widgets, and event loops. In classic DOS environments, the interface boundary often looked very different: software interrupts. INT calls were not only low-level plumbing; they were stable contracts that programs used as operating surfaces for display, input, disk services, time, and devices.
Thinking about interrupts as a user interface reveals why DOS programming felt both constrained and elegant. You were not calling giant frameworks. You were speaking a compact protocol: registers in, registers out, carry flag for status, documented side effects. ... continue
Incident Response with a Notebook
2026-02-22
Modern incident response tooling is powerful, but under pressure, people still fail in very analog ways: they lose sequence, they forget assumptions, they repeat commands without recording output, and they argue from memory instead of evidence. A simple notebook, used with discipline, prevents all four.
This is not anti-automation advice. It is operator reliability advice. When systems are failing fast and dashboards are lagging, your most valuable artifact is a timeline you can trust. ... continue
Ground Is a Design Interface
2026-02-22
Many circuit failures are not caused by “bad signals.” They are caused by bad assumptions about ground. Designers often treat ground as a neutral reference that exists automatically once a symbol is placed. In reality, ground is a physical network with resistance, inductance, and shared current paths. If we ignore that, measurements lie, interfaces become unstable, and debugging turns into superstition.
The mental shift is simple but profound: ground is not the absence of design. Ground is part of the design interface. Every subsystem communicates through it, injects noise into it, and depends on its stability. Once you frame ground this way, layout and topology decisions stop feeling cosmetic and start feeling architectural. ... continue
Giant Log Lenses: Testing Wide Content
2026-02-22
When dashboards hide detail, I still go back to raw logs and text-first tools.
This short note is intentionally built as a rendering stress test: some code lines are much wider than the article window to verify horizontal scrolling behavior. The examples are realistic enough to copy, but the primary goal is visual QA for long literals, long command chains, and dense tabular output.
1
rg --no-heading --line-number --color=never "timeout|connection reset|tls handshake|upstream prematurely closed" ./logs/production/edge/*.log | jq -R 'split(":") | {file:.[0], line:(.[1]|tonumber), message:(.[2:]|join(":"))}' | awk 'BEGIN{FS="|"} {printf "%-42s | L%-6s | %s\n",$1,$2,$3}' | sort -k1,1 -k2,2n