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:
- Conheça o STREMIO – Sua opção gratuita à NETFLIX
- Tome suas notas e dos seus scripts utilizando o Medley Text
- Utilize o NATTT e acabe com a procrastinação das suas tarefas
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:
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:
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!