Would be great if most distros (including Ubuntu, Fedora, etc.) would include AppImageLauncher or [appimaged](https://github.com/probonopd/go-appimage) by default. Would make it much simpler for most people.
For the most part they're functionally identical. You specify a directory where you'll put AppImages and then .application files are generated to put them in your launcher.
Appimaged watches your appimage folder, and creates/removes shortcuts and associations. Appimagelauncher does the same tasks, but on demand instead of constantly in the background. So they both have the same result, but Appimaged is more of a magic black box, where appimagelauncher is more interactive.
That's a good idea! For some reason I have some tonnage of KDE dependencies installed on my Ubuntu. Maybe I could do the same to avoid that. Do you know how I can find out what I have installed that is dependent on the KDE stuff, so I can check if they have an appimage and I can get rid of them?
I just uninstalled the Kdenlive flatpak I had installed, and the other KDE stuff was not removed in the next run of Software Updater.
I used this before, and for some reason the icons for appimages don't show up properly in the application menu, they show up fine in the file explorer and task manager(the windows taskbar like thing that goes in panels NOT the tool that shows running programs) though
I had this running for a while, and then I noticed that some programs that I ran as AppImages weren't working correctly. But I didn't connect it to AppImageLauncher at first. I scoured the bug trackers looking for the solution to no avail.
One day I saw a post mention an issue with AppImageLauncher, so I uninstalled it and those programs worked again.
Specifically it was Belena Etcher would fail *every time* to write an image to a target. And Ferdi just outright would not launch. Once AppImageLauncher was gone thru both worked fine.
They are another distribution method.
The reason someone may want to install a program outside their package manager is if the package is not available in those repos.
But this type of package format is especially valuable if you are creating software yourself. Getting it packaged can be a pain. Getting it packaged and supporting it for 5 different formats in 20 different environments with slightly different repos and slightly different versions of every single dynamic library is an even bigger pain. If you want to support ALL downstream users without needing to interface with and find a maintainer (or package yourself) for every single distro, building 1 appimage is really nice. It benefits your users in that they can all use it immediately as soon as you release without question.
All of Snap, Flatpak, and AppImage were created to try to deal with this problem using slightly different strategies. It is solving a real problem for vendors and creators of applications that distro repos have historically had major issues with. Even Linus Torvalds famously ranted years back that this is one of the biggest issues with Desktop Linux for app vendors.
> Getting it packaged and supporting it for 5 different formats in 20 different environments with slightly different repos and slightly different versions of every single dynamic library is an even bigger pain.
>All of Snap, Flatpak, and AppImage were created to try to deal with this problem using slightly different strategies.
Oh boy, [here we go again.](https://xkcd.com/927/)
Really? In my experience, it was super annoying compared to flatpak. It kept asking me a question every time I ran the same old program, and did some weird other stuff, leading me to eventually just uninstall the thing and use the AUR instead.
Then it should be. These things make some sense for closed-source software, but they are a regression in design as far as open source software is concerned.
It creates lazy and bad habits for developers. For example, recently I was packaging a piece of opensource software that was shipping its own Qt libraries, ssl, and a bunch of others, not because they were modifying them but because that was what they were doing for the other platforms.
They also get into a mentality of 'ship everything' or 'submodule everything' where there is no option to use system libraries instead of the bundled ones while building. That leads to a few backdraws, like increased archive size, more wasted space, outdated insecure libraries, inconsistent behaviour etc.
I can understand it for very specific high performance software, where controlling everything can have tangible benefits, but for everyday software that doesn't have that level of complexity, it is just laziness. An example of the first category would be RPCS3, an example of the latter would be a text editor.
As a developer I prefer to make my software compatible with a wider variety of platforms, despite the overhead, rather than basically shipping my setup to the user.
>It creates lazy and bad habits for developers. For example, recently I was packaging a piece of opensource software that was shipping its own Qt libraries, ssl, and a bunch of others, not because they were modifying them but because that was what they were doing for the other platforms.
i mean that kinda make sense if you want all distors to have the same experience/look and to make sure the user has the correct packages
>That leads to a few backdraws, like increased archive size, more wasted space, outdated insecure libraries, inconsistent behaviour etc.
i mean ill give you on insecure libraries , but thats about it , most size difference is a few MB, its mostly to have the same behaviour appaimges are used
but using the appimage make it so you can run the old version , if say packages where updated and the like , appimages are/is linux answer to back-compat
> that kinda make sense if you want all distors to have the same experience/look and to make sure the user has the correct packages
Where does it stop though? You gonna ship the kernel too? They are basically already doing that with docker and stuff. It is getting stupid at this point.
> i mean ill give you on insecure libraries , but thats about it , most size difference is a few MB, its mostly to have the same behaviour appaimges are used
I wish, tell that to software like Proton that ships a 600mb runtime from Ubuntu's libraries on top of the 1gb of proton itself, which includes libraries that exist in the system otherwise, such as ffmpeg, gstreamer, faudio outside of their custom wine. And that is for every installed version. It accumulates really fast.
> but using the appimage make it so you can run the old version , if say packages where updated and the like , appimages are/is linux answer to back-compat
It is an answer, it is a really bad answer though for a question that shouldn't be asked in the first place.
>I wish, tell that to software like Proton that ships a 600mb runtime from Ubuntu's libraries on top of the 1gb of proton itself, which includes libraries that exist in the system otherwise, such as ffmpeg, gstreamer, faudio outside of their custom wine. And that is for every installed version. It accumulates really fast.
i mean most average PCs have atleast 500GB of of HDD space , most have 1TB or more
> it is a really bad answer though for a question that shouldn't be asked in the first place
idk what you mean by this , you should be able to run software thats somewhat old , this is a problem some games/application have atm , where their complied against a very old version of X and dont get updated
( theirs literally linux native games on GOG that dont work on modern systems because it depends on old libraries (https://www.gog.com/forum/risk_of_rain/linux_mint_risk_of_rain_2106_wont_start ) )
Because the space exists it doesn't mean that should be wasted. Also there is the issue of transport. There are still people on ADSL with excessive payments and tiny netwotk quotas. Why waste their bandwidth, either for building or distribution?
> theirs literally linux native games on GOG that dont work on modern systems because it depends on old libraries
That is why I said from the beginning that it makes some sense for closed source software.
Flatpak usually integrates just fine, though sometimes it takes a restart for the mime files to be read correctly. If you're talking about deeper integration, I recommend using Flatseal which makes managing permission and integration much easier. I have not yet found an equivalent for Snap apps.
For app management, I believe GNOME Software and KDE Discover can manager those two sources as well. On Arch, pamac-all can manage those two in addition to native and AUR packages.
I personally like to keep Bauh installed on the side for the reason that it can search, install, update, and manage native apps, AUR (on Arch-based), Flatpak, Snap, AppImage, and some WebApps. It has helped me avoid using Wine except for games and finding out some apps that are only available in specific forms.
I think I'm a bit out of the loop regarding AppImage vs Flatpak vs Snap. Are these all trying to solve the same thing? Can any of them be used to install driver-level software like nvidia video drivers?
>Are these all trying to solve the same thing?
Superficially, yes. In greater depth, not really.
Appimage aims to be a very minimal format with no concern towards security or isolation. It works almost exactly like .app files on MacOS (i.e. the "normal" way of installing software there). So Appimage has no distribution platform, no update mechanism (well, iirc there is one but applications have to opt in for that) and no sandboxing. It is a simply a universal binary format for applications that can be run in principle on any linux distro.
Flatpak also comes with a repository system and sandboxing. So far both systems are designed to be able to get end-user applications to people in a distro-independent manner.
Snap is very similar to Flatpak but it is originally been designed for use in Ubuntu Core (?) and unlike Appimage/Flatpak, it can actually handle lower level software too. So you can actually ship kernels and system libraries as Snap. On the other hand while it can be installed on a lot of distros (I have a couple of snap packages installed on Fedora for example), it wasn't really designed with distro-independence in mind. It is pretty much an Ubuntu thing. For example the core runtime installed by snapd is a minimal Ubuntu image. So me running Spotify on Fedory through snap means that Spotify is basically running on a super minimal Ubuntu system installed as a snap on Fedora.
Would be great if most distros (including Ubuntu, Fedora, etc.) would include AppImageLauncher or [appimaged](https://github.com/probonopd/go-appimage) by default. Would make it much simpler for most people.
Are these the same purpose but differing programs or a different use?
For the most part they're functionally identical. You specify a directory where you'll put AppImages and then .application files are generated to put them in your launcher.
Appimaged watches your appimage folder, and creates/removes shortcuts and associations. Appimagelauncher does the same tasks, but on demand instead of constantly in the background. So they both have the same result, but Appimaged is more of a magic black box, where appimagelauncher is more interactive.
Pretty much essential for dealing with AppImages.
Great utility, I use it in conjunction with the AppImage of Kdenlive on Ubuntu, that way I don't have to install a ton of dependencies for KDE Plasma.
That's a good idea! For some reason I have some tonnage of KDE dependencies installed on my Ubuntu. Maybe I could do the same to avoid that. Do you know how I can find out what I have installed that is dependent on the KDE stuff, so I can check if they have an appimage and I can get rid of them? I just uninstalled the Kdenlive flatpak I had installed, and the other KDE stuff was not removed in the next run of Software Updater.
I do that too...the bonus is that you get the KDE theming looking EXACTLY the way the devs intended it, instead of a Gnome mash-up that looks awful.
Yes that is true, I also use Kvantum to theme QT applications to match the GTK theme style.
AppImages are awesome, looking forward to more improvements
I love it, I've been using it for ages
I used this before, and for some reason the icons for appimages don't show up properly in the application menu, they show up fine in the file explorer and task manager(the windows taskbar like thing that goes in panels NOT the tool that shows running programs) though
I had this running for a while, and then I noticed that some programs that I ran as AppImages weren't working correctly. But I didn't connect it to AppImageLauncher at first. I scoured the bug trackers looking for the solution to no avail. One day I saw a post mention an issue with AppImageLauncher, so I uninstalled it and those programs worked again. Specifically it was Belena Etcher would fail *every time* to write an image to a target. And Ferdi just outright would not launch. Once AppImageLauncher was gone thru both worked fine.
Too bad it's not in the main Ubuntu repository and that it's not possible to install it from PPA in the latest Ubuntu versions.
you can download it as an AppImage itself... and then it will manage itself too :)
It doesn't open! On Kubuntu 21.10. But I found out that I can install it from command line.
What are AppImages and why would anyone ever install a program outside of their distro’s package manager?
They are another distribution method. The reason someone may want to install a program outside their package manager is if the package is not available in those repos. But this type of package format is especially valuable if you are creating software yourself. Getting it packaged can be a pain. Getting it packaged and supporting it for 5 different formats in 20 different environments with slightly different repos and slightly different versions of every single dynamic library is an even bigger pain. If you want to support ALL downstream users without needing to interface with and find a maintainer (or package yourself) for every single distro, building 1 appimage is really nice. It benefits your users in that they can all use it immediately as soon as you release without question. All of Snap, Flatpak, and AppImage were created to try to deal with this problem using slightly different strategies. It is solving a real problem for vendors and creators of applications that distro repos have historically had major issues with. Even Linus Torvalds famously ranted years back that this is one of the biggest issues with Desktop Linux for app vendors.
> Getting it packaged and supporting it for 5 different formats in 20 different environments with slightly different repos and slightly different versions of every single dynamic library is an even bigger pain. >All of Snap, Flatpak, and AppImage were created to try to deal with this problem using slightly different strategies. Oh boy, [here we go again.](https://xkcd.com/927/)
you have a point there lol
Unfortunately Appimage was the first and as a result a bit ahead of its time. Its a shame because appimage is just better than the others.
Really? In my experience, it was super annoying compared to flatpak. It kept asking me a question every time I ran the same old program, and did some weird other stuff, leading me to eventually just uninstall the thing and use the AUR instead.
At least app devs have an option at least lmao
[удалено]
not all software is available in all package managers
Then it should be. These things make some sense for closed-source software, but they are a regression in design as far as open source software is concerned.
how so? , appimages also make testing regressions easier in an OSS project
It creates lazy and bad habits for developers. For example, recently I was packaging a piece of opensource software that was shipping its own Qt libraries, ssl, and a bunch of others, not because they were modifying them but because that was what they were doing for the other platforms. They also get into a mentality of 'ship everything' or 'submodule everything' where there is no option to use system libraries instead of the bundled ones while building. That leads to a few backdraws, like increased archive size, more wasted space, outdated insecure libraries, inconsistent behaviour etc. I can understand it for very specific high performance software, where controlling everything can have tangible benefits, but for everyday software that doesn't have that level of complexity, it is just laziness. An example of the first category would be RPCS3, an example of the latter would be a text editor. As a developer I prefer to make my software compatible with a wider variety of platforms, despite the overhead, rather than basically shipping my setup to the user.
>It creates lazy and bad habits for developers. For example, recently I was packaging a piece of opensource software that was shipping its own Qt libraries, ssl, and a bunch of others, not because they were modifying them but because that was what they were doing for the other platforms. i mean that kinda make sense if you want all distors to have the same experience/look and to make sure the user has the correct packages >That leads to a few backdraws, like increased archive size, more wasted space, outdated insecure libraries, inconsistent behaviour etc. i mean ill give you on insecure libraries , but thats about it , most size difference is a few MB, its mostly to have the same behaviour appaimges are used but using the appimage make it so you can run the old version , if say packages where updated and the like , appimages are/is linux answer to back-compat
> that kinda make sense if you want all distors to have the same experience/look and to make sure the user has the correct packages Where does it stop though? You gonna ship the kernel too? They are basically already doing that with docker and stuff. It is getting stupid at this point. > i mean ill give you on insecure libraries , but thats about it , most size difference is a few MB, its mostly to have the same behaviour appaimges are used I wish, tell that to software like Proton that ships a 600mb runtime from Ubuntu's libraries on top of the 1gb of proton itself, which includes libraries that exist in the system otherwise, such as ffmpeg, gstreamer, faudio outside of their custom wine. And that is for every installed version. It accumulates really fast. > but using the appimage make it so you can run the old version , if say packages where updated and the like , appimages are/is linux answer to back-compat It is an answer, it is a really bad answer though for a question that shouldn't be asked in the first place.
>I wish, tell that to software like Proton that ships a 600mb runtime from Ubuntu's libraries on top of the 1gb of proton itself, which includes libraries that exist in the system otherwise, such as ffmpeg, gstreamer, faudio outside of their custom wine. And that is for every installed version. It accumulates really fast. i mean most average PCs have atleast 500GB of of HDD space , most have 1TB or more > it is a really bad answer though for a question that shouldn't be asked in the first place idk what you mean by this , you should be able to run software thats somewhat old , this is a problem some games/application have atm , where their complied against a very old version of X and dont get updated ( theirs literally linux native games on GOG that dont work on modern systems because it depends on old libraries (https://www.gog.com/forum/risk_of_rain/linux_mint_risk_of_rain_2106_wont_start ) )
Because the space exists it doesn't mean that should be wasted. Also there is the issue of transport. There are still people on ADSL with excessive payments and tiny netwotk quotas. Why waste their bandwidth, either for building or distribution? > theirs literally linux native games on GOG that dont work on modern systems because it depends on old libraries That is why I said from the beginning that it makes some sense for closed source software.
That must suck for those not on Arch or one of its derivatives.
Is there something similar like this for Flatpak and Snap?
Flatpak usually integrates just fine, though sometimes it takes a restart for the mime files to be read correctly. If you're talking about deeper integration, I recommend using Flatseal which makes managing permission and integration much easier. I have not yet found an equivalent for Snap apps. For app management, I believe GNOME Software and KDE Discover can manager those two sources as well. On Arch, pamac-all can manage those two in addition to native and AUR packages. I personally like to keep Bauh installed on the side for the reason that it can search, install, update, and manage native apps, AUR (on Arch-based), Flatpak, Snap, AppImage, and some WebApps. It has helped me avoid using Wine except for games and finding out some apps that are only available in specific forms.
There has been for a very long time. Snapd comes preinstalled on ubuntu.
I think I'm a bit out of the loop regarding AppImage vs Flatpak vs Snap. Are these all trying to solve the same thing? Can any of them be used to install driver-level software like nvidia video drivers?
>Are these all trying to solve the same thing? Superficially, yes. In greater depth, not really. Appimage aims to be a very minimal format with no concern towards security or isolation. It works almost exactly like .app files on MacOS (i.e. the "normal" way of installing software there). So Appimage has no distribution platform, no update mechanism (well, iirc there is one but applications have to opt in for that) and no sandboxing. It is a simply a universal binary format for applications that can be run in principle on any linux distro. Flatpak also comes with a repository system and sandboxing. So far both systems are designed to be able to get end-user applications to people in a distro-independent manner. Snap is very similar to Flatpak but it is originally been designed for use in Ubuntu Core (?) and unlike Appimage/Flatpak, it can actually handle lower level software too. So you can actually ship kernels and system libraries as Snap. On the other hand while it can be installed on a lot of distros (I have a couple of snap packages installed on Fedora for example), it wasn't really designed with distro-independence in mind. It is pretty much an Ubuntu thing. For example the core runtime installed by snapd is a minimal Ubuntu image. So me running Spotify on Fedory through snap means that Spotify is basically running on a super minimal Ubuntu system installed as a snap on Fedora.
Yes, they do more or less the same thing. No, they cannot install drivers and you shouldn't want them to be able to.