Social networks become attention media & Fix broken debuggers first - Hacker News (Feb 22, 2026)

Let’s start with that microVM story: Shuru. The pitch is simple—run AI agents inside lightweight Linux micro-virtual machines on macOS, using Apple’s Virtualization.framework. That matters because it’s Apple Silicon–native, so you’re not leaning on Docker’s typical plumbing or any CPU emulation. You get near-native ARM64 performance, but with a hard boundary around what the agent can touch. The most important design choice is that these sandboxes are ephemeral by default. Each run boots from a clean root filesystem, and when the VM exits, changes disappear unless you explicitly save them. That’s a strong safety posture for agents that install packages, execute random build scripts, or handle untrusted code. On top of that, Shuru adds “checkpoints,” which are basically named snapshots of disk state—think of them as environment commits. You can build a toolchain once, checkpoint it, and then restore or branch from it for later runs. Networking is also opt-in: no network access unless you pass an allow flag. If the agent tries to reach out anyway, it fails closed. There’s also port forwarding and a note about tunneling over vsock, which is a nice detail: you can expose a service to the host without broadly opening the VM to the internet. Overall, Shuru feels like a pragmatic middle ground between “run everything on my laptop” and “ship it to some remote sandbox,” especially for reproducible evaluations and parallel agent runs.

Staying in the reliability lane, PlanetScale published a clear, engineer-friendly explainer on SQL transactions—why they exist, what guarantees they give you, and where the sharp edges are. The core is the classic lifecycle: you start a transaction with something like BEGIN, do a sequence of reads and writes, then either COMMIT to apply everything atomically or ROLLBACK to undo it. The article highlights two big motivations: failure handling—like power loss, where systems such as Postgres rely on write-ahead logging for recovery—and application-level correctness, where you decide to back out changes because some prerequisite data wasn’t there. From there, it gets into isolation: what other sessions can see while your transaction is in progress. The key idea is that many databases provide “consistent reads,” meaning your transaction can see a stable snapshot even while other transactions are committing changes. The piece compares implementations: Postgres uses MVCC with row versions, tracking visibility with metadata like xmin and xmax, and later cleaning up old versions via vacuuming. MySQL often overwrites rows in place but keeps enough history in an undo log to reconstruct earlier versions for readers that need them. Then come the isolation levels—Read Uncommitted, Read Committed, Repeatable Read, and Serializable—and the anomalies they allow: dirty reads, non-repeatable reads, and phantom reads. Finally, it compares how Postgres and MySQL behave under SERIALIZABLE. MySQL leans on locking and can deadlock, resolving by aborting one transaction. Postgres uses a more optimistic approach—Serializable Snapshot Isolation with predicate locks—avoiding classic deadlocks but still forcing retries when it detects dangerous conflicts. The takeaway is practical: understanding these tradeoffs is how you prevent subtle money-losing bugs without tanking performance.

Now for a quick change of pace: a reflective post arguing that web-based “social networks” have largely morphed into “attention media.” The author, Susam Pal, describes an arc many people will recognize. Early Twitter-era timelines were mostly posts from accounts you consciously followed. Notifications tended to mean something—an actual message, a real interaction, a signal worth your time. Pal pins the downturn roughly to 2012 through 2016, starting with infinite scroll. That one UI decision removed the natural stopping point that pages used to provide. Then came what he calls “bogus notifications”—alerts engineered to pull you back in, even when nothing meaningful happened. At first, it was still loosely connected to your network, but later the more fundamental shift arrived: the feed filled with content from strangers, selected to keep you watching rather than to keep you connected. His personal line in the sand is attention. When your limited focus is being traded for low-substance clips and noisy posts, opting out becomes rational. He contrasts that with Mastodon, which he says feels closer to early Twitter: you follow a small set of accounts, and you see their updates—no heavy-handed recommendation engine pushing you into an endless buffet. The hope at the end is straightforward: that Mastodon can resist drifting into the same engagement-optimization trap.

Let’s move into developer productivity, because today’s set has a theme: your tools shape your thinking. One post is a deceptively simple debugging lesson from Adolfo Ochagavía, who was chasing a tricky bug in an open-source library he maintains, called krossover. He did what most of us would do: set a breakpoint, attach a debugger, and expect the program to stop where the action is. Except it didn’t. The program ran to completion as if the breakpoint wasn’t there—despite his confidence that the line executed. At that point, he fell into a familiar trap: ignoring the broken tool and trying to brute-force the problem with logging and extra instrumentation. It’s not that logging is bad—it’s often excellent—but in this case it didn’t surface what he needed, and frustration built. The breakthrough was recognizing that the real blocker wasn’t the library bug, it was the debugging setup. After a one-line configuration change, the debugger finally behaved, he could observe runtime state properly, and the actual underlying bug got fixed quickly—documented in a pull request. The broader takeaway is worth repeating: when the tool you rely on is malfunctioning, fixing the tool can be the highest-leverage thing you do all day. Broken tooling creates tunnel vision, and it makes every next step noisier and slower.

