Some technologies die. Some technologies are replaced. Some technologies refuse to do either and instead become infrastructure — load-bearing walls in a building that everyone wants to renovate but nobody dares demolish.

COBOL runs your bank. FAT32 formats your USB drive. And X11 draws your Linux desktop.

X11 is 39 years old. It has not had a major version release since September 1987. Its replacement was announced in 2008. Its replacement’s replacement has not been announced because the replacement has not finished replacing it yet.

This is the story of the display server that refused to die and the protocol that has been “almost ready” for longer than most software engineers have been alive.

The Origin: MIT, 1984

The X Window System was created at MIT in 1984 by Bob Scheifler and Jim Gettys as part of Project Athena — a joint project between MIT, DEC, and IBM to build a networked computing environment for campus use.

The design philosophy was radical and correct: “Mechanism, not policy.”

X provides drawing primitives — windows, pixels, input events. It does not provide a desktop environment, a window manager, a taskbar, or a theme engine. Those are someone else’s problem. X draws rectangles and routes mouse clicks. What you build on top is your business.

This is why the Linux desktop has KDE, GNOME, XFCE, i3, Sway, Hyprland, and approximately seven hundred tiling window managers maintained by people who believe their approach to arranging rectangles is philosophically superior to everyone else’s. X11 does not care. X11 draws what you tell it to draw. Mechanism, not policy.

X went through rapid iterations — X1 through X10 between 1984 and 1986. Then X11 arrived in September 1987. Version 11 of the X protocol. The version that would run unchanged for the next four decades.

There is no X12. There was never a serious proposal for X12. X11 was so flexible, so extensible, so stubbornly adequate that nobody could justify a protocol-breaking revision. The community just kept bolting extensions onto it — XRender, XComposite, XInput2, XRandR — like adding rooms to a house by leaning plywood against the original walls.

Network Transparency: The Feature That Was Genius and Disaster

X11’s signature capability is network transparency. The X server (which draws pixels on your screen) and the X client (your application) can run on different machines. The protocol is network-native. You can run Firefox on a server in Tokyo and display it on your screen in Paris. You do this with SSH X forwarding, and it works — slowly, with rendering artifacts, over a connection that was designed for 1987 Ethernet speeds — but it works.

ssh -X user@tokyo-server firefox

That command launches Firefox on a remote server and draws it on your local display. The pixels traverse the Pacific Ocean. This was revolutionary in 1987, when “distributed computing” meant something, and dumb terminals needed to display graphical applications from central servers.

In 2026, it is a curiosity that sysadmins use when they need to run virt-manager on a headless server and are too stubborn to set up a web interface.

But here is the problem with network transparency: it requires trust.

The Security Catastrophe

X11 was designed in an era when “security” meant locking the door to the computer room.

The X11 security model is simple: any client connected to the X server can do anything. Read keystrokes from any other window. Take screenshots of any application. Inject mouse clicks and keyboard events into any running program. Enumerate every window. Access the clipboard.

This is not a bug. This is the architecture. X11 clients share a flat trust domain. If you can connect, you are trusted. There is no isolation between applications. Your password manager and your web browser and that sketchy Electron app you installed last week all have equal access to everything happening on your display.

Writing an X11 keylogger is a weekend project for a first-year computer science student. It is not an exploit. It is using the API as designed.

# This is roughly how trivial it is
xdotool getactivewindow
xinput test-xi2 --root

The X11 security model assumes that every application running on your desktop is trustworthy. In 1987, when “installing software” meant compiling it yourself from source you personally reviewed, this was defensible. In 2026, when you install packages from npm that install packages from npm that install packages from npm, each with a supply chain longer than the Silk Road, this is insane.

This is the fundamental reason Wayland exists. Not compositing. Not performance. Not modernity. Security. X11 trusts everything, and in 2026, nothing deserves trust.

XFree86 and the Fork

For most of X11’s life, the dominant implementation was XFree86 — a free implementation of X11 for x86 hardware, started in 1992.

In 2004, the XFree86 project changed its license. They added an advertising clause — a requirement that all software using XFree86 include a specific credit in its documentation. This is the same clause that made the original BSD license problematic. The open-source community had learned this lesson before. XFree86 apparently had not.

