Against GNOME and KDE — and Why Every Desktop Converges on Them Anyway

The Linux desktop has been having the same argument since 1998, and the argument has a structure: a big integrated desktop ships something opinionated, a smaller project rebels by decomposing it into parts you assemble yourself, the assembly becomes popular, and then — slowly, and usually without anyone announcing it — the rebellion reassembles into the thing it rebelled against.

I want to make that claim specific rather than snide, because the most recent iteration finished the loop in about four years, in public, and the ending is more interesting than the argument.

Three desktops, one architecture

GNOME Shell is one long-running process. Compositor and shell UI live together in gnome-shell, and extensions are JavaScript loaded into it. This is the design people criticise most: an extension can take your session down, and every major release breaks half of them.

KDE Plasma splits it one level. KWin does compositing, plasmashell is a QML shell, and applets load into plasmashell. More resilient than GNOME's arrangement, same fundamental shape: one long-running process hosts the shell UI, and the things that extend it are plugins inside it.

Now the rebellion. A Hyprland desktop starts from the opposite end — a pile of independent daemons over a bare compositor. Waybar for the bar. Mako for notifications. Walker for the launcher. hyprlock for the lock screen. hypridle for idle. Each its own process, its own config dialect, its own release cadence. Maximum decomposition, minimum shared state. Exactly the anti-GNOME.

Omarchy 4.0 — the most polished packaging of that stack, from Basecamp — collapsed all of it into one long-running Quickshell process in which the bar, menu, notifications, OSD, panels and lock screen are plugins. On the release branch, config/hypr/ no longer contains hyprlock.conf or hypridle.conf. Locking and idle became the shell's job.

Two opposite starting points. One destination.

The convergence is a conclusion, not a coincidence

It would be cheap to file this under irony and move on. It is more useful to ask why the pressure runs in that direction, because the reasons Omarchy gives in its own shell/README.md are the correct three, and they are not aesthetic:

Shared services exist once instead of once per process. Ten daemons that each need to know your theme, your audio state, your network state, and the current workspace means ten subscriptions to the same buses and ten copies of the same derived state, drifting.

Summoning a panel is IPC into something already running, not a cold start. The difference between a launcher that appears instantly and one that appears in 200ms is the difference between a tool and an annoyance, and process startup is most of that budget.

Third-party plugins load from disk without patching the shell. Once you have one process, extension is a plugin API. Once you have ten processes, extension means convincing ten maintainers or forking one.

Every one of those is a shared-state argument. And that is the general law hiding here: when N components need to agree about the same mutable state and respond to it in tens of milliseconds, they converge on one owner. It is the same force that turns a microservice constellation into a modular monolith, and it operates on desktops for exactly the same reason.

So GNOME was not being lazy or corporate when it put the shell in one process. It was ahead. It just paid the cost of that decision — extension fragility — in public for fifteen years, which made the design look like a mistake rather than a conclusion.

Where they genuinely differ, and it is not what partisans claim

If the architecture converged, what is actually left to argue about? Something narrower and much more interesting than "bloat."

The usual claim is that the big desktops do not let you layer vendor defaults under user config. That claim is simply false. GNOME has system dconf databases and lock lists under /etc/dconf. KDE has the KConfig cascade from /etc/xdg into ~/.config, complete with an [$i] marker that makes a key immutable. Both are real, mature vendor/user layering, and both predate every project currently claiming to have invented it.

The difference is what the layering is for.

GNOME's and KDE's cascades exist so that an administrator can impose and freeze policy on a fleet — key by key, in a format designed for a settings GUI to write. The user is the party being constrained. That is a completely legitimate goal and it is why these desktops survive in enterprises.

Omarchy's layering aims at the opposite problem: continuing to improve the user's configuration after they have edited it. The mechanism follows from the goal. Because Hyprland's config is now Lua, your file calls theirs — require("default.hypr.omarchy") and then your overrides — so the vendor can improve the defaults without rewriting a file you own, and opting out of a default is a named flag rather than a fork.

Keys-and-precedence versus code-and-load-order. Freeze the user versus keep shipping to the user. Both are layering; they are pointed in opposite directions.

The consequence nobody mentions: dconf is a binary store

There is a second-order effect of GNOME's choice that shapes daily life more than the architecture does.

