Mateus Müller

O carinha do Linux

06 fev. 2018

Entendendo o formato de pacotes AppImage

Durante o desenvolvimento de vários artigos aqui para o blog, notei uma grande quantia de empresas que estão distribuindo aplicações no formato AppImage, um formato inovador e que traz diversas vantagens.

Desta forma, decidi fazer um estudo um pouco mais profundo sobre este formato de pacotes, sua história, suas vantagens e outras curiosidades.

História do AppImage

A história do formato AppImage começou em 2004 quando foi lançado o klik, seu antecessor, desenvolvido por Simon Peter. O objetivo era o mesmo de simplificar o gerenciamento de pacotes, tanto pelo lado do desenvolvedor, quanto pelo lado do usuário.

Os usuários poderiam executar um aplicativo de uma forma muito mais fácil, sem danificar o sistema, bem como os desenvolvedores não precisariam desenvolver uma aplicação para cada distribuição, como por exemplo os formatos .deb, .rpm, .tar.gz, etc.

O projeto klik foi tomando forma, e mais desenvolvedores foram se interessando pela ideia, trazendo novos inputs, quando em 2007 o klik2 foi lançado, utilizando o recurso FUSE (que por sinal melhorou bastante coisa).

Depois disso, vários outros projetos começaram a surgir, como por exemplo o Flatpak, Snappy, e é claro, o AppImage.

Obs.: Você pode conferir a linha histórica aqui.

O que é o formato AppImage?

Você já viu os formatos de pacotes portables no Windows? Pois então, é a mesma coisa! Confira aqui algumas vantagens:

  • Você não precisa instalar.
  • Você só precisa de dois cliques que ele irá executar e funcionar normalmente.
  • Todas as bibliotecas já são comprimidas dentro do arquivo
  • Você não precisa de permissão de administrador para executa-lo, visto que ele não irá modificar nada no seu sistema.
  • Este formato funciona em qualquer distribuição.

Se você quiser testar, confira os seguintes artigos que trabalham com este formato:

Qual a real diferença entre klik e AppImage?

A ideia continua a mesma, o que de fato alterou foi o modo de execução utilizando o FUSE. Deixe-me explicar melhor.

O klik, quando executava um aplicativo no formato .cmg (que seria o nosso .AppImage), criava um novo sistema de arquivos virtual utilizando os dispositivos loop dentro do /dev, de modo que todos os arquivos necessários ficassem lá dentro. Mas, veja uma coisa:

Entendendo o formato de pacotes AppImage
Entendendo o formato de pacotes AppImage

Só temos 8 instâncias do loop disponíveis no Linux, nos limitando a executar somente 8 aplicativos no formato .cmg.

Pensando nisso, o modo de execução deste softwares foi alterado utilizando o FUSE – Filesystem in Userspace. Isto fez com que fosse permitida a criação de novos sistemas de arquivos pelos usuários sem alterar diretamente o código do Kernel, mas sim utilizando o módulo do FUSE que serve como uma “ponte” para este processo.

Veja o resultado executando o Medley Text:

Entendendo o formato de pacotes AppImage
Entendendo o formato de pacotes AppImage

Desta forma não temos mais problemas trabalhando diretamente no Kernel, além de não ter mais um limite de aplicações para executar.

Obs.: Se você é desenvolvedor e quer entregar seu aplicativo no formato AppImage, clique aqui e veja como trabalhar com o AppImageKit.

Bom pessoal, esse foi o artigo de hoje. Até a próxima!

Se tiver alguma dúvida ou sugestão de conteúdo, por favor, comente!

Comentários Disqus