¿Se está eliminando Xorg? ¿Qué significa esto?
El plan de Red Hat de retirar el servidor Xorg de RHEL 10 en favor de Wayland está generando debate sobre compatibilidad, seguridad y mantenimiento a largo plazo de la pila de escritorio Linux. Quienes lo apoyan argumentan que Xorg está prácticamente sin mantenimiento, es inseguro y demasiado complejo, y que Wayland ofrece mejor soporte para sandboxing, funciones gráficas modernas y un diseño de protocolo más limpio. Los críticos temen roturas en flujos de trabajo de larga data, herramientas de accesibilidad, configuraciones de entrada compartida/uso remoto y ciertos controladores de GPU, y cuestionan si forzar la transición antes de que Wayland cubra plenamente todos los casos de uso es una decisión responsable.
Definición de Xorg “bare metal”
- Un hilo aclara “bare metal” como que Xorg es el servidor de pantalla principal que se comunica directamente con los dispositivos de entrada (evdev) y de salida (DRM/KMS).
- Esto se contrasta con servidores “anidados” como Xwayland, Xephyr, vfb, xnest, xquartz y xwin, que renderizan dentro de otro sistema de pantalla.
- A algunos les resulta poco intuitivo este uso de “bare metal” en comparación con el significado más común de “no en una VM/contenedor”.
Alcance: eliminación de Xorg específicamente en RHEL10
- El hilo señala que el título es algo engañoso: el plan concreto es eliminar el servidor Xorg “al estilo xfree86” en RHEL10.
- Algunos sostienen que esto quizá no afecte a muchos, ya que RHEL suele estar orientado a servidores o se usa en configuraciones de estación de trabajo de nicho; otros creen que el movimiento de Red Hat influirá en otras distribuciones, como ocurrió con systemd.
Xorg frente a Wayland: deuda técnica y seguridad
- Muchos describen Xorg como antiguo, desordenado y en modo de mantenimiento, con muchas extensiones apenas usadas y pocas personas capaces de mantenerlo.
- Quienes apoyan su eliminación destacan:
- Mejor aislamiento y permisos con Wayland + tecnologías modernas como Flatpak/PipeWire.
- El débil aislamiento de X (facilidad para keylogging, espionaje de pantalla, pantalla de bloqueo como una ventana más).
- La dificultad de añadir de forma limpia funciones modernas (altas tasas de refresco, HDR).
- Los escépticos cuestionan las mejoras prácticas de seguridad en escritorios típicos, especialmente donde el sandboxing aún no está muy extendido.
Preocupaciones de compatibilidad y experiencia de usuario
- Algunos temen “toda una nueva clase” de roturas para aplicaciones antiguas, específicas de X o sin mantenimiento.
- Otros responden que Xwayland preserva la compatibilidad con clientes X durante décadas y que distribuir un Xorg sin mantenimiento es irresponsable.
- Varios usuarios informan que probaron Wayland y rápidamente encontraron regresiones o funciones ausentes (por ejemplo, Nvidia, flujos de trabajo, peculiaridades de la pantalla de bloqueo).
Accesibilidad y herramientas de compartición de entrada
- Se mencionan roturas concretas: Talon + Cursorless (control por voz) y synergy/barrier/input-leap (compartición de entrada entre varias máquinas).
- Están surgiendo reemplazos orientados a Wayland (libei, waynergy), pero el soporte es incompleto, depende del compositor y a veces encuentra resistencia.
- Existen requisitos de accesibilidad para Talon en Wayland, pero aún necesitan más trabajo de implementación; algunos usuarios aceptarían un subconjunto mínimo.
Tangente sobre systemd y mantenimiento
- El hilo traza brevemente un paralelismo entre Xorg→Wayland y sysvinit→systemd:
- Un lado celebra reemplazar código viejo y torpe por sistemas más coherentes pero más grandes.
- Otro lado subraya que existen inits alternativos y resiente los diseños de “gran bola de código”.
- En términos más generales, varios comentarios argumentan que depender de software sin mantenimiento y expuesto a la red (como versiones antiguas de synergy/barrier) es arriesgado, mientras que otros insisten en que el contexto (airgaps, túneles) importa y que los usuarios deberían decidir sus propios compromisos.