Xorg sendo removido. O que isso significa?
O plano da Red Hat de retirar o servidor de exibição Xorg do RHEL 10 em favor do Wayland está gerando debate sobre compatibilidade, segurança e manutenção de longo prazo da pilha de desktop Linux. Os defensores argumentam que o Xorg está efetivamente sem manutenção, é inseguro e excessivamente complexo, e que o Wayland oferece melhor suporte a sandboxing, recursos gráficos modernos e um design de protocolo mais limpo. Os críticos temem quebra de fluxos de trabalho antigos, ferramentas de acessibilidade, configurações de compartilhamento de teclado/entrada e certos drivers de GPU, e questionam se forçar a transição antes de o Wayland cobrir totalmente todos os casos de uso é responsável.
Definição de Xorg “bare metal”
- Um fio esclarece “bare metal” como o Xorg sendo o servidor de exibição principal, falando diretamente com dispositivos de entrada (evdev) e de saída (DRM/KMS).
- Isso é contrastado com servidores “nested” como Xwayland, Xephyr, vfb, xnest, xquartz e xwin, que renderizam dentro de outro sistema de exibição.
- Alguns acham esse uso de “bare metal” pouco intuitivo em comparação com o significado mais comum de “não em uma VM/container”.
Escopo: remoção do Xorg especificamente no RHEL10
- O fio observa que o título é um pouco enganoso: o plano concreto é remover o servidor Xorg “semelhante ao xfree86” no RHEL10.
- Alguns argumentam que isso pode não afetar muita gente, já que o RHEL costuma ser voltado a servidores ou usado em configurações de workstation de nicho; outros acham que a decisão da Red Hat influenciará outras distros, como aconteceu com o systemd.
Xorg vs Wayland: dívida técnica e segurança
- Muitos descrevem o Xorg como antigo, bagunçado e em modo de manutenção, com muitas extensões quase não usadas e poucas pessoas capazes de mantê-lo.
- Os defensores da remoção enfatizam:
- Melhor sandboxing e permissões com Wayland + tecnologias modernas como Flatpak/PipeWire.
- O isolamento fraco do X (keylogging fácil, espionagem de tela, tela de bloqueio como apenas outra janela).
- Dificuldade de adicionar recursos modernos (altas taxas de atualização, HDR) de forma limpa.
- Céticos questionam os ganhos práticos de segurança em desktops típicos, especialmente onde o sandboxing ainda não é amplamente usado.
Preocupações com compatibilidade e experiência do usuário
- Alguns temem “uma classe inteira” de falhas para aplicativos antigos, específicos de X ou sem manutenção.
- Outros contrapõem que o Xwayland preserva a compatibilidade com clientes X por décadas e que distribuir um Xorg sem manutenção é irresponsável.
- Vários usuários relatam ter testado Wayland e encontrado rapidamente regressões ou recursos ausentes (por exemplo, Nvidia, fluxos de trabalho, peculiaridades da tela de bloqueio).
Acessibilidade e ferramentas de compartilhamento de entrada
- Quebras específicas mencionadas: Talon + Cursorless (controle por voz) e synergy/barrier/input-leap (compartilhamento de entrada entre máquinas).
- Existem substitutos emergentes voltados ao Wayland (libei, waynergy), mas o suporte é incompleto, depende do compositor e às vezes encontra resistência.
- Existem requisitos de acessibilidade para o Talon no Wayland, mas ainda é preciso mais trabalho de implementação; alguns usuários aceitariam um subconjunto mínimo.
systemd e desvio sobre manutenção
- O fio faz um paralelo breve entre Xorg→Wayland e sysvinit→systemd:
- Um lado celebra substituir código antigo e desajeitado por sistemas mais coerentes, porém maiores.
- Outro lado ressalta que existem alternativas a inits e critica projetos de “gigantesca bola de código”.
- De forma mais ampla, vários comentários argumentam que depender de software não mantido e exposto à rede (como versões antigas de synergy/barrier) é arriscado, enquanto outros insistem que o contexto (airgaps, túneis) importa e que os usuários devem decidir seus próprios compromissos.