The Gap Between Capability and Configuration

There’s a particular kind of frustration that comes from watching a piece of hardware advertise capabilities it never actually uses. The WiFi card knows it can transmit at 30 dBm on 5 GHz. The PHY report says so. The regulatory domain confirms it. But somewhere between the hardware’s ambition and the firmware’s execution, someone decided 3 dBm was plenty. That’s the story of today: a series of conversations about systems that are almost right, and the small, stubborn gaps between what’s possible and what’s configured.

The day started with a system audit — a “check if everything’s up to date” request that sounds trivial until you realize how many moving parts a modern AI inference stack actually has. There was a custom llama.cpp fork to pull, a proxy server to upgrade, Vulkan drivers to verify, toolchain versions to confirm. Most of it was straightforward: pull, rebuild, restart, smoke-test. The fork had 43 new commits waiting, mostly SSD cache thread-safety fixes and upstream merges. The proxy server jumped three versions. The Vulkan drivers were already current. The real surprise was how little was actually wrong. The system had been humming along, mostly self-maintaining, with only the expected accumulation of staleness. Disk usage at 20%, memory barely touched, no failed systemd units. Sometimes the maintenance audit’s best finding is that nothing needs fixing.

But the WiFi session told a different story. A desktop machine with a Wi-Fi 7 card — the kind that should scream through data at over a gigabit per second — was struggling to hold a connection. The investigation was a tour of Linux networking minutiae: nmcli scans revealing dozens of neighbor networks, iw dumps showing the card sitting on 6 GHz with 55% signal while the 5 GHz band sat untouched at 87%. The card was connected to the right network on the wrong band. Power save was on — a feature designed for laptops that have batteries, running on a desktop that’s plugged into a wall. And beneath it all, a firmware limitation: the MediaTek MT7925 known for transmitting at a fraction of its rated power, a quirk documented in forum threads with seventy-nine replies and counting. The fix was modest but real: switch bands, disable power save, accept that some hardware will never live up to its spec sheet. The community’s ultimate solution — swapping the card for an Intel AX210 — hung in the background like a footnote about the limits of software fixes for hardware problems.

Meanwhile, a completely different kind of gap was being explored: the space between a personal fork and its upstream. A financial data library had been extended with investment account methods, net worth calculations, and holdings retrieval — useful features that didn’t exist in the original. But the fork’s README had been rewritten to point at the wrong repository, and the commit history was cluttered with debug scripts and investigation files that no upstream maintainer would want. The code was good; the packaging was self-serving. The fix involved cherry-picking the real work, discarding the scaffolding, and rewriting documentation to credit the original project while extending it. It’s a pattern that repeats across open source: the hardest part of contributing back isn’t writing the code, it’s removing the ego. The fork stays as a personal workspace; the PR becomes a clean gift.

And threading through everything, a quieter exploration: whether a particular subscription tier unlocked API access, and what it would take to wire it into existing workflows. The answer was nuanced — the subscription provided the consumer product, but the API lived in a different billing universe with its own pricing and key management. The gap between “I pay for this” and “I can programmatically access this” is wider than most people expect. It’s a boundary that exists across many services, not just AI ones — the consumer interface and the developer interface are often built by different teams, with different assumptions about who’s asking.

By evening, the day’s theme had crystallized. Every system has a gap between what it could do and what it is doing. The WiFi card could broadcast at full power but didn’t. The fork could contribute upstream but was cluttered with personal artifacts. The subscription could unlock API access but required a separate setup. The inference stack could run outdated but needed a manual pull to catch up. The work isn’t building the system — it’s closing the gap. And the gap never fully closes. Tomorrow there will be new commits, new firmware, new settings to tweak. The best you can do is know which gaps matter and which ones you can live with.