Software 43123 Published by

A new version of the "AM" application manager for AppImage has been released with various improvements.

A new option -HC has been introduced, enabling users to configure dedicated $HOME and $XDG_CONFIG_HOME directories for multiple AppImages simultaneously. The -C and -H options have been transitioned from the sandboxes.am module to the management.am module, with the former specifically focused on sandboxing through Aisap and BubbleWrap. The program additionally eliminates installation scripts for outdated, optionless Type 1 AppImages, prompting users to reach out to upstream developers for security considerations. Scripts are currently subjected to testing 250 times each hour, every day, to maintain oversight and evaluation of applications installed from the "AM" database. The program addresses an issue related to updating outdated ghapikeys, facilitates the listing and search of portable apps exclusively within the "AM" database, reverses backup/restore options, and permits app references from additional databases.





"AM" 9.6.2

Various improvements

Since "AM" is a modular program, modules can receive updates separately, independently of changes in the main CLI "APP-MANAGER"... which is why three-digit releases can bring with them much more news than two- or one-digit ones, and vice versa.

This three-digit release brings with it the following.


New option -HC (or -CH if you prefer)This new option is nothing more than the combination of the options -H/--home and -C/--config, useful to set dedicated $HOME and $XDG_CONFIG_HOME directories for one or more AppImages, this time in one go.You will need to run
am -HC {PROGRAM}
instead of
am -H {PROGRAM} && am -C {PROGRAM}
...and of course you can use multiple arguments at once.DISCLAIMER: AppImage dotfile isolation works in most cases, but it all depends on the default settings wanted by the upstream developer/packager. Please use --sandbox to ensure dotfile isolation, as well as improve security.In this sense, the above-mentioned -C and -H options have been moved from the sandboxes.am module to the management.am module, and the former will be completely dedicated to actual sandboxing via Aisap and BubbleWrap. "Limited" Type 1 AppImage supportInstallation scripts for obsolete, optionless Type 1 AppImages have all been removed. However, they will still be manageable using the --launcher option."AM" discourages the use of Type 1 AppImage packages and encourages users to contact upstream developers to upgrade to a more recent and widely supported runtime, for security reasons.Typically, Type 1 AppImages are the kind of files that, once downloaded, cannot be extracted using --appimage-extract nor respond to the other options commonly found on most Type 2 AppImages (both the older ones that depend on libfuse2 and the newer ones that don't)... and instead, the program is launched directly.That's why I preferred to remove that type of AppImage.Anyway, if you really rely on an old type 1 AppImage of 2018 or older, install 7z and manage it with --launcher as I said above. WorkflowsScripts are now tested at 250 at a time every hour, every day, to ensure control and review of the applications that can be installed from the "AM" database.While the workflow is currently disabled in this repository, it is still active in our test repository maintained by @zen0bitSee https://github.com/ivan-hc/amcheck/actions/workflows/test-apps.yml for all results. Option apikeyFixed an issue with updating outdated ghapikeys, by @nazdridoyOptions -l/list and -q/query, new --portable flagIt is now possible to list and search for only portable apps (not AppImages) in the "AM" database using the --portable flag Options -o/overwrite and -b/backupBoth backup/restore options and other options of the same type that use selection can be undone by pressing ZERO, no undo with CTRL+C is needed.Options -a/about and -f/filesApps outside of supported databases, i.e. AppImages installed with the -e or extra option, can now be referenced as being from the extra database (which does not exist) in -f, just like programs installed from supported third-party databases.ConclusionsI know that bombarding a release with information like this is difficult and may seem confusing (especially for some sites that specialize in reporting releases and that, in an attempt to rework a text with AI, write something completely different from what I wrote here... in fact, unlike Agent Smith in the Matrix, I say "never let a machine do a human's job")... but I have my logic on how releases should be. They should describe real changes... and they should not be aimed at attracting attention and visibility by pushing your project to the top of search results with every commit... just to appear high in a site or catalog (like Flathub, for example).I prefer that each release is like an updated "guide" to what changes in my project. Users need to know what I did and what has changed. So much so that even my AppMan repository has a link connected to this release, to every AppMan release (and probably you who are reading this came from there too).Today some developers prefer to attract attention instead of focusing on how to improve their project to consequently supporting an ecosystem by externalizing its dormant potential. Well, I prefer to be boring, and reveal to the people that AppImages evolve and that they have internal options capable of isolating dotfiles while keeping the system clean... or that they support delta updates... that they can be closed in a sandbox or that they can be converted so as not to depend on libfuse2!This is how you support an ecosystem: revealing its best, and involving the community to improve it!There are those who work to support a community idea... and those who work for themselves (begging for donations), causing only damage to that community... pushing users towards another community, even if unconsciously.I took AppImage as something to save, and there are those who have followed my idea by setting up interesting projects supported by entire communities. But as expected, there are always some leeches ready to make all this fail, disguising their project as something extremely useful (while not proposing anything new, but using "trendy" tools that create nice apps... and that's it), but which in fact belongs to a mainstream ecosystem opposite to the one we support as a community.We who truly love AppImage, want to warn you about false idols: Beware of appearances!If you really want to support AppImages and those who work to improve them... do it properly! Support all those projects that work directly on AppImage packages! Support whoever builds your favorite AppImage packages! It doesn't matter how (donations, bug reports, pull requests...)... as long as it's directly with those who really understand AppImages.It's the only way to keep this ecosystem alive.Many people believe that all AppImages still depend on the old and obsolete libfuse2, and some developers mask their inability to package AppImages by saying "it's hard to make them" but ignoring those who offer to help them, or by saying that "most AppImages are Electron-based applications", when a quick look through my repositories shows that VLC, GIMP, Bottles, VirtualBox, OBS Studio... are anything but Electron apps. Here, be wary of these clichés and of those who tell you these phrases... especially those who elevate their solutions as "definitive" by inventing excuses, lies and cowardly supporting their theses for vile money!AppImage is many things. Let's support its ecosystem! For real!What's Changed

New Contributors

Full Changelog 9.6.1...9.6.2

Release "AM" 9.6.2 · ivan-hc/AM