Os gerenciadores de pacotes fornecem uma maneira de empacotar, distribuir, instalar e manter aplicativos em um sistema operacional. Com os aplicativos modernos de desktops, servidores e IoT do sistema operacional Linux e as centenas de diferentes distros existentes, torna-se necessário abandonar os métodos de empacotamento específicos e tradicionais da plataforma. Este post explora 3 dessas ferramentas, a saber, AppImage, Snap e Flatpak. Cada um pretende ser o futuro da implantação e gerenciamento de software no Linux. No final, resumimos algumas características importantes.

1. AppImage

AppImage segue um conceito chamado “One app = one file”. Isso deve ser entendido como um AppImage sendo um “arquivo” independente regular contendo um aplicativo com tudo o que ele precisa para ser executado no arquivo. Uma vez tornado executável, o AppImage pode ser executado como qualquer aplicativo em um computador, basta clicar duas vezes no sistema de arquivos do usuário.

É um formato para criar software portátil para Linux sem exigir que o usuário instale o aplicativo mencionado. O formato permite que os desenvolvedores originais do software criem uma versão independente de plataforma e distribuição (também chamada de distribuição-agnóstica binária) de seu aplicativo, que basicamente rodará em qualquer versão do Linux.

AppImage existe há muito tempo. Klik, um antecessor da AppImage foi criado por Simon Peter em 2004. O projeto foi encerrado em 2011 depois de não ter passado a fase beta. Um projeto chamado PortableLinuxApps foi criado por Simon na mesma época e o formato foi escolhido por alguns portais que oferecem software para usuários de Linux. O projeto foi renomeado novamente em 2013 para seu nome atual AppImage. Assim, um repositório foi mantido no GitHub (link do projeto) com todas as alterações mais recentes para o mesmo desde 2018.

Escrito basicamente em C e usando a licença do MIT desde 2013, o AppImage é atualmente desenvolvido pelo projeto The AppImage. É uma maneira muito conveniente de usar aplicativos.

Possui os seguintes recursos:

1. O AppImages pode ser executado em praticamente qualquer sistema Linux. Como mencionado antes, os aplicativos obtêm muita funcionalidade do sistema operacional e algumas bibliotecas comuns. Esta é uma prática comum no mundo do software, pois se algo já estiver feito, não há sentido em fazê-lo novamente se você puder escolher quais partes do mesmo usar. O problema é que muitas distribuições do Linux podem não ter todos os arquivos que um aplicativo específico requer para executar, uma vez que é deixado aos desenvolvedores dessa determinada distribuição incluir os pacotes necessários. Portanto, os desenvolvedores precisam incluir separadamente as dependências do aplicativo para cada distribuição Linux para a qual estão publicando seu aplicativo. Usando o formato AppImage, os desenvolvedores podem optar por incluir todas as bibliotecas e arquivos que eles possivelmente não podem esperar que o sistema operacional de destino tenha como parte do arquivo AppImage. Assim, o mesmo arquivo de formato AppImage pode funcionar em diferentes sistemas operacionais e máquinas sem precisar de controle.
2. A filosofia de um único arquivo significa que a experiência do usuário é simples e elegante, pois os usuários precisam apenas baixar e executar um arquivo que atenda às suas necessidades de uso.
3. Nenhum requisito de acesso root. Os administradores de sistemas exigirão que as pessoas tenham acesso root para impedir que eles mexam com computadores e sua configuração padrão. Isso também significa que as pessoas sem privilégios de acesso root ou de superusuário não podem instalar os aplicativos de que precisam conforme desejarem. A prática é comum em um ambiente público (como computadores de bibliotecas ou universidades ou em sistemas corporativos). O arquivo AppImage não requer que os usuários “instalem” nada e, portanto, os usuários precisam apenas baixar o arquivo e torná-lo executável para começar a usá-lo. Isso elimina os dilemas de acesso que os administradores de sistemas têm e facilita seu trabalho sem sacrificar a experiência do usuário.
4. Nenhum efeito no sistema operacional principal. O formato de aplicativo AppImage permite usar aplicativos com toda a sua funcionalidade sem precisar alterar ou até mesmo acessar a maioria dos arquivos do sistema. O que quer que os aplicativos façam, a configuração do sistema operacional principal e os arquivos permanecem inalterados.
5. Um AppImage pode ser feito por um desenvolvedor para uma versão específica de seu aplicativo. Qualquer versão atualizada é feita como um AppImage diferente. Portanto, os usuários, se necessário, podem testar várias versões do mesmo aplicativo, executando diferentes instâncias usando diferentes AppImages. Esse é um recurso importante quando você precisa testar seus aplicativos a partir do ponto de vista do usuário final para notar diferenças.
6. Leve seus aplicativos para onde você for. Como mencionado anteriormente, os AppImages são justamente os arquivos que um aplicativo requer e podem ser usados sem instalar ou mesmo se preocupar com a distribuição que o sistema usa. Portanto, se você tiver um conjunto de aplicativos que usa regularmente, poderá montar alguns arquivos AppImage em um pen drive e levá-lo consigo para usar em vários computadores que executam várias distribuições diferentes sem se preocupar com o funcionamento dos mesmos.

