O Linux no desktop sempre foi um espaço de experimentação. Ao longo das décadas, ele já passou por mudanças profundas na forma de instalar programas, atualizar o sistema, lidar com hardware e até na maneira como as pessoas interagem com o computador no dia a dia. Ainda assim, existe uma sensação confortável de familiaridade: instalar uma distro, abrir o gerenciador de pacotes, rodar um update, instalar aplicativos e seguir a vida.
Só que esse modelo, que parece tão “natural” hoje, pode não ser o padrão no futuro.
E não estamos falando de um futuro distante. Se projetos como o Bluefin, o Bazzite e o SteamOS realmente emplacarem, e há fortes indícios de que isso está acontecendo, o Linux no desktop pode se tornar algo estruturalmente diferente do que você está acostumado.
Talvez mais seguro, mais previsível… e um pouco estranho à primeira vista.
O início de uma mudança maior
Se você ainda não sabe exatamente o que é o Bluefin, relaxa: essa confusão é completamente compreensível. Inclusive, entender o que ele é — e o que ele não é — ajuda bastante a compreender o rumo que parte do ecossistema Linux parece estar tomando.
O Bluefin é um sistema operacional criado pelo projeto Universal Blue, baseado no Fedora, que adota um modelo de sistema imutável e fortemente orientado a tecnologias modernas como containers, Flatpak, Wayland e PipeWire. Ele não está sozinho nessa abordagem.
O SteamOS, usado no Steam Deck, segue princípios semelhantes. O Bazzite, que também nasce dentro da comunidade Universal Blue, aplica a mesma filosofia com foco maior em jogos. E, fora desse ecossistema, gigantes como Red Hat, Canonical, SUSE e Oracle já falam abertamente sobre desktops imutáveis como um caminho natural para o futuro.
O que é, afinal, um sistema imutável?
O nome “imutável” costuma assustar. Ele passa a ideia de um sistema engessado, travado, onde o usuário não pode mexer em nada. Mas isso não é verdade.
Um sistema de base imutável é completamente modificável, só que a forma de fazer essas modificações é diferente do Linux tradicional.
Em uma distro clássica, como Ubuntu, Fedora Workstation, Arch ou Linux Mint, o sistema permite que arquivos essenciais da raiz sejam modificados diretamente pelo gerenciador de pacotes ou pelo próprio usuário. Quando você roda um apt upgrade, dnf upgrade ou pacman -Syu, o sistema substitui arquivos em tempo real, um por um.
Isso funciona bem na maioria das vezes, mas não é à prova de falhas.
O problema das atualizações tradicionais
Em um sistema Linux tradicional, aplicativos e bibliotecas costumam compartilhar dependências. Dois programas diferentes podem usar exatamente a mesma biblioteca ao mesmo tempo, o que economiza espaço em disco, mas cria um problema estrutural.
Imagine que dois programas dependem da mesma biblioteca, digamos, a versão 1.0. Um deles recebe uma atualização e agora exige a versão 2.0 dessa biblioteca. O gerenciador de pacotes faz o que parece correto: atualiza a biblioteca para a versão mais nova.
Resultado: o programa atualizado funciona, mas o outro pode quebrar.
Esse tipo de situação ficou menos comum com o tempo, graças à maturidade das distros, mas nunca deixou de existir. E além disso, uma atualização interrompida por queda de energia, erro de dependência ou falha de disco pode deixar o sistema em um estado inconsistente.
Tudo ou nada
Sistemas imutáveis funcionam de outra forma. Em vez de modificar arquivos da raiz em tempo real, o sistema baixa uma imagem completa da nova versão do sistema operacional, geralmente em segundo plano.
Essa atualização só entra em vigor no próximo boot. Ou ela acontece por completo, ou simplesmente não acontece.
Não existe “meio atualizado”. Se algo der errado, o sistema pode simplesmente voltar para a imagem anterior, que já estava funcionando.
Esse modelo é usado há décadas em ambientes de computação em nuvem. E é exatamente por isso que serviços grandes continuam funcionando mesmo quando algo dá errado, ou se recuperam muito rápido quando falham.
Mas isso faz sentido em desktop?
Essa é a pergunta-chave.
À primeira vista, parece que esse modelo só funciona bem em servidores, onde o usuário interage com aplicações e não diretamente com o sistema operacional. Mas, pensando bem, isso também é verdade para a maioria dos usuários de desktop.
A esmagadora maioria das pessoas só interage com aplicativos. Navegador, editor de texto, IDE, cliente de e-mail, jogos. Pouquíssimos usuários realmente mexem nas entranhas do sistema.
Por isso, para um grande público, a diferença entre um sistema tradicional e um imutável pode ser praticamente invisível.
Um bom exemplo disso é o Android. Ele é um sistema imutável. E quase ninguém reclama disso.
O papel dos containers
Em sistemas como o Bluefin, os aplicativos não vêm do repositório tradicional da distro. Eles são instalados principalmente via Flatpak, além de AppImages e containers mais clássicos como Docker e Podman.
Ferramentas como Distrobox permitem criar ambientes baseados em qualquer distro Linux dentro de containers, dando acesso a repositórios do Arch, Debian, Ubuntu ou Fedora sem misturar esses pacotes com a base do sistema.
O Homebrew também entra nesse ecossistema como uma forma moderna e multiplataforma de instalar ferramentas de linha de comando.
O resultado é um sistema onde a raiz permanece intacta, previsível e confiável, enquanto o usuário continua livre para instalar praticamente qualquer software que precise.
O Bluefin brinca com a ideia de ser “distroless”. Não no sentido literal de não ter uma distribuição por baixo, mas no sentido de que a distro base se torna menos relevante no uso diário.
Se os aplicativos vêm do Flathub, as ferramentas técnicas vêm do Homebrew ou de containers, faz tanta diferença assim se a base é Fedora, Ubuntu ou Arch?
Hoje, ainda faz alguma. Versões de kernel, drivers e componentes base ainda importam. Mas, no longo prazo, essa diferença tende a diminuir.
A distro deixa de ser o centro da experiência e passa a ser apenas o ponto de partida.
E se você quiser mexer fundo no sistema?
É aqui que entram os principais contrapontos.
Se você precisa modificar profundamente o sistema, trocar kernel, alterar componentes centrais, aplicar patches específicos, isso ainda é possível em sistemas imutáveis. Mas o caminho correto é criar uma nova imagem do sistema, e não alterar arquivos diretamente.
A vantagem é óbvia: se algo der errado, o rollback está ali, fácil e rápido. A desvantagem é que isso exige uma mudança de mentalidade. É menos “hackear na hora” e mais “planejar a mudança”.
Por que esse modelo é tão atraente para empresas?
Previsibilidade.
Para empresas e desenvolvedores, a possibilidade de saber exatamente como o sistema do usuário vai se comportar é enorme. Atualizações quebram menos. Bugs são mais reproduzíveis. Suporte técnico fica mais simples.
Não é à toa que empresas grandes do ecossistema Linux estão investindo pesado nessa abordagem.
Mas isso não significa o fim do Linux tradicional. A comunidade Linux sempre foi plural. Da mesma forma como gestores de pacotes modernos um dia foram vistos como polêmicos, e projetos como o Slackware continuam existindo até hoje, sempre haverá alternativas.
Se você não gostar desse modelo, outras distros continuarão oferecendo abordagens tradicionais. Early adopters e early resisters sempre coexistiram no mundo Linux.
Estranho no começo, natural depois
Sistemas imutáveis, desktops baseados em containers e a ideia de um Linux “distroless” podem parecer esquisitos hoje. Mas muitas tecnologias que hoje consideramos normais também foram vistas assim no começo.
Se esse modelo se tornar o padrão, softwares que ainda não se adaptaram provavelmente vão precisar mudar para sobreviver. Da mesma forma que hoje um simples tarball raramente é suficiente, talvez no futuro um .deb ou .rpm também não seja.
Talvez esse não seja o Linux que você está acostumado. Mas pode muito bem ser o Linux que a maioria das pessoas vai usar daqui pra frente.
Quer um exemplo mais prático do uso de um sistema imutável no dia a dia? Confira nossa experiência com o Bazzite!