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.
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
