That’s kind of the point though. One of the foundational pillars of a good distribution is mature package management, and that includes not relying on self-updaters that will pollute your system with untracked files
I do wish something like AM’s functions was built into an all-in-one package manager for my distro. The closest I found was bauh which handles “AppImage, Debian and Arch Linux packages (including AUR), Flatpak, Snap and Web applications”. Which seems like an all-in-one solution.
But the problem with bauh (that last time I tried it) is that it accesses only a small number of (often very out-of-date) AppImages from the largely moribund AppImageHub.com, unlike AM, which pulls in the latest releases from loads of GitHub repos, and adds more on a frequent basis or request.
With flatpak devs can’t agree to use a common runtime, so the user ends up with a bunch of different runtimes and even EOL versions of the same runtime, making the storage usage 5x more than the appimage equivalent and this is much worse if you use nvidia which flatpak will download the entire nvidia driver again.
flatpak could not bother to fix the hardcoded~/.var directory, something that AM fixes by simply bind mounting the existing application config/data files to their respective places when sandboxing which yes it is able to sandbox appimages with aisap (bubblewrap).
flatpak threw the mess of handling conflicting applications to the user, so you have to type nonsense like flatpak run io.github.ungoogled_software.ungoogled_chromium, AM just puts the app to PATH like everyone else does, even snap doesn’t have this issue.
That’s cool and all but it would be even cooler if you could just install and keep it updated through your package manager
Some AppImages have that built in, like Ente.
That’s kind of the point though. One of the foundational pillars of a good distribution is mature package management, and that includes not relying on self-updaters that will pollute your system with untracked files
Absolutely, but don’t AppImage updaters basically just replace the AppImage? They’re self-contained, no?
I use AM package manager for that.
That’s cool.
It would still be even cooler if the app makers just packaged them for distros. Or even just Flatpak.
But that’s a cool project I’ll keep it in mind for my next go with an immutable distro
I do wish something like AM’s functions was built into an all-in-one package manager for my distro. The closest I found was bauh which handles “AppImage, Debian and Arch Linux packages (including AUR), Flatpak, Snap and Web applications”. Which seems like an all-in-one solution.
But the problem with bauh (that last time I tried it) is that it accesses only a small number of (often very out-of-date) AppImages from the largely moribund AppImageHub.com, unlike AM, which pulls in the latest releases from loads of GitHub repos, and adds more on a frequent basis or request.
AM was started because flatpak sucks.
With flatpak devs can’t agree to use a common runtime, so the user ends up with a bunch of different runtimes and even EOL versions of the same runtime, making the storage usage 5x more than the appimage equivalent and this is much worse if you use nvidia which flatpak will download the entire nvidia driver again.
flatpak could not bother to fix the hardcoded
~/.vardirectory, something that AM fixes by simply bind mounting the existing application config/data files to their respective places when sandboxing which yes it is able to sandbox appimages with aisap (bubblewrap).flatpak threw the mess of handling conflicting applications to the user, so you have to type nonsense like
flatpak run io.github.ungoogled_software.ungoogled_chromium, AM just puts the app toPATHlike everyone else does, even snap doesn’t have this issue.updating Hello World program