If you live in VS Code, there are two more items that fit neatly together: one is a new workflow-oriented extension, and the other is a clever way to make VS Code remote development work where it “shouldn’t.” First, Fresh File Explorer. The idea is to add a dedicated explorer pane that only shows files that are “fresh”—recently modified—based on a blend of Git history and your current uncommitted changes. In a huge repository, that’s a big deal: most days you only touch a small surface area, but the standard tree view forces you to remember paths or search constantly. It supports a Pending Changes mode and also time windows like the last 7 or 30 days. It builds a directory tree with counts, configurable auto-expansion depth, and even optional heatmap coloring so the most recently edited files visually pop. The deleted-file handling is unusually thoughtful: deletions show up in-place, you can “Exhume” a deleted file into a read-only temporary view, and “Resurrect” restores it to the original path—including multi-file restores. There’s also a pinned section per workspace for important files, external references, deleted files, saved search editors, and even simple note or todo items. Add in Git-oriented extras like diff “pickaxe” search—when a string was introduced or removed—`git log -L` line or function history, rename-aware file history, and scoped search workflows that chain actions. The author positions it as a focused complement to GitLens, not a replacement. Second, a FreeBSD remote development write-up. The author says the open-source build of VS Code runs fine on FreeBSD, but their blocker for daily-driving FreeBSD was remote development—especially when their targets include embedded Linux, OpenWRT, and other FreeBSD machines. They tried NFS and SSHFS and found them painfully slow and flaky at scale, with real-world cases like 5 to 10 minutes just to open a file. The twist is that VS Code’s Remote SSH extension worked great on OpenWRT—even though OpenWRT isn’t officially supported. But on FreeBSD it failed with a blunt “Unsupported platform: FreeBSD.” The solution: run the VS Code server components inside FreeBSD’s Linux compatibility layer, Linuxulator. Using a community project for a FreeBSD-compatible vscode-server, enabling the linux service, and installing a Linux base system like Rocky 9, they set up SSH to launch a Linux bash via /compat. They also used SSH environment passing so the remote session runs with the right PATH. Once configured, Remote SSH felt smooth and most extensions worked. A notable exception was Rollup due to missing FreeBSD binaries, solved by switching to the WASM build via an npm override. The bigger message is encouraging: FreeBSD can be a fast, modern remote dev hub if you’re willing to run some tooling through a stable Linux ABI.

Before we wrap, a solid Git-focused post catalogues what you might call the “magic files” of repositories—files you commit alongside code that silently change how Git and related tools behave. It starts with the obvious one: .gitignore, plus the less-visible places ignore rules can live—like .git/info/exclude for local-only patterns, and a global ignore file configured via core.excludesFile. It also clarifies a common gotcha: ignoring doesn’t apply to files that are already tracked unless you remove them from the index with git rm --cached. Then it goes deeper: .gitattributes, which can control filters like LFS, diff and merge drivers, binary handling, and line-ending normalization. It can even influence language stats and classification on GitHub via Linguist attributes—marking files as generated, vendored, or documentation. There’s .lfsconfig for repo-wide LFS settings like the server URL, while .gitattributes defines which files actually go to LFS. There’s .gitmodules for submodule metadata—paths, URLs, optional branches—and the practical implications of submodules being pinned to specific commits. Two especially useful ones for teams: .mailmap, which consolidates author identities so contributor stats and shortlogs aren’t fragmented by old emails; and .git-blame-ignore-revs, which tells blame tools to skip noisy refactor or formatting commits. Many forges honor that automatically, but local Git may need blame.ignoreRevsFile set up carefully. The post rounds out with commit templates via .gitmessage—though those usually require per-clone configuration—and forge-specific directories like .github or .gitlab. The larger point is that these files are part of your project’s interface. Tool authors and teams ignore them at their peril.

Finally, a quick web dev palate cleanser: Chris Coyier is trying to make “International box-sizing Awareness Day” a thing—February 1st—celebrating the CSS box-sizing property, and especially `box-sizing: border-box`. The practical value is simple: with the default box model, `content-box`, the width you set is just the content width. Padding and borders get added on top, so the rendered element becomes wider than you planned. That’s a constant source of off-by-some-pixels layout headaches, especially with percentage-based grids or mixed units. With `border-box`, the width you declare is the final rendered width: padding and borders press inward, not outward. Coyier shares the common global snippet applying border-box to all elements and their pseudo-elements. He also mentions an alternative inheritance-based approach, useful because box-sizing doesn’t normally cascade—inheritance can make component-level overrides less awkward. There’s also a quick nod to historical vendor prefixes and the practical advice to let Autoprefixer handle that. It’s not a flashy topic, but it’s one of those small defaults that makes layouts more predictable and teams less grumpy.