Problems with D-Bus on the Linux desktop

Reaction to the rant and new bus

• Many readers find the article’s tone overly hostile and see it as a “hatchet job” that misrepresents specs and omits context (e.g., the xdg-desktop-portal restore_token vs restore_data APIs).
• The proposed replacement bus (hyprwire/hyprtavern) is viewed as immature: almost no spec, docs, or tests yet; some say protocol clarity matters more than the C++ implementation, but others won’t take it seriously without both.
• Several argue that if you want wide adoption you need the “ruff/uv” playbook: ship something faster and clearly better, be diplomatic, and gradually replace D‑Bus, not start with a public flame.
• XKCD’s “new standards” comic is repeatedly invoked: critics see this as just another incompatible standard that will fragment things further.

Critiques and defenses of D‑Bus

• D‑Bus is called a “godawful mess”: overly complex types, awkward XML, poor tooling, fragile behavior, and inconsistent higher‑level APIs (e.g., portals).
• Others say it “just works” and is widely deployed (TVs, cars, desktops), and most of the pain is in GNOME/desktop use and politics, not the core bus design.
• Some point out D‑Bus has policies and can be constrained with SELinux/AppArmor; the fact that desktop projects don’t lock it down is not an inherent protocol flaw.
• D‑Bus’s success is attributed to GNOME/Red Hat/Ubuntu backing and “good enough” timing, not technical optimality.

Secrets, keyrings, and threat models

• The article’s key complaint—that any app on the session bus can read all unlocked secrets from gnome‑keyring/kwallet—shocks many.
• Defenders counter that on classic Linux desktops any process running as the user can already read that user’s data; keyrings mainly protect secrets at rest (stolen laptop), not from peer apps.
• Others argue this is outdated now that sandboxing (Flatpak, containers) and portals exist; in that world, a global “dump all secrets” API is seen as an unnecessary and dangerous escape hatch.
• There’s deep disagreement over whether per‑app secret isolation (Android/iOS‑style) is worth the complexity on Linux, and how much can realistically be enforced without stronger kernel‑level identity and policy.

Sandboxing, portals, and Wayland

• Several note that Flatpak filters D‑Bus access via proxies, so the article’s criticisms don’t apply to sandboxed apps in the same way; others point out sandbox adoption is patchy and permissions are often lax.
• xdg‑desktop‑portals are widely described as brittle and confusing: many report broken file dialogs or screencasting until they discover the right combination of portal backends and compositor support.
• Wayland is defended as much nicer than D‑Bus on the protocol level and a model for better, code‑generated IPC; skeptics see Wayland and portals as “security theater” given other holes (full home dir access, ptrace, LD_PRELOAD).

Alternative IPC mechanisms

• Android’s Binder is proposed as a battle‑hardened replacement: kernel support, massive deployment, corporate backing. Critics reply it’s Android‑centric, C++/Java‑heavy, tied to Linux‑only features, and not obviously a drop‑in desktop fit.
• Others suggest reusing Wayland’s protocol machinery for a general bus, or older ideas like Sun RPC/XDR, CORBA‑like systems, Cap’n Proto, or MQTT over Unix sockets; most agree transport is easy, semantics, tooling and security are hard.
• Varlink (systemd’s JSON‑based RPC) and ubus (OpenWrt) are mentioned as existing alternatives; type‑safety vs “JSON everywhere” is a recurring complaint.

Linux desktop politics and fragmentation

• Several see this as another example of Linux desktop “reinventing the wheel”: every new irritation spawns a new compositor, IPC, or secrets service, worsening fragmentation.
• Others argue fragmentation reflects genuinely different use cases (embedded, tiling WMs, heavy DEs) and weak centralized governance.
• There’s concern that as Linux desktop finally gains mainstream users (gaming, WSL, Steam Deck‑driven distros), its weak, inconsistent security model (including D‑Bus and keyrings) will become a serious liability.