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…
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.
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.
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.
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
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.
Meanwhile Inkscapes official methods to get the GTK4 nightly are
When there is a beta release there will likely be a flatpak soon though.
Why is Appimage broken by design?
https://github.com/boredsquirrel/dont-use-appimages
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.
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
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.
Thanks.
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.
Yawn…
Because Linux isn’t Windows 95
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.
Stop gaslighting.
What?
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.
I solved it.
Uhm did you forget a /s ?
That’s basically sandboxing with extra steps… but whatever works for you, I guess.
It’s a joke, obviously
Many years ago, it was discovered that Wine could run Windows viruses/worms/malware just fine, thank you very much…
“Sandboxing”, it isn’t.
It runs with all the privileges of the user running the app, iirc.
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
good god
It’s a nightly build, I don’t really see that as an issue. The stable build is available in every format I can imagine.
For sure. It is not a huge problem. But still kind if a bummer
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?
selinux support doesn’t actually work. The point was to present snap as portable when it is not.
Bubblewrap on the other hand…
Works on any Linux kernel in the past like decade, yes.
Damn.
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.