The Team Kodi PPA has long been a staple for Ubuntu (and similar) users wishing to use more recent, and less adulterated, versions of Kodi. It is with sadness that the team has come to a decision…
Flatpak installs sandboxed libraries and then shares them between different apps as you install them. The first app installed may seem big but often the next app will use many of the same libraries rather than redownload/reinstall them.
Appimage does not share libraries. Each Appimage is a complete image, libraries included and compressed out of necessity. It can be targeted at systems to reduce library bloat but it’s often easier just to shove everything in to ensure it works. Also that compressed file system needs to be decompressed which causes further overhead. Simple apps with few dependencies will be small, but big apps can bloat massively particularly if they’re not targeted (and that’s common as they’re treated as run-anywhere solutions for developers).
Plus Appimage can include security flawed libraries - the significance of that will depend on the App being exposed to them. I wouldn’t want to run a web browser using a poorly maintained appimage for example, but I’d consider running a random small tool or utility if that was the only option.
Both models are flawed compared to native apps - not quite to the point of installing an entire distro but close. But Flatpak installs one shared set sandboxed environment, while every AppImage is crudely it’s own distro.
I’m trying to understand the Flatpak model here, so if Flatpak installs sandboxed libraries, does that mean that all programs on Flathub are compiled against the same “base” runtime? Theoretically, if I had 10 flatpaks installed, could they pull in 10 different runtimes? It seems like this could get out of hand. Iirc, Fedora has their own runtime for their own flatpaks, tied to the version. (A runtime for Fedora 39, another for 40, etc?) In that case, is the idea to have one (traditional) set of libraries for the base OS, and another (runtime) set of libraries for user applications? Could it come full circle so that the base OS is relying on the same libraries as provided by the runtime? I am somewhat confused…
The first app installed may seem big but often the next app will use many of the same libraries rather than redownload/reinstall them.
Do you want me to repeat the flatpak test as see if I install libreoffice along side firefox that the install size wont go from 3 GiB to 3.3GiB or more?
needs to be decompressed which causes further overhead
You don’t have to do this, you can run the decompressed appimage at the cost of increasing its size, which yeah you will have to decompress a lot of appimages before the space usage is comparable to that of flatpak.
Simple apps with few dependencies will be small, but big apps can bloat massively particularly
kdenlive is 200 MiB, is that too big for such application?
I wouldn’t want to run a web browser using a poorly maintained appimage for example
Good thing librewolf releases their appimage officially.
while every AppImage is crudely it’s own distro.
Do you think portable apps are also their own distro?
Why use an appimage when they also have official RPM or DEB repos? There is nothing gained here, but you have an insecure install and update mechanism.
How the fuck did libreoffice even increase the size by 1.4 GiB? the libreoffice appimage that is “its own distro” is 860 MiB uncompressed (it is 323 MiB when it is an appimage btw) , the flatpak added 1.4 GiB somehow kek.
There is nothing gained here
I use appimages because they have a lot of features that I really like, from having portable homes, taking less space than native packages, etc.
They also allow easy version control, did I run into a regresion from certain application? let me try the older appimage (this happened with ferdium to me btw).
Why use an appimage when they also have official RPM or DEB repos?
What if I’m using (I am btw) archlinux, and not that means that I need to rely on aur packages which I can’t even compile right now because my system ran into a weird bug in cmake and haven’t even been able to report because I can’t register in the cmake gitlab lol.
Also I used voidlinux for a few weeks and that really opened my eyes on how much I relied upon the aur and I made the change to switch to appimages.
and update mechanism.
I use appimages with the AM packages manager that installs them, adds a symlink to PATH, adds the desktop entry, and keeps them up to date as well.
Yes I will give you that flatpaks are safer than appimages, aur or even native packages, but from there everything else is just downsides, including performance regressions, and I don’t know about you, I don’t like that so I don’t use it, as simple as that. And it really made me mad when I saw that github thing of the other user lying that appimages bloat the system, that shit even links an article saying that firejail isn’t safe as argument against appimages, when that very article even mentions that flatpaks sandbox isn’t safe either kek.
I moved it to a different partition because I had already noticed that my Btrfs filesystem level compression was makiing the size different much smaller (the root filesystem actually grew by about 3 GiB but my file manager was reporting over 6 GIB on the flatpak dir).
EDIT: Also that tool reports the flatpak size as 3.5 GiB while fastfetch reports the flatpak partition as 3.4 GIB.
EDIT2: This is after installing yuzu:
~/ ./flatpak-dedup-checker
Directories: /var/lib/flatpak/{runtime,app}
Size without deduplication: 5.70 GB
Size with deduplication: 4.03 GB (70% of 5.70 GB)
It actually grew considerably for yuzu, yuzu appimage itself is 60 MiB compressed 170 MiB uncompressed.
Btrfs compression is filesystem wide, and it is usually zstd (the same compression that newer appimages are using, however appimages use zstd 15 by default while filesystem it is usually zstd 3 or less).
Yeah turns out that if I were to decompress all my appimages and run them that way, Btrfs filesystem compression would mitigate the issue of having several duplicated libraries.
I actually made a concept appimage for suyu that had the x86-64 v2 and x86-64 v3 binaries in it with a script that determined which binary to use depending on the system, and even though the appimage was shipping two 38 MiB similar binaries, the actual size increase in the resulting appimage was only 6 MiB thanks to the compression in the appimage.
I also was at the yuzu linux-support channel before they closed down, and you have no idea how many times I saw people complaining that yuzu was broken and when I told them to use the appimage it fixed their issue every single times, there was even one case where the person wasn’t even buying what I was telling them until the moment they noticed their crashing issue instantly went away with the appimage lol:
This is because the mesa version that flatpak uses was (and likely still is) too old, and specially with amd gpus that let to users running into bugs that had been fixed for over a year in other distros.
This is misleading.
Flatpak installs sandboxed libraries and then shares them between different apps as you install them. The first app installed may seem big but often the next app will use many of the same libraries rather than redownload/reinstall them.
Appimage does not share libraries. Each Appimage is a complete image, libraries included and compressed out of necessity. It can be targeted at systems to reduce library bloat but it’s often easier just to shove everything in to ensure it works. Also that compressed file system needs to be decompressed which causes further overhead. Simple apps with few dependencies will be small, but big apps can bloat massively particularly if they’re not targeted (and that’s common as they’re treated as run-anywhere solutions for developers).
Plus Appimage can include security flawed libraries - the significance of that will depend on the App being exposed to them. I wouldn’t want to run a web browser using a poorly maintained appimage for example, but I’d consider running a random small tool or utility if that was the only option.
Both models are flawed compared to native apps - not quite to the point of installing an entire distro but close. But Flatpak installs one shared set sandboxed environment, while every AppImage is crudely it’s own distro.
I’m trying to understand the Flatpak model here, so if Flatpak installs sandboxed libraries, does that mean that all programs on Flathub are compiled against the same “base” runtime? Theoretically, if I had 10 flatpaks installed, could they pull in 10 different runtimes? It seems like this could get out of hand. Iirc, Fedora has their own runtime for their own flatpaks, tied to the version. (A runtime for Fedora 39, another for 40, etc?) In that case, is the idea to have one (traditional) set of libraries for the base OS, and another (runtime) set of libraries for user applications? Could it come full circle so that the base OS is relying on the same libraries as provided by the runtime? I am somewhat confused…
A new freedesktop runtime releases once a year, most apps are on the latest.
Nobody uses the Fedora runtime. It exists for political reasons not practical.
Thanks.
Do you want me to repeat the flatpak test as see if I install libreoffice along side firefox that the install size wont go from 3 GiB to 3.3GiB or more?
You don’t have to do this, you can run the decompressed appimage at the cost of increasing its size, which yeah you will have to decompress a lot of appimages before the space usage is comparable to that of flatpak.
kdenlive is 200 MiB, is that too big for such application?
Good thing librewolf releases their appimage officially.
Do you think portable apps are also their own distro?
Portable apps are their own distro, yes.
Why use an appimage when they also have official RPM or DEB repos? There is nothing gained here, but you have an insecure install and update mechanism.
Btw I just added libreoffice and kdenlive and shit is 6.2 GiB wtf.
https://imgur.com/gCUuW5P.png
How the fuck did libreoffice even increase the size by 1.4 GiB? the libreoffice appimage that is “its own distro” is 860 MiB uncompressed (it is 323 MiB when it is an appimage btw) , the flatpak added 1.4 GiB somehow kek.
I use appimages because they have a lot of features that I really like, from having portable homes, taking less space than native packages, etc.
They also allow easy version control, did I run into a regresion from certain application? let me try the older appimage (this happened with ferdium to me btw).
What if I’m using (I am btw) archlinux, and not that means that I need to rely on aur packages which I can’t even compile right now because my system ran into a weird bug in cmake and haven’t even been able to report because I can’t register in the cmake gitlab lol.
Also I used voidlinux for a few weeks and that really opened my eyes on how much I relied upon the aur and I made the change to switch to appimages.
I use appimages with the AM packages manager that installs them, adds a symlink to PATH, adds the desktop entry, and keeps them up to date as well.
Yes I will give you that flatpaks are safer than appimages, aur or even native packages, but from there everything else is just downsides, including performance regressions, and I don’t know about you, I don’t like that so I don’t use it, as simple as that. And it really made me mad when I saw that github thing of the other user lying that appimages bloat the system, that shit even links an article saying that firejail isn’t safe as argument against appimages, when that very article even mentions that flatpaks sandbox isn’t safe either kek.
Check again with that tool that size is really strange.
I am not a fan of that bloat, as Android works similar and apps are 30MB max. I simply think flatpak is the best foundation.
Alright I just moved flatpak to its own partition and checked the size of the partition instead:
with firefox, kdenlive and libreoffice:
Disk (/var/lib/flatpak) 2.69 GiB / 19.12 GiB (14%) - ext4That’s much better now. But still twice the size that 15 appimages took.
This is with now having
firefoxlibrewolfbravekdenliveandlibreoffice:Disk (/var/lib/flatpak) 3.40 GiB / 19.12 GiB (18%) - ext4Still though, the appimages take less space. A by a large margin.
Please just use that tool. Why would you move flatpak to a different partition? But interesting results
WIth the same 5 application that I had before: https://imgur.com/Yn5O7Ni.png
I moved it to a different partition because I had already noticed that my Btrfs filesystem level compression was makiing the size different much smaller (the root filesystem actually grew by about 3 GiB but my file manager was reporting over 6 GIB on the flatpak dir).
EDIT: Also that tool reports the flatpak size as 3.5 GiB while fastfetch reports the flatpak partition as 3.4 GIB.
EDIT2: This is after installing yuzu:
~/ ./flatpak-dedup-checker Directories: /var/lib/flatpak/{runtime,app} Size without deduplication: 5.70 GB Size with deduplication: 4.03 GB (70% of 5.70 GB)It actually grew considerably for yuzu, yuzu appimage itself is 60 MiB compressed 170 MiB uncompressed.
Holy shit my dude I just installed flatpak and firefox and it was 3 GiB like before, and then I installed libreoffice.
The var/lib/flatpak directory went from 3 GiB to 4.4 GIB
DO YOU WANT ME TO CONTINUE?
AM I STILL MISLEADING?
I installed kdenlive now, it is now 6.2 GiB, this shit is painful:
Please use this tool and report the real sizes
https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker
Take 3, with the tool included (and also installed gimp):
And this is what flatpak uses when it just has firefox installed:
It still uses more than 15 AppImages kek.
Interesting, you have no compression as that is likely only on BTRFS
Btrfs compression is filesystem wide, and it is usually zstd (the same compression that newer appimages are using, however appimages use zstd 15 by default while filesystem it is usually zstd 3 or less).
Yeah turns out that if I were to decompress all my appimages and run them that way, Btrfs filesystem compression would mitigate the issue of having several duplicated libraries.
I actually made a concept appimage for suyu that had the x86-64 v2 and x86-64 v3 binaries in it with a script that determined which binary to use depending on the system, and even though the appimage was shipping two
38 MiBsimilar binaries, the actual size increase in the resulting appimage was only6 MiBthanks to the compression in the appimage.Damn that is really cool. Good compression algorithms are key.
I also think that flatpaks huge issue is
I also was at the yuzu linux-support channel before they closed down, and you have no idea how many times I saw people complaining that yuzu was broken and when I told them to use the appimage it fixed their issue every single times, there was even one case where the person wasn’t even buying what I was telling them until the moment they noticed their crashing issue instantly went away with the appimage lol:
https://imgur.com/p6aby3Z.png
This is because the mesa version that flatpak uses was (and likely still is) too old, and specially with amd gpus that let to users running into bugs that had been fixed for over a year in other distros.