Desktop open source: as ideias para modernizá-lo de vez

Uma atualização de pacote quebrou meu ambiente gráfico às 23h de uma terça, e eu passei a noite num TTY lendo log. Quem usa Linux no desktop há alguns anos provavelmente tem uma história parecida. A LWN publicou um texto com ideias para modernizar o desktop open source, e a pergunta de fundo é justamente essa: como fazer um sistema que não quebre quando você só queria atualizar o navegador?

Vou dizer o que está em discussão, por que isso importa para quem desenvolve e o que muda na prática.

O que significa modernizar o desktop open source

O modelo clássico de distro Linux tem décadas. Um gerenciador de pacotes instala tudo num único sistema de arquivos compartilhado. O app, a biblioteca de sistema e o kernel ficam no mesmo balaio. Atualizar uma coisa pode mexer em outra.

Esse modelo funcionou bem para servidores e para quem sabe consertar o próprio sistema. Para a pessoa comum, e até para dev que só quer trabalhar, ele cobra caro.

A conversa sobre modernização gira em torno de alguns eixos que já estão em andamento há anos:

• Sistema base imutável: a raiz do sistema é somente leitura e atualizada como uma imagem inteira. Deu problema? Você volta para a versão anterior no boot.
• Apps isolados: aplicativos rodam em sandbox, com permissões explícitas, e vêm de um formato comum entre distros, como o Flatpak.
• Portais: em vez de o app ler o disco inteiro, ele pede ao sistema "abre um seletor de arquivos" e recebe só o que o usuário escolheu.
• Wayland como padrão: o X11 está saindo de cena. O GNOME já tirou a sessão X11 do padrão e o KDE também tem data para parar de mantê-la.

Nada disso é novo isoladamente. O Fedora Silverblue existe desde 2018. O Flathub virou a loja de fato de muita gente. O que mudou é que as peças finalmente parecem prontas para virar o jeito normal de usar Linux, e não um experimento para entusiasta.

Por que o modelo antigo começou a pesar

O problema central é o acoplamento. Quando todo app depende das bibliotecas que a distro empacotou, cada distro vira um alvo diferente. Quem mantém um app desktop precisa testar em Ubuntu, Fedora, Arch, Debian estável e mais meia dúzia. Na prática, ninguém testa, e o usuário descobre o bug.

Um exemplo que todo dev de frontend entende: imagine que o node_modules do seu projeto fosse compartilhado com todos os outros projetos da máquina. Atualizar o React num projeto atualizaria em todos. Parece absurdo, né? Pois é mais ou menos assim que o desktop Linux tradicional trata bibliotecas de sistema.

Um sistema que você tem medo de atualizar já está quebrado, só não te avisou ainda.

O segundo peso é segurança. No modelo antigo, qualquer app que você instala pode ler seu ~/.ssh, seus tokens no ~/.config e o histórico do navegador. Depois de tanto ataque à cadeia de suprimentos em pacotes npm e PyPI, confiar cegamente em todo binário da máquina ficou difícil de defender.

O que muda para quem desenvolve apps desktop

Se você publica um app para Linux, seja Electron, Tauri ou nativo em GTK ou Qt, a direção é clara: empacotar uma vez, rodar em qualquer distro, pedir permissão para o que precisa.

Um manifesto Flatpak simples já mostra a mudança de mentalidade:

app-id: dev.horvatti.MeuApp
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
command: meu-app
finish-args:
  - --share=network
  - --socket=wayland
  - --socket=fallback-x11
  - --device=dri

Repare no finish-args. Você declara o que o app precisa. Rede, sim. Acesso ao home inteiro, não. Se o app precisa abrir um arquivo, ele usa o portal de seleção de arquivos, e o sistema entrega só aquele arquivo.

Na prática, isso muda três coisas no seu código:

1. Caminhos fixos param de funcionar. Aquele fs.readFileSync(os.homedir() + '/Documentos/config.json') vai falhar dentro do sandbox. Use o diálogo de arquivos do framework, que no Electron e no Tauri recentes já passa pelo portal.
2. Wayland deixa de ser opcional. Captura de tela, atalhos globais e posição de janela funcionam de outro jeito. Se o seu app depende de "pegar a tela inteira", ele precisa usar o portal de screencast.
3. Atualização vira responsabilidade do formato. Você publica no Flathub e a atualização chega para o usuário sem você escrever um auto-updater.

