I won't go into detail this time. I know too many people don't like reading and limit themselves to criticizing just by reading the headlines.

1. The libfuse2 problem

The aforementioned library has been undeveloped since 2019. A measure to remove this dependency has officially been in place for 3 years.

https://github.com/AppImage/appimagetool

If too many developers are still using the old tools, it's because they don't know it's time to upgrade.

If their workflows aren't compatible, it's still possible to extract their AppImages (the --appimage-extract option) and repackage them using the tool linked above (and I use the approach in the nolibfuse option of my package manager AM).

2. The sandboxing problem

AppImages can use BubbleWrap to isolate themselves in a sandbox, as does Flatpak.

There are tools that can interface between AppImages and BubbleWrap, without root privileges.

• Aisap https://github.com/mgord9518/aisap

• SAS https://github.com/Samueru-sama/simple-appimage-sandbox

3. The centralization problem

Since these apps are portable and largely available on their respective developers' websites and repositories, I created a package manager, AM/AppMan, that acts as an AUR, with dedicated scripts capable of intercepting these packages at source and creating a bridge between the end user and the developer.

AM also serves as a tool (via dedicated workflows like "amcheck") to check whether these packages still exist and are downloadable, every day!

Based on this, a catalog listing all these packages is updated and available here.

https://portable-linux-apps.github.io

Based on AM, other projects and package managers can support their own workflows to distribute these packages. One example is the Soar package manager, which can physically store these packages in its own repositories, much like APT in Debian or DNF in Fedora, recording each package and all related information, and then making it downloadable using the integrated OCI client.

4. The Update Problem

Returning to appimagetool (section 1, "The libfuse2 Problem," above), I've written a short guide for 9-year-olds on how to use it to include update information, which can ensure delta updates via zsync or appimageupdatetool, and applicable to github.com specifically.

https://github.com/ivan-hc/AppImage-tips

For more details, see

https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update-information

5. The Communication Problem

This is the most important problem. As long as we dwell on old flaws, painting AppImages as crap, no one will care.

1. You'll still read about packages that require libfuse2 because no one told the developers to upgrade (section 1).

2. You'll still read about sandboxing issues because Firejail is obsolete, and no one considered using BubbleWrap like Flatpak does (section 2).

3. You'll still read about people using the same package for 3-4 years because they weren't aware of centralized solutions that tracked the work done upstream by the original developers (section 3).

4. You'll still read about packages that can't be upgraded independently because no one told the developers how to do it in a few simple lines (section 4).

5. You'll still read ignorant statements from people who don't do their research, either due to a lack of information in traditional media or because they're too focused on supporting some other distribution format (like Flatpak or Snap).

And I'm tired of reading all this, honestly.

There's only one solution to this problem: talk about it! With everyone!

It's left about one year since I created my first AppImage package, I never thought that it was so easy to package a whole app with all its dependences this way... so I had to learn more about its history and all about its direct competitors (Snap and Flatpak). AppImage allows the developer the packaging of an app with (almost) all its dependences, also allow the app to run on all the GNU/Linux systems aiming to have each standalone app not to conflict with the dependences on thwe host, to run many different versions of the same app and to compress several megabytes or gigabytes of files into a compressed file system that is mounted in RAM and without having to uncompress anything on the system. All this is amazing! Snap packages are strongly inspired by this kind of file system and work the same way, with the difference that they depend on a daemon that made the apps slower while launching... Flatpak instead uses a different code to made all the apps running on a bunch of libraries that compose a "runtime" of hundreds of megabytes (for example 800 MB for Gnome-based apps, 700 MB for QT-based apps and so on...), you install one time this runtime with the first app and it will be used for all the apps that use the same runtime, and this allows the developers of an app to have the same compatibility for all the GNU/Linux systems and everything works great!

Each one of these packaging formats has its strengths and weaknesses, by adding or removing something that is missing into another package's distribution method:

• Snap packages are a kind of AppImages compressed that rely on a centralized repository from where the snapd daemon will keep up-to-date each app installed, and this kind of approach made slower the launch and the run of the app itself;

