Snap vs Flatpak vs Appimage

Todos sabem qual minha preferência, mas vou mostrar aqui minha visão de cada tecnologia e o porquê da minha preferência por Flatpak’s.

Primeiramente, quero dizer que você não precisa escolher 1. Flatpak, Snap e Appimage podem ser usados em paralelo sem nenhum conflito.

Segundo, óbvio que este artigo é de minha opinião e tendência, porém não é por que prefiro X, que quero que o Y se exploda. Prefiro o serviço Steam, mas não é por isso que não gostaria de opções como GOG ou itchio existissem.

Criei um grupo para divulgação de Snap, Flatpak e Appimage no Telegram:

https://t.me/flatpaksnapappimage

Muitos acabam escolhendo um ou outro por conta das primeiras experiências, que infelizmente podem variar de distro para distro.

Porque uso Flatpak

Pessoalmente já tive problemas com as 3 tecnologias, com isso quero dizer que nenhuma é “perfeita”. Mas escolhi usar Flatpak’s por conta da maior integração com a DE/desktop que uso (GNOME). Também pela sua essência de ser uma tecnologia voltada ao “desktop Linux” como foi originalmente criada. Além do fato de Snap’s não serem, atualmente, compatíveis com o meu OS atual (Fedora Silverblue).

Também tem a questão de estar no repositório de praticamente todas distribuições (veja neste artigo sobre o suporte Flatpak nas distros) o que me garante mais flexibilidade na escolha de sistema, caso algum dia o Fedora tome decisões que me desagrade e queira migrar de OS, sem necessidade de me arriscas em adicionar repositórios de terceiros ao sistema.

Também o fato de contribuir para o sistema de “Loja de app’s” ajudando na integração com do OS, sem precisar ter que recorrer ao método “Windows XP” de descoberta de programas. Falo de ter que caçar de site em site para baixar/atualizar meus app’s. Se integra a várias lojas de app’s e ainda via terminal, não preciso recorrer a este método antigo de busca na web de instalação de software.

Existe a possibilidade de isto acontecer no Flatpak (como acontece com Appimage) pois não é uma tecnologia centralizadora (como Snap) mas devido ao estado de facilidade para um mantenedor/dev em manter um app no Flathub e tendências atuais, faz mais sentido disponibilizarem Flatpak’s em uma central, como o Flathub ou como o elementaryOS na sua AppCenter.

Com isso, apesar de gostar do método de gerenciamento de app’s via “Central de aplicativos” entendo que forçar/obrigar não é legal, ainda existe dev’s que preferem disponibilizar seus app’s em seus sites/github’s/repositórios próprios e o Flatpak permite isto com mais facilidade.

Poucos dev’s de programas escolhem distribuir via Flatpak sem usar Flathub atualmente.

Fora que isso pode garantir mais segurança, familiaridade e facilidade no uso. Ao mesmo tempo que não “obriga” a todos desenvolvedores usarem 1 loja/repo caso não queiram. Exemplo disso é o elementary OS com seu repositório Flatpak “AppCenter”.

Isso não quer dizer que a usabilidade com Flatpak é perfeita, mas o maior “inconveniente” que podemos ter, é o fato de ter que adicionar o Flathub e/ou outro repo Flatpak, caso algum sistema já não adicione ou facilite isto por padrão. Ou “inconveniente” é ter que lidar com permissões, pois tirando o eOS, para gerenciar permissões via GUI é preciso instalar o Flatseal.

O Flatseal não é algo que arrisca a integridade do sistema como adicionar uma ppa/ copr/pacote do AUR no sistema, é um app GUI para gerenciar com clicks de uma forma que lembra o Android, porém com todo o poder que o Flatpak te dá.

Outro ponto fraco do Flatpak é não ter um suporte muito bom para app’s CLI (linha de comando). Pois não foi feito pensado nestes casos. Apesar de ser possível (usei ffmpeg uma vez) não tem a melhor experiência.

O Flatpak não vai cobrir casos de uso para ferramentas do sistema, ou de softwares que foram feitos para se incorporarem no sistema e ter permissão total (como uma DE por exemplo). Isso pode ser visto como ponto fraco, mas pessoalmente não acho, pois gosto desta separação entre ferramenta do sistema / app do usuário.

Lembrando que adicionar vários repositórios Flatpak, não é o mesmo que adicionar repositórios ao seu sistema como: PPA’s ou COPR’s. Pois eles não quebrarão o seu sistema em updates ou conflitar seu gerenciador de pacotes apt, dnf etc. Estarão protegidos pela sandbox.

Snap

O Snap também promove o esquema de “loja de app’s” porém a sua central e apenas a sua. Por default usa Snapcraft mantida pela Canonical e originalmente criado para IoT devices e Ubuntu.

O Snapd não foi incluído nos repositórios oficiais do OpenSUSE (por conta de não passar em testes de segurança) e ArchLinux (por conta das dependências) no Fedora a sandbox dos snap’s não funcionam corretamente por conta de usar SELinux e não o AppArmor com patchs da Canonical.

No momento também não é suportado em sistemas como Fedora Silverblue (que uso diariamente), EndlessOS, ChromeOS e ClearLinux, OSTree Based e qualquer um que não use Systemd.