Outros detalhes

Além disso, o AppImageKit permite que usuários de todas as origens construam seus próprios AppImages a partir de aplicativos que eles já possuem ou para aplicativos que não são fornecidos um AppImage por seu desenvolvedor upstream.

O gerenciador de pacotes é independente de plataforma, mas se concentra principalmente na distribuição de software para usuários finais em seus desktops com um daemon dedicado. AppImaged para integrar os formatos AppImage aos respectivos ambientes de desktop. AppImage é suportado nativamente agora por uma variedade de distros como Ubuntu, Debian, openSUSE, CentOS, Fedora, etc. e outros podem configurá-lo de acordo com suas necessidades. O AppImages também pode ser executado em servidores com funcionalidade limitada por meio das ferramentas CLI incluídas.

Para saber mais sobre o AppImages, vá para a página de documentação oficial do AppImage.

2. Snappy

O Snappy é um sistema de gerenciamento de pacotes e implantação de software como o AppImage ou qualquer outro gerenciador de pacotes para essa instância. Ele foi originalmente projetado para o já extinto sistema operacional Ubuntu Touch. O Snappy permite que desenvolvedores criem pacotes de software para uso em uma variedade de distribuições baseadas em Linux. A intenção inicial por trás da criação do Snappy e da implementação de “snaps” em sistemas baseados no Ubuntu é obter um formato unificado que pode ser usado em tudo, desde dispositivos IoT até sistemas de computador completos que executam alguma versão do Ubuntu.

O principal desenvolvedor por trás do projeto é a Canonical, a mesma empresa que pilota o projeto do Ubuntu. O Ubuntu tinha suporte a snap nativo a partir da versão 16.04 LTS, com mais e mais distribuições suportando a partir da caixa ou através de uma configuração simples nos dias de hoje. Se você usa o Arch, o Debian ou o openSUSE, será fácil instalar o suporte para o gerenciador de pacotes usando comandos simples no terminal, conforme explicado mais adiante nesta seção. Isso também é possível ao disponibilizar os arquivos necessários da plataforma de encaixe nos respectivos repos.

O Snappy possui os seguintes componentes importantes que compõem todo o sistema do gerenciador de pacotes.