The community forked XFree86 as the X.Org Server, maintained by the X.Org Foundation, under the original MIT license. Developers migrated. Distributions switched. XFree86 was dead within a year.

X.Org Server lives on as the X11 implementation running on virtually every Linux system today. A license dispute killed the dominant implementation, and a fork replaced it overnight. The X11 protocol did not care. The protocol is 39. It has survived worse than a license fight.

Wayland: The Correct Replacement

In 2008, Kristian Hogsberg, a Red Hat developer, started Wayland as a side project. The premise: X11 is too old, too complex, too insecure, and too full of legacy code that exists only to support hardware from the 1990s. Start fresh.

Wayland is not a display server. It is a protocol — a specification for how compositors (the thing that draws windows) and clients (your applications) communicate. The compositor is the display server. There is no middleman. The compositor owns the screen, manages input, and talks directly to clients through the Wayland protocol.

The security model is the opposite of X11: clients are isolated. An application cannot read another application’s input. Cannot take screenshots of other windows. Cannot inject events. The compositor mediates everything. If an application wants to share its screen, it must ask the compositor, which asks the user, through a portal. This is correct.

Wayland 1.0 shipped in 2012. The year of Wayland had begun.

It is now 2026. The year of Wayland is still ongoing.

The Fourteen-Year “Almost There”

Wayland has been “almost ready to replace X11” for longer than X11 was old when Wayland was announced. X11 was 21 in 2008. Wayland has been “nearly ready” for 18 years.

Year	Milestone	Still Missing
2008	Wayland announced	Everything
2012	Wayland 1.0 released	Screen sharing, global hotkeys, color management, NVIDIA support
2016	GNOME on Wayland default (Fedora 25)	Screen sharing, global hotkeys, NVIDIA support
2019	PipeWire starts fixing screen sharing	Global hotkeys, NVIDIA support, HDR
2022	NVIDIA finally supports GBM	HDR, color management, mixed DPI
2024	KDE Plasma 6 defaults to Wayland	HDR partial, mixed DPI still janky
2026	Present day	HDR incomplete, XWayland still required for most apps

Every year from 2012 to the present, someone has declared it “the year of Wayland.” This is the display server equivalent of “the year of Linux on the desktop.” Both phrases are now used primarily as punchlines.

What Wayland Deliberately Removed

Wayland did not fail to implement X11’s features. It refused to implement them. Network transparency? Gone. Not by accident — by design. Hogsberg argued that network-transparent rendering was an anachronism, that modern remote desktop solutions (VNC, RDP, PipeWire streaming) were superior.

He was technically correct. He was also removing a feature that sysadmins relied on daily, with no built-in replacement, and telling them to use a portal protocol that did not exist yet.

The list of things X11 had that Wayland deliberately removed or delayed:

• Network transparency: No ssh -X. XWayland exists as a compatibility layer, but native Wayland apps cannot be forwarded.
• Screen sharing: Broken for years. Required xdg-desktop-portal and PipeWire integration. Zoom and Teams on Wayland were a disaster until approximately 2021.
• Global keyboard shortcuts: Applications could not register global hotkeys. Required a portal protocol. Your media keys worked. Your custom hotkeys did not.
• Color management: Came very late. Photographers and designers stayed on X11.
• Variable refresh rate (VRR/FreeSync): Came late. Gamers stayed on X11.
• HDR support: Still partial in 2026. Content creators stay on X11 or switch to macOS.
• Multi-monitor with mixed DPI: A 4K monitor next to a 1080p monitor. On X11, it was ugly but functional. On Wayland, it was functional but differently ugly. In 2026, it is mostly fine. Mostly.

Wayland was architecturally correct and practically incomplete. It solved the security problem and created a decade of feature-parity problems. This is the classic tradeoff of rewrites: you fix the foundation and spend twelve years rebuilding the furniture.

NVIDIA: The Holdout

NVIDIA deserves special mention in the Wayland story, because NVIDIA spent years refusing to support the standard buffer-sharing API.

The Wayland ecosystem standardized on GBM (Generic Buffer Management) for sharing graphics buffers between the compositor and applications. NVIDIA refused. They implemented EGLStreams instead — their own proprietary alternative. The compositor developers (GNOME, KDE, wlroots) had to either support both APIs or ignore NVIDIA. Most ignored NVIDIA.

