Depois de rodar o Guix System por um tempo na minha máquina principal, resolvi escrever minhas impressões sobre a distro, seus pontos fortes, quem é seu público e também fazendo algumas comparações com o NixOS. São duas distros que tentam resolver o mesmo problema, cada uma com sua particularidade.
O que é o Guix System
Guix é um gerenciador de pacotes funcional e transacional, e o Guix System é a distribuição GNU/Linux construída em cima dele. A ideia central é a mesma do Nix: builds isolados e reprodutíveis, ambiente descrito de forma declarativa, rollback de qualquer mudança e múltiplos perfis/gerações coexistindo sem conflito. A grande diferença de proposta é que, no Guix, tudo — do gerenciador de pacotes ao daemon de build, passando pela linguagem de configuração — é escrito em Guile Scheme, um dialeto de Lisp que é também a linguagem de extensão oficial do projeto GNU. Não existe uma DSL própria como o Nix language: você escreve Scheme de verdade, com REPL, macros higiênicas, e todas as ferramentas do ecossistema Guile à disposição.
Isso não é só estética. Como pacotes e serviços são código Scheme rodando dentro do próprio Guix (e não uma linguagem separada e congelada por compatibilidade), as APIs internas podem evoluir com mais liberdade — quem lê o pacote sempre está lendo com a versão correspondente do Guix.
Pontos fortes e o que faz dele único
Atualizações de Segurança Instantâneas com “Grafts”
Quando uma biblioteca base crítica (como a glibc ou openssl) recebe uma atualização de segurança no Nix, por exemplo, praticamente todo o seu grafo de dependências precisa ser recompilado (ou baixado novamente dos servidores de cache), gerando builds gigantescos ou alta dependência do cache da comunidade.
O Guix resolve isso com um mecanismo chamado Grafting (Enxerto). Ele substitui cirurgicamente a referência da biblioteca antiga pela nova diretamente dentro dos binários já existentes no store, sem quebrar o hash de derivação e sem exigir uma recompilação em massa. Suas correções de segurança acontecem em segundos.
guix shell e ambientes efêmeros muito flexíveis. Na 1.5.0 o comando ganhou --emulate-fhs (pra rodar binários que esperam um FHS tradicional dentro do container) e --nesting (permite usar o próprio Guix dentro de containers do guix shell), além do root do container agora ser somente-leitura por padrão, com --writable-root quando necessário. Isso é comparável ao nix shell/nix develop, mas com sandboxing por padrão mais explícito.
guix pack para distribuir software fora do Guix. A 1.5.0 trouxe formatos novos: rpm e appimage, além de --max-layers e --file para builds de imagem de container. Isso facilita pegar algo empacotado no Guix e distribuir pra quem não usa Guix nem Nix. Possuindo o código-fonte de um programa você pode, facilmente, criar um .appimage de um software e fazer a distribuição dele para qualquer pessoa por exemplo.
GNU Shepherd como init, também em Scheme. Diferente do systemd (usado pela maioria das distros, NixOS incluso) ou mesmo do runit, o Shepherd é o init do Guix System, e com a 1.5.0 chegou na versão 1.0, trazendo serviços com timer (equivalente a timers do systemd), suporte a kexec reboot e um sistema próprio de logs/rotação que substitui Rottlog e syslogd. Serviços do sistema são definidos como registros Scheme — dá pra inspecionar e estender programaticamente.
Uma documentação completíssima. O manual do Guix é uma das coisas mais completas que eu já vi, bem documentado e com disponibilização de várias línguas, além de ser bem simples de entender - ainda não existe algo como uma wiki, mas o manual já cobre bastante coisa e muito bem. Acho que essa é uma das partes mais incômodas para quem já tentou começar a usar o NixOS, a documentação dele é simplesmente horrível - algo que os usuários tentam driblar com trabalhos da comunidade.
Transformações de pacote pela linha de comando. --with-version, --with-configure-flag (novos na 1.5.0), além dos já existentes --with-source, --with-patch etc., permitem alterar um pacote na hora do build sem precisar fazer fork do canal. É um recurso que o Nix tem via overlays, mas no Guix isso é first-class na CLI.
Crescimento real do catálogo. Desde a 1.4.0 foram mais de 12.500 pacotes novos e quase 30.000 atualizados, num total de mais de 32 mil pacotes no canal principal — o suficiente pra manter o Guix entre as dez maiores distros por número de pacotes segundo o Repology, mesmo sendo bem menor em contribuidores que o Nixpkgs.
Outros destaques da 1.5.0 que valem menção: ~40 novos serviços de sistema (Forgejo Runner, RabbitMQ, iwd, dhcpcd entre eles), serviço declarativo para KDE Plasma 6.5, GNOME atualizado com Wayland como padrão, correções para cinco CVEs no daemon, imagens oficiais para RISC-V 64-bit, e suporte experimental ao kernel GNU Hurd — inclusive com criação automática de childhurds via serviço de sistema.
Guix vs. NixOS: onde cada um ganha
Linguagem de configuração. Aqui é onde a preferência pessoal pesa mais. Guile Scheme é uma linguagem de propósito geral, madura, com REPL interativo de verdade (dá pra fazer eval de trechos da sua configuração no Emacs enquanto edita, por exemplo) e sem curva de aprendizado dedicada — se você já programa em Lisp/Scheme, já sabe ler configuração de Guix. A linguagem Nix é uma DSL desenhada especificamente pra isso, o que a torna mais enxuta pra casos comuns, mas também mais limitada fora desse escopo e com uma sintaxe que soma mais uma coisa pra aprender. Eu pessoalmente achei mais fácil aprender e entender a lógica do Scheme do que da Nix language.
Flakes vs. guix describe/guix time-machine. O Nix tem flakes como forma padronizada de fixar (pin) inputs e reproduzir builds exatamente. O Guix não tem um equivalente direto: você usa guix describe pra gerar a lista de canais fixados numa revisão específica, e guix time-machine pra voltar/avançar no tempo com base nisso. Funciona, mas com uma limitação relevante — ele não rastreia “inputs dos inputs” da forma que flakes fazem. Se um canal seu depende de outro canal, essa dependência transitiva não fica registrada automaticamente do jeito que aconteceria com um flake.lock. Na prática, isso significa mais cuidado manual pra garantir reprodutibilidade de configurações que dependem de vários canais de terceiros.
Home Manager vs. Guix Home / rde. Pro gerenciamento declarativo do ambiente de usuário (dotfiles, pacotes por usuário, serviços de sessão), o Nix tem o Home Manager, um projeto maduro com cobertura enorme de aplicações. O equivalente no Guix é o guix home (que nasceu do projeto RDE, de Andrew Tropin/abcdw, e depois foi incorporado ao Guix oficial), usando o mesmo mecanismo de extensão de serviços do guix system. Ele é elegante e consistente com o resto do Guix, mas ainda tem bem menos serviços prontos que o Home Manager — se a sua aplicação favorita não tiver um home-service escrito, você vai ter que escrever o seu. O projeto RDE em si vale mencionar à parte: é mais que um “home manager”, é uma proposta mais opinativa e completa de ambiente de desenvolvimento/desktop baseada em Guix, incluindo configuração de um GNU Emacs, mas isso também o torna mais “tudo ou nada” pra quem só quer algo pontual.
Disponibilidade de binários pré-compilados. O cache oficial do Nix (cache.nixos.org) é enorme e cobre praticamente tudo. O Guix também tem substitutos (ci.guix.gnu.org), mas a cobertura historicamente é menor, especialmente pra combinações menos comuns de arquitetura/pacote — o que te faz esperar que compilações do zero sejam mais frequentes (apesar de terem rolado pouco comigo).
Por que Guix pode ser a escolha certa (pra você)
Não dá pra dizer que o Guix System é uma distro pra todo mundo, nem dá pra dizer que “Guix é objetivamente melhor que Nix” — são propostas com pesos diferentes. O Guix é pra você se:
- Você prefere configurar tudo numa linguagem só, com REPL, em vez de aprender uma DSL nova e/ou já vive no ecossistema Lisp/Scheme/Emacs.
- Você prefere um projeto com políticas de “free software” muito claras desde o primeiro dia e documentação bem feita.
- Não quer usar systemd. Shepherd escrito em Scheme como PID 1 é mais fácil de estender/depurar pra quem já programa Scheme do que mexer em unidades systemd ou em Nix modules pra isso.
Ressalvas importantes
Como nem tudo é perfeito, e aqui entram os pontos que costumam pegar gente de surpresa:
É um projeto GNU oficial, com tudo que isso implica. O Guix segue as Free System Distribution Guidelines da FSF à risca: nada de firmware não-livre, nada de microcódigo de CPU, nada de drivers proprietários no canal oficial — nem pra recomendação em canais de suporte oficiais (mailing list, IRC/Matrix). Na prática, isso significa que instalar Guix “puro” numa máquina moderna pode deixar seu Wi-Fi, GPU ou até correções de segurança de microcódigo de CPU faltando, porque essas atualizações de microcódigo (que corrigem vulnerabilidades reais de hardware) são tratadas como blobs não-livres e ficam de fora por política, não por limitação técnica.
Nonguix resolve isso, mas é um projeto à parte. O Nonguix é um canal comunitário (fora da infraestrutura oficial) que fornece o kernel Linux “normal” (não o linux-libre, ou seja, linux, linux-lts entre outros), firmware não-livre, initrd com carregamento de microcódigo, drivers da Nvidia e outros pacotes que não podem entrar no Guix oficial por política. É praticamente indispensável pra quem quer instalar Guix System num notebook/desktop comum com Wi-Fi funcionando de primeira. A ressalva importante: os próprios mantenedores do Nonguix pedem explicitamente pra não promover ou pedir suporte do Nonguix nos canais oficiais do Guix — é uma forma de respeitar a política do projeto principal e evitar atrito. É bastante comum ver usuários que contribuem no nonguix contribuirem também no guix e o clima num geral é bem amistoso. Mas é preciso ter em mente que bugs do Nonguix vão para os mantenedores do Nonguix, não para a lista do Guix.
No meu caso pessoal precisei do nonguix porque meu laptop até dá boot com o kernel linux-libre mas usa um driver de vídeo genérico e o wi-fi não funciona, trocar pro linux-lts foi relativamente simples e tudo está funcionando 100%.
guix.moe é outra peça externa ao projeto oficial. O guix moe é uma iniciativa comunitária (mantida por um único desenvolvedor, “hako”) que oferece um build farm/cache de substitutos (ci.guix.moe, com espelho via CDN da Cloudflare) e imagens de instalação (LiveCDs) já com Nonguix embutido (essa que usei para fazer minha atual instalação) — o que facilita bastante pra quem não quer passar pelo processo manual de configurar o Nonguix durante a instalação em modo shell. É um serviço útil, mas vale ter em mente que é infraestrutura de terceiros, não oficial, dependente da disponibilidade de quem mantém e na confiança. Hako é um dev bem ativo, inclusive no próprio projeto do guix.
Curva de aprendizado e tamanho de comunidade. Mesmo com a documentação melhorada na 1.5.0, o Guix ainda espera bem mais familiaridade com Scheme do que o Nix espera com sua própria linguagem — que, sendo uma DSL dedicada, tem exemplos mais “copiáveis” pra quem só quer resolver um problema pontual sem aprender uma linguagem de programação completa. A comunidade também é sensivelmente menor que a do Nix/NixOS, o que se reflete em menos posts de blog e times menores.
Menos “tudo pronto” no geral. Seja em serviços do guix home, seja na disponibilidade de binários em cache, seja em quantidade total de pacotes — o Guix ainda corre atrás do Nixpkgs em cobertura bruta, mesmo crescendo rápido (12.500+ pacotes novos desde a última versão estável).
Porém, acredito que isso possa servir até como um convite ao espírito “hacker” do sistema. No Guix, quando algo não está pronto, resolver o problema é bastante acessível. Criar um pacote novo ou estender um serviço é literalmente escrever uma receita simples em Lisp (muitas vezes herdando e modificando pacotes existentes com poucas linhas) e carregá-la localmente com um guix install -f. Se você gosta de entender como as coisas funcionam por baixo do capô e preza pela autonomia de conseguir se virar sozinho com facilidade, o Guix é um prato cheio.
Conclusão
Se reprodutibilidade determinística e rollback são o que você busca, tanto Guix System quanto NixOS entregam. A escolha entre os dois, na prática, vira uma questão de que trade-offs você tolera.
Pra quem gosta de Lisp, valoriza a coerência de “tudo é Scheme” e não se importa de rodar Nonguix pra ter uma máquina utilizável no dia a dia, o Guix System está num dos melhores momentos da sua história. Decidi dar uma chance e estou me apaixonando cada vez mais pela distro e o que ela representa. Vale o teste, principalmente numa VM antes de ir de cabeça numa máquina principal.
E você, já testou Guix System ou o guix como gerenciador de pacotes? Vamos trocar figurinhas!
Vou deixar aqui no post também meu repo no github com meus arquivos de config da distro, ainda preciso atualizar eles lá, mas dá pra ter uma ideia geral.