• Snap – é o formato de arquivo dos próprios pacotes. Aplicativos individuais que são implantados usando o Snappy são chamados de “Snaps”. Qualquer aplicativo pode ser empacotado usando as ferramentas fornecidas para fazer um snap que deve ser executado em um sistema diferente executando o Linux. Snap, semelhante ao AppImage, é um arquivo com tudo incluído e contém todas as dependências que o aplicativo precisa para ser executado sem assumi-las como parte do sistema de destino.
• Snapcraft – é a ferramenta que permite aos desenvolvedores criar snaps de suas aplicações. É basicamente um comando que faz parte do sistema snap, bem como um framework que permite que você construa seus próprios snaps.
• Snapd – é o daemon de segundo plano que mantém todos os instantâneos instalados no sistema. Integra-se ao ambiente de desktop e gerencia todos os arquivos e processos relacionados ao trabalho com snaps. O daemon snapd também verifica as atualizações normalmente 4 vezes por dia, a menos que seja definido de outra forma.
• Loja Snap– é uma galeria online de classificações que permite aos desenvolvedores fazer upload de seus snaps no repositório. O Snap store também é um meio de descoberta de aplicativos para usuários e permitirá que os usuários vejam e experimentem a biblioteca de aplicativos antes de baixá-los e instalá-los.

O componente snapd é escrito principalmente em C e Golang, enquanto o framework Snapcraft é construído usando Python. Embora ambos os módulos usem a licença GPLv3, deve-se notar que o snapd possui um código proprietário da Canonical para suas operações no lado do servidor, com apenas o lado do cliente sendo publicado sob a licença GPL. Este é um dos principais pontos de discórdia entre os desenvolvedores, pois envolve desenvolvedores assinando um formulário CLA para participar do desenvolvimento instantâneo.

Indo mais fundo nos detalhes do gerenciador de pacotes Snappy, pode-se notar o seguinte:

1. Os snaps, como mencionado anteriormente, são todos inclusivos e contêm todos os arquivos (dependências) necessários que o aplicativo precisa executar. Assim, os desenvolvedores não precisam fazer snaps diferentes para as diferentes distros que eles segmentam. Estar atento aos tempos de execução é tudo o que é necessário se os tempos de execução base forem excluídos do snap.
2. Pacotes Snappy são feitos para suportar atualizações transacionais. Essa atualização transacional é totalmente reversível, o que significa que você pode usar o aplicativo enquanto ele está sendo atualizado e que, se uma atualização não se comporta como deveria, você pode reverter o mesmo sem nenhum outro efeito. O conceito também é chamado de programação delta, na qual apenas as alterações no aplicativo são transmitidas como uma atualização, em vez de todo o pacote. Um derivativo do Ubuntu chamado Ubuntu Core na verdade promete o protocolo de atualização para o próprio sistema operacional.
3. Um ponto-chave de diferença entre snaps e AppImages é como eles lidam com diferenças de versão. Usando o AppImages, versões diferentes do aplicativo terão diferentes AppImages, permitindo que você use simultaneamente duas ou mais versões diferentes do mesmo aplicativo ao mesmo tempo. No entanto, o uso de snaps significa conformidade com o sistema de atualização transacional ou delta. Embora isso signifique atualizações mais rápidas, evita que você execute duas instâncias do mesmo aplicativo ao mesmo tempo. Se você precisar usar a versão antiga de um aplicativo, será necessário reverter ou desinstalar a nova versão. O Snappy suporta um recurso chamado “instalação paralela”o que permitirá que os usuários alcancem objetivos semelhantes. No entanto, ainda está em um estágio experimental e não pode ser considerado uma implementação estável. O Snappy também faz uso de canais, o que significa que você pode usar a versão beta ou a versão noturna de um aplicativo e a versão estável ao mesmo tempo.
4. Suporte extensivo das principais distribuições Linux e grandes desenvolvedores, incluindo Google, Mozilla, Microsoft etc.
5. Snapd a ferramenta de integração de desktop suporta tirar “instantâneos” do estado atual de todos os snaps instalados no sistema. Isso permitirá que os usuários salvem o estado de configuração atual de todos os aplicativos instalados através do gerenciador de pacotes Snappy e permitam que os usuários voltem a esse estado sempre que desejarem. O mesmo recurso também pode ser configurado para tirar instantâneos automaticamente em uma frequência considerada necessária pelo usuário. Os snapshots podem ser criados usando o comando snap save na estrutura snapd.
6. Os encaixes são projetados para serem colocados em sandbox durante a operação. Isso fornece uma camada necessária de segurança e isolamento aos usuários. Os usuários não precisam se preocupar com aplicativos baseados em snap mexendo com o restante do software em seus computadores. Sandboxing é implementado usando três níveis de isolamento viz, classic, strict e devmode. Cada nível de isolamento permite ao aplicativo diferentes níveis de acesso dentro do sistema de arquivos e do computador.

