I will do this later anyway, but I reallly really doubt it is going to get any better, like it is already once again using more storage than an entire distro with 30 appimages + home.
It will use more, but not exponentially more if de-duplication works as well as is claimed. The problem with AppImages is that they don’t include all of the dependencies, making them less reliable. At the expense of storage space, Flatpak bundles everything for reliability.
The total size 27 GIB for 173 apps works out at an average of 155 MiB per application.
The average appimage is also that size. Like besides very big applications like libreoffice which is 300 MiB and kdenlive which is 200 MiB. The rest of apps are usually 150 MiB or less.
And most appimages are “lazy” appimages made with linuxdeploy, if you do finer control on the build you can get the size of the appimage way way down.
One example is qbittorrent, the official appimage is 100 MiB, while there is a fork called qbittorrent-enhanced edition, and they got the size of the appimage down to 26 MiB
making them less reliable
Hard disagree that they are less reliable, that might be less reliable on weird distros or very minimal installations, but usually the issue is that you are missing a lib and not that the app itself is less reliable, but stability wise, they have been the most reliable, case in point was yuzu, the flatpak was such as nightware that even the devs would talk againts it due to issues with mesa.
And the support channel of yuzu in their discord was full of people having issues with the flatpak that were magically fixed the moment they tried the appimage, due to that issue with mesa being outdated in the flatpak.
But anyway, I will install my applications as flatpak and compare the storage used.
What storage expense? appimage are actually the smallest thanks to their compression.
I’m saying that Flatpaks use more storage for reliability, and that AppImages are less reliable because they rely on system dependencies in some circumstances.
but usually the issue is that you are missing a lib and not that the app itself is less reliable
This is why AppImages are less reliable. Flatpaks either work for everybody, or they don’t work at all. AppImages might not work if you’re on a “weird distro” or forgot to install something on your system.
And the support channel of yuzu in their discord was full of people having issues with the flatpak that were magically fixed the moment they tried the appimage, due to that issue with mesa being outdated in the flatpak.
Packaging your software with Flatpak does not mean you won’t have issues. But when you do have issues, you know they’ll be an issue for everybody. So when you fix it, you also fix it for everybody.
For example, the RetroArch package was using an old version of the Freedesktop Platform, which comes with an old version of Mesa. When they bumped the version (just changing it from 22.08 to 23.08), the problem was fixed: https://discourse.flathub.org/t/problems-with-mesa-drivers/5574/3
Oh I’m very sorry, I didn’t see the period before the At the expense of storage space
Flatpaks either work for everybody, or they don’t work at all.
Maybe? I’ve seen enough people having weird issues with flatpaks that others don’t have. One recent example was somebody complaining here that the firefox flatpak took very long start, which I found odd because flatpaks aren’t compressed squashfs images and should not be taking long to start up, that’s an issue of appimages and snaps instead lol.
Packaging your software with Flatpak does not mean you won’t have issues. But when you do have issues, you know they’ll be an issue for everybody. So when you fix it, you also fix it for everybody.
Another issue that I’ve noticed with flatpaks is that they are usually built with generic flags, I don’t know if this is a requirement or lazy developer, but this is also an issue that yuzu had, the flatpak was built for x86-64 while the appimage was for x86-64-v2 and that had a 8% boost on fps at the cost of people with cpus older than sandy bridge not being able to use it. (Which I mean if your cpu is that old you can’t use yuzu anyway).
EDIT: And by weird distro I basically meant nix or musl distros, which I know flatpak works on because it bundles an entire distro basically, while appimage tries its best to be compatible with every distro provided it uses glibc and follows the FHS.
On that there is no dispute that flatpak/snap is your only option.
Will still be using 4.79 GiB?
I will do this later anyway, but I reallly really doubt it is going to get any better, like it is already once again using more storage than an entire distro with 30 appimages + home.
It will use more, but not exponentially more if de-duplication works as well as is claimed. The problem with AppImages is that they don’t include all of the dependencies, making them less reliable. At the expense of storage space, Flatpak bundles everything for reliability.
De-duplication works better the more Flatpak applications you have installed. e.g. de-duplication saves TheEvilSkeleton over 50GB of storage space here: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users
What storage expense? appimage are actually the smallest thanks to their compression.
Compare the librewolf appimage vs a native pacakge, it is 100 vs 300 MiB iirc.
Same with libreoffice, it is 300 vs 600 MiB.
And these native packages seem to share very few libraries, because when I remove them from my system the removed size is that, 300, 600 MiB, etc.
My distro would not be 4.2 GIB if I dropped my appimages for native packages.
The total size 27 GIB for 173 apps works out at an average of 155 MiB per application.
The average appimage is also that size. Like besides very big applications like libreoffice which is 300 MiB and kdenlive which is 200 MiB. The rest of apps are usually 150 MiB or less.
And most appimages are “lazy” appimages made with linuxdeploy, if you do finer control on the build you can get the size of the appimage way way down.
One example is qbittorrent, the official appimage is 100 MiB, while there is a fork called qbittorrent-enhanced edition, and they got the size of the appimage down to 26 MiB
Hard disagree that they are less reliable, that might be less reliable on weird distros or very minimal installations, but usually the issue is that you are missing a lib and not that the app itself is less reliable, but stability wise, they have been the most reliable, case in point was yuzu, the flatpak was such as nightware that even the devs would talk againts it due to issues with mesa.
And the support channel of yuzu in their discord was full of people having issues with the flatpak that were magically fixed the moment they tried the appimage, due to that issue with mesa being outdated in the flatpak.
But anyway, I will install my applications as flatpak and compare the storage used.
I’m saying that Flatpaks use more storage for reliability, and that AppImages are less reliable because they rely on system dependencies in some circumstances.
This is why AppImages are less reliable. Flatpaks either work for everybody, or they don’t work at all. AppImages might not work if you’re on a “weird distro” or forgot to install something on your system.
Packaging your software with Flatpak does not mean you won’t have issues. But when you do have issues, you know they’ll be an issue for everybody. So when you fix it, you also fix it for everybody.
For example, the RetroArch package was using an old version of the Freedesktop Platform, which comes with an old version of Mesa. When they bumped the version (just changing it from
22.08to23.08), the problem was fixed: https://discourse.flathub.org/t/problems-with-mesa-drivers/5574/3Oh I’m very sorry, I didn’t see the period before the
At the expense of storage spaceMaybe? I’ve seen enough people having weird issues with flatpaks that others don’t have. One recent example was somebody complaining here that the firefox flatpak took very long start, which I found odd because flatpaks aren’t compressed squashfs images and should not be taking long to start up, that’s an issue of appimages and snaps instead lol.
Another issue that I’ve noticed with flatpaks is that they are usually built with generic flags, I don’t know if this is a requirement or lazy developer, but this is also an issue that yuzu had, the flatpak was built for x86-64 while the appimage was for x86-64-v2 and that had a
8% booston fps at the cost of people with cpus older than sandy bridge not being able to use it. (Which I mean if your cpu is that old you can’t use yuzu anyway).EDIT: And by weird distro I basically meant nix or musl distros, which I know flatpak works on because it bundles an entire distro basically, while appimage tries its best to be compatible with every distro provided it uses glibc and follows the FHS.
On that there is no dispute that flatpak/snap is your only option.