Modernizar o desktop open source: o que muda para devs

O X11 nasceu em 1987, e boa parte dos desktops Linux ainda roda em cima das decisões tomadas naquela época. A LWN publicou um texto chamado Ideas on modernizing the open-source desktop, e o título já resume uma conversa que está pegando fogo na comunidade: o que precisa mudar para o desktop open source parar de parecer um projeto eternamente "quase pronto". Vale ler o original. Aqui eu quero falar do lado que interessa a quem programa: o que essa modernização mexe no seu dia a dia.

O que significa modernizar o desktop open source?

Modernizar não é trocar ícone nem mudar tema. É mexer na fundação. Hoje, quando alguém fala em desktop Linux moderno, quase sempre está falando de três coisas:

• Wayland no lugar do X11, como forma de desenhar janelas na tela.
• Apps empacotados e isolados, com Flatpak e os portais do xdg-desktop-portal.
• Sistema base imutável, que atualiza de forma atômica e volta atrás se der problema.

Nenhuma dessas ideias é nova. O Wayland existe desde 2008. O Fedora Silverblue já tem anos de estrada. A novidade é que a conversa saiu do "um dia, quem sabe" e virou plano com prazo. GNOME e KDE já anunciaram o fim da sessão X11. A KDE tem uma distro própria, a KDE Linux, que é imutável desde o começo. E o GNOME OS deixou de ser só uma imagem de teste.

Por que isso importa agora

O motivo é simples: o modelo antigo não escala. No desktop tradicional, todo app enxerga tudo. Qualquer programa lê seu ~/.ssh, qualquer janela consegue capturar a tela das outras no X11. Isso era aceitável nos anos 90. Hoje, com extensão de navegador maliciosa e pacote npm comprometido aparecendo toda semana, é um convite.

O outro motivo é manutenção. Uma distro clássica é um quebra-cabeça de milhares de pacotes atualizados um por um. Uma atualização que trava no meio deixa o sistema num estado que ninguém testou. O modelo imutável troca isso por uma imagem inteira, testada como um bloco. Atualizou e quebrou? Reinicia na versão anterior.

Quem já perdeu uma tarde consertando o próprio sistema depois de um update entende o valor de um botão de voltar.

E tem um exemplo que mostra que isso funciona fora do laboratório: o Steam Deck. O SteamOS é imutável, usa Flatpak para apps de desktop, e milhões de pessoas usam Linux sem saber que estão usando Linux. Esse é o sinal mais claro de que o caminho funciona para gente normal.

O que muda no seu fluxo de desenvolvimento

Agora a parte que dói. Desktop moderno e ambiente de dev tradicional brigam em alguns pontos.

Sistema imutável não deixa você instalar tudo na raiz. Aquele sudo dnf install postgresql-devel que você roda sem pensar não funciona do mesmo jeito. A resposta do ecossistema são os containers de desenvolvimento, com toolbox ou distrobox:

distrobox create --name dev --image fedora:latest
distrobox enter dev

# dentro do container, vida normal
sudo dnf install nodejs postgresql
curl -fsSL https://bun.sh/install | bash

O container compartilha sua home, então seu projeto, suas chaves e seu .gitconfig continuam lá. Na prática, depois de uma semana você esquece que está dentro de um container. Eu acho isso até melhor que o modelo antigo: cada projeto com suas dependências, e o sistema base limpo.

Editor em Flatpak vê pouco. Se você instalar o VS Code pelo Flathub, ele roda isolado. O terminal integrado não enxerga o Node que você instalou no host, e os language servers somem. Dá para abrir permissões:

flatpak override --user --filesystem=home com.visualstudio.code

Mas aí você está desfazendo parte do isolamento que justificou o Flatpak. Minha opinião: ferramenta de desenvolvimento pesada (editor, IDE, Android Studio) funciona melhor instalada dentro do mesmo container onde está o toolchain. O Flatpak brilha em app de usuário final: navegador, Slack, player de música.