Por outro lado, os snaps são amplamente criticados por estarem centrados no modus operandi da Canonical. A maioria dos compromissos com o projeto é de funcionários ou contratados da Canonical, e outros contribuintes são obrigados a assinar um formulário de liberação (CLA). O recurso de sandboxing, muito importante do ponto de vista da segurança, é falho porque o sandboxing realmente requer que alguns outros serviços principais sejam executados (como o Mir), enquanto os aplicativos que executam o desktop X11 não suportam o dito isolamento. Portanto, o recurso de segurança é irrelevante. Comunicados de imprensa questionáveis e outros esforços de marketing da Canonical e do repositório de aplicativos “central” e fechado também são aspectos amplamente criticados do Snappy. Além disso, os tamanhos dos arquivos dos diferentes snaps também são muito grandes em comparação com os tamanhos de aplicativos dos pacotes criados com o AppImage.

Para mais detalhes, verifique a documentação oficial Snap.

3. Flatpak

Como o Snap/Snappy listado acima, o Flatpak também é uma ferramenta de implantação de software que visa facilitar a distribuição de software e uso no Linux. O Flatpak era conhecido anteriormente como “xdg-app” e era baseado no conceito proposto por Lennart Poettering em 2004. A idéia era conter aplicativos em uma caixa de proteção virtual segura, permitindo o uso de aplicativos sem a necessidade de privilégios de root e sem comprometer a segurança dos sistemas. Alex começou a mexer com o Klik (pensado para ser uma versão anterior do AppImage) e queria implementar melhor o conceito. Alexander Larsson que na época estava trabalhando com a Red Hat escreveu uma implementação chamada xdg-app em 2015 que funcionou como um precursor para o formato atual do Flatpak.

O Flatpak saiu oficialmente em 2016 com o apoio da Red Hat, Endless Computers e Collabora. O Flathub é o repositório oficial de todos os pacotes de aplicativos Flatpak. Então, o Flatpak é uma estrutura para aplicativos de distribuição de construção e empacotamento para Linux. Ele simplesmente exige que os desenvolvedores estejam em conformidade com algumas diretrizes de ambiente de desktop para que o aplicativo seja integrado com sucesso ao ambiente Flatpak.

Direcionado principalmente para as três implementações de desktop populares FreeDesktop, KDE e GNOME, o próprio framework Flatpak é escrito em C e funciona com uma licença LGPL. O repositório de manutenção pode ser acessado através do link do GitHub aqui.

Alguns recursos do Flatpak que o diferenciam são mencionados abaixo.

Observe que os recursos que o Flatpak compartilha com o AppImage e o Snappy são detalhados aqui.

