Linux in 2026: AI Rules, BSD Shifts, and a Sega

A week in Linux that runs the full emotional spectrum: a kernel update that breaks AMD compute workloads at embarrassing scale, Linus Torvalds drawing a clean line through the AI discourse, FreeBSD completing a licensing migration years in the making, and a developer booting Linux on a 1994 Sega Genesis for absolutely no practical reason whatsoever. The last item is the most important thing I've read all week.

Let's start with the headline that sounds worse than it is.

The Ubuntu AMD Regression

Ubuntu announced on their forums that a kernel update in the 7.0.0-28.28 build can make certain AMD ROCm workloads up to 42 times slower. The concrete example: Stable Diffusion XL image generation on an RX 6950 XT went from around 9 seconds to 388 seconds. Michael Tunnell, covering this on This Week in Linux, puts the context bluntly — "if you see the 42 times performance loss in a headline somewhere, technically that's true. But it's a very specific use case."

The bug lives in the AMD GPU's shared memory path, where a retry loop could spin with no chance of success, stacking delay onto each failed memory operation. Ubuntu is shipping the affected update anyway because it carries critical security fixes — a genuinely uncomfortable tradeoff that Canonical, to their credit, disclosed proactively. A fix is already staged for the next update, and affected ROCm users are advised to hold their current kernel build in the meantime.

This isn't purely Ubuntu's problem. Any distribution running the affected kernel build could see this behavior; Fedora caught it and patched it before it became news. The story here is less about the bug itself and more about the communication: Canonical identified the affected user segment, explained the security rationale for moving forward, and telegraphed the fix timeline. Not every distribution handles these tradeoffs this transparently.

Linus on AI: Clear, Blunt, and Actually Useful

The more significant story this week is Torvalds stepping into the kernel mailing list debate around Sashiko — an AI agent system that reviews proposed kernel patches using LLMs. The argument had fractured into predictable camps: one side wanted maintainers to triage Sashiko's reviews before they reached patch authors; another warned that extra gatekeeping would defeat the tool's purpose; a third faction was simply opposed to AI involvement on principle.

Torvalds' response, per Tunnell: Linux is not anti-AI. AI is a useful tool. Those who strongly disagree can fork the project or walk away.

That last bit is what Tunnell memorably called "conflict resolution with the subtlety of a sledgehammer" — and he's right that clarity is underrated. The kernel already has formal rules in place for AI-assisted contributions: AI agents cannot add a Signed-off-by tag; a human must review, certify, and take full responsibility for the code; contributors should disclose the tool and model used via an Assisted-by tag (though that specific tag is under debate, as some AI companies have apparently tried to treat it as promotional real estate). The standard for merging hasn't changed: is the patch correct, properly reviewed, correctly licensed, and worth including?

The distinction Tunnell draws is worth sitting with. Vibe coding — using AI to generate code you cannot read, review, or understand — is a real problem in software at large. It is not what kernel developers are doing when they use AI assistance. Someone who has spent years working at the kernel level and uses an LLM to draft or review a patch is not trusting blindly. They're using a tool they can evaluate. Whether AI assistance improves or degrades kernel code quality at scale is still an open empirical question — but the rules now require that humans remain accountable for the answer.

Secure Boot's Quiet Certificate Expiry

Microsoft's UEFI CA 2011 certificate, used to sign Linux shims, expired June 27th. Most users won't have noticed, because UEFI doesn't refuse entry based on a certificate's printed date — it checks trust chains and revocation lists instead. Existing shims keep working.

The pressure comes from the forward path. Microsoft now signs new shims with its 2023 certificate. A machine that doesn't have that certificate enrolled could reject a future Linux installer or shim update. Distributions are already moving: AlmaLinux's current x86_64 shim carries both signatures; Debian 13.6 shipped with fwupd 2.0.20, which can update the certificate authority key exchange key and the DBX revocation list.

That DBX update also handles a secondary problem — many old, vulnerable shim versions were still trusted, meaning an attacker with boot process access could use one to bypass Secure Boot entirely. Revoking those binaries closes a long-standing gap. As Tunnell observes: "a expired certificate can remain trusted while a signed old program can be unsafe." Security infrastructure is weird.

