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…
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.
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.
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.
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.
No, Firefox doesn’t take up multiple gigabytes of space. It shares a runtime with a bunch of other programs. So yeah if you literally install one Flatpak, it’ll prompt you to download a bunch of extra stuff, but after that it won’t. Most people don’t only install one program on their PCs, so it’s not much of an issue.
Flatpak has deduplication, which appimages doesn’t have. If you install a load of appimages and a bunch of flatpaks, the flatpaks should take up less space, because Flatpak uses deduplication (i.e. only one copy is actually stored) and appimages don’t, it has several copies of the same dependencies.
Appimages also sometimes don’t even contain everything your system needs to run them, which can cause issues if the host system doesn’t have it. So it can frequently fail at the main touted usecase: portability!
And don’t get me started on stuff like theming, lack of app updates, worse Wayland support (the main dev even flat out refusing to merge Wayland fixes as he is ideologically opposed to it), and downloading programs via a browser like on a Windows system.
Not to mention having to browse to a specific folder and running the appimage every time, unless you do tedious work to add them to your app launcher, or you have a program that acts as an appimage launcher, which is again more tedious setup.
That isn’t the amount of space it’s using. This has been explained to you. Stop intentionally misleading people.
And what’s with the writing in caps? Just write like a normal person.
Appimages have waaaaaaaay worse theming issues lol. No appimage can integrate with system theming, Flatpak does.
You clearly don’t understand what I meant when I mentioned updates. Or maybe you did and were just trying to mislead again. My point was that flatpaks don’t have a mechanism for updating, unless the developer builds an updater service into the program, like apps do in Windows. The official way to update appimages is to open your browser and go to each individual piece of software’s download page, then download it.
Yes I’m aware there are appimage managers and launchers. But that’s more setup, more tinkering, and isn’t a part of the appimage standard. You may as well be saying “what do you mean downloading apps on Windows is a pain? There’s Chocolatey and a Ghocolatey GUI for app management!” Like yeah, cool, but it’s a separate hacked-on project. Not part of the actual appimage standard.
Downloading appimages via a browser is very much the intended usecase.
There’s a reason why appimages don’t get much support but Flatpak does. Bluntly, because they’re a far worse solution.
You clearly don’t know what that means. Since Flatpaks do have a mechanism for updating, that statement cannot be a Freudian slip.
A Freudian slip essentially means revealing secret thoughts or feelings through misspeaking, it doesn’t just mean parsing a sentence wrong. It’s not my secret thought that Flatpaks actually can’t update and any updates pushed to them have actually been a collective hallucination of everybody who uses them.
Now are you going to address the actual point that I was making? Of course not.
Alright, you were right, flatpaks don’t use 6GIB for 6 applications, I am very sorry, they use 4 GIB KEK.
Again with the lies.
I have 61 flatpaks installed and it totals under 5GiB. HuR dUr FiRefOx fLatPaK usEs 3GiB
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.
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
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.
deleted by creator
Please just use that tool. Why would you move flatpak to a different partition? But interesting results
deleted by creator
deleted by creator
Please use this tool and report the real sizes
https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker
deleted by creator
Interesting, you have no compression as that is likely only on BTRFS
deleted by creator
Damn that is really cool. Good compression algorithms are key.
I also think that flatpaks huge issue is
deleted by creator
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.
deleted by creator
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.
deleted by creator
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
Wow you are really trying to mislead here.
No, Firefox doesn’t take up multiple gigabytes of space. It shares a runtime with a bunch of other programs. So yeah if you literally install one Flatpak, it’ll prompt you to download a bunch of extra stuff, but after that it won’t. Most people don’t only install one program on their PCs, so it’s not much of an issue.
Flatpak has deduplication, which appimages doesn’t have. If you install a load of appimages and a bunch of flatpaks, the flatpaks should take up less space, because Flatpak uses deduplication (i.e. only one copy is actually stored) and appimages don’t, it has several copies of the same dependencies.
Appimages also sometimes don’t even contain everything your system needs to run them, which can cause issues if the host system doesn’t have it. So it can frequently fail at the main touted usecase: portability!
And don’t get me started on stuff like theming, lack of app updates, worse Wayland support (the main dev even flat out refusing to merge Wayland fixes as he is ideologically opposed to it), and downloading programs via a browser like on a Windows system.
Not to mention having to browse to a specific folder and running the appimage every time, unless you do tedious work to add them to your app launcher, or you have a program that acts as an appimage launcher, which is again more tedious setup.
deleted by creator
That isn’t the amount of space it’s using. This has been explained to you. Stop intentionally misleading people.
And what’s with the writing in caps? Just write like a normal person.
Appimages have waaaaaaaay worse theming issues lol. No appimage can integrate with system theming, Flatpak does.
You clearly don’t understand what I meant when I mentioned updates. Or maybe you did and were just trying to mislead again. My point was that flatpaks don’t have a mechanism for updating, unless the developer builds an updater service into the program, like apps do in Windows. The official way to update appimages is to open your browser and go to each individual piece of software’s download page, then download it.
Yes I’m aware there are appimage managers and launchers. But that’s more setup, more tinkering, and isn’t a part of the appimage standard. You may as well be saying “what do you mean downloading apps on Windows is a pain? There’s Chocolatey and a Ghocolatey GUI for app management!” Like yeah, cool, but it’s a separate hacked-on project. Not part of the actual appimage standard.
Downloading appimages via a browser is very much the intended usecase.
There’s a reason why appimages don’t get much support but Flatpak does. Bluntly, because they’re a far worse solution.
deleted by creator
You clearly don’t know what that means. Since Flatpaks do have a mechanism for updating, that statement cannot be a Freudian slip.
A Freudian slip essentially means revealing secret thoughts or feelings through misspeaking, it doesn’t just mean parsing a sentence wrong. It’s not my secret thought that Flatpaks actually can’t update and any updates pushed to them have actually been a collective hallucination of everybody who uses them.
Now are you going to address the actual point that I was making? Of course not.
Again with the lies.
I have 61 flatpaks installed and it totals under 5GiB. HuR dUr FiRefOx fLatPaK usEs 3GiB
deleted by creator
You know what’s VERY TERRIBLE? appimages. Really bad kek. wtf. kek kek.
deleted by creator
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.
deleted by creator
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.