• Integração profunda em ambientes populares de desktop Linux, como o GNOME eo KDE, para que os usuários possam simplesmente usar Flatpaks usando ferramentas gráficas de gerenciamento de software, em vez de recorrer ao terminal. O Flatpak pode ser instalado a partir dos repositórios padrão dos principais ambientes de área de trabalho e, uma vez que os aplicativos estejam configurados, eles podem ser usados e fornecer recursos semelhantes aos aplicativos normais de desktop.
• Compatibilidade com versões anteriores – Flatpaks são construídos a partir do zero, mantendo em mente os principais núcleos e tempos de execução dos sistemas operacionais. Portanto, mesmo que você atualize sua distro, os Flatpaks ainda devem funcionar a menos que haja uma atualização principal. Isso é especialmente crucial para pessoas que preferem ficar com versões de desenvolvimento de suas distros. Para essas pessoas, como os problemas do sistema operacional em si não são resolvidos normalmente, o aplicativo Flatpak será executado sem problemas, sem depender dos arquivos ou bibliotecas do sistema operacional para sua operação.
• Sandboxing usando Bubblewrap – snaps também são, por padrão, colocados em sandbox, pois são executados isoladamente do resto dos aplicativos em execução enquanto você está usando seu computador. No entanto, os Flatpaks permitem que o aplicativo acesse arquivos do sistema operacional e arquivos do usuário durante sua operação por padrão. Isso significa essencialmente que os administradores de sistema podem ter certeza de que os Flatpaks instalados em seus sistemas não podem explorar o computador e os arquivos contidos, ao passo que para usuários finais isso significa que para acessar algumas funções específicas ou permissão de raiz de dados do usuário é necessário.
• O Flatpak suporta distribuição descentralizada de aplicativos nativamente, mas a equipe por trás do Flatpak ainda mantém um repositório online central de aplicativos/Flatpaks chamado Flathub. Os usuários podem, de fato, configurar o Flatpak para usar vários repositórios remotos como acharem necessário. Ao contrário do snap, você pode ter vários repositórios.
• Acesso modular através da sandbox. Embora essa capacidade tenha um grande custo potencial para a integridade do sistema, a estrutura do Flatpak permite que os canais sejam criados por meio da caixa de proteção para troca de informações específicas de dentro da caixa de proteção para o sistema host ou vice-versa. O canal é neste caso referido como um portal.

Críticas

Um dos aspectos mais criticados do Flatpak, no entanto, é o próprio recurso sandbox. Sandboxing é como os gerenciadores de pacotes, como o Snappy e o Flatpak, implementam importantes recursos de segurança. Sandboxing essencialmente isola o aplicativo de tudo o mais no sistema, permitindo apenas a troca de informações definidas pelo usuário de dentro do sandbox para fora. A falha é que os dados têm que ser eventualmente transferidos entre os dois domínios. Assim, com simples comandos do Linux, podem se livrar da restrição de sandbox. Isso  significa que os aplicativos mal-intencionados podem potencialmente sair da referida sandbox.

Isso combinado com o comprometimento pior do que o esperado com o lançamento de atualizações de segurança para o Flatpak resultou em críticas generalizadas à alegação da equipe de fornecer uma estrutura segura. O blog (chamado flatkill), linkado no final deste guia, menciona algumas façanhas que não foram abordadas pela equipe do Flatpak assim como deveriam.

Para mais detalhes, leia a documentação oficial do Flatpak.

AppImage vs Snap vs Flatpak

A tabela anexada resume os detalhes acima em uma comparação concisa e técnica das três estruturas.

Aqui está uma longa comparação tabular dos recursos AppImage vs. Snap vs. Flatpak. Por favor, note que a comparação é feita a partir de uma perspectiva AppImage.

• https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison

Conclusão

Embora todas essas três plataformas tenham muito em comum entre si e visem ser independentes em termos de plataforma, elas oferecem diferentes níveis de competência em algumas áreas. Embora o Snap possa ser executado em diversos dispositivos, incluindo osintegrados, o AppImages e o Flatpaks são criados pensando no usuário da área de trabalho. AppImages de aplicativos populares, por outro lado, tinham tamanhos de embalagem e portabilidade superiores, enquanto que o Flatpak realmente brilha com sua compatibilidade quando é usado em um conjunto independentemente do sistema.

Fonte

O post Veja uma comparação entre AppImage, Snap e Flatpak apareceu primeiro em SempreUPdate.