5 distros Linux que você talvez não conheça
Compare cinco distribuições Linux pouco conhecidas para desenvolvedores: CachyOS, Bazzite, Nobara, Vanilla OS e Chimera Linux, com foco em drivers, atualizações e ferramentas.
A melhor distro Linux para desenvolvedores é aquela que faz toolchains, contêineres e drivers de GPU funcionarem com o mínimo de atrito. CachyOS, Bazzite, Nobara, Vanilla OS e Chimera Linux fazem, cada uma, uma escolha diferente em relação a esses três pontos.
A maioria das listas de “melhor distro” é, na verdade, um conjunto de benchmarks de jogos. Elas mostram taxas de quadros, não se o npm install, o Docker ou a sua IDE vão funcionar direito numa terça-feira de manhã.
Seu laptop não precisa mais espelhar o ambiente de produção, porque os contêineres agora cuidam disso. Assim, a escolha do sistema operacional host se resume a três fatores: drivers, comportamento das atualizações e a forma como você instala ferramentas. Este artigo analisa cinco distros menos conhecidas sob essas três perspectivas. Omarchy e Garuda Linux têm artigos próprios, por isso ficaram de fora aqui.
Principais conclusões
- CachyOS é Arch com um kernel ajustado e repositórios otimizados por CPU, então os repositórios do Arch, o AUR e a Arch Wiki continuam valendo.
- Em distros imutáveis como Bazzite e Vanilla OS, os pacotes do host são aplicados em camadas sobre uma imagem somente leitura, e as toolchains de linguagens ficam em contêineres que compartilham seu diretório home.
- Nobara é um Fedora gravável com codecs e drivers NVIDIA pré-instalados, então a documentação do Fedora e os hábitos com
dnfcontinuam valendo. - Chimera Linux usa musl, LLVM/Clang, ferramentas base do FreeBSD e dinit, o que significa que binários pré-compilados exclusivos para glibc podem falhar sem um contêiner glibc.
- Nenhuma dessas distros muda o ambiente em que seu código roda em produção. A escolha define como as ferramentas chegam à máquina e como as atualizações são aplicadas.
CachyOS: Arch ajustado para desempenho
CachyOS é uma distribuição rolling release baseada no Arch. Ela se diferencia do Arch padrão em dois aspectos: um kernel ajustado pelo CachyOS que usa, por padrão, um escalonador EEVDF otimizado (o BORE e outros escalonadores são opcionais), e repositórios de pacotes compilados para x86-64-v3, x86-64-v4 e AMD Zen 4/5. É indicada para desenvolvedores que já gostam do Arch e querem que o ajuste fino venha pronto.
- Pacotes: repositórios do Arch mais o AUR. CLIs incomuns, language servers e SDKs de nicho geralmente estão a um pacote de distância.
- Antes de começar a trabalhar: instale seus runtimes e o Docker ou Podman pelos repositórios. Nada atrapalha.
- NVIDIA: o empacotamento NVIDIA do Arch e a página sobre NVIDIA da Arch Wiki se aplicam diretamente.
- Como máquina de trabalho: atualizações do kernel, do Mesa e das toolchains chegam continuamente, e espera-se que você leia as notícias antes de grandes upgrades.
O custo: a manutenção típica de um rolling release. Uma atualização problemática em dia de prazo é problema seu.
Bazzite: Fedora Atomic com imagens NVIDIA separadas
Bazzite é uma distribuição imutável cujo sistema base é uma imagem Fedora Atomic somente leitura. Ela é atualizada como uma unidade única, e o rollback é feito inicializando a imagem anterior. Isso significa que você não instala ferramentas de desenvolvimento globalmente, como faria com o dnf. É indicada para desenvolvedores que querem uma máquina que se mantenha consistente e estão dispostos a trabalhar dentro de contêineres.
- Pacotes: Flatpak para aplicativos gráficos, camadas com rpm-ostree para software do host e contêineres para toolchains. O Bazzite vem com o Distrobox. Se você quiser Docker pronto para uso, ele vem na variante Bazzite DX, não na imagem padrão.
- Antes de começar a trabalhar: crie um contêiner de desenvolvimento.
- NVIDIA: o Bazzite oferece imagens específicas para NVIDIA. Escolha a sua na página de download.
- Como máquina de trabalho: as atualizações são atômicas e podem ser revertidas, mas seu diretório home, seus contêineres e os pacotes em camadas continuam sendo sua responsabilidade.
Em um sistema Fedora imutável, você adiciona pacotes no nível do host como camadas sobre a imagem com o rpm-ostree, e eles passam a valer após uma reinicialização. As toolchains de linguagens ficam em um contêiner Distrobox ou Toolbx que compartilha seu diretório home:
rpm-ostree install zsh # host layer, applied on next boot
systemctl reboot
distrobox create --name dev --image registry.fedoraproject.org/fedora:latest
distrobox enter dev
sudo dnf install nodejs gcc make # inside the container only
rpm-ostree rollback # revert to the previous deployment
Tudo o que você instalar dentro de dev fica fora da imagem do host, e excluir o contêiner remove tudo.
A base somente leitura do Bazzite quebra hábitos. Talvez você normalmente resolva problemas com sudo e um editor de texto, e domine permissões e propriedade de arquivos de cor. No Fedora Atomic, /usr é somente leitura. /etc continua gravável, mas o OSTree mescla suas alterações a cada nova imagem. Há ainda outra armadilha: uma IDE empacotada como Flatpak roda em um sandbox, então ela pode não enxergar os compiladores do seu contêiner ou do host, a menos que você a configure para isso.
O custo: cada instalação de ferramenta exige decidir antes se ela pertence ao host, a um contêiner ou a um Flatpak.
Nobara: Fedora sem as arestas
Nobara é um Fedora comum e gravável, com codecs de mídia, drivers NVIDIA e patches de kernel voltados para jogos. A maior parte da documentação do Fedora e dos hábitos com dnf continua valendo sem alterações. É mantido por GloriousEggroll e é indicado para usuários de Fedora cansados de configurar codecs e drivers a cada instalação.
- Pacotes:
dnf, Flatpak e o ecossistema Fedora, além dos repositórios próprios do Nobara. - Antes de começar a trabalhar: muito pouco. Instale seus runtimes e o engine de contêineres como faria no Fedora.
- NVIDIA: pré-instalado, o que elimina a fonte mais comum de atrito no primeiro boot do Fedora.
- Como máquina de trabalho: um sistema mutável. Você pode editar qualquer coisa e também quebrar qualquer coisa.
O custo: um projeto menor que o Fedora. Quando algo quebra, você precisa investigar tanto os patches do Nobara quanto o upstream.
Vanilla OS: imutável e com foco em contêineres
O Vanilla OS mantém o sistema base imutável e transfere a instalação de software para contêineres. Instalar um compilador começa com a decisão sobre em qual contêiner ele vai ficar, e não de qual repositório ele vem. É indicado para desenvolvedores que precisam com frequência de pacotes de várias distribuições em uma única máquina.
- Pacotes: o host é gerenciado pelo ABRoot, que aplica cada atualização em uma segunda partição raiz e alterna para ela na próxima reinicialização. O Apx gerencia contêineres baseados em outras distribuições e expõe os gerenciadores de pacotes delas a partir do host. O Flatpak cuida dos aplicativos gráficos.
- Antes de começar a trabalhar: crie um contêiner Apx para cada família de toolchains.
- NVIDIA: consulte a documentação do projeto para o seu hardware.
- Como máquina de trabalho: valem as mesmas contrapartidas de sistemas imutáveis do Bazzite, mas com as ferramentas próprias do Vanilla em vez do rpm-ostree.
O custo: ferramentas específicas do Vanilla. A documentação do Fedora Atomic e do Arch não se aplica de forma direta.
Chimera Linux: a realmente diferente
O Chimera Linux é uma distribuição independente e rolling release que evita o GNU sempre que possível. Ele usa musl em vez de glibc, ferramentas base do FreeBSD em vez do GNU coreutils, LLVM/Clang como toolchain do sistema e dinit como init. Os pacotes são gerenciados pelo apk-tools. É indicado para programadores de sistemas e para quem quer testar portabilidade.
- Pacotes: repositórios apk. Qualquer coisa que dependa do empacotamento do Arch ou do Fedora precisa de um contêiner.
- Antes de começar a trabalhar: verifique se seus runtimes funcionam com musl.
- NVIDIA: consulte a documentação do projeto sobre suporte a NVIDIA.
- Como máquina de trabalho: shell scripts escritos para o GNU coreutils podem se comportar de forma inesperada, porque as ferramentas BSD usam flags diferentes.
Uma distribuição baseada em musl como o Chimera Linux compila e executa seu próprio código sem problemas. Já binários pré-compilados vinculados à glibc são outra história: CLIs de fornecedores e pacotes que publicam apenas builds para glibc podem não funcionar sem uma camada de compatibilidade ou um contêiner glibc.
O custo: as premissas do ecossistema. A maior parte do mundo distribui binários compilados para glibc.
Qual é a melhor distro Linux para desenvolvedores?
- Se você vive no AUR e não se importa com atualizações contínuas, o CachyOS oferece o Arch com o ajuste fino já feito.
- Se você quer um sistema operacional estável e não se importa em desenvolver dentro de contêineres, o modelo de imagens do Bazzite e o Distrobox atendem.
- Se você já conhece o Fedora e só quer NVIDIA e codecs resolvidos, o Nobara mantém seus hábitos intactos.
- Se você precisa com frequência de pacotes de várias distribuições em uma única máquina, o Vanilla OS coloca cada toolchain em seu próprio contêiner Apx.
- Se você quer um sistema não convencional para testar portabilidade, o Chimera vai expor todas as premissas de glibc e GNU do seu código.
Nenhuma delas muda o ambiente em que seu código roda em produção. A escolha define como as toolchains chegam à máquina, como as atualizações são aplicadas e quanto trabalho com drivers é necessário antes de abrir um editor. Escolha o cenário que corresponde ao seu, instale a distro em uma partição sobressalente e recrie ali o ambiente do seu projeto atual antes de se comprometer.
Perguntas frequentes
Preciso reiniciar toda vez que executo rpm-ostree install no Bazzite ou no Fedora Atomic?
Não, se você estiver apenas adicionando pacotes. Por padrão, toda operação do rpm-ostree é offline e só passa a valer no próximo boot, mas rpm-ostree install --apply-live (forma abreviada -A) aplica os pacotes recém-adicionados em camada ao sistema em execução imediatamente. A aplicação ao vivo funciona apenas para adição de pacotes, sem outras alterações pendentes. Remoções ainda exigem reinicialização, e rpm-ostree apply-live --reset reverte para a árvore inicializada.
O CachyOS funciona em CPUs mais antigas sem suporte a x86-64-v3?
Sim. O CachyOS mantém um repositório x86-64 genérico junto às builds x86-64-v3, x86-64-v4 e Zen 4/5. Durante a configuração, o instalador e o script de repositórios identificam o que o processador suporta e escolhem o nível de repositório mais adequado. CPUs sem AVX2 recebem os pacotes genéricos, então a base rolling do Arch e as ferramentas do CachyOS continuam valendo. Executar /lib/ld-linux-x86-64.so.2 --help mostra quais níveis sua CPU suporta.
Qual é a diferença entre Distrobox e Toolbx para contêineres de desenvolvimento?
Ambos criam contêineres de longa duração que compartilham seu diretório home com o host. O Toolbx roda apenas sobre o Podman e funciona melhor com imagens no estilo Fedora. O Distrobox encapsula o Podman ou o Docker, recorre ao seu próprio gerenciador Lilipod como alternativa e executa imagens de praticamente qualquer distribuição. O Toolbx atende contêineres Fedora no Fedora Atomic. O Distrobox é a escolha certa quando você precisa de um userland Arch, Ubuntu ou Alpine, por exemplo, para uma ferramenta de fornecedor distribuída apenas como .deb.
A versão Flatpak do VS Code consegue usar compiladores instalados no Distrobox ou no host?
Não por padrão. O pacote do VS Code no Flathub roda em um sandbox que não acessa SDKs instalados no host, então toolchains em um contêiner Distrobox ou adicionadas em camada com rpm-ostree ficam invisíveis. As notas do pacote listam três soluções alternativas: executar comandos do host via flatpak-spawn --host ou host-spawn, apontar o terminal integrado para um shell do host, ou instalar extensões do Freedesktop SDK, como o SDK de Go ou de .NET, dentro do sandbox.
Observação: esta tradução segue o português do Brasil. Se preferir uma versão adaptada ao português europeu (por exemplo, “ficheiro”, “ecrã”, “utilizador”), posso ajustá-la.