Muitas distribuições não escolheram Snap como default ou como melhor formato para app’s de “terceiros” mesmo tendo o snapd em seus repositórios, como LinuxMint, ElementaryOS, Zorin, PopOS, Fedora…

A flexibilidade na escolha da distribuição para usar Snap, não me parece tão boa quanto com Flatpak e Appimage, o que é um ponto importante para mim.

Agora, a maneira como os snap’s e o snapd funcionam não me agrada, além de automaticamente conectar ao Snapraft (que não tem lá uma curadoria ou controle de qualidade muito rigorosa) com o tempo se inicia uma porrada de serviços junto com o sistema, que podem ou não atrasar o boot ou causar outros problemas. Os app’s ficam compactados, precisar ser compactados e depois montados como dispositivos virtuais na qual roda em um sistema de arquivos virtual e se atualizarão automaticamente, então caso precise congelar um app em alguma versão por conta de um bug, não poderá (já precisei fazer isso com um app e o Flatpak me permitiu). E isso tudo me soa muito errado…

Appimage

É o mais antigo deles, criado pelo Probono, uma pessoa que tem seus ideais baseados em MacOS dos anos 80. Pode ver no vídeo abaixo:

“My typical AppImage discovery goes like this:

Read on Twitter that PrusaSlicer has this cool new feature

Go to the PrusaSlicer GitHub project and read the release notes there

While there, download the AppImage and have it running a few seconds later”

Já falou em entrevistas, que está OK com o sistema de descoberta de appimage’s via Twitter!

Ele acha OK ter que pesquisar ou baixar de github’s/repositórios aleatórios, que talvez sejam minimamente confiáveis ou não (o usuário tem que descobrir isto também) assim como ter que atualizá-los repetindo o processo de busca (existe ferramentas separadas para update’s mas não são confiáveis ou apenas não funcionam em muitos app’s) na web para refazer o download novamente.

O dev do Appimage, Simon Peter (probono no twitter) leva este conceito para o uso do sistema operacional também, onde para atualizar seu OS, baixa a nova .iso novamente (se existir nova iso).

O Appimage também promove a liberdade e escolha do sistema / distros Linux. Mesmo assim possui um problema que os outros formatos e modos de distribuições tem, a experiência pode depender da distro, como mostro neste artigo. É recomendado usarem o LTS mais antigo do momento, na hora de empacotar um appimage, para “aumentar as chances” de sucesso em rodar em vários OS’s diferentes.

Meu maior problema é com esta “filosofia” ala WindowsXP de busca e download de app’s. Já nos anos 90 o desktop Linux mostrou que uma “central de apps” integrada ao sistema ou repositório, instalando, atualizando, gerenciando… é talvez a melhor forma de se usar um OS. Anos depois a Google e Apple mostraram em seus sistemas o mesmo esquema e atualmente todos principais OS’s do mercado, usam este workflow de descoberta de app’s via central de software.

Isso não quer dizer que você não pode descobrir um novo app via Twitter/rede social, mas depender disso me parece um retrocesso na usabilidade.

Existe tentativas de oferecer uma Central de App’s, integradores e gerenciador de atualizações para Appimage’s, mas estão muito atrás das outras soluções existentes, no quesito qualidade, confiabilidade e integração com DE’s/sistemas, além de muitas vezes serem projetos separados que parecem não estar de acordo um com outro (minha visão).

Considerações finais

Gosto que exista estas 3 opções, que ao meu ver facilitam e promovem uma concorrência no desktop Linux. Eu sei que existe pontos que você pode considerar mais importantes, como a disponibilidade de app’s, se um programa que você quer/precisa usar não está disponível em um formato, corre para o outro e vice versa.

Também muitos usam o argumento “quantidade de app’s disponíveis” outro que não me interessa tanto quanto o “qualidade dos app’s disponíveis” ou “curadoria dos app’s disponíveis” entre muitos outros.

Porém, assim como não uso Linux no desktop pela disponibilidade de um ou outro software, também não uso Flatpak por este motivo, até porque todos formatos são ricos em opções de app’s e praticamente os 3 podem atender meu uso (nem tanto).

Se deseja me dar sugestões, mande para fastos2016@gmail.com ou nas redes sociais.

5 comentários em “Snap vs Flatpak vs Appimage

Adicione o seu

  1. Legal a comparação, mas achei a perspectiva um pouco rasa na descrição do AppImage. Um dos melhores aspectos do AppImage é a simplicidade de instalação e total independência do sistema host (não precisa cliente de AppImage como flatpak/snap). Você simplesmente baixa e instala, uma aplicação auto contida e que não precisa de nada além do sistema operacional. Sinceramente numa conexão direta entre desenvolvedor e usuário, esse fluxo é um dos mais simples que tem e que é um tanto vergonhoso ser tão complicado no Linux.

    Curtir

    1. Teoricamente é simples, na prática não. Pois não tem uma loja, devs disponibilizam um em cada site, não se integra com o sistema criando ícones se atualizando com os outros , o usuário provavelmente vai ter que baixar novamente o app, ou quando não baixa e continua usando um app sem correções de segurança..etc

      Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Blog no WordPress.com.

Acima ↑

%d blogueiros gostam disto: