Snaps. Por quê? Por favor, parem

Artigo original ↗ Discussão no Hacker News ↗

Usuários Linux avaliam os trade-offs entre os pacotes Snap da Canonical e formatos tradicionais gerenciados pela distro, como .deb, Flatpak, AppImage e Docker. Críticos do Snap apontam grande uso de disco, problemas de desempenho, infraestrutura opaca e centralizada, e a tendência do Ubuntu de substituir pacotes nativos (por exemplo, Firefox, Chromium) por snaps, enquanto defensores argumentam que bundles autocontidos e com atualização automática reduzem o inferno de dependências e transferem a manutenção para os desenvolvedores upstream. A tensão mais ampla é sobre quem deve controlar o empacotamento e as atualizações — as distribuições ou os fornecedores de aplicativos — e como equilibrar segurança, conveniência, abertura e limitações de recursos do sistema.

Idade e contexto da discussão

  • A thread se concentra em por que os Snaps existem e se são uma boa ideia, com muitas comparações a Flatpak, AppImage, Docker e ao empacotamento tradicional das distros.
  • Vários comentários observam que a postagem original do fórum é de 2019–2021, mas os problemas ainda são vistos como relevantes.

Espaço em disco, armazenamento e desempenho

  • A principal preocupação: os Snaps consomem muito espaço em disco devido ao empacotamento de dependências e à retenção de várias versões por pacote.
  • Exemplos: snaps base core e GNOME replicados em várias versões; apps pequenas inchando para centenas de MB ou mais.
  • Isso é visto como especialmente problemático em laptops baratos com armazenamento pequeno, muitas vezes não atualizável.
  • Alguns relatam o snapd causando carga alta constante de CPU e logs grandes.

Debate sobre atualizabilidade do hardware

  • Um lado afirma que “muitos laptops” agora têm armazenamento soldado ou eMMC, tornando o espaço algo precioso.
  • Outros argumentam que isso ainda é uma minoria e que a maioria dos laptops usa SSDs facilmente substituíveis.
  • A extensão do uso de eMMC em laptops de consumo é contestada e permanece essencialmente “incerta”.

Modelos de empacotamento e carga para o desenvolvedor

  • Há um argumento forte de que o empacotamento tradicional das distros não escala: esperar que fornecedores publiquem .deb/.rpm para cada distro é irrealista.
  • Outros contrapõem que ferramentas (por exemplo, Open Build Service) e sistemas de build padrão já tornam o empacotamento para múltiplas distros manejável.
  • Alguns argumentam que o empacotamento deve continuar sendo responsabilidade da distro; outros dizem que ele deve ser transferido para os desenvolvedores upstream.

Vantagens percebidas dos Snaps

  • Empacotamento entre distros e distribuição mais fácil de software comercial e de terceiros.
  • Atualizações automáticas e sandboxing restrito são vistos como grandes vantagens para servidores e alguns serviços auto-hospedados (por exemplo, Nextcloud).
  • Alguns consideram os Snaps uma opção melhor para “apps modernas” com muitas dependências, evitando conflitos de bibliotecas.

Principais críticas aos Snaps

  • Uso forçado no Ubuntu (por exemplo, Firefox/Chromium via Snap mesmo quando instalados com apt).
  • Backend de código fechado, store da Canonical codificada, e percepção de centralização/controle de acesso.
  • Grande uso de disco, inicialização lenta, várias versões retidas e poluição de mount com muitos dispositivos loop.
  • Problemas de integração/sandbox: dificuldades com DNS de VPN, cartões inteligentes/YubiKey, CUPS e outros recursos do sistema.
  • Alguns veem o Snap como “tecnologia Canonical inacabada” e uma tentativa de copiar a economia de mobile/app store.

Flatpak, AppImage, Docker, Nix etc.

  • Flatpak é preferido por alguns para apps GUI; ainda há relatos de problemas de permissões, temas e inchaço de runtimes, embora esteja melhorando.
  • AppImage é elogiado pela simplicidade, mas a falta de atualizações automáticas é ao mesmo tempo uma desvantagem e um recurso, dependendo do fluxo de trabalho.
  • Docker/Podman são frequentemente usados em vez disso para workloads “bleeding edge” ou de servidor.
  • Nix/Guix e distros imutáveis são mencionados como alternativas mais principistas para controle de dependências.

Gerenciadores tradicionais de pacotes e estabilidade

  • Vários usuários antigos de Debian/Ubuntu dizem que o inferno das dependências é, em grande parte, um problema resolvido se você ficar nos repositórios oficiais ou usar pinning adequado.
  • Outros insistem que o inferno das dependências ainda existe, especialmente com repositórios de terceiros e PPAs.
  • Alguns migram para longe do Ubuntu (para Debian, Arch, Mint, Pop!_OS) principalmente para evitar Snaps e as ferramentas extras/anúncios do Ubuntu.
  • Tensão contínua: desejo por pacotes estáveis e integrados à distro vs. uma mentalidade de “corrigir para frente” e atualizações automáticas rápidas.