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.12 GiB (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.12 GiB (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.
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.
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.
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
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.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
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
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
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.
That’s basically sandboxing with extra steps… but whatever works for you, I guess.
It’s a joke, obviously
Uhm did you forget a /s ?
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.