Makes sense - PPAs are very platform specific, plus from a user point of view a bit of a security nightmare (not the Kodi PPA but the idea of adding lots of different PPAs, often poorly named and difficult to keep track of as a user).
I used to get fed up with PPAs when I used Ubuntu - particularly when you to go through a major distro upgrade and you have to go hunting through all of them to see if they support your new distro version. They’re just not a good distribution system for most users.
Also the Flatpak will benefit more users across other systems and has the potential to be more secure (particularly given the add ons people download and run in kodi).
Edit: worth noting they have retired the PPA but haven’t built out all their equivalent Flatpak versions. An example of the unpaid hard work and hours volunteers put in to maintain open source software.
You mean… zero scrutiny? 🙂 The big advantage of AUR is that there’s only one of it but that’s about it.
The PPA model is fundamentally broken. As soon as you replace a core package from a PPA (which happens silently if it’s a dependency) you can kiss upgradeability goodbye. By the time the next Ubuntu release rolls out you’ll be in dependency hell and won’t be able to upgrade cleanly.
It’s basically a privately hosted repo with a very small set of programs/libraries. PPA is a Personal Package Archive.
If you run Ubuntu (or most Debian derivatives) you can add a PPA as an extra repo and the version of software in that repo will usually be newer than the versions maintained by the distro (or even not present in the distro).
It’s not quite like the AUR - the AUR is a central public repo that people submit their packages to. Each PPA is a privately run and maintained repo with their packages in.
It is used by some projects to officially distribute their software but it is also something of a potential security nightmare.
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: imgur.com/a/WRcRWIL
While this is 15 appimages, that includes libreoffice, kdenlive and two web browsers: imgur.com/a/YxjUYdt
EDIT: After being accused of misleading people by@BananaTrifleViolinI 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:
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:
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.
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.
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:
<span style="color:#323232;">~/ ./flatpak-dedup-checker
</span><span style="color:#323232;">Directories: /var/lib/flatpak/{runtime,app}
</span><span style="color:#323232;">Size without deduplication: 5.70 GB
</span><span style="color:#323232;">Size with deduplication: 4.03 GB (70% of 5.70 GB)
</span>
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.
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…
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.
<span style="color:#323232;">28,88 GB "naive"
</span><span style="color:#323232;">21,57 GB with deduplication
</span><span style="color:#323232;">16,24 GB with compression
</span>
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.
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.
Alright do you want to install those 15 application on flatpak and compare the space usage again? Are you 100% sure that it wont be over 4GiB if I do that? (while the appimages was 1.2 GiB I remind you).
EDIT: also, that 3GiB doesn’t include that dependencies that flatpak installed in my system lol. It is only the var dir but it doesn’t include the other stuff that flatpak pulled when it installed on my system lol.
EDIT2: I JUST INSTALLED flatpak, firefox and libreoffice, AND THE THING IS 4.4GiB NOW, HOW THE FUCK DOES LIBREOFFICE FLATPAK CAN EVEN DO THIS WTF.
Will you still say that I’m trying to mislead?
And don’t get me started on stuff like theming, lack of app updates, and downloading programs via a browser like on a Windows system.
Asif flatpak never had theming issues or lack of updates, I can tell you for example that the suyu flatpak is outdated right now while the appimage isn’t.
Also you don’t have to download appimages via a browser… why do you even bother replying if you don’t know this? I mentioned several appimage package managers in this very thread.
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.
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.
Freudian slip eh.
That isn’t the amount of space it’s using. This has been explained to you. Stop intentionally misleading people.
Alright, you were right, flatpaks don’t use 6GIB for 6 applications, I am very sorry, they use 4 GIB KEK.
<span style="color:#323232;">~/ ./flatpak-dedup-checker
</span><span style="color:#323232;">Directories: /var/lib/flatpak/{runtime,app}
</span><span style="color:#323232;">Size without deduplication: 5.70 GB
</span><span style="color:#323232;">Size with deduplication: 4.03 GB (70% of 5.70 GB)
</span>
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
Might wanna improve the reading skills there, because I even mentioned here that appimages suck because the runtime doesn’t statically link glibc and that would improve their compatibility to 100% if they did (would work on musl distros).
going on all-caps rages
Yeah I can’t take blatantl lies like those that say that appimages bloat the system while promoting flatpaks, and I’ve already shared you enough info showing that is utterly false.
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.
Beyond the given arguments, App images are destined to have subpar Wayland support because the main dev behind app images is a toxic kid who has a weird attachment to the x server, to the point of rejecting PRs where others have done the work of improving Wayland support on his behalf.
Hahaha that is actually mentioned in the article below
According to Robin Stern, PhD, co-founder of the Yale Center for Emotional Intelligence, “Gaslighting is often used in an accusatory way when somebody may just be insistent on something, or somebody may be trying to influence you. That’s not what gaslighting is.”[17]
Ok, my bad. But you see what i meant. You not liking appimage doesn’t mean it’s broken. In fact, i consider packaging some old-but-beloved apps with compile errors lately as appimage, because it just runs without much hassle.
FWIW, snaps are sandboxed on any system that uses AppArmor, which includes most Debian or SuSE based distros. There’s also a partial implementation of the sandboxing for SELinux, but the different model makes doing a complete implementation problematic.
Is that sandboxing graphically available like with Flatpak? To my knowledge it required Apparmor patches but that these are upstreamed is a good info. The SELinux implementation sounds interesting, but well… I dont see the point?
Yes, that sandboxing works with graphical apps in addition to CLI apps and services, and there are several graphical applications that allow you to select connections for snapped apps, including KDE Discover.
The SELinux implementation is primarily there to ensure that SELinux’s enforcement doesn’t break snapped apps, but a side effect of the different model compared to AppArmor’s means that filesystem based sandboxing is only partial. And, of course, if the system has SELinux in permissive mode snapd won’t force it into enforcing mod. Specific vary from system to system, but it means that the filesystem isolation isn’t as good under SELinux as it is under AppArmor. Most of the sandboxing is done through cgroups, though, which is not dependent on whether one uses SELinux or AppArmor.
Just get the exe and use wine. Or windows VM. I always use .exe for everything. I have no app images or flatpaks. On Ubuntu make a windows VM, in that windows VM install virtualbox and make an Ubuntu VM… And keep doing this until you have no disk space. Make a VM for every app.
Thats why you should only use flatpakked wine wrappers like Bottles. Bottles has no filesystem permissions at all, everything uses portals. So I suppose (apart from maybe privileged syscalls?) Viruses would be harmless
Add comment