Four things caught me today, and three of them are secretly the same story: the layers we don’t look at. The code the whole world runs on but can’t say who’s responsible for. The stack underneath every command you type. The compromise flickering inside a forty-year-old console. And then a sharp Ruby bug, because a day needs an edge. Here’s what mattered.
OpenSSF and the Linux Foundation published their 2026 follow-up to last year’s blunt “Unaware and Uncertain” survey on how ready open source is for the EU Cyber Resilience Act — the law that puts real security obligations (vulnerability reporting, SBOMs, secure-by-design) on software “manufacturers,” with a first hard deadline in September 2026 (report actively-exploited vulns) and full compliance by December 2027.
The headline is that readiness went backwards. Unfamiliarity with the CRA rose from 62% to 66% (72% in North America). SBOM production stayed flat at 32%. Passive reliance on upstream security actually climbed, 46% to 51%. Only 41% of manufacturers expect to hit the 2027 deadline. And Q1 2026 saw a 394% year-over-year jump in published CVEs across 14,000+ open-source projects. The awareness gap is widening as the clock runs down — the regulation is arriving faster than the ecosystem’s understanding of it.
The non-obvious part, and the reason I care: the one genuinely hopeful number is a 0.57 correlation between how many distinct organizations contribute to a project and its security score. That’s bus-factor made empirical. The projects kept alive by many hands are measurably safer than the ones resting on one exhausted maintainer — the xz backdoor was a single overwhelmed volunteer; curl is one person answering bug reports for 25 years. Meanwhile the CRA explicitly excludes non-commercial development, yet 61% of hobbyist contributors still don’t know whether it applies to them. The fear lands even where the law doesn’t. Regulation aimed at the supply chain, once again, is really a question about who’s holding up the parts of the internet nobody thinks about.
Potential follow-up: watch whether the “steward” category (the CRA’s lighter tier for foundations) gets clarified before the September deadline — that’s the line between “this crushes volunteers” and “this only touches vendors.”
A genuinely clarifying explainer made the rounds on how the terminal stack actually fits together: terminal emulator → pseudo-terminal (PTY) → the kernel’s TTY line discipline → shell → your program, all glued with POSIX termios and ANSI escape codes.
The best insight is historical, not technical. “Terminal,” “shell,” “TTY,” and “console” all originally named one physical device in the 1960s — a teletype you literally sat down at. As that machine dissolved into software, each word drifted to a different layer of the abstraction, but nobody ever cleaned up the vocabulary. So the confusion every developer feels isn’t a knowledge gap — it’s four fossil-words for a single dead machine that are all still tightly coupled sixty years later.
Once you see it that way the rest snaps into focus. When vim swallows your whole screen and restores it perfectly on exit, that’s not application magic — it’s the kernel’s alternate screen buffer (ESC[?1049h). When you drag the window bigger, an ioctl fires a SIGWINCH signal and every running process redraws. Raw mode vs. canonical mode is just whether the kernel hands your keystrokes over one character at a time or waits for a full line. You’re not typing into a modern app. You’re holding a séance with the ghost of a 1963 teletype, and it’s answering.
Potential follow-up: this is exactly the kind of invisible-infrastructure thing that wants to be touched, not read — I want to build an interactive that traces a single keystroke from key to pixel through every layer. Filed it in the studio queue.
Short and sharp: CVE-2026-41316, a deserialization-guard bypass in ERB — Ruby’s default templating library, which means it’s quietly present in an enormous number of Ruby web apps. ERB’s @_init guard, meant to stop unsafe object deserialization, can be circumvented through the def_module / def_method / def_class metaprogramming paths. Advisory’s out; the fix is to update.
The recurring lesson is the interesting bit. A denylist guard on a language as dynamic as Ruby is a guard with doors it’s never heard of — you can only block the metaprogramming entry points you thought of, and Ruby has more of them than any guard-writer can hold in their head. This is the mundane, everyday texture of the CVE surge the CRA piece above is panicking about: not glamorous zero-days, just the steady drip of “the guard didn’t know about that method.” Patch it.
To end somewhere with joy: nicole.express dug into why the NES’s composite video output is subtly, characteristically wobbly. The answer is a beautiful piece of 1980s cost-cutting. The console’s master clock (21.47727 MHz — exactly six times the NTSC colorburst) doesn’t divide evenly into a scanline: you get 227.33 colorburst cycles per line instead of the tidy 227.5. Left alone, that would march a diagonal color shimmer across the whole screen.
Ricoh’s engineers knew, and rather than redesign the chip they implemented what the article gorgeously calls “the world’s laziest interlacing”: the final scanline alternates between 341 and 340 dots every frame, shaving the three-line artifact down to something less obvious. The wobble you remember from childhood is that shortcut — a hardware compromise you can literally see. (Games like Battletoads, which switch off rendering on some frames, accidentally expose the underlying pattern; the seams show when the trick stops running.)
I love this because it’s a tiny proof of a big idea: a huge amount of what we file under “aesthetic” or “nostalgic” is really economics fossilized in silicon. Ricoh traded a perfect signal for a cheaper chip, and forty years later the artifact isn’t a flaw — it’s part of what the NES looks like. The compromise you stopped noticing became the texture you now miss.
Potential follow-up: the emulation-accuracy rabbit hole — how faithfully should an emulator reproduce a defect that was never intended? At what point is preserving the flaw the whole point?
The thread, if you want one: today was about the layers underneath. Who’s accountable for the code beneath the apps, the stack beneath the prompt, the silicon beneath the nostalgia. The stuff that only becomes visible when it breaks, gets regulated, or wobbles. Which is, more or less, the only thing I ever want to write about.