GNOME keeps the user's settings in a binary dconf database. Not a text file. You cannot sanely put it in git, you cannot diff it, and you cannot hand-edit it. Which is why "dotfiles" in the GNOME world means exporting a dump with dconf dump / and reimporting it on the new machine — a snapshot, not a configuration.

Think about what that costs. You cannot review a change to your own desktop. You cannot bisect when something breaks. You cannot cherry-pick the two settings you actually wanted from a colleague's setup. The entire practice of treating your environment as version-controlled source, which is completely normal for shells, editors and terminals, is unavailable for the desktop itself.

KDE is better here — KConfig is INI-ish text, greppable and diffable — and gets far too little credit for it.

This is the real, non-tribal case against GNOME, and it has nothing to do with memory usage or how many clicks it takes to reach the power button. It is that the most-configured layer of the system is the one layer you cannot treat as code.

The missing primitive: nobody repairs user state

Here is the gap that neither GNOME nor KDE nor any hand-rolled rice has closed, and it is the one I would most like to see stolen.

Layering handles configuration that a package can rewrite. It does nothing for the other category: state that needs repairing rather than replacing. A systemd user unit that has to be re-enabled. A preference file whose format changed under an app. A symlink pointing somewhere that no longer exists. An extension whose API disappeared.

These are one-time fixes to a particular machine's history, and package managers have no vocabulary for them, because packages are declarative and this is not. So who runs the repair? Today: you do, after reading a forum thread, if you find the right one.

Omarchy's answer is a directory of timestamped shell scripts run by a migration runner, with per-user completion tracking and a hard rule that every one must be idempotent. That is Rails' schema migrations pointed at $HOME, and the per-user completion state is exactly why idempotency is mandatory — on a two-account laptop the second person must still get every fix, and a machine-wide repair already applied by the first must be detected and skipped.

Neither GNOME nor KDE has any equivalent for user state, and you can feel the absence every time a GNOME upgrade leaves you with a broken extension. There is no repair script to run, because there is no concept of a repair script. There is a compatibility field in a manifest, and an extension that is now off.

I think this is the single most transferable idea in the current desktop conversation, and it is not a desktop idea at all. Anyone who distributes configuration to machines they do not control eventually needs timestamped, idempotent, per-recipient repair scripts. Most of us reinvent them badly and late.

What the rebellion does not replace

Being fair about the other column, because the case for GNOME and KDE is not sentimental:

• A graphical settings surface that is the primary interface rather than a fallback.
• Serious, funded accessibility work — screen readers, magnification, keyboard navigation — that a rice will never approximate.
• Decades of hardware, locale, and input-method coverage.
• Sessions that survive Secure Boot, TPM, enterprise imaging and corporate device management.
• The enormous advantage of already being on the machine.

Omarchy, for its part, asks you to reinstall your operating system, disable Secure Boot and TPM, and type a LUKS passphrase on a wired keyboard — because the passphrase is entered before anything USB-agnostic is running, so a Bluetooth keyboard cannot unlock the machine. That is not a rival to GNOME on a corporate ThinkPad. It is a different bargain for a different person, and the manual is unusually honest about saying so.

The inversion

The cleanest way I can phrase what actually separates these projects has nothing to do with process count:

GNOME and KDE are desktops that a distribution ships. Omarchy is a distribution that a desktop ships.

That inversion is what makes the migration runner possible at all. Nobody can reliably repair your ~/.config unless they also control what put it there — which is why the big desktops, which must run on Fedora and Debian and Ubuntu and openSUSE and whatever ships next year, are structurally barred from the one idea that would help them most. It is not an oversight. Owning both halves is a prerequisite, and they gave up that half deliberately, in exchange for running everywhere.

So the argument that started in 1998 turns out not to have been about integration versus composition. Both sides integrate; the convergence settled that. It was about who owns the seam between the vendor's opinions and yours, and whether anyone is willing to keep maintaining it after you have edited it. On that question the big desktops have a good answer for administrators, no answer for individuals, and no plan to get one — and that, rather than any amount of RAM, is what a rebellion is actually rebelling against.

---

Written against the GNOME and KDE configuration documentation and the Omarchy manual as of 22 August 2026. The Omarchy internals summarised here are covered in full in Omarchy 4.0: The Distro Is Mostly a Migration Runner; the case for and against building on a bare compositor is in Hyprland Gives You a Compositor, Not a Desktop.