12k
All articles

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.

OpenReplay Team
OpenReplay Team
5 distros Linux que você talvez não conheça

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 dnf continuam 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.

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — self-hosted, with full data ownership.

Star on GitHub

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.

We use cookies to improve your experience. By using our site, you accept cookies.