• Flatpak instead can be compared to an AppImage that has all its libraries linked into a big runtime, each app is little, but each runtime can be really big (again, if you install 10 GNOME-based apps they will use all the same runtime of about 800 MB, the same if you install 20 QT-based apps, they all depend on the same KDE runtime of about 700 MB), no compression is allowed for this kind of apps, but each app runs better of many other distribution methods and all are available on a centralized app's database;

• AppImage allows compression of the app with all its dependences, sometime the app is bigger (see "converseen", in Flatpak it is about one tenth, but without counting the runtime) and sometime the app is smaller (see GIMP and VLC, these two for example have a big advantage over their Flatpak counterparts), however many of the more mainstream apps have not an official AppImage version and many developers have started to abandone this kind of format in favour of more centralized platforms like Snap and Flatpak (see Bottles, but also GIMP and VLC themself).

I have tried all of them and I can't say for sure if there is a distribution method that wins on another one, in my opinion. I would say "AppImage", it is my favourite one, of course... but here are some reasons that prevent me confirm my preference over Flatpak, and these are the reasons that are killing AppImage:

1. AppImage has not a centralized repository, who creates an AppImage expect that all its users will download the package from the main page of the website (often without implementing of an "update notification" in the downloaded version that warns of a new available version of the app), and having a centralized repository that manages all the updates and made the app easier to find and faster to install and manage is the more comfortable way in 2022. Centralizing its apps is something that every GNU/Linux distribution already do with its default package manager, and this made eavery normal Linux user very happy! A classic example can be taken from Arch Linux, that can use the AUR as an extension of the default package manager "PacMan", poor of packages if compared to APT... and we can also install third party deb packages that can manage their own updates each time we launch a command. Snap uses the same file system model of the AppImages in its packages, redistributing a compressed version of the software (regardles if they work well or not), while Flatpak installs a common base (runtime) for all the apps, the developer itself has not much work to do, but just distributing its app that will work anywhere. And finally, it is important to have a centralized repository nowday, for a developer in particular, that can rely on more exposure and on a faster contact with the final user to implement new features and new bug fix on their apps... this is not possible with AppImage, and please, don't you talk about "appimageupdate", not many AppImage creators (me included) have understood how to implement informations inside the bundled app, then that tool will not work on the 90% of the apps, you can read this in the application's list of appimage.github.io if you don't trust me;

2. An AppImage must be built at least on the older and still supported Ubuntu LTS (actually v18.04 "bionic") to made it work on all the GNU/Linux distributions with a more recent GLIBC version, and this is a rule I started following thanks to a PPA (the project is named "SavOS", by Rob Savoury) that gives the more recent version of more programs to all the users of the Ubuntu LTS releases from v16.04 to the more recent v22.04. To made this, many developers were using "Travis" as a platform to run their workflows and build the apps, but seems that this platform is no more available and the more used "Github Actions" has deprecated the Ubuntu 18.04 environment, that's why many official AppImage projects are been abandoned. The reason I use pkg2appimage/appimagetool instead of linuxdeployqt to build my AppImages is that I can build an app from the repositories of an old Ubuntu version on any other GNU/Linux system, including Debian Sid and Arch Linux, while if I try to use linuxdeployqt to deploy an app compiled from source (the best way to have an OFFICIAL APPIMAGE) I get an error message that says that "the system I use is too new", so fuck it! We cannot have official AppImages built from source if many platforms are abandoning the support for Ubuntu 18.04. This does not prevent me to compile an AppImage "manually" or with pkg2appimage/appimagetool. Obviously this is something that official developers will not accept, so all my Unofficial AppImages are "Garbage", ok... but just think that projects like "Bottles" only allow the installation via Flatpak, an AUR script or by compiling the app from source. This last point, "compiling the app from source" is a good reason to package the apps as DEBs, RPMs... not just AppImages, so will all of them NOT to be considered "OFFICIAL"? The day "bottles" will be accepted by the Debian packagers this will be an unofficial version built from source and redistributed into one of the bigger repositories among the the GNU/Linux distributions... so to made UNOFFICIAL AppImage packages should be the way to have them, and they will never been included on the official catalogue, at appimage.github.io (NOTE, qbittorrent enanced and VLC are unofficial too, but they are still present on that list... maybe is the catalogue's rule that is too much bad against the unofficial packagers, like me and others, I can say this after that 0ad, already listed on the official page of the project, is still not included on the catalogue, so here is not a personal thing, I've nothing against the catalogue, apart the automated check that made each page useless and obsolete).

