KDE reaches its thirtieth birthday with a decision that splits the Linux desktop. Plasma 6.8, now in its second and final beta, will be the first release without a native X11 desktop session: the release is scheduled for October 14, the project's 30th anniversary, and from that version the desktop will run on Wayland. X11 applications will continue to work through XWayland, but the X11 session as a standalone environment will no longer ship. Plasma 6.7 still offered it as an optional install; with Plasma 6.8 that door closes.

The beta is not only about dropping X11. It continues the public preview of the Union theme engine, which can now style QtWidgets applications such as Dolphin and Kate, though the support remains preliminary. The revived Oxygen theme gets further polish. On the opposite side, the Klassik project recreates the KDE 3 experience using Plasma 6, Qt 6, Qt Quick and KDE Frameworks 6. It is not a fork or a port of the original Qt 3 code: it reimplements the panel, K Menu, Quicklaunch, Task Manager, lock and logout buttons and the old clock, with support for Wayland and fractional scaling.

Klassik's technical choice is more interesting than it sounds. Preserving an interface does not mean preserving the stack that ran it in 2002. It is possible to keep the user experience on modern libraries, avoiding frozen historical dependencies and reducing maintenance costs for anyone who needs familiar environments on updated foundations. That lesson goes beyond the desktop: long-term compatibility is often an architecture problem, not an act of fidelity to original code.

The fork landscape tells a structural story. Trinity Desktop Environment, the oldest, maintains TQt, a Qt3 fork, and the April 14.1.6 release is available for 14 distributions. Sonic, newer and active on GitHub, keeps X11 support through a KWin fork called Sonic-win. MiDesktop goes back to KDE 1.1.2 using Osiris, a Qt 2.3.2 fork. Katana, a KDE 4 fork, appears stalled: the repository shows no commits or releases in three years. The variety of these projects signals that not everyone accepts the Wayland-first direction, but also that preservation often requires separate codebases, with their own costs and risks.

Dropping the X11 session is not a painless protocol change. Wayland imposes a stricter security model: it isolates clients, does not grant every application global control of the display, and gives the compositor responsibility for input, screen capture and sharing. For teams managing workstations in regulated environments or with automation pipelines, that means verifying remote access, screenshot tooling and testing against the specific compositor. XWayland softens the immediate impact but moves compatibility inside the Wayland session, where legacy tooling must live with tighter rules. It is the same dynamic seen in self-hosted deployments: when a foundational component changes, the real cost is not the upgrade itself but the review of everything that depends on it.

For those comparing local strategies and external services, the issue of reproducibility and session control is the same one AI-RADAR maps in its /llm-onpremise frameworks: trade-offs are not limited to AI workloads. Forks are therefore not just archaeology. They signal that part of the Linux desktop is asking for long-term stability and compatibility, even at the cost of walking outside the main branch.