FreeBSD Goes GPL-Free — and That's Actually About Power

FreeBSD completed its long-running goal of removing all GPL code from its base system on July 7th, when developers removed dialog, libdpv, and libfig, then retired the now-empty GNU directory. The final holdout — dialog, the terminal tool behind text boxes and progress screens — had been replaced in FreeBSD's installer by the BSD-licensed bsddialog four years ago. The cleanup was, by that point, almost ceremonial.

But "almost ceremonial" is doing a lot of work in that sentence, and it's worth pressing on what this licensing choice actually means in 2026.

The GPL requires that anyone who distributes software containing GPL code must also distribute the source under the same terms. The BSD license imposes no such requirement. You can take BSD-licensed code, modify it, ship it in a proprietary product, and never publish a line. Apple has done exactly this for decades — macOS ships a BSD userland. Embedded systems, networking hardware, and commercial appliances routinely build on BSD stacks precisely because they can do so without triggering sharing obligations.

FreeBSD completing its GPL removal is, in one reading, a philosophical statement about software freedom — the BSD community has always argued that freedom to use includes freedom to use proprietarily. In another reading, it's a practical accommodation to the economic reality that the projects most likely to adopt FreeBSD at scale are commercial entities who want no part of copyleft. Whether you think that's a feature or a bug depends entirely on your theory of how open source actually creates long-term public benefit.

What makes this interesting from a governance angle: FreeBSD is pursuing this while simultaneously investing heavily in desktop usability — targeting 8 hours of laptop battery life, modern standby support, Wi-Fi 6, a KDE installer option, better Nvidia and AMD ROCm support. It's a project trying to widen its user base at the same moment it's removing the one licensing constraint that historically pushed commercial adopters toward sharing improvements back upstream. That tension isn't resolved by removing dialog. It's just made more visible.

COSMIC 1.3 and AppManager

System76's COSMIC Desktop 1.3 arrives with frosted glass — a blurred, translucent treatment for panels, applets, menus, and supported app surfaces — adjustable from nearly transparent to nearly opaque. Tunnell took several months of work across the COSMIC stack to land, and third-party COSMIC apps will need updated libraries before they can participate. Whether COSMIC is production-ready is still contested; some reports say yes, others urge caution. The frosted glass effect, at minimum, looks like a considered design decision rather than a trend-chasing one. (The shot at Apple's "liquid glass" is entirely fair.)

AppManager is a quieter but practically significant release. AppImages have always had a portability problem that nobody officially solved: you download a file, make it executable, and then sort of lose track of it. AppManager gives AppImages a Mac-style drag-to-Applications install flow — double-click, drag the icon to the applications folder, done. It creates a desktop launcher, handles background update checks, supports zsync delta updates so you're not re-downloading entire files on each release, and — critically — uses the uruntime project rather than FUSE 2, which means AppImages work even on distributions that have migrated to FUSE 3 and dropped the older dependency. The silent failure mode of FUSE 2 AppImages on FUSE 3 systems (nothing happens, no error) has been a real paper cut for years. AppManager sidesteps it cleanly.

Sega Genesis

Developer cakehonolulu ported Linux to the Sega 32X, the 1994 add-on for the Sega Genesis/Mega Drive. The 32X contains two 23MHz SH2 processors, and the port boots Linux across both of them using software synchronization, with the original 68000 CPU handling interrupt routing. The LinuxMD project separately gets Linux running on the base Mega Drive itself, using a flash cartridge's special mapper to massively expand available RAM — the Sega Genesis shipped with 64KB of work RAM, according to Carleton University's vintage computing records, which contextualizes just how heroic that flash cartridge expansion actually is.

It's slow. It's gloriously impractical. It is also exactly the kind of project that explains why people stay in this community — the combination of deep technical knowledge and zero concern for whether any of this is a good idea.

Linux is everywhere, including places it has absolutely no business being.

Dev Kapoor covers open source software and developer communities for Buzzrag.