O terceiro ponto sozinho já economiza trabalho. Quem já escreveu updater para Electron sabe o tamanho da dor.

Sistema imutável serve para quem programa?

Essa é a objeção que mais escuto. "Eu preciso instalar compilador, banco, Docker, versão específica do Node. Sistema imutável vai me travar."

A resposta curta: não trava, mas muda o lugar onde as coisas moram. O sistema base fica intocado e o ambiente de desenvolvimento vai para um container. Ferramentas como Toolbx e Distrobox criam um container com a distro que você quiser, integrado ao seu home e ao terminal.

distrobox create --name dev --image fedora:latest
distrobox enter dev
sudo dnf install postgresql nodejs

Dentro do container você faz a bagunça que quiser. Quebrou? Apaga e cria outro em um minuto. O sistema que te dá o desktop continua funcionando.

Eu uso uma variação disso há um tempo e o ganho real é psicológico: parei de ter medo de testar coisas. Isso vale mais do que parece. O custo existe: tem uma curva de aprendizado, algumas ferramentas que mexem em hardware ficam chatas de configurar e o primeiro dia é meio confuso. Mas o custo é pago uma vez só.

O que ainda está mal resolvido

Seria desonesto vender isso como solução pronta. Tem pontos fracos concretos.

Permissões mal declaradas. Muito app no Flathub pede --filesystem=home porque dá menos trabalho do que usar portal. Aí o sandbox vira decoração. O modelo só protege se os mantenedores fizerem a parte deles, e hoje muitos não fazem.

Espaço em disco e duplicação. Cada runtime Flatpak traz suas bibliotecas. A deduplicação ajuda, mas em máquina com SSD pequeno você sente.

Fragmentação de formatos. Flatpak, Snap e AppImage ainda disputam espaço. Para quem publica app, isso significa escolher um lado ou manter três pipelines. Minha opinião: o Flatpak ganhou no desktop fora do Ubuntu, e brigar contra isso é perda de tempo.

Acessibilidade e ferramentas antigas no Wayland. Leitores de tela, automação de interface e utilitários que dependiam de o X11 deixar qualquer programa espiar qualquer janela ainda estão se adaptando. Para parte dos usuários isso não é detalhe, é o que impede a migração.

Minha opinião sobre o rumo do desktop open source

Acho que a direção está certa e demorou. O desktop Linux passou anos otimizando para o usuário que sabe consertar tudo, e esse público nunca foi grande o suficiente para sustentar o ecossistema de apps.

A virada que importa para mim não é técnica, é de responsabilidade. No modelo novo, a distro cuida do sistema, o dev cuida do app, e o usuário escolhe o que cada app pode acessar. Cada um no seu quadrado. É o mesmo desenho que tornou o celular usável para bilhões de pessoas, só que com código aberto e sem uma empresa decidindo o que você pode instalar.

Se você mantém um app desktop, o conselho prático é simples: empacote em Flatpak, pare de assumir acesso ao home e teste no Wayland antes que seu usuário teste por você. E se usa Linux para trabalhar, experimente uma distro imutável com um container de dev. No pior caso, você volta para o modelo antigo. No melhor, nunca mais passa uma terça à noite no TTY.

Se quiser ver como eu aplico essas ideias no dia a dia, dá uma olhada nos projetos que eu mantenho.

Uma atualização de pacote já me deixou uma noite inteira num TTY lendo log. E o problema não era o pacote, era o modelo.

No desktop Linux tradicional, o app, as bibliotecas e o sistema dividem o mesmo espaço. Atualizar uma coisa pode quebrar outra.

A saída que finalmente está amadurecendo: sistema base imutável com rollback, apps isolados em Flatpak e permissões pedidas via portal.

Para quem programa, isso não trava nada. O ambiente de dev vai para um container com Distrobox, e se quebrar você apaga e cria outro em um minuto.

Se você mantém app desktop: empacote em Flatpak, pare de assumir acesso ao home e teste no Wayland antes que seu usuário teste por você.

Um sistema que você tem medo de atualizar já está quebrado, só não te avisou ainda.

Escrevi mais sobre isso no blog, o link está nos comentários.

#Linux #OpenSource #Flatpak #DesenvolvimentoDeSoftware #DevExperience