Xorg being removed. What does this mean?

Original Article ↗ Hacker News Discussion ↗

Red Hat’s plan to drop the Xorg display server from RHEL 10 in favor of Wayland is prompting debate over compatibility, security, and long-term maintenance of the Linux desktop stack. Supporters argue Xorg is effectively unmaintained, insecure, and overly complex, and that Wayland better supports sandboxing, modern graphics features, and cleaner protocol design. Critics worry about breakage of long‑used workflows, accessibility tools, remote/keyboard‑sharing setups, and certain GPU drivers, and question whether forcing the transition before Wayland fully covers all use cases is responsible.

Definition of “bare metal” Xorg

  • One thread clarifies “bare metal” as Xorg being the primary display server talking directly to input (evdev) and output (DRM/KMS) devices.
  • This is contrasted with “nested” servers like Xwayland, Xephyr, vfb, xnest, xquartz, and xwin, which render into another display system.
  • Some find this use of “bare metal” unintuitive compared with the more common “not in a VM/container” meaning.

Scope: Xorg removal specifically in RHEL10

  • Thread notes the title is somewhat misleading: the concrete plan is removal of the Xorg “xfree86-like” server in RHEL10.
  • Some argue this may not affect many, since RHEL is often server‑focused or used in niche workstation setups; others think Red Hat’s move will influence other distros, as with systemd.

Xorg vs Wayland: technical debt and security

  • Many describe Xorg as old, messy, and in maintenance mode, with many barely‑used extensions and few people able to maintain it.
  • Supporters of removal emphasize:
    • Better sandboxing and permissions with Wayland + modern tech like Flatpak/PipeWire.
    • X’s weak isolation (easy keylogging, screen snooping, lock screen as just another window).
    • Difficulty adding modern features (high refresh rates, HDR) cleanly.
  • Skeptics question the practical security gains on typical desktops, especially where sandboxing is not yet widespread.

Compatibility and user experience concerns

  • Some fear “a whole new class” of breakage for long‑lived, X‑specific, or unmaintained apps.
  • Others counter that Xwayland preserves X client compatibility for decades to come and that shipping an unmaintained Xorg is irresponsible.
  • Multiple users report trying Wayland and quickly hitting regressions or missing features (e.g., Nvidia, workflows, lock‑screen quirks).

Accessibility and input‑sharing tools

  • Specific breakages mentioned: Talon + Cursorless (voice control) and synergy/barrier/input-leap (multi‑machine input sharing).
  • There are emerging Wayland‑oriented replacements (libei, waynergy), but support is incomplete, compositor‑dependent, and sometimes resisted.
  • Accessibility requirements for Talon on Wayland exist but need more implementation work; some users would accept a minimal subset.

Systemd and maintenance tangent

  • The thread briefly parallels Xorg→Wayland with sysvinit→systemd:
    • One side celebrates replacing clunky, old code with more coherent but larger systems.
    • Another side stresses alternative inits exist and resents “giant ball of code” designs.
  • More broadly, several comments argue that depending on unmaintained, network‑facing software (like old synergy/barrier versions) is risky, while others insist context (airgaps, tunnels) matters and users should decide their own trade‑offs.