Muito se tem falado sobre fragmentação, a favor e contra, mas agora existem algumas soluções muito interessantes surgindo ultimamente, como os pacotes snap Canonical que foram abertos para todas as distros, não apenas para o Ubuntu. Mas além disso, existem outras possibilidades, uma delas é aquela que a gente vem a apresentar essa visão, é a Imagens de aplicativos. Basicamente, uma possibilidade de empacotar aplicativos de uma forma genérica para GNU / Linux.
Isso ajuda os desenvolvedores a serem encorajados a criar mais software para Linux, pois às vezes eles ficam relutantes sobre o número de pacotes que precisam gerar e manter para as diferentes distros existentes. Outras vezes, optam por fornecer apenas softwares compatíveis com determinadas distribuições, ignorando o resto, o que não é uma solução total. Por isso, projetos desse tipo abrem esperanças para que o universalidade para pacotes de software.
Além disso, as atualizações dos apps, inclusive de segurança, chegariam de forma mais direto via upstream (do desenvolvedor original). Isso viria graças às atualizações delta, ou seja, pacotes que incluem apenas as alterações das novas versões. Assim ganharíamos todos, tanto os desenvolvedores com aquela maior facilidade, quanto as vantagens de atualizar para ter sempre o mais recente e ter pacotes mais compatíveis para os usuários finais. Além de melhorar a segurança, técnicas de sandbox podem ser implementadas para isolá-los.
Mas nem tudo são vantagens, contra ele tem o da redundânciaa, pois ao integrar todas as dependências podemos encontrar espaço de armazenamento desperdiçado por bibliotecas e outros elementos repetidos que atualmente não estão disponíveis. Mas hey, é o preço que deve ser pago pelo resto das vantagens ... Para mais informações, pode consultar appimage.org.
Eu gosto que o Appimage poderia ter sido levado mais em consideração, eles já existem há muito tempo e agora com a batalha é muito improvável que eles se tornem padrão. Eles são super fáceis de criar no Ubuntu (eu realmente não gosto muito, só no Ubuntu). Eu criei perfeitamente uma Appimage de vokoscreen no ubuntu e a utilizo no openSUSE sem problemas.
Esperançosamente, aquele que vence como padrão é tão fácil de criar e não apenas a partir do Ubuntu
Diga-me como isso é feito e quais etapas e aplicativos você usou para fazer isso
Eu fiz como o wiki diz
https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages
primeiro baixe os componentes necessários que aparecem na primeira linha
sudo apt-get update; sudo apt-get -y install libfuse-dev libglib2.0-dev cmake git libc6-dev binutils realpath fuse # debian, Ubuntu
Depois
clone git https://github.com/probonopd/AppImageKit.git
CD AppImageKit
cmake.
fazer
e em vez de folha
export APP = leafpad && ./apt-appdir/apt-appdir $ APP && ./AppImageAssistant.AppDir/package $ APP.AppDir $ APP.AppImage && ./$APP.AppImage
Eu coloquei vokoscreen
export APP = vokoscreen && ./apt-appdir/apt-appdir $ APP && ./AppImageAssistant.AppDir/package $ APP.AppDir $ APP.AppImage && ./$APP.AppImage
Isso de uma máquina virtual, porque eu uso o openSUSE, tive algumas complicações com algumas bibliotecas que não estavam incluídas sozinhas (me mostrou que a biblioteca estava faltando no openSUSE), mas eu as adicionei ao diretório vokoscreen.AppDir e recriei o AppImage com
export APP = vokoscreen && ./AppImageAssistant.AppDir/package $ APP.AppDir $ APP.AppImage && ./$APP.AppImage
Funciona desde que o arquivo com o mesmo nome não exista, então você deve excluir o .AppImage anterior
Se você não entendeu ou não fui muito claro, acho que farei um vídeo tutorial com AppImage para kdenlive
lembranças
.
Muito bom appimage's
A melhor coisa para mim é que eles são portáteis
Bem, muito sucesso, acho que seria uma grande melhoria e uma forma de padronizar um pouco mais.Eu sou um usuário de Linux, mas acho desconfortável para certas coisas.
Nem mesmo concordamos com isso. O Ubuntu lançou seus pacotes SNAP, a Red Hat lançou seu Flatpak. E eles não concordam em padronizar uma coisa. O problema de fragmentação no Linux continuará existindo.