Wayland muda coisas que você nem lembrava que dependiam do X11. Captura de tela, compartilhamento no Meet, ferramentas de automação que simulam clique, atalhos globais. No Wayland, nada disso é livre. Tudo passa por portal, com o usuário autorizando. Para quem faz app web, o getDisplayMedia() no navegador já funciona via PipeWire e portal sem você mudar uma linha. Para quem faz app Electron ou ferramenta de desktop, vale testar:

# força o Electron a rodar nativo no Wayland em versões mais antigas
code --ozone-platform-hint=auto

Versões recentes do Electron já detectam o Wayland sozinhas. Mas se você mantém um app Electron antigo, é o tipo de coisa que aparece como bug de "tela borrada" ou "não consigo compartilhar a tela" no issue tracker.

As objeções mais comuns, respondidas

"Vou perder controle do meu sistema." Perde um pouco, sim. Você deixa de editar /usr na mão. Em troca, ganha um sistema que não apodrece. Para quem gosta de mexer em tudo, distro tradicional continua existindo e vai continuar.

"Flatpak duplica biblioteca e ocupa disco." Ocupa mais que pacote nativo, isso é verdade. Os runtimes compartilhados e a deduplicação reduzem o estrago, mas não zeram. Em 2026, com SSD de 1 TB barato, eu troco alguns gigas por apps que não quebram quando a distro atualiza a glibc.

"Wayland ainda não faz X." Essa lista encolheu muito. Há três anos tinha muita coisa nela. Hoje sobra um nicho: certas ferramentas de acessibilidade, alguns fluxos de automação e software proprietário que não atualiza. O nicho é real e quem depende dele tem razão de reclamar. Mas não é motivo para segurar todo mundo no X11.

"Isso é a Red Hat empurrando agenda." O GNOME e a Red Hat puxaram muito disso, mas a KDE, a Valve e o pessoal do Bazzite e do openSUSE Aeon chegaram em conclusões parecidas por caminhos diferentes. Quando gente com interesses diferentes converge, normalmente é porque o problema é real.

O que eu faria hoje, na prática

Se você desenvolve em Linux e quer se adiantar sem trocar de distro amanhã:

1. Rode sua sessão em Wayland por uma semana. Anote o que quebra. Provavelmente é menos do que você imagina.
2. Coloque um projeto dentro de um distrobox. Se der certo, mova os outros aos poucos.
3. Se você mantém app desktop, teste em Wayland nativo e com Flatpak. Seus usuários vão chegar lá antes de você.
4. Deixe o isolamento ligado nos apps que não precisam ver sua home inteira. Seu ~/.aws/credentials agradece.

Nada disso exige reinstalar o sistema. E se der errado, é só sair do container. A parte boa da modernização é justamente essa: errar fica barato.

A minha opinião

O desktop open source passou duas décadas tentando ganhar do Windows no jogo do Windows. Não ganhou. O que está mudando agora é diferente: em vez de copiar, ele está construindo algo que o desktop comercial ainda não tem direito. Sistema base que não quebra, apps isolados por padrão, rollback de graça. A transição vai ser chata, e quem depende de ferramenta antiga vai sofrer primeiro. Mas o destino faz sentido, e pela primeira vez em muito tempo parece que a comunidade está remando para o mesmo lado.

Eu já trabalho com o ambiente de dev em container faz um tempo e não volto atrás. Se quiser ver o que sai desse ambiente, dá uma olhada nos projetos que eu tenho construído.

O desktop Linux ainda carrega decisões de 1987. E isso finalmente está mudando.

GNOME e KDE já anunciaram o fim da sessão X11. Wayland, Flatpak e sistema imutável deixaram de ser "um dia, quem sabe" e viraram plano com prazo.

Para quem programa, isso pesa no dia a dia: nada de instalar tudo na raiz, editor em Flatpak que não acha o seu Node, captura de tela que agora depende de portal.

Minha saída foi o ambiente de dev em container com distrobox. Cada projeto com as próprias dependências, o sistema base limpo e, se algo dá errado, é só sair do container.

O Steam Deck já provou que o modelo funciona para gente comum. Errar ficou barato.

Escrevi no blog o que eu faria hoje, na prática, para me adiantar sem reinstalar nada. O link está nos comentários.

#Linux #OpenSource #Wayland #DevExperience #Desenvolvimento