You don’t perform open-heart surgery on a running patient. Unless you’re GNOME, and the patient is the Linux desktop.
\n\n
At Guadec 2026, someone stood up and said the quiet part out loud: GNOME is planning to replace Glib and D-BUS — the two pieces of infrastructure that have held the desktop together for over two decades — with a Rust-based stack built on VARLINK.
\n\n
Glib and D-BUS aren’t just libraries. They’re the connective tissue of an entire desktop ecosystem. Replacing them isn’t a refactor — it’s a transplant.
\n\n
Let me explain what’s actually on the table.
\n\n
Glib is GNOME’s foundational C utility library. Object system, data structures, event loop, threading — the load-bearing walls of the house. D-BUS is the inter-process communication system that lets GNOME components talk to each other. Together, they form what you might call GNOME’s nervous system.
\n\n
The proposal: rip out both. Replace them with Rust for memory safety. Replace D-BUS with VARLINK for IPC.
\n\n
On paper, this sounds like progress. Rust eliminates entire classes of vulnerabilities that have haunted C codebases since the 1970s. Use-after-free, buffer overflows, double-frees — gone. Compiled out of existence. VARLINK offers a simpler, JSON-based, schema-driven IPC model designed for a containerized world.
\n\n
And here’s where the celebration stops.
\n\n
Everyone’s cheering for memory safety. Almost nobody’s asking what VARLINK actually does to GNOME’s architecture.
\n\n
D-BUS isn’t just a message bus. It’s a system that enables loose coupling between components. Services discover each other dynamically. They negotiate interfaces at runtime. They communicate through a shared bus that handles routing, ownership, and lifecycle. This is why GNOME feels modular — components can come and go without breaking each other.
\n\n
VARLINK works differently. It’s connection-oriented. Each client connects directly to a service endpoint. There’s no shared bus in the traditional sense. No discovery layer baked in.
\n\n
This means: every component that wants to talk to another component needs to know where that component lives. You’re trading the flexibility of a message bus for the simplicity of direct connections.
\n\n
You’re not just swapping C for Rust. You’re swapping a philosophy. The question is whether GNOME’s modularity survives the trade.
\n\n
Think about what this means in practice. Right now, if you’re writing a GNOME shell extension, you don’t need to know the internal address of the settings daemon. You send a D-BUS message. The bus figures out where it goes. That’s the magic — and it’s magic that thousands of extensions, applications, and system services depend on.
\n\n
Under VARLINK, someone has to manage those connections. Someone has to handle the case where a service moves, restarts, or doesn’t exist yet. That \”someone\” is either going to be a mountain of boilerplate in every component, or a new layer of infrastructure that… starts to look suspiciously like D-BUS.
\n\n
The universe of IPC systems has a gravity well at the center, and its name is \”message bus.\” You can orbit it, but escaping it costs more fuel than anyone expects.
\n\n
Let me be clear about where I stand: this rewrite is necessary. The C memory safety problem is real, it’s expensive, and it’s not going away. Every year GNOME stays on Glib is another year of CVEs, another year of developers chasing bugs that Rust would have caught at compile time. The status quo is not free — it’s just billing you in installments.
\n\n
But \”necessary\” and \”safe\” are not the same word.
\n\n
The risk isn’t that Rust is bad. The risk is that in the rush to embrace memory safety, GNOME accidentally architects itself into a corner. VARLINK’s connection model could lead to tighter coupling between components — the exact opposite of what made GNOME’s design work. You fix the memory bugs but break the modularity. You make the desktop safer but harder to extend.
\n\n
And the transition itself? This isn’t a weekend project. We’re looking at years where both old and new systems need to coexist. Compatibility layers. Bridge code. The bugs that come with maintaining two architectures simultaneously. Every GNOME user, every extension developer, every downstream distribution will feel this churn.
\n\n
The stakes extend beyond GNOME. The Linux desktop ecosystem has been consolidating around GNOME and KDE for years. If GNOME pulls this off — if they can modernize the foundation without collapsing the house — it sets a template for every other desktop environment watching from the sidelines. If they fail, we’re looking at a decade of instability and user frustration that the Linux desktop can’t afford.
\n\n
The next decade of the Linux desktop will be shaped by whether GNOME can pull off this rewrite without losing what made it work. Memory safety is the headline. Architectural integrity is the story nobody’s reading.
\n\n
The people proposing this aren’t naive. They know the risks. They’ve lived with Glib’s warts for years. They understand the pain ahead.
\n\n
But knowing the risks and surviving them are different things. And if they get this wrong, we’ll have built a safer desktop that nobody wants to use.
FAQ
Q: What is the key takeaway?
A: See the article.