This meant that for years, “Wayland support” had an asterisk: works on AMD and Intel. NVIDIA users, go back to X11.

NVIDIA finally capitulated and added GBM support in their 495 driver series in late 2021, with full support landing in 2022. The EGLStreams vs. GBM war lasted roughly five years. The proprietary GPU vendor that controls 80% of the discrete GPU market held back Wayland adoption for half a decade because they wanted their own protocol. This is the NVIDIA way. The leather jacket asks for forgiveness, not permission.

XWayland: The Compatibility Crutch

Here is the truth nobody promoting Wayland wants to acknowledge: most “Wayland” desktops run most applications through XWayland — a compatibility layer that implements an X11 server inside the Wayland session.

Every application that has not been ported to native Wayland — and that includes a staggering number of applications in 2026 — runs through XWayland. It speaks X11 to the application and Wayland to the compositor. It is a translation layer. It works. It also means that the “Wayland desktop” is, for many users, an X11 desktop with a Wayland compositor managing the windows.

The replacement needs the thing it replaced to function. This is not a transition. This is a hostage situation. X11 is sitting in the corner of the Wayland session, running three-quarters of the applications, and saying: you cannot remove me. You tried. Look at your application list. I am still here.

FreeBSD and Wayland

Wayland is not Linux-specific. It works on FreeBSD. The Wayland protocol is OS-agnostic. Compositors like Sway and Hikari run on FreeBSD.

But X11 remains dominant on FreeBSD desktops. The FreeBSD community, characteristically, is waiting for Wayland to finish before committing. They watched Linux distributions adopt Wayland prematurely and deal with years of breakage. FreeBSD will adopt Wayland fully when Wayland is fully ready. This may take additional years. FreeBSD has patience. FreeBSD has seen technologies come and go. X11 has not gone.

The Real Winner

X11 won by surviving. It was supposed to be temporary in 1987 — a protocol version that would be replaced by X12 or something better. X12 never came. X11 survived XFree86’s death, survived Wayland’s announcement, survived 18 years of “this is the year X11 dies,” and is currently running inside its own replacement as a compatibility layer.

Wayland wins by being correct. The security model is right. The architecture is right. The isolation between clients is right. Every technical criticism of X11 that motivated Wayland’s creation was valid. Every design decision in Wayland’s protocol is defensible.

Both of these things are true simultaneously.

X11 is the wrong answer that works. Wayland is the right answer that is still being assembled. X11 is FAT32 — technically inferior, universally supported, impossible to kill. Wayland is ZFS — technically superior, adoption measured in decades, still waiting for the world to catch up.

Some technologies are not replaced. They are outlived. X11 will not be replaced by Wayland. X11 will slowly become unnecessary, application by application, toolkit by toolkit, until one day XWayland is removed from a major distribution and nobody notices because nothing needed it anymore. That day is not today. That day is not 2026. That day may not be this decade.

X11 was designed when security meant locking the door to the computer room. Wayland was designed when security meant not trusting the applications inside the room. Both are products of their era. One era lasted 39 years. The other has been trying to start for 18.

Replacements in technology do not arrive on schedule. ReiserFS was supposed to be replaced by Reiser4. BTRFS was supposed to replace ext4 a decade ago. systemd replaced init in five years because it had corporate backing and a willingness to absorb everything in its path. Wayland has been polite. Wayland has followed the protocol. Wayland has waited for consensus. And X11, impolitely, has refused to leave.

In the Republic of Derails, we solved the display server problem in 2009. The display is the television. There is one channel. It shows what the Party wants. There is no compositor. There is no protocol negotiation. There is no client isolation because there is one client: the state broadcast. The screen renders at exactly the resolution the Supreme Leader approves. There are no mixed-DPI problems because there is one DPI. There are no global hotkey conflicts because there is one hotkey, and it changes the channel to the same channel. There is no network transparency because the network is not transparent to anyone.

This is better than both X11 and Wayland. No security vulnerabilities. No compatibility layers. No fourteen-year transition plan. One screen. One channel. One resolution. The display server problem is a Western problem. We do not have it. We have a television.

— Kim Jong Rails, Supreme Leader of the Republic of Derails