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 is bloated mess. It basically installs a whole distro onto your existing distro.
That person is also lying very badly by saying that appimages bloat the system… they are actually even smaller than native packages due to their compression (like for example the entire libreoffice suite being 300 MiB while a native package is 600 MiB).
While this is 15 appimages, that includes libreoffice, kdenlive and two web browsers: https://imgur.com/a/YxjUYdt
EDIT: After being accused of misleading people by @BananaTrifleViolin@lemmy.world I decided to install firefox, libreoffice and kdenlive to flatpak, just those 3 applications, because I was told sure the deduplication was going to do miracles:
)6.2 GIB WTF** (15 appimages was 1.2 GiB once again kek, how can flatpak be this bad lmao)
EDIT2: This actually isn’t the real size, I moved the flatpaks to their own partition and checked that instead:
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.12GiB (14%) - ext4
That’s much better now. But still twice the size that 15 appimages took.
This is with now having firefoxlibrewolfbravekdenlive and libreoffice:
Disk (/var/lib/flatpak) 3.40 GiB /19.12GiB (18%) - ext4
Still though, the appimages take less space. A by a large margin.
Flatpak is just a bloated mess, even with deduplication:
And this is what flatpak uses with just firefox installed:
Sorry for misleading people, turns out flatpak doesn’t use near 3X as much as 15 AppImages when it just has firefox installed (which once again those 15 AppImages use 1.2 GIB). It just uses 1.35GiB when it has a single app kek.
On top of that flatpak is not terminal friendly, you have to start everything with flatpak run org.etc.etc (this also breaks scripts that expect the simple binary name in PATH).
This person is complaining that appimages suck because you have to put the desktop entry yourself, when apps like am or zap and appimagelauncher do it for you lmao. (And at least am also makes a symlink in PATH so it fully integrates the appimage unlike flatpak ever will)
EDIT: That github link is really bad, it even links this article for saying that sanboxing with appimages isn’t secure:
Appimages also install another distro onto your system. May be small, but you have no deduplication at all. Flatpak could do a better job at enforcing the use of very few runtimes, but at least it is transparent what is used, unlike with Appimages (where you have no idea if any app has a runtime with a vulnerability etc).
If they use compression, you replace disk space with CPU power.
28,88 GB "naive"21,57 GB with deduplication
16,24 GB with compression
For all my apps, including a ton of stuff I just test. And that on a 1TB drive is just not important.
Appimages can be placed in ~/.local/bin/ which makes them kinda okay for terminal use. But none of the formats is terminal friendly. Flatpak has a veeeery descriptive syntax, which makes sense but for sure it is a pain to write.
But yes, CLI stuff is not covered but that is also okay. Flatpak deals with all the huge GUI apps, the distros can take care of the small rest.
Of course thats not perfect, but snaps have no sandboxing without apparmor (with patches) and appimages have no sandboxing at all, ignoring firejail which is a root binary and has had security vulnerabilities in the past, making it basically a privilege escalator.
Yes they break that strange XDG idea, and that makes sense. Every app is a container, and if you delete that app directory, all its settings are reset etc. It is a huge advantage for a clean system.
For sure the directories are long as f*ck but that is an okay drawback for having the ability to control the app data so easily.
Appimages also install another distro onto your system. May be small,
Would you say portable builds (like deadbeef) also install another distro onto your system? This is what appimages primary replace…
If they use compression, you replace disk space with CPU power.
You can also extract the appimage and run the AppRun script, comes with the downside that it increases the size of the appimage but you don’t have that trade off anymore if that is a problem. And yeah you will have to umcompress a lot of appimages before the space usage is comparable to that of flatpak lol.
And that on a 1TB drive is just not important.
Yeah but there is a big difference in saying that appimages bloat the system when they DO NOT, and now dismissing? flatpack usage it as “is just not important” wtf.
Yes they break that strange XDG idea, and that makes sense
Is it strange idea to not want my home cluttered by a bunch of useless top level dotfiles?
Appimages can be placed in ~/.local/bin/ which makes them kinda okay for terminal use. But none of the formats is terminal friendly
Package managers like AM automatically place the appimage in /opt and make symlinks to /usr/.local/bin (it also keeps the appimage up to date by comparing the version from that of the repo). I use it for terminal apps like amdgpu_top, which ships as an appimage by the creator themselves.
It also has a portable mode called ‘appman’, I use this one and I drop my appimages in ~/.local/opt and it automatically makes symlinks to ~/.local/bin (this last one is also a XDG location btw).
Both also automatically install the desktop entry to the appimage, something that seems to be too hard for the person that made that github thing. There is also zap and appimagelauncher for that. And even gearlever for the flatpak users that want to use appimages.
CLI stuff is not covered but that is also okay.
It is not ok at all, flatpak could be much better but they don’t want to fix it, that is the issue, and I haven’t gone into the performance issues you can have with flatpak because like in the case of yuzu, the flatpak was compiled for x86-64 generic while the appimage was x86-64 v2, and it also had a bunch of issues because flatpak ships its own version of mesa iirc. Honestly if I’m forced to choose one thing out of everything, it would likely have to be nix, and nix has the small issue of not being FHS compliant lol. So yeah it really sucks.
appimages could also be much better, if the runtime statically linked glibc they would also work on musl distros which is a shame they don’t.
Would you say portable builds (like deadbeef) also install another distro onto your system?
They statically link binaries which is pretty similar.
You can also extract the appimage and run the AppRun script, comes with the downside that…
I guess you cannot update an app anymore when doing that.
Flatpak uses BTRFS compression afaik, so I dont know if it has a performance hit and it can likely not be turned off.
Is it strange idea to not want my home cluttered by a bunch of useless top level dotfiles?
That is .firefox etc. Flatpaks put everything in ~/.var/app/ which doesnt clutter anything.
Those Appimage helpers sound interesting and I will look at them. The tasks of placing somewhere, creating desktop entries etc. is not hard, but needing to do that manually is a strange and broken concept. I suppose those helper programs have some kind of community support, as Balena Etcher or whatever dont supply .desktop files.
I agree with the problems you mentioned after that. Relying on glibc is bad, using outdated x86_64 architecture is silly. The last one could be fixed easily. The former one probably not that easily.
Desktop Linux is messy for sure. But Flatpak is just really good at what it can do.
There is actually a workaround for firefox, but for flatpak you would essentially have to make flatpak have its own home dir, and that is just too much of a hack for such application. As every app being called in flatpak would be under this fakehome as well.
I guess you cannot update an app anymore when doing that.
I could make a script for am that does it btw. I’ve never had the need to do this but it is possible.
The script would run ./*.AppImage --appimage-extract the newly installed appimage, rm ./*.AppImage && ln -s ./squashfs-root/AppRun nameof.AppImage and that is it, it will work with the old desktop entry and symlink in PATH and every time the appimage gets updated it does the same thing like a pacmanhook would.
as Balena Etcher or whatever dont supply .desktop files.
Flatpak does this, just have a look. Every app has its config stored in its own directory. Apps only have access to that directory, if they dont get other static permissions.
yes you could of course script that, but it doesnt change the problem with appimages having insecure updates. Flatpak uses OSTree, Android has a package manager that saves the signature and if that doesnt match, an update fails.
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…
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.
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.
To me, those aren’t real Flatpak issues. Yeah the CLI interface is clunky, but why would I care when the XDG desktop file path is being added automatically and Flatpak is for desktop apps, not for CLI. It only matters when debugging broken application, but at the same time it’s not that hard. Overall that also gives us ability to have multiple instances of the same app installed multiple times from different sources.
Flatpak can easily work on anything that has it in its repo and usually the setup is piece of cake. I had much worse time dealing with some AppImages due to its wild guesses about what the host system is, like libfuse version. Desktop integration is really meh imho and I could never figure out how to use it effectively without some lost desktop files here and there I had to clean manually (haven’t tried in a couple of years now, it could be better now).
Wayland support is intentionally broken by AppImage creator/maintainer just to be able to point finger at Wayland ecosystem and say: look - unfixable. Lately the same dude wanted to propose collection of out-of-tree Wayland protocols to make it more like X11, which is horrible idea and no actual Xorg/Wayland dev would have any interest in doing, because it defeats the decade long efforts to change how the graphics stack works.
AppImage maintainers also showed their disappointing attitude when trying to get OBS to use it, assuming everyone will be interested in having that package format published on official projects website, while conforming to all requirements and doing the work of adjusting app to that format. To no surprise, OBS was horribly broken when built that way, and they demanded OBS devs to fix it, not getting how could they possibly not be interested in having app image, while already having well built (I use it myself, it’s great) Flatpak package.
Flatpak does sandboxing with fine tuning abilities (using something like Flatseal or new KDE’s built-in KCM) + there is actual verification process at least for new apps on Flathub. I don’t say it’s 100% safe, but compare that to AppImages which is just running randomly downloaded binaries from the web with full filesystem access.
Overall that also gives us ability to have multiple instances of the same app installed multiple times from different sources.
You can’t just type this like that while ignoring the fact that appimages also let you do that.
Flatpak is for desktop apps
Yeah and unfortunately I’ve already seen takes of people saying that snaps are better than flatpaks because snaps are CLI friendly and “why would I have two different systems when one does everything”, this was just a bad decision on flatpaks side.
Imo, nixos does what flatpak tries to do much better, and more importantly you can run nix alone as its own thing, while flatpak has to be on top of a existing distro.
Wayland support is intentionally broken by AppImage creator/maintainer just to be able to point finger at Wayland ecosystem and say: look - unfixable.
Link?
Also btw, wayland has been insanely broken for me, this is mostly because I’m stuck with sway as my only option though, I have 4 bug reports still open that came from two days of trying to use sway.
AppImage maintainers also showed their disappointing attitude when trying to get OBS to use it, assuming everyone will be interested in having that package format published on official projects website, while conforming to all requirements and doing the work of adjusting app to that format. To no surprise, OBS was horribly broken when built that way, and they demanded OBS devs to fix it, not getting how could they possibly not be interested in having app image, while already having well built (I use it myself, it’s great) Flatpak package.
I use OBS-studio as an appimage made by a guy that basically wraps the aur package in a junest enviroment. It is actually a whole distro in a small package at this point, the downside is that it makes this appimage 172 MiB. Which is meh. Could be better but it is better than either depending on my distro (I have ptsd from using voidlinux if you didn’t know lol) to provide me a obs-version that works, or install the whole flatpak and hope that the obs-flatpak doesn’t actually break (and this last step will be way more than 172 MiB due to the runtimes).
Flatpak does sandboxing with fine tuning abilities (using something like Flatseal or new KDE’s built-in KCM) + there is actual verification process at least for new apps on Flathub. I don’t say it’s 100% safe, but compare that to AppImages which is just running randomly downloaded binaries from the web with full filesystem access.
Please be aware that you just commented on some of the points.
Madaidan is often criticised and debunked, and that “linux is insecure” post is pretty old.
They say that many flatpakked apps have broad permissions, which is not a flatpak issue, because those are simply legacy apps that are often huge, dont support Flatpak at all and often also dont care.
They mention the “badness enumeration” like restricted syscalls, which is really problematic and seems to still be used. This is really bad and I hope it gets fixed, will open an issue about that.
But dont forget: flatpak apps may have broad permissions, but native apps have all permissions, appimages too. They have unrestricted syscalls, if not changed in the system itself.
So these might be valid points, but not a defense of Appimages at all.
This is really bad lmao.
flatpak is bloated mess. It basically installs a whole distro onto your existing distro.
That person is also lying very badly by saying that appimages bloat the system… they are actually even smaller than native packages due to their compression (like for example the entire libreoffice suite being 300 MiB while a native package is 600 MiB).
This is the space that flatpak takes to install firefox, just firefox: https://imgur.com/a/WRcRWIL
While this is 15 appimages, that includes libreoffice, kdenlive and two web browsers: https://imgur.com/a/YxjUYdt
EDIT: After being accused of misleading people by @BananaTrifleViolin@lemmy.world I decided to install firefox, libreoffice and kdenlive to flatpak, just those 3 applications, because I was told sure the deduplication was going to do miracles:
https://imgur.com/ExH84gV.png))
6.2 GIB WTF** (15 appimages was 1.2 GiB once again kek, how can flatpak be this bad lmao)EDIT2: This actually isn’t the real size, I moved the flatpaks to their own partition and checked that instead:
Alright I just moved flatpak to its own partition and checked the size of the partition instead:
with
firefox,kdenliveandlibreoffice: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.
Flatpak is just a bloated mess, even with deduplication:
And this is what flatpak uses with just firefox installed:
Sorry for misleading people, turns out flatpak doesn’t use near 3X as much as 15 AppImages when it just has firefox installed (which once again those 15 AppImages use 1.2 GIB). It just uses 1.35GiB when it has a single app kek.
On top of that flatpak is not terminal friendly, you have to start everything with
flatpak run org.etc.etc(this also breaks scripts that expect the simple binary name in PATH).Flatpak is also non XDG base dir compliant, and they said over and over that they wont fix that issue: https://github.com/flatpak/flatpak.github.io/issues/191
This person is complaining that appimages suck because you have to put the desktop entry yourself, when apps like
amorzapandappimagelauncherdo it for you lmao. (And at least am also makes a symlink in PATH so it fully integrates the appimage unlike flatpak ever will)EDIT: That github link is really bad, it even links this article for saying that sanboxing with appimages isn’t secure:
https://madaidans-insecurities.github.io/linux.html#firejail
WHEN THAT VERY LINK SAYS THAT FLATPAK ISN’T GOOD EITHER, it even calls out the flatpak devs for it.
Appimages also install another distro onto your system. May be small, but you have no deduplication at all. Flatpak could do a better job at enforcing the use of very few runtimes, but at least it is transparent what is used, unlike with Appimages (where you have no idea if any app has a runtime with a vulnerability etc).
If they use compression, you replace disk space with CPU power.
You might want to check flatpak disk usage using this tool
Mine is
28,88 GB "naive" 21,57 GB with deduplication 16,24 GB with compressionFor all my apps, including a ton of stuff I just test. And that on a 1TB drive is just not important.
Appimages can be placed in
~/.local/bin/which makes them kinda okay for terminal use. But none of the formats is terminal friendly. Flatpak has a veeeery descriptive syntax, which makes sense but for sure it is a pain to write.There are easy workarounds for that though, like this aliasing script
But yes, CLI stuff is not covered but that is also okay. Flatpak deals with all the huge GUI apps, the distros can take care of the small rest.
Of course thats not perfect, but snaps have no sandboxing without apparmor (with patches) and appimages have no sandboxing at all, ignoring firejail which is a root binary and has had security vulnerabilities in the past, making it basically a privilege escalator.
Yes they break that strange XDG idea, and that makes sense. Every app is a container, and if you delete that app directory, all its settings are reset etc. It is a huge advantage for a clean system.
For sure the directories are long as f*ck but that is an okay drawback for having the ability to control the app data so easily.
Would you say portable builds (like deadbeef) also install another distro onto your system? This is what appimages primary replace…
You can also extract the appimage and run the
AppRunscript, comes with the downside that it increases the size of the appimage but you don’t have that trade off anymore if that is a problem. And yeah you will have to umcompress a lot of appimages before the space usage is comparable to that of flatpak lol.Yeah but there is a big difference in saying that appimages bloat the system when they DO NOT, and now dismissing? flatpack usage it as “is just not important” wtf.
Is it strange idea to not want my home cluttered by a bunch of useless top level dotfiles?
Package managers like AM automatically place the appimage in
/optand make symlinks to/usr/.local/bin(it also keeps the appimage up to date by comparing the version from that of the repo). I use it for terminal apps like amdgpu_top, which ships as an appimage by the creator themselves.It also has a portable mode called ‘appman’, I use this one and I drop my appimages in
~/.local/optand it automatically makes symlinks to~/.local/bin(this last one is also a XDG location btw).Both also automatically install the desktop entry to the appimage, something that seems to be too hard for the person that made that github thing. There is also zap and appimagelauncher for that. And even gearlever for the flatpak users that want to use appimages.
It is not ok at all, flatpak could be much better but they don’t want to fix it, that is the issue, and I haven’t gone into the performance issues you can have with flatpak because like in the case of yuzu, the flatpak was compiled for x86-64 generic while the appimage was x86-64 v2, and it also had a bunch of issues because flatpak ships its own version of mesa iirc. Honestly if I’m forced to choose one thing out of everything, it would likely have to be nix, and nix has the small issue of not being FHS compliant lol. So yeah it really sucks.
appimages could also be much better, if the runtime statically linked glibc they would also work on musl distros which is a shame they don’t.
They statically link binaries which is pretty similar.
I guess you cannot update an app anymore when doing that.
Flatpak uses BTRFS compression afaik, so I dont know if it has a performance hit and it can likely not be turned off.
That is .firefox etc. Flatpaks put everything in
~/.var/app/which doesnt clutter anything.Those Appimage helpers sound interesting and I will look at them. The tasks of placing somewhere, creating desktop entries etc. is not hard, but needing to do that manually is a strange and broken concept. I suppose those helper programs have some kind of community support, as Balena Etcher or whatever dont supply .desktop files.
I agree with the problems you mentioned after that. Relying on glibc is bad, using outdated x86_64 architecture is silly. The last one could be fixed easily. The former one probably not that easily.
Desktop Linux is messy for sure. But Flatpak is just really good at what it can do.
There is actually a workaround for firefox, but for flatpak you would essentially have to make flatpak have its own home dir, and that is just too much of a hack for such application. As every app being called in flatpak would be under this fakehome as well.
I could make a script for am that does it btw. I’ve never had the need to do this but it is possible.
The script would run
./*.AppImage --appimage-extractthe newly installed appimage,rm ./*.AppImage && ln -s ./squashfs-root/AppRun nameof.AppImageand that is it, it will work with the old desktop entry and symlink in PATH and every time the appimage gets updated it does the same thing like a pacmanhook would.https://imgur.com/NUZiECs.png
Flatpak does this, just have a look. Every app has its config stored in its own directory. Apps only have access to that directory, if they dont get other static permissions.
yes you could of course script that, but it doesnt change the problem with appimages having insecure updates. Flatpak uses OSTree, Android has a package manager that saves the signature and if that doesnt match, an update fails.
you can add images inline with
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.
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.
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.
To me, those aren’t real Flatpak issues. Yeah the CLI interface is clunky, but why would I care when the XDG desktop file path is being added automatically and Flatpak is for desktop apps, not for CLI. It only matters when debugging broken application, but at the same time it’s not that hard. Overall that also gives us ability to have multiple instances of the same app installed multiple times from different sources.
Flatpak can easily work on anything that has it in its repo and usually the setup is piece of cake. I had much worse time dealing with some AppImages due to its wild guesses about what the host system is, like libfuse version. Desktop integration is really meh imho and I could never figure out how to use it effectively without some lost desktop files here and there I had to clean manually (haven’t tried in a couple of years now, it could be better now).
Wayland support is intentionally broken by AppImage creator/maintainer just to be able to point finger at Wayland ecosystem and say: look - unfixable. Lately the same dude wanted to propose collection of out-of-tree Wayland protocols to make it more like X11, which is horrible idea and no actual Xorg/Wayland dev would have any interest in doing, because it defeats the decade long efforts to change how the graphics stack works.
AppImage maintainers also showed their disappointing attitude when trying to get OBS to use it, assuming everyone will be interested in having that package format published on official projects website, while conforming to all requirements and doing the work of adjusting app to that format. To no surprise, OBS was horribly broken when built that way, and they demanded OBS devs to fix it, not getting how could they possibly not be interested in having app image, while already having well built (I use it myself, it’s great) Flatpak package.
Flatpak does sandboxing with fine tuning abilities (using something like Flatseal or new KDE’s built-in KCM) + there is actual verification process at least for new apps on Flathub. I don’t say it’s 100% safe, but compare that to AppImages which is just running randomly downloaded binaries from the web with full filesystem access.
You can’t just type this like that while ignoring the fact that appimages also let you do that.
Yeah and unfortunately I’ve already seen takes of people saying that snaps are better than flatpaks because snaps are CLI friendly and “why would I have two different systems when one does everything”, this was just a bad decision on flatpaks side.
Imo, nixos does what flatpak tries to do much better, and more importantly you can run nix alone as its own thing, while flatpak has to be on top of a existing distro.
Link?
Also btw, wayland has been insanely broken for me, this is mostly because I’m stuck with sway as my only option though, I have 4 bug reports still open that came from two days of trying to use sway.
I use OBS-studio as an appimage made by a guy that basically wraps the aur package in a junest enviroment. It is actually a whole distro in a small package at this point, the downside is that it makes this appimage
172 MiB. Which is meh. Could be better but it is better than either depending on my distro (I have ptsd from using voidlinux if you didn’t know lol) to provide me a obs-version that works, or install the whole flatpak and hope that the obs-flatpak doesn’t actually break (and this last step will be way more than 172 MiB due to the runtimes).Cool, if only the rest wasn’t as bad.
Please be aware that you just commented on some of the points.
Madaidan is often criticised and debunked, and that “linux is insecure” post is pretty old.
They say that many flatpakked apps have broad permissions, which is not a flatpak issue, because those are simply legacy apps that are often huge, dont support Flatpak at all and often also dont care.
I maintain a list of modern apps, that do not need broad permissions like that
They mention the “badness enumeration” like restricted syscalls, which is really problematic and seems to still be used. This is really bad and I hope it gets fixed, will open an issue about that.
But dont forget: flatpak apps may have broad permissions, but native apps have all permissions, appimages too. They have unrestricted syscalls, if not changed in the system itself.
So these might be valid points, but not a defense of Appimages at all.