Much has been said about fragmentation, for and against, but now there are some very interesting solutions coming up lately, like the Canonical snap packages that have been opened for all distros, not just Ubuntu. But in addition to this, there are other possibilities, one of them is the one that we come to present this view, it is about the AppImages. Basically a possibility to package applications in a generic way for GNU / Linux.
This helps developers to be encouraged to create more software for Linux, as they are sometimes reluctant about the number of packages they have to generate and maintain for the different existing distros. Other times they choose to only provide software compatible with certain distributions, ignoring the rest, which is not a total solution. For this reason, these types of projects open up hope so that the universality to software packages.
In addition to this, the updates to the apps, including the security ones, would arrive in a way more direct via upstream (from the hand of the original developer). That would come thanks to the delta updates, that is, packages that include only the changes of the new versions. So we would all win, both developers with that greater ease, and the advantages of updating to always have the latest and have more compatible packages for end users. In addition to improving security, sandboxing techniques can be implemented to isolate them.
But not everything are advantages, against it has that of redundancya, since by integrating all the dependencies we can find storage space wasted by libraries and other repeated elements that are currently not available. But hey, it is the price that must be paid for the rest of the advantages ... For more info, you can consult appimage.org.
I like the Appimage's could have been taken more into account, they have been around for a long time and now with the battle it is very unlikely that they will become standart. They are super easy to create from Ubuntu (I don't really like that much though, just from Ubuntu). I seamlessly created a vokoscreen Appimage on ubuntu and I use it on openSUSE without problem.
Hopefully the one that wins as standart is just as easy to create and not just from Ubuntu
Tell me how it is done and what steps and applications did you use to do it
I did it as the wiki says
https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages
first download the necessary components that show in the first line
sudo apt-get update; sudo apt-get -y install libfuse-dev libglib2.0-dev cmake git libc6-dev binutils realpath fuse # debian, Ubuntu
Then
git clone https://github.com/probonopd/AppImageKit.git
cd AppImageKit
cmake.
make
and instead of leafpad
export APP = leafpad && ./apt-appdir/apt-appdir $ APP && ./AppImageAssistant.AppDir/package $ APP.AppDir $ APP.AppImage && ./$APP.AppImage
I put vokoscreen
export APP = vokoscreen && ./apt-appdir/apt-appdir $ APP && ./AppImageAssistant.AppDir/package $ APP.AppDir $ APP.AppImage && ./$APP.AppImage
That from a virtual machine, because I use openSUSE, I had some complications with some libraries that were not included on their own (it showed me that the library was missing in openSUSE) but I added them to the vokoscreen.AppDir directory and recreated the AppImage with
export APP = vokoscreen && ./AppImageAssistant.AppDir/package $ APP.AppDir $ APP.AppImage && ./$APP.AppImage
It works as long as the file with the same name does not exist, so you have to delete the previous .AppImage
If you did not understand or I was not very clear, I think I will make a video tutorial with AppImage for kdenlive
regards
.
Very good appimage's
The best thing for me is that they are portable
Well, quite successful, I think it would be a great improvement and a way to standardize a little more. I'm a Linux user but I find it uncomfortable for certain things.
We don't even agree on that. Ubuntu released its SNAP packages, Red Hat released its Flatpak. And they do not agree to standardize one thing. The problem of fragmentation in Linux will continue to exist.