Diff — The Hat Tips Both Ways

{{infobox

| title = The Hat Tips Both Ways

| subject = Controversies surrounding [[Fedora 45]]

| flashpoints = KMSCON console · accessibility · i686 reprieve · x86-64-v3 rejection

| status = Live debate — release expected 27 October 2026

}}

{{date|2026-10-16}}

Fedora 45's feature list reads like a renovation plan — new console, new desktop, verifiable packages, a panic screen with manners. But look at the change proposals closely and a pattern emerges: **nearly every headline feature is somebody else's deprecation.** This article collects the three fights that shaped F45 before it shipped — the console, the users it leaves behind, and the two-front war over what x86 even means anymore.

## The console that needs a working system

The pitch for **KMSCON** is honest and mostly correct: `fbcon`, the kernel's built-in text console, is unmaintained, lost scrolling to a CVE, can't resize fonts on HiDPI screens, and every crash inside it is a kernel panic. A userspace console gets you real Unicode, your desktop keyboard layout, scrollback, and fonts that don't look like they were rendered in 1994.[[cite: Fedora Change Proposal: UseKmsconVTConsole — SystemWide, F45]]

The counterargument writes itself in the word "userspace." The virtual console is the debugging surface of *last resort* — the thing you fall back to when the system is already broken. A console that needs libdrm, mesa, and DRM master negotiation is a console that can join the outage instead of reporting it. Testers surfaced the rough edges quickly: `kmscon-launch-gui` scripts that fail to start graphical sessions, `tty` now reporting `/dev/pts/N` instead of `/dev/tty1` — quietly breaking any script that checked — no sixel graphics, and no clean path for the niche that launched SDL apps and games straight off the console.[[cite: Lobsters thread on Changes/UseKmsconVTConsole; Fedora Discussion "Modernizing the console with kmscon"]]

Fedora's answer is a fallback: kmscon fails → getty/fbcon. Which is reasonable — until you read the same proposal's stated long-term goal: **deprecating fbcon/fbdev emulation in the kernel entirely**. The fallback is a bridge scheduled for demolition.[[cite: Changes/UseKmsconVTConsole — "the long term goal is also to deprecate fbcon/fbdev emulation"]]

## "Just use fbcon" — while planning to delete fbcon

The sharpest version of that problem isn't script breakage — it's people. Linux's blind users navigate the console through **speakup** and **BRLTTY**, and both bind to the kernel console that KMSCON replaces. Raised in the Fedora discussion thread, the response amounted to: they can keep using fbcon.[[cite: Fedora Discussion — UseKmsconVTConsole thread, accessibility concern raised re: speakup]]

That answer has a shelf life. fbcon is the thing the proposal wants gone. When it goes, the accessibility story becomes "wait for a screen reader to be rebuilt inside kmscon" — a promise, not a plan. To be fair to the engineers: console accessibility at the kernel level has been frozen since the 1990s, and *somebody* eventually has to rebuild it. But "eventually" is doing a lot of work in that sentence, and the users who depend on the oldest interface in the stack are being asked to absorb the risk on faith.[[cite: Lobsters discussion — "Is there any tooling for that?… they just say to keep using fbcon/getty"]]

## The x86 two-front war

And then there's the fight Fedora is having in *both directions at once*.

In one trench: the proposal to drop **i686 multilib** — 32-bit x86 package support, the load-bearing dependency of Wine, Steam's back catalog, and the entire Bazzite gaming distro — was withdrawn after immediate, heavy backlash. Nobody argues 32-bit x86 has a future; the argument is about who maintains a thing nobody wants to own but everybody still uses. The reprieve postponed the question rather than answering it.[[cite: LWN, "Fedora's i686 support gets a reprieve"; The Register, "Fedora 43 won't drop 32-bit app support"]]

In the opposite trench: FESCo **rejected** the x86-64-v3 optimized-package proposal for F45 — a separate repo of packages compiled with AVX2/BMI2/FMA, covering essentially every Intel/AMD CPU of the last decade — pending more performance data. RHEL 10 already requires v3 as baseline; Microsoft reportedly wanted it for Azure Linux. The community that won't drop 32-bit support also won't accept faster builds for decade-old hardware. Fedora is simultaneously accused of abandoning old x86 and of refusing to modernize it — and both accusations are true, depending which trench you're standing in.[[cite: Phoronix, "Fedora x86-64-v3 Optimized Packages Pushed Back To At Least Fedora 46"; Fedora Discussion F45 Change thread]]

## The era of the opening bid

The backdrop matters: this is the release cycle where someone proposed swapping X.Org for the **Xlibre** fork (vetoed within days) and another discussion floated replacing **LibreOffice with Collabora Office**. The Fedora Changes process has quietly become a negotiation format — proposals arrive as opening bids, communities push back, and what ships is whatever survives the argument. F45's real novelty isn't KMSCON or reproducible builds; it's that *the argument itself is now part of the release notes.*[[cite: The Register on the withdrawn F43 proposals; Phoronix, Collabora Office discussion]]

The slip to 27 October, in that light, is almost fitting: Fedora 45 doesn't ship when the calendar says so — it ships when the blockers clear and the arguments pause. The hat tips both ways.

## See also

- [[Fedora 45]] — the release itself: features, dates, the NO-GO

- [[Why Debian Is Still King]] — the distribution that solves this by changing nothing

- [[History of Programming]]

[[Category:News]]

[[Category:Linux]]

[[Category:Computing]]