"AM" 9.7.1
Permanently remove notifications, if you want
With this release, you can simply run the existing command
am --disable-notifications
...to permanently remove update notifications, even for apps installed later.
Control of scripts requiring root
Fixed a bug with scripts named "remove", which in "AM" are set to run only with root privileges. By @Samueru-sama
Usage in Fedora Atomic
Added support for Fedora Atomic and distributions where /opt is a link in /var. By @fiftydinar
More AppImages, less portable apps
Started a transition where many standalone portable apps will have their own repository where they can be converted to AppImage packages, without alterations, and to allow isolation, sandboxing, and delta updates via
appimageupdatetool
(a big plus, especially for large packages).Some examples, all the development branches of Blender, UrbanTerror, Telegram... but also Calibre, Floorp and Mullvad.
Among the communities open to this transition, there is portable-linux-apps, which you may already know from our catalog, https://portable-linux-apps.github.io
Rehost/reassembly of old, unmaintained (and badly maintained) AppImages
Some apps hosted on problematic hosting services and others that have poor maintenance (for example, Libreoffice and the AppImages of Firefox and Thunderbird) have been rehosted on github repositories.
AppImage is dying, again! Many upstreams are removing them!
"AM" serves not only as a centralized database, but also as a solution for daily monitoring of hosting services, sites and platforms that produce and distribute AppImage packages, with the intent of preserving their maintenance and adoption by developers. Monitoring is done through cataloging these packages and daily testing via " amcheck".
Unfortunately there is an alarming fact to report: many upstream developers have abandoned the AppImage format or have completely removed their historical builds from their archives, apparently to prevent users from using legacy versions of their apps.
My efforts and those of my collaborators seem to be of no use. The lack of information leads many upstream developers to move all their work to more renowned platforms, such as Flatpak and Snap, which guarantee centralization in an official way.
About AppImages, their unavailability and lack of centralization are their weakness.
I wrote "AM", 5 years ago. "AM" is not the arrival, but the starting point, if you want to continue supporting portable packages.
Probably also due to the low visibility of this project, which offers to provide a centralized solution for all portable apps and AppImages.
I invite you to promote "AM" to make people understand that you don't have to look for AppImages. They are (and will be) here, if you want them!
Contribute to our cause! Help us support AppImage!
New Contributors
- @candrapersada made their first contribution in #1522
- @CODJointOps made their first contribution in #1527
- @coyoteclan made their first contribution in #1544
Full Changelog: 9.7...9.7.1
A new version of the "AM" AppImage manager has been released and introduces several improvements, including the ability to permanently remove notifications, control scripts requiring root privileges, and support for Fedora Atomic. It also introduces a transition where many standalone portable apps have their repository for conversion to AppImage packages, allowing isolation, sandboxing, and delta updates. This transition is supported by communities like portable-linux-apps. Additionally, "AM" has started rehosting old, unmaintained AppImages on GitHub repositories. However, many upstream developers have abandoned the AppImage format or removed historical builds to prevent users from using legacy versions of their apps. This lack of information has led many developers to move their work to more reputable platforms like Flatpak and Snap, which guarantee centralization. "AM" serves as a starting point for supporting portable packages and offers a centralized solution for all portable apps and AppImages.