[Installation] Is there a best practice for using AppImages?

[RollingPanda]

Hi,

Wondering if there are any apps that can manage AppImages with a drag and drop, i.e., store the apps in a common place, generate desktop files, and maybe even check for updates?

Thanks,
RP
Oh and where do people usually store AppImages?

[claydoh]

Appimages are run from wherever they are located, there is no formal location for them. That is up to you if you want to put them somewhere specific. They can be run from anywhere.
If you want to manage them a bit better, there is a utility you can install called AppimageLauncher. It has some useful features

Best/easiest place to get it from:https://launchpad.net/%7Eappimagelau.../ubuntu/stable
https://github.com/TheAssassin/AppIm...untu-or-Debian

[RollingPanda]

That's excellent. Thank you for the tip claydoh!

[GreyGeek]

Adding to what Claydoh wrote, I store my AppImages in a subdirectory of ~/Download called AppImages. After setting their execute permissions, I edit the KMenu to add them to its listings. The only downside to AppImages is that I run, which is 15, is that I haven't come across one that includes its own icon for the menu. I usually do an Internet search for a suitable icon of the appropriate size. AppImages will leave config and data files on your home account. FreeCAD, for instance, leaves your drawings in its ~/.FreeCAD config file. Generally, you can store data files that you generate anywhere you want to put them.

AppImages are very flexible. I use CubicSDR to run the rtl-sdr dongle I purchased, which is the Rafael Micro R*20T/2, which has a range of 24 - 1768 MHz.

I prefer AppImages over snap or flatpak packages because they don't depend on having snapd running all the time and, if you are super cautious, you can run them with firejail. But I don't bother doing that.

I use the AppImage of Audacium (the fork of Audacity), balenEtcher, Blender, Minetest, OBS and others. Around 15 in total.

[Bings]

https://github.com/prateekmedia/appimagepool is something for browsing and managing appimages that are hosted on appimagehub. It stores them in ~/Applications iirc Most/All appimages on there are not official but packaged by the site's members.

[RollingPanda]

GreyGeek About the desktop icons for AppImages: I noticed that too I had to google for PNG image format desktop icons for AppImages. As for preferences of flatpak, appimage, and snap. I would prefer snap tbh, however, I had two issues with snap, the dialogue boxes that pop up from the app get a font which just contains boxes/rectangles and I've tried everything to try to fix it with no luck. On top of that, apparently AppImages have way better performance according to this: https://verummeum.com/portable-package-formats/ Thanks for the reply!

Bings Thank you for the link, looks great, will try it.

[GreyGeek]

GreyGeek About the desktop icons for AppImage: I noticed that I had to google for PNG icons for AppImages. As for preferences of flatpak, AppImage, and snap. I would prefer snap TBH, however, I had two issues with snap, the dialogue boxes that pop up from the app get a font which just contains boxes/rectangles, and I've tried everything to try to fix it with no luck. On top of that, apparently AppImage have way better performance according to this: https://verummeum.com/portable-package-formats/ Thanks for the reply!

....

It has been my observation that AppImages DO run faster than apps installed from the repository. The reason is the difference between dynamic and static compiling.
When one compiles a program in the dynamic mode the program depends on the correct libraries, of the correct version, to be on the disk and a call is made to the disk to load the library into memory. The library function table is available as a pointer to the code in the library. Sometimes the library needs to call code from the disk. For SSD's the penalty is not too bad, but for HDD's it can slow the code considerably. Static compiling is where the compiler compiles all the libraries the app needs in with the app itself to produce a binary which can be much larger than the binary of a dynamic compile. It days gone by the size of the app was important because disk space was at a premium, that is, there wasn't much of it, and so was RAM. Dynamically compiled apps work best on system with a large amount of memory. The more memory the less paging. IF you have enough memory, the app doesn't have to page at all and the only time it accesses the drive is to store data.

Today, a 1 TB HDD can cost less than $100, and some less than $50. 2, 4 and 8 TB drives make storage cheap and statically compiled apps are not so much of a problem today. About 17 years ago, before I retired, I was training an individual to replace me. At the time we were using Visual FoxPro 6.0 to make a client-server app that accessed an Oracle database. Normally, the compiled dynamic app was about 5Mb in size, IIRC. The rookie's first compile was 52Mb, and it was a dynamic compile. The rookie had included the entire database into the app. When clerks started calling me I fired up the app and noticed the slowdown. After 5 minutes, the app wasn't loaded and the network hadn't yet been touched. We checked with personnel about the rookie's qualifications. They called former employers (you wouldn't do that today) and found that the individual was lying about their qualifications and falsified their documents. Needless to say, that individual was fired.

[claydoh]

My appimages are not running any faster, but it does depend.

I use Openshot, installed with native packages, and also via appimage, as lately the newest deb versions have been sometimes ...buggy. This is a Qt app, not a KDE one. It takes more than twice the time to load the appimage version.
The appimage has to loads its own qt, its theming bits, and everything else that you might already have loaded in ram. It is a bit slower when editing/rendering but not by much. AND it does not work in Wayland ;p while the their PPA version does. Not to mention that the appimage does not have hardware decoding baked in, so it is not available as an option (and hwaccel is not always the better choice here, to be sure)

[RollingPanda]

Thank you for the detailed replies. Although I don't have memory, space, or even performance problems there are a few snap apps that I replaced with binary downloads since they loaded very slow. Hopefully it will get better in the future because snap (and flatpack etc) are really nice technologies imho for business environments and so on.

[GreyGeek]

Personally, I don't run snap because having a service running continually when its services are needed only occasionally suggest other reasons for the service. Those other reasons include "telemetry". I don't install TeamViewer for the same reason. When I require it I'll install it but when I am finished I uninstall it. However, most of the friends I've helped move to Kubuntu have passed on (I'm 80), so I haven't run it in several years. I like the fact that AppImages do not touch your system aside from being stored on it. When I exit an AppImage, it is no longer using any services. When I delete an AppImage it is gone completely from my system. No lingering traces, except for any data files that I may have created using it.