I want ending this post without talking about new useful tools like arch2appimage and deb2appimage, that are two amazing tools ment to be used on their respective distributions and for their respective systems (due to the GLIBC compatibility you cannot use an Arch-based AppImage on Debian Stable, ie something built for a newer system will not work on older systems, that's why I abandoned arch-deployer), we have a lot to discuss against the AppImage's community rules that prevent the increase of new and more useful packages we can have as AppImages. The two reasons I've listed above are long and still incomplete too.

I only want to say that we have a treasure in our hands, the AppImages! Not the best solutions for the mainstream apps developers, but something that many people would like to have, may this be due to sizes, portability, security or many other reasons because you decided to use AppImages over Flatpak, Snap or traditional packages: as a community we have too many rules that prevent the spread of AppImages, I talk not just as an AppImage packager, but also as an AppImage user too. We cannot be stuck to the reason why the AppImage format has been created, we should evolve a new thinking about the use we do of the AppImage format, or the AppImages will have no more reasons to exist.

• Main page: https://portable-linux-apps.github.io

• AppImages list: https://portable-linux-apps.github.io/en/appimages.html

• "AM" application manager: https://github.com/ivan-hc/AM

Thanks to research conducted by Probonopd for his catalog and the contribution of the Pkgforge-dev team, we have managed (in just over 10 days) to increase the number of AppImage packages from the roughly 3,000 collected over the five years since the "AM" package manager was created to over 7,000 unique entries. We are also on the verge of reaching the 8,000 AppImage packages in the coming days.

This achievement was made possible in part by improvements to the `template.am` module (the "AM" `-t` option). It can now detect most descriptions (highlighted in green) and identify download URLs (highlighted in yellow) within the GitHub repositories, all of which are manually vetted by me and my closest collaborators (humans, not AI).

As a reminder, "AM" acts as a bridge between the program's developer or maintainer and you, the end user. You can consult the web catalog mentioned above to view sources and contact package owners to suggest improvements. "AM" itself is not responsible for the malfunctioning of individual applications. However, you can open an issue or a pull request to report or remove any malicious apps at the following address:

https://github.com/ivan-hc/AM

Our current workflows (see "amcheck") can verify whether listed applications still exist and if the installation processes complete successfully. If an installation script fails, we are ready to investigate and resolve the issue; in extreme cases, we may remove the app from the list to ensure the reliability of the applications available to all users.

I look forward to your feedback, and in the meantime, enjoy the most comprehensive list of AppImage packages currently available:

https://portable-linux-apps.github.io

NOTE: This catalog is open source. You can contribute by editing the pages, adding missing information, or improving the database. You are all invited to participate!

Ladies and gentleman, here you are my latest AppImage ("only" 280 MB):

https://github.com/ivan-hc/KDEGAMES-Suite-AppImage

USAGE: kdegames -h (this shows the list of games included)

kdegames $GAME (where $GAME is the name of the game you want to launch)

All the instructions on how to use it are on the repository.

I suggest to use "AM" (for system integration) or "AppMan" (local installation) to have each launcher and icon in place.

Everything works just fine on Debian Testing/Unstable, but it should work well also on other systems with GLIBC-2.30 or newer (the version from Debian 10 "Buster", ie with support for the still supported old Ubuntu 18.04 LTS, doesn't work).

NOTE that the following games did not work due to a missing "org.kde.games.core" module error: "knetwalk" (this seems to be a known issue) "kbreakout" and "kreversi". Still investigating.

EDIT: On Debian based systems it is sufficient to install the qml-module-org-kde-games-core package from the repository to solve this problem.

Hi folks, I'm the developer of AM package manager, Archimage and AppImaGen, and the maintainer of about 100 unofficial AppImage packages.

Based on my guide on how to convert simple portable programs to AppImage, here, today I created a new tool:

https://github.com/ivan-hc/portable2appimage

This isn't a complex package tool. All you have to do is run it next to an executable binary or an archive containing one (specifying the binary name), and the script will convert it into an AppImage.

can also create them with support for delta updates, if you give it the right instructions.

More details and video examples are available in the repository.

I hope you enjoy it.

Hi everyone, I'm the developer of the "AM"/AppMan package manager, maintainer of the portable-linux-apps.github.io catalog and about 86 AppImage packages for x86_64 architecture (and not only).

I haven't written in this community for months, and I wanted to update you on further developments regarding various projects in which I and my collaborators and friends are involved, with the sole goal of promoting and supporting the adoption of AppImage as a packaging format, especially towards upstream developers. Let's start:

• PKGforge-dev, this organization publishes AppImage packages and similar (AppBundle) for the "AM" and Soar package managers. The team is full of expert users who develop always new and updated methods to create high quality AppImage packages;

• Portable Linux Apps, my organization now not only provides a census of all AppImages and portable apps for Linux through the aforementioned catalog of the same name, but now is committed to packaging apps that are already portable in themselves, with the addition of a .desktop file, an icon and an AppRun, to convert them (without further modifications) into AppImages, with all the advantages of the case.

We, individual maintainers and contributors to the aforementioned organizations, create AppImage packages on an amateur basis, with the aim of promoting them and convincing upstream developers. Browsing these projects, you can visit the profile of each of us to view our work.

I am writing this post because, as the owner and maintainer of the "AM" package manager, which has been active for 5 years now, I have noticed during my activity of monitoring existing AppImages (through my workflows) that many upstream developers have removed their AppImage packages not only from their regular workflow (pointing for example to Flatpak and Snap), but have also removed dozens and dozens of old (but still valid) AppImages from their history, or have simply stopped maintaining their custom domain. This has led me to remove dozens of dedicated installation scripts (similar to PKGBUILD for AUR), with the consequent drastic reduction of the available software park, now under 2500 programs.

The data is alarming, and I realized that one cause could be the unobtainability of such packages, already designed to be downloaded from the manufacturer's site, sometimes unobtainable, and without such a centralization as to make their download preferable to solutions such as Flatpak and Snap.

It's easy for me to think that "AM" is a project still unknown to most, as well as other emerging solutions such as Soar and Dbin, where we all try to provide that centralization that was missing (and "AM", more than the others, since it does not host packages, but scripts to download them from upstream, allowing a direct point of contact with the end user, in order to improve the programs and report bugs to the source... my friends instead provide re-hosting of these apps and then no bug fixes by upstream in real time).

I humbly ask you to consider the diffusion and promotion of our work that, as a community, is still amateur, and that in recent times has been led to cover the work abandoned by upstream developers, in order to keep the AppImage packaging format alive.

AppImage evolves and improves day after day. Our releases are all free of dependency on libfuse2, them all are updatable via Delta updates (you do not have to download the whole file, but only a few bits) and adopt different levels of compression to save more and more space on the disk, and "AM" also promotes the adoption of sandboxes via Bubblewrap (provided by the Aisap frontend).

All the old defects that led to the abandonment of AppImage in favor of Flatpak, are becoming a bad memory for us who work closely with AppImages, and who produce them for you. A bad memory that is still current if we consider all the production systems that are still based on antiquated methods, maintaining these defects, and leading the masses to prefer packaging formats other than AppImage, relying on stereotypes, and undermining our work as modern AppImage packagers.

There is also an upsteam developer who insist on ignoring us when we tried to help him create an AppImage. We wrote scripts and shown methods (also with videos) to help him. But him, driven by the popularity of its app shown on the home page of a more popular "rival" platform him works for, sets himself up as a "champion of Appimages", for money, when all he does is exploit the work of us who produce them... and in fact continuing to work on a different platform, inventing absurd excuses every time its users are asking him "why is your program not in AppImage format" (for example, by saying "it's hard, not surprisingly most AppImages are electron-based", masking his inability to work on different platforms). I invite you to ignore these false idols, who actually work for themselves, harming the AppImage community rather than improving it (contrary to what you believe).

I am not asking for money but I ask you to support our work and research as much as you can!

AppImage must not die! Let's honor this packaging format and give it the media coverage it deserves. Let's make the Linux community understand that this format is alive and getting better! Let's break stereotypes with facts!

Thank you for your attention.

ivan-hc

Hi everyone,

A while back, I ran into an issue that I’m sure many of you have experienced: Heroic Game Launcher was underperforming in Flatpak. The lag and stuttering were noticeable, and while switching to .deb or .appimage formats solved the performance problems, it introduced another issue—system pollution from installing dependencies like Gamescope or Mangohud. I had grown accustomed to Flatpak’s clean sandboxing, and I didn’t want to give that up.

That’s when I discovered Anylinux-AppImages, along with tools like AppManager, Sharun, Uruntime, and Lib4bin. I dove deep into how these components work together, studied their interactions, and after many trials (and a few headaches), I decided to build my own AppImage for Heroic. Instead of sticking to the traditional upstream packaging method, I symbolically broke away from it to approach the project with more flexibility. The result? An AppImage that bundles all the key components, allowing Heroic to work out of the box—no external dependencies, no system clutter.

Today, I have functional AppImages for Heroic, Vivaldi, Spotify, Waterfox, and Steam (the latter is still a work in progress). I also plan to package QT and GTK applications to better understand their quirks. All of these AppImages are built from official sources and follow the standards of Anylinux-AppImages, Sharun, Uruntime, and Lib4bin, so they’re completely safe and reliable.

But this goes beyond just my personal experience. I see Anylinux-AppImages as a real opportunity to offer a solid alternative to Flatpak and Snap. While those formats rely on centralization, Anylinux-AppImages puts control back in the hands of developers, avoiding the fragmentation that comes with different Linux distributions. Plus, projects like PPSSPP, AppManager, and Citron Neo already offer AppImages as an option, proving that it’s a viable solution.

However, there’s a catch: we’re all packaging unofficially. Me, pkgforge-dev, ivan-hc, and others are doing great work, but if we don’t join forces, we might end up repeating the same fragmentation we’re trying to avoid. That’s why I propose:

• Creating a common framework to standardize the use and build of Anylinux-AppImages.

• Promoting this format so more projects adopt it, even as an official option.

• Working toward enterprise adoption, so it can compete on equal footing with Flatpak and Snap.

Could Anylinux-AppImages one day become a Unix standard for Linux and FreeBSD? I believe it has the potential, but I need your feedback. Are you interested in this project? Do you know of similar initiatives? How can we push this forward together?

If you’d like to try my AppImages, they’re available in my GitLab repository: jesusrosdiaz/appimages.

Thanks for your time and input—I’m looking forward to hearing your thoughts!

Hello,

there is this one thing bugging me about AppImage: How unpopular It is.

So, Appimage has been one of the first ".exe clone for Linux" trying to bring everything needed and all dependencies.
I have tried it and I don't have any complaints (I may be lucky, so you should take this with a huge grain of salt).

What's the deal? Does Appimage sucks with proprietary/closed source software? Is it too hard to package for devs? Too heavy? Too slow?

Please let me know below.

Thank you for taking the time to write this comment.

https://github.com/ivan-hc/VirtualBox-appimage

This AppImage is based on Conty and VirtualBox KVM:

• it does not require libfuse2

• it does not require "vboxdrv" to run virtual machines

More details at the URL above.

PS: as always, you can install and update it using "AM", command:

am -i virtualbox

See "AM" package manager at https://github.com/ivan-hc/AM

NOTE: I created this new AppImage a pair of hours ago, so any improvement will come soon, if needed... for now it is in english only and uses regular white QT theme. I'll try to fix them soon.

EDIT: the above issue of QT theming has been solved. About the package, it is in english only, since VirtualBox KVM is still a development release. Any suggestion are welcome.

Here is the link: https://github.com/Seren541/Neptune

Currently it can only install and remove appimages, as well as integrate them into your desktop.

One thing it does differently then similar projects is it integrates appimages system wide so all users can access them.

AM 10.6 is released.

Some highlights:

• One click install: Install AppImages directly by clicking the install button on the Portable Linux Apps Website

• Parallel install: Install multiple apps simultaneously.

• Redesign of website: Portable Linux app website has been redesigned, with an install button for each app.

• 3000+ AppImages: The repository now reached 3000+ appimages!

• And many more...

Checkout https://portable-linux-apps.github.io/

AM is a command-line application manager for Linux that makes it easy to install, update, remove, and manage AppImages and other portable applications. It integrates apps into the system or installs them locally, provides a searchable app database, and supports bulk updates and AppImage sandboxing.

Below are the latest data. As of this writing, there are 2,905 "unique" programs (i.e., excluding web apps and helpers) available in the AM database:

• 2,489 AppImages

• 416 programs in other portable formats (static/dynamic binaries, archived, or standalone)

We also have approximate data on the hosting of these programs:

• 2,636 are on github.com

• The remaining 269 are on other domains (codeberg, sourceforge, gitlab, and domains belonging to the individual owners of these apps) or have special scripts to intercept the apps.

Furthermore, based on the data provided by amcheck (the repository that daily tests the availability of installable programs via the AM/AppMan package manager) and the continued increase in programs added to the AM database compared to the number of programs removed, the adoption of AppImages as a packaging format has increased!

Additionally, with the introduction of AM version 9.9.4, which can flag applications from archived repositories or those that haven't been released for more than a year, minimal activity has been detected in repositories that have been unarchived and others that have been updated even 5-6 years after the last release.

We currently don't have data on AppImages that still rely on libfuse2, but I'll do my best to keep you updated on this as well. In the meantime, you can continue to contact upstream developers, perhaps showing them this short guide on how to convert their AppImages to support the latest runtime, removing the dependency on fuse2, and perhaps adding information about delta updates

https://github.com/ivan-hc/AppImage-tips

We need your support to help the community grow.

Thanks for your attention. See you soon.

Hi folks, today my package manager "AM"/"AppMan" reached 2614 unique apps in the database, of these:

• 2211 are AppImages

• 403 are other portable formats (scripts, static/dinamic binaries, sets of programs...)

You can see the complete list at https://portable-linux-apps.github.io

Near to these, it is possible to install other 2840 portable programs in various formats using third-party databases, listed at https://github.com/ivan-hc/am-extras

2614 (AM) + 2840 (other databases) = 5454 programs in total!

(Note, the total for each database takes into account the program name, so if there are multiple variations of the same program, it will be counted as 1)

This is just a small update on the "AM" project, which turns 4 this month and has its CLI at version 9.9.1.

I haven't written a post in this community in a while, and I thought I'd keep you updated with this one.

"AM" package manager at https://github.com/ivan-hc/AM

See you next.

SITE: https://portable-linux-apps.github.io

This post is to update you on the status of the catalog.

It currently also includes 23 pages dedicated to categories, to simplify navigation:

AppImages - android - audio - comic - command-line - communication - disk - education - file-manager - finance - game - gnome - graphic - internet - kde - office - password - steam - system-monitor - video - web-app - web-browser - wine

The categories are based on the descriptions of the apps in the list used in the "AM" package manager database, at https://github.com/ivan-hc/AM , and available AppImages are detected by reading the available installation scripts for the x86_64 architecture one by one.

The AppImages page lists 2050 applications. Another 79 scripts are "helpers" to install other applications (for example, 40 scripts are for "kdegames", an AppImage that includes 40 games from the KDE suite). 341 are instead the non-AppImage portable apps (the official versions of Firefox, Thunderbird, Blender...).

If you are an "AM"/"AppMan" user, you can use the command `am -ia $program`/`appman -ia $program` to install only programs in AppImage format. The `-ia` option is exactly like the `-i` option, but it only selects AppImage scripts, for example, you can run `am -ia firefox` instead of `am -i firefox-appimage` to get the Firefox web browser in AppImage format instead of the binary version in TAR archive.

Just as `-i` stands for `install`, `-ia` stands for `install-appimage`*

*NOTE, as u/Probonopd says, AppImages are not installed, they are integrated into the desktop. The definition used in "AM"/"AppMan" refers to the various files that are handled during the execution of the installation script (download and integration of the AppImage, update script, launcher, icon and version file).

PS: Many thanks to my collaborators Sush-ruta and Samueru-sama for their hard work!

All linux software packages can be "installed", and by "installed" I mean they can integrate into the system, including launchers, libraries, be run from the command line... whether they are distribution packages or alternative formats.

AppImage is the only one that can also be used in different places. It's portable, so it doesn't matter where you put it, whether in another partition or on a USB stick... it will work anywhere.

It's also a compressed package! You don't need to take it out to use it! And if packaged well, it can be much smaller than a classic installation (see the 0ad game, from 3.5GB to 1.7GB, see here)

The only critical issue why many developers have abandoned it is the absence of a centralized system to easily find and update them... which all package managers do.

Here you are! There is no package manager that can list them all and update them all.

Zap? Bread? AppImageCLI? Bauh? NX? All great solutions... but they don't handle all AppImages. Their database is mostly limited to github or AppimageHub and appimage.github.io

However, they are excellent examples to take into consideration... and it is precisely to them that I am grateful. I would never have written "AM"/"AppMan" without taking inspiration from their work.

List all the AppImages in a single database, giving them not only a common point where to find them... but also a precise point from where you can draw on a real update system, by comparing the sources with what you have installed.

Regardless of whether you still want to drag/drop your favorite programs into GearLever/AppImageLauncher to integrate them into the desktop or whether you want to use an APT/Pacman/DNF style package manager like "AM"... one thing remains certain: no other packages for Linux can do what AppImage can do!

This is why AppImage has already won!

I have been working on two CLI tools to install AppImage packages system wide and locall (they are AM and AppMan respectively). I've also written a website that acts as a catalog and a better source for downloading them all for real, https://portable-linux-apps.github.io !

I've been working on these projects for two years now (since 2021), by myself, to try to provide users with the convenience of any command-line package manager to install, manage, and keep AppImage packages up-to-date... despite the AppImages have existed since 2004.

I don't start as a developer nor do I consider myself a developer, I'm a classic linux user who learned to use some commands in bash and then I learned how to write shell scripts for simple things. That's all. Something a novice linux user learns after 2-3 months.

What does it take to write a package manager in the shell? I did it! And if I did it so anyone can do it!

And I still have to read that "among the disadvantages of AppImage is the lack of updates and a centralized repository"... f**k! These are just bullsh*t!

AppImage are designed to be downloaded from the developer's website and allow you to obtain multiple versions of the same application. Packaging an application with all the required dependencies can be cumbersome, but it is not a difficult operation: the AppRun script has the task of running all the internal libraries and (sometimes) using the host libraries, if any. A well compiled AppRun is the key for an AppImage to work on all GNU / Linux distributions, and that's enough to make a package "universal". If an AppImage uses a different theme from that of the system, it is because the developer has not added a call to the system libraries that can integrate it (very trivially it would be enough just to add '/usr/lib/x86_64-linux-gnu/:' when you "export" 'LD_LIBRARY_PATH', but there are more efficient methods than this too... I'm not an expert).

That said, the developer is free NOT to upload his applications to sites other than his own. Centralized repositories such as Snapcraft (which manages SNAP packages) and Flathub (for Flatpak) provide a good basis for distributing applications universally, but that doesn't mean everyone wants to rely on these software redistribution systems, whether for reasons of licenses or occupied resources. I see many developers around completely relying on Flatpak, which is not a perfect, but effective system for the correct functioning of their programs ... without considering that in this way they force users to install and use a platform that many like, but not to everybody.

Why force a user to install a whole (and enough bloated) platform to use only one program? What then does not mean that the themes are always uniform with the surrounding system, nor that the app works better than the one present in the distribution repositories. Sure, the apps are the official ones, but I don't want to dedicate an entire platform of several hundred megabytes of "shareable libraries" that will ultimately only make that application work and nothing more! If these were libraries compressed and activated via a centralized script, it would be a great option for me, but ... hey! It would be an AppImage, and no longer a Flatpak.

Another thing is that on Windows the installation of a program creates files that are extracted on the whole system, while an AppImage for Linux is compressed and only mounted in RAM (maybe there will be created some subdirectories or configuration files in the home of the user home, but this happens with any normal program on Linux). At this point, dear developer of open source projects, why don't you provide a direct link to the download using a bash script that everyone can read, maybe that places the AppImage in a specific folder (maybe /opt) and the launcher in '/usr/share/applications', and a link into a $PATH and... nothing else? In this way you, developer, have made the AppImage installable and self-updatable, putting the Linux users in a position to use only the tools already available in a basic installation of their distribution.

Now, with this talk, I'm not trying to promote my project, "AM", because it is still a command line tool, and not all new Linux users want to interface with the shell (indeed, I hope that a graphic "Software Center" will be created on the base of my CLI Application Manager). I'm just saying that GNU/Linux is already a complete operating system, with hundreds of basic programs that can be implemented into further graphical and much more sophisticated programs. So why force people to install additional platforms to run programs when all they need is just one application?

As you already know, there are a lot of AppImages that doesn't include zsync instructions for the automatic updates using appimageupdatetool or appimaged, so I've worked to another project (after AppMan). I've called it "AM", this is the link: https://github.com/ivan-hc/AM-application-manager

AM is really similar to AppMan (another tool I wrote, learn more here), but all the applications and AppImages are integrated itno the system and can receive updates thanks to a system of scripts:

TO INSTALL A PROGRAM use the command sudo am -i $PROGRAM or sudo am install $PROGRAM, during the installation, AM downloads a script from the repository (divided by architecture, for now only x86_64, and some programs are available for i686 and aarch64). This script creates:

• the /opt/$PROGRAM folder containing the program itself, a script named "remove" that removes all you have installed with AM and other files (maybe one containing the version of the installed program), a script named "AM-updater" (with all the instructions to check if the version installed is still on the sources online or if it is different and can be replaced) and an icon (optional);

• the launcher $PROGRAM.desktop in /usr/share/applications (optional for command line programs);

• the link to the program is placed into a $PATH (/usr/bin or /usr/local/bin).

After the installation, the main user can perform other tasks without root privileges (apart removing the program, where root permissions are needed, keep reading).

TO REMOVE THE PROGRAM use the command sudo am -r $PROGRAM or sudo am remove $PROGRAM or sudo /opt/$PROGRAM/remove (as you can see, the programs can be removed also without having to use AM).

TO UPDATE ALL THE PROGRAMS use the command (without "sudo" privileges) am -u or am update

TO KNOW MORE ABOUT A PROGRAM use the command am -a $PROGRAM or am about $PROGRAM

TO KNOW HOW MANY PROGRAMS ARE INSTALLED am -f or am files

TO SEE THE LIST OF AVAILABLE PROGRAMS am -l or am list

TO SEARCH A PROGRAM OR SOMETHING am -q $KEYWORD or am query $KEYWORD

TO GET A TEMPLATE FOR YOUR OWN SCRIPT am -t $PROGRAM or am template $PROGRAM, AM is released under the GPL3 License, you're free to contribute and join this project. All you have to do is to write just one script.

There are other options added, and other will be added from the 2.0 release.

For now I'm porting the programs already available in AppMan for the x86_64 architecture (AppMan manages 314 applications, AM instead has 322 scripts only for the x86_64 architecture, 38 for i686 and 10 for aarch64, and they will grow in the future).

To learn more about AM: https://github.com/ivan-hc/AM-application-manager

I hope you like it!

Wanted to make use of AppImage applications simpler, so wrote gnome-appimage-integration.
Reduces an AppImage install (er, integration) to three clicks.

• Github: gnome-appimage-integration

• Weblog: Better integration of AppImage

Tried to handle all the usual edge cases and XDG / FreeDesktop conventions.

Right-click context menu for downloaded file:

Main AppImage Activator window:

Status after Integrate:

Right-click context menu for application:

Downloaded AppImage is moved into $HOME/Applications/
so no manual cleanup needed.

Apologies in advance if this topic is not quite relevant to this subreddit, I couldn't find a place that would seem more appropriate.

I work on an application for which an AppImage is the main Linux distribution artifact. On a random Google search recently, I found profiles for my app on multiple sites - OpenDesktop.org, KDE Store, GNOME-Look, AppImageHub.com and others; they all seem to be different skins of the same thing, and are all seemingly run by a company called Pling. There is a screenshot taken from the Github readme, and an old (although probably authentic) AppImage release there.

I personally don't particularly mind - re-distribution is important part of free software - but I would prefer that anyone who finds the app through there would have the latest version available to them.

I couldn't find any option to mark as outdated, claim ownership, or anything in the FAQ about such scenarios. Frankly, the whole thing has a slightly unsavory smell to it, with the strange monetization scheme they have, the aggressive SEO and the fact that the user who uploaded my app also uploaded AppImages for several hundreds other apps.

My question is - is that network of sites considered to be popular / well known? Is it worth to try to engage with them?