Appimages totally suck, because many developers think they were a real packaging format and support them exclusively.
Their use case is tiny, and in 99% of cases Flatpak is just better.
I could not find a single post or article about all the problems they have, so I wrote this.
This is not about shaming open source contributors. But Appimages are obviously broken, pretty badly maintained, while organizations/companies like Balena, Nextcloud etc. don’t seem to get that.
I’m a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:
Usability issues
GearLever solves all the problems mentioned.
Updates
There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.
The lack of repositories
Appimages don’t even have a central place where you can find them, not to mention download them.This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.
Lack of Sandboxing
That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.
Random location
[…] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.
I completely disagree with making the entirety of /home as non-executable, when
$HOME/.local/binis recommended by the XDG standard as a place to store executables. As long as$HOME/.local/binis in the XDG spec, I’ll continue storing my executables there. If you disagree, go argue with the XDG guys.Duplicated libraries
This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.
If users would really install every Software as Appimages, they would waste insane amounts of storage space.
Then it’s a good thing that they don’t right? What’s the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn’t really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn’t be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn’t be using Flatpaks either.
Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don’t even need to do anything special to get AppImages integrated nicely in your system, and there’s nothing stopping other distros adding these packages as optional dependencies - but it’s kinda moot at this point I guess since Flatpak has already won the war.
Personally, I’m pro-choice. If AppImage doesn’t work for you, then don’t use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it’ll die a natural death and you don’t have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution…
This is how you bring your thoughts to the table. Awesome information that I certainly did not have. Thanks man.
I agree with you on all but one point: I detest the argument that “storage is cheap”.
While true, it’s of no value to have 10 times the storage when all your apps grow 10 times in size. You can still only do as much as before but had to upgrade in between. This also means, it leaves behind people who simply can’t afford an upgrade and who have an otherwise running system.
On top of that, we live in a time where we should not waste resources, since the world already suffers enough.
I am therefore still a fan of optimizing software to be as efficient as possible.
That being said: carefully used AppImages solve one such issue for me. Not every application I use needs constant updates. I want to stay at a specific version. That’s easy with AppImages.
GearLever
Download from Flathub
Hehe.
Duplicated libraries
This is a fair point but “they include all the libraries they need” is the entire point of AppImage - so mentioning this is pointless.
“Bloat” is one big topic around these newer packaging formats so definitely not a pointless thing to bring up imo. I don’t think it should be as big of a topic as it is (the actual issue here is fairly minor imo) but it is definitely talked about.
And flatpak (and snap I think) have much better tools to mitigate the space use issues.
(any Flatpak user would’ve at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes)
While I overall do prefer Flatpak over AppImage these days, the sandboxing has indeed been giving me more trouble than I think it is worth so far.
GearLever](https://github.com/mijorus/gearlever) solves all the problems mentioned.
Sceptical but I will try it for sure.
It makes appimages less worse than Flatpaks though, so its only “badness reduction” for me.
There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don’t want to use GearLever, there are other updaters like AppImageUpdate.
The first is what I mentioned, such updates can be perfectly done by a central package manager. Did you ever try to seal off a Windows install using Portmaster, where every installed app needed network access for their individual update services? Just no…
Ans to the repos, yeah maybe, havent looked if they are as secure as a linux repo. But the concept of “it is acceptable to download software from random websites” allows for malware to fit in there. Only if you will never find a .flatpak file it is possible to be sure its malware.
But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you’re actually running an untrusted app.
All worse than bubblewrap. Containers are either manual af (like with bubblejail) or if you refer to Distrobox/Toolbox, unconfined by default. They have no portal integration and no GUI configuration apps. So it may work somehow but probably worse, more resource heavy and there simply already is something better.
Same for VMs. Keep an eye on Kata containers, but this is about least privilege, not some QubesOS system that will not run in a tablet, for example. Android uses containers, is damn secure, and runs on phones.
[non executable stuff]
This is about protecting against malware. Linux Desktops are built on a different logic. Any unconfined software can download a binary to localbin, copy a random desktop entry from usrshareapps to your local folder, edit the exec line and add that binary to it.
Or just manipulate your .bashrc, change the sudo command to read input, save to file, pipe input to sudo. Tadaa, sudo password stolen.
That concept of “users can change their home but not the system” is poorly pretty flawed. So any directory that is writable without any priveges is insecure, if you dont trust every single piece of software you run.
Agree that Snaps are a problem. Its only really problematic when repackaging is illegal though, of course annoying but the Spotify flatpak is a repackaged snap. Same as with appimages.
I should write the same about snaps, but I feel they are covered WAY better.
This tool also good
Dont spam please
Ate em up
Yeah, it is also interesting how people do not see in eyes of developers.
Oooh yes, let’s throw some mud in the gaping holes of this packaging solution, spit and tape the rest to make it do something it was not designed to do. Brilliant idea! ☺️
I agree with this, but as an app developer, can I just say, Flathub’s documentation is an absolute abomination. It is so bad, that I’ve tried 3 times to publish an app and have given up each time. I can build a local Flatpak just fine, but getting it on Flathub is just so convoluted and bad.
AppImages are ridiculously easy to build and distribute, just a pain to actually use. And even then, they’re not that much of a pain.
Totally understand that. Development docs are so needed.
what are flathub issues? IMO it’s easier than putting your app in Debian…
If worst comes to worst you can just distribute your .flatpak file directly, as you would with your app image
This would tick a lot of issues but please dont do that. People will get used to it and suddenly malware is possible again.
Try getting Creality Print to run without manually updating components of the appimage. I’ll wait.
This has nothing to do with my comment.
Uhh ok pal, sure thing.
Bro, a developer (which I am not) voiced his opinion. What’s the need for the toxicity? Isn’t it better for everyone if we all ask questions or provide our opinions respecting others? This is the reason why ANY difference of opinion ends up turning into a heated and useless argument. If you have something to counter what he said, by all means, bring it to the table. @hperin didn’t say anything out of place.
I think you’re both on something either really good or really bad. I added to the sentiment about appimages and you’re both too busy sniffng your own farts too actually read the very short thing I wrote. You’d rather create a narrative in your own head about what a big meanie I am. So be in it then.
In conclusion, screw both of you, you’re blocked. I have only marginally more patience for stupid than Linus does and you’re both well past that. Have a nice day.
You too bud. A great week actually.
One specific implementation by a terrible company that can barely manage to check quality control on their actual products isn’t a very good example of appimage’s problems.
Not saying they don’t have problems. But having seen creality’s version of Marlin, I gotta say, I’d be willing to bet they rebranded something, but using vastly out of date versions.
Probably should switch to simplify3d, prusa or cura.
While you’re not wrong, the problem I was referencing is an outdated library embedded in the image. It makes the whole app crash and it could happen to any app.
AppImage is great at what it does - provide an ultra-low effort packaging solution for ad-hoc app distribution that enables a developer who won’t spend the time to do rpm/deb/flatpak packaging. There are obvious problems, security and otherwise, that arise if you try using it for a large software collection. But then again some people use things like Homebrew and pacstall unironically so …
Great, now tell me why your appimage is complaining about not having some .so file on my system
The developer made extra low effort and missed a lib. 😅
No, the problem is more subtle, the developer assumed I have the same libs in the same locations as a mainstream distro like Ubuntu, but I do not
I actually have several versions of each library in different hashed folders (my distro does this) and I just steam-run normal Linux executables
Except I can’t do that when using this appimage thing so it doesn’t directly work on my system
Well, theoretically if the developer had bundled the libs they assumed would be present on Ubuntu into the AppImage, maybe it would have worked. Would it be larger? Sure. 😂
But then again some people use things like Homebrew and pacstall unironically so …
Thank you for mentioning this! Unfortunately a quick search on the internet didn’t yield any pointers. Would you mind elaborating upon the security problems of Homebrew(/Linuxbrew)? Thanks in advance 😊!
Post about homebrew by Jorge Castro
I am not sure how secure it is.
I am aware that Homebrew has become the go-to solution for installing CLI applications on Bluefin. Which is exactly why I feel compelled to ask the question in my previous comment.
Btw, I don’t really understand why you felt the need to share Jorge Castro’s blog post on Homebrew? AFAIK it doesn’t go over any security implications. Sharing the article would only make sense if Jorge Castro is regarded as some authority that’s known to be non-conforming when security is concerned. While I haven’t seen any security related major mishaps from him or the projects he works on, the search for the CLI-counterpart to Flatpak seemed to be primarily motivated by facilitating (what I’d refer to as) ‘old habits’; which is exactly what Homebrew allows. It’s worth noting that, during the aforementioned search process, they’ve made the deliberate choice to rely on Wolfi (which is known for upholding some excellent security standards) rather than Alpine (which -in all fairness- has also been utilized by Jorge for boxkit). IIRC, people working on uBlue and related projects have even contributed to upstream (read Distrobox) for patches related to Wolfi. So, there’s reason to believe that the uBlue team takes security seriously enough to work, contribute and deliver on more secure alternatives as long as it doesn’t come with a price to be paid by convenience. Which, in all fairness, is IMO exactly why Homebrew is used for in the first place (besides their recent utilization of technologies that have similarities to the ‘uBlue-way’ of doing things)…
I’m not a security expert but I do know that the Homebrew is working with openssf on security: https://openssf.org/blog/2023/11/06/alpha-omega-grant-to-help-homebrew-reach-slsa-build-level-2/
Boxkit predates wolfi so it’s still alpine, I’ll probably replace it at some point but most of the forks of boxkit are because people want the premade github actions and they end up replacing it with whatever distro they want anyway. The wolfi connection is because I know the people who work there (including a ublue maintainer) and we have similar goals/ideas on how linux distros should be put together. My ideal dream is a wolfi userspace systemd-sysext on top of fedora base, then we can have our cake and eat it too!
We’re not security experts but lots of us work in the field and that gives us access to peer review from experts when we set things up. We sign every artifact with sigstore so users can verify that the code used in github is what’s on their image, that sort of thing. And most of our practices utilize CNCF governance templates that lots of other projects use.
I learned quite some things from this talk
https://youtube.com/watch?v=4WuYGcs0t6I&t=456
Appimages are damn broken
I mean, I’m not saying they aren’t. I think the original argument is valid. I just think they’re better than the alternative, which isn’t Flatpak but self-extracting .sh files.
Yes thats true. But that talk specifically mentioned the horrible security practice of appimages, and that they dont run everywhere at all
No argument. The security aspect is something that seemingly a lot of people in this thread don’t get. The some-person-creates-a-package-I-install model works as reliably as it does without sandboxing only when that person is a well known trusted individual or group. For example the Debian maintainers team. It’s a well known group of people who are trusted due to their track record to not produce malware-ridden packages intentionally or unintentionally. That is the line of defense you got. If you remove that, you end up in download-random-shit-on-Windows land in regards of security.
What’s worse, this extends to the bundled libraries. Unlike central systems with shared libraries like Debian, bundling libraries means that the problem extends to the sources of those libraries! Package A and package B both include libjpeg-v1, it’s got a remote exploit gaping hole. Developer A has time to follow CVEs and updates theirs. Developer B doesn’t or has moved on. The system gets a patched libjpeg-v1, app A gets it, assuming it can be auto-updated. App B remains open for exploitation.
Therefore given all that, sandboxing is a requirement for safely using packages from random people. Even when the packages from those come from a central source like Flathub or Snap Store. Sandboxing is why this model works without major security incidents on Android.
Anyway, won’t be the first bad practice advocated by some in this community.
This matches very well with this talk of an OpenSuse microOS maintainer doing a followup on his thoughts of Appimages, Snaps and Flatpak.
Spoiler: Flatpaks are the only ones that work.
Snaps work too if you use Ubuntu and trust Canonical, as he mentions. I’m a bit annoyed at Flatpak for being inferior to Snap in that it can’t be used to install system components. Snap allows for a completely snappy system, without the need to build the base OS one way and the user apps another. The OS from-traditional-packages, user-apps-from-Flatpaks model is an unfortunate compromise but I guess we’re gonna get to live with it long term. It’s better than the status quo.
BTW I completely disagree with him that everyone should be using rolling releases. As a software developer, user, and unpaid IT support, this is a mind boggling position.
Yesno. Snaps are not sandboxed at all, which is a nogo for normal application distribution.
So while I think it also sounds nice to pack an OS into different immutable parts, if the entire system is flawed, its not worth it.
Flatpak is good for app distribution, the rest is job of the OS.
not rolling release but normal stable release, not some random LTS. Not every software is like Firefox ESR (which honestly is not needed as Firefox doesnt break), but Debian etc. often just randomly dont ship updates.
Fedora is a bit too rolling, but if you always stay on the older supported version, thats okay. Especially with atomic.
Here is an alternative Piped link(s):
https://piped.video/watch?v=4WuYGcs0t6I&t=456
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
oh boy here we go I strongly disagree with this article
While complex .tar archives (like firefox) may seem messy, they integrate many different things. An installer script takes care of placing a .desktop entry, you can have an updater script, a LICENSE, README and more. Those are all missing with Appimages.
.tar ARE messy, sometimes they don’t work right, dep conflicts, etc. An installer script can be shipped with an appimage anyways. Moot point IMO
Apps installed with the system package manager get their .desktop Entry in /usr/share/applications, installed Flatpaks get their entry linked to ~/.local/share/flatpak/exports/share/applications/, user overrides and other installs can be put in ~/.local/share/applications/.
Appimages have no desktop entry, so they have (currently) no icon on Wayland and they don’t appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.
see above
Instead users follow strange habits like placing the files on their desktop, which is a highly discouraged “Windows workflow” (symbolic image) and not even supported on many Desktop Environments, most notably GNOME.
Who discourages it? I personally prefer this myself, lack of desktop icons is a common complain for stuff like GNOME…
This is both a usability and a security issue. Traditional Linux apps, even if they are cross platform, don’t have updater services, as package managers are way better at doing that.
I disagree that this is better. A personal issue but I Much prefer when apps can update themselves.
This means, packing as an Appimage either requires to implement an updating service, on a platform that doesn’t need that, or to have no updates at all.
Instead users need to follow an RSS feed, get a mail, or manually check for updates, which is horrible UX. Then how do they update?
Is this really a massive issue? There have been appimage stores in the past. Self updating appimages really isn’t that hard either. If this was a massive issue, you could do something like obtanium for android which could easily automate the process.
Appimages don’t even have a central place where you can find them, not to mention download them. This is extremely insecure. Modern Application stores and every well made Linux repository uses cryptographic (mostly gpg) verification, which secures the authenticity of the software. You can be sure you downloaded the real package.
I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe then downloading from a repo or a “curated” service. So we can grant one here.
There is no updating mechanism. On Android you may also update by downloading .apk files, but once installed, the .apk needs to be signed with the same key, otherwise updates are blocked. With Appimages… you just delete the old .appimage file, download the new one, change the name to remove the version and hope your .desktop entry didn’t break.
This is how you get malware.
the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.
They are not well maintained
There is a well known “bug” on modern Ubuntu, where Appimages lost their “works on every Linux Distro”, because they are built for the outdated libfuse2, while Ubuntu now uses libfuse3. The fix is to install the outdated version of libfuse (!), and this is still not fixed.
An application format, that is incompatible with the latest version of its core dependency, is broken.
This is a very minor issue, i’ve had way more issues with traditional repo packages then I have had with appimages.
Lack of Sandboxing …
I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything from devices not being recognized, weird storage issues and more.
Random location …
Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
Duplicated libraries
Appimages bloat the system. They include all the libraries they need, and unlike system packages or Flatpaks, they don’t share a single libary. If users would really install every Software as Appimages, they would waste insane amounts of storage space.
This also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.
and? When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.
Appimages are not needed Flatpak solved many Linux desktop issues at once …
None of these provide reasons as to why appimages aren’t needed. Appimages still offer a lot, for one I can just download and run it I don’t need to worry about installing and uninstalling application when I just want to try it, I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.
Appimages also let me do fine grained control over the dependencies. No unexpected runtime updates, I can compile the deps with flags/features I want to support, and disable flags/features I don’t want to support, Users don’t need to download a stupid appstore or use CLI (not a single appstore i’ve used to date isn’t hot garbage, I hope cosmic-store will be different).
I agree with much of this. However, regardless of which platform you’re on. it’s best to follow the design patterns of that platform.
Putting binaries on your desktop is not in keeping with Linux design patterns, nor are self-updating apps. I think those are fair points.
Having dozens of apps all using their own update mechanism introduces unnecessary complexity, which can be exploited. This has been a problem on Mac and Windows over the years. On Mac, for example, a common solution to this is the Sparkle framework, which devs can use in their app to manage self-updating; but Sparkle itself has been exploited, so then you have apps out there running god-knows-what-version of Sparkle in their bundles, leaving users vulnerable with no good way to identify or remediate it. This is why I typically disable any self-updating feature in any apps I use.
Dont know where user installed tar archives (with statically linked binaries or including deps) would have dep conflicts, maybe if they are not statically linked.
The self updating stuff and desktop icons is personal opinion and not the common way on Desktop Linux, so I skip that.
you could do something like obtanium for android which could easily automate the process.
That is called a package manager, with a repo, with gpg signing etc. On Android (which I mentioned) updates are secure. Let alone the point that appimages are not updated in a regular way, they are just replaced.
I’d argue it makes little difference. But yes, Downloading things from the internet is more unsafe
No the difference is huge. If you are used to downloading software from websites, a faked website can easily lead to downloaded malware. Flathub can be added with a click and flatpak is included in distros, which means no hunting on the internet and no accidental clicks.
And as I said, until nobody downloads
.flatpakpackages online, and there may be an occasion where this is normal behavior, people will believe malware links are legit.the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.
Appimages are distributed everywhere, just as .exe files for Windows. This means they are favored by developers used to Windows and Mac, and those will not add them to a repo instead.
So a faked website of whatever etcher or something is easy.
The fact that Linux malware is not a thing, while Appimages clearly give the headstart for that, is a miracle.
I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything
Flatpaks are not secure because their sandboxes are weakened to not have such issues. This is due to apps not following secure standards, and until that is fixed they are insecure or broken or both. (Apps need to write configs in the container, they should use portals etc.)
I maintain a list of flatpak apps following modern standards, which is a small portion but getting better.
Linux is only somewhat secure because everything is FOSS and comes from repos.
This is broken by appimages, that can easily distribute malware and thus fix the “my malware is not running on that distro” issue.
Every software that can write to your .bashrc can easily catch your sudo password.
Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren’t “one of the major standards” this is just wrong.
Yes linux experts would put them there. As mentioned in that text malware would also install itself there, so on secure systems this should be only writable by root/ some elevated group privilege.
But apart from that users put them on the desktop, or in some random folder, I mean that dir is hidden for a reason.
Or put it in that PATH and then link to the desktop, resulting in a broken link when you remove the app.
When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.
If something is not scaleable its not a good concept. The fact that you will only install a couple of appimage apps is enough proof.
On modern atomic distros users can rely purely on flatpak.
Btw see the linked dedup checker. You may download more dependencies but they are linked between each other and not actually take up so much space.
I don’t need to worry about installing and uninstalling application when I just want to try it
We need to overthink those habits. You dont just “try an app”, you run unsandboxed code from an unverified origin. As mentioned above, this could be totally fine, and also add a function to your bashrc that catches your sudo password (the next time you use it) and sends it to a server.
The secure way to do that is completely unpractical.
- Get a GPG app or use the cli, create a personal key. Secure the access permissions, as gpg always complains on Fedora for example.
- Hunt the internet for the gpg key of the dev
- Look for at least another source of that key like GrapheneOS does it
- Compare those keys hashes using cli or some app
- When correct, load the key into gpg/kleopatra/kgpg
- Verify the key with your internal key (yeah gpg is overcomplicated)
- Download the appimage, and a signed hash (most of the time its done like that)
- Verify the signed hash
- Sandbox the appimage using bubblejail (doesnt work) or firejail (no idea if it works, and its insecure)
- Repeat on every damn update (if it doesnt have a builtin updater)
This is unusable. And repositories do this automatically without anything you need to do. For sure you could “extra check the website” and say "
Also app data will be everywhere, often in its traditional location, while there is no package manager at all to delete them. Flatpaks store all their stuff (when devs care and not just ignore that, cough Cryptomator) in their container and data can be easily removed during uninstallation, GUI stores show a popup to delete data and I also made a small script to do that.
And that “try it out” app will either have no desktop entry or that entry needs to be manually and will be still there after uninstalling.
I don’t need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.
This may be a reason, but this is only for testing then. But for sure, when its a small project, getting it on Flathub may be much efford.
I can imagine the developer experience is easiser. Flatpaks are simply very “defined” and need all that metadata and more to be complete. But needing to use available runtimes is a good thing mostly, its basically supporting a specific distro.
Flatpak through CLI is fine (I would like to have a standalone small store just for flatpak), Discover is nice too. The Linux Mint store also seemed fine but not much experience. (Linux Mint has some Wayland support now, so there is a secureblue Cinnamon spin, have to try that). The Cosmic store is just a stub currently, lets see!
Cheers!
Odd, this random github rant didn’t seem to sway my opinion.
To hell with user choice, only flatpak
I’m not going to weigh in on the specifics of Flatpak vs AppImage, because I don’t know enough about the particulars.
However, I think the “user choice” argument is often deployed in situations where it probably shouldn’t be.
For instance, in this case, it’s not the user’s choice at all, but a developer’s choice, as a normal user would not be packaging their own software. They would be merely downloading one of a number of options of precompiled packages. And this is the thrust of the argument. If we take the GitHub rant at face value, some developers seem to be distributing software using AppImage, to the exclusion of other options. And then listing ways in which this is problematic.
I, for one, would be rather annoyed if my only option were either AppImage or Flatpak, as I typically prefer use software packaged for my package manager. That is user choice, give me the option to package it myself; hopefully it’s already been done for me.
There are some good things to be said about trust and verification, and I’m generally receptive to those arguments way more than “user choice.”
Thanks. Also, afaik lots of software is not legal to redistribute as Flatpak.
It’s thanks to user choice that we aren’t all stuck on proprietary operating systems, so saying that isn’t great.
Now I WILL get judged for this but hear me out… AppImages are useful for apps that will not get on Flathub. If you have an app that cannot get on Flathub (like a pirated Minecraft Launcher), you will be thankful developers are using AppImages for them. In this case, they’re unlikely to use snaps (alt repos for snap are possible but difficult from what I’ve heard) and maintaining a flatpak repo just seems like overkill for a single program. So for cases like these, I’m glad to see these packaged as appimages
Okay fair point. Piracy, illegal content etc. will all get removed from Flathub.
Similar to another comment about archiving software that may get removed
Well you can just put a flatpac on a website and let download it from their right?
You can, but it seems to be not documented how to get a .flatpak from an installed app.
Yea im pretty sure flatpak suports bundles that you can install directly, just like an appimage
As far as I know flatpak applications can be distributed as a file without the need for a repository, just like .deb or .rpm files
Can they? I’ll be honest, I’m not that familiar with how flatpak works on a more technical level.
AppImage is a nice way to have an app on an USB stick, remote server or for archival. But for normal app usage, why?
I want to find a way to do this with flatpaks too.
A small GUI tool (a statically linked binary lol) that can be placed on that stick
- copy the flatpak app and runtime stuff to a folder
- copy the desktop entry over
- copy app data when chosen
And the same thing to copy it from the stick to a live system. Should work, probably not haha
TIP: Flatpak have a build-in way for creating USB, check out the “flatpak --help”.
But the point is with Appimage all that have to be installed is FUSE, which is expected to be installed on most installs when you go to a friend or work where Linux is used.
Oh nice!
Flatpak also works everywhere and appimages are not ported to fuse3…
I mean I want to think Appimages where nice, and they are kinda, but no.
When I was first getting into Linux, Flatpak wasn’t a thing quite yet. I ended up installing software in all of the following ways:
-
A .run file. Simplify3D (commercial 3D printer slicer) did this, it was kind of a literal word for word translation of the Windows .exe installer system. Please don’t do this. See also install.sh. Just don’t do this.
-
A .tar.gz file full of the executable and its assets with no further elaboration. This happened a few times but I really remember FTL: Faster Than Light did this when I bought the game directly from them rather than on Steam, and they were nice enough to link it to a Steam key for me. This’ll work if you’re handing out a thing you made to a couple other people, don’t distribute like this please.
-
Clone my git repo. I’m going to type this slowly so that it will best be understood: Git is for people who are contributing to code, not for people who just want to run it. Do not ask end users to compile from source.
-
Ubuntu PPAs. This one seems to have died; it’s been a couple years since I’ve seen anyone suggest adding a PPA. Good, they somewhat sucked.
-
Pip. There are way too many end-user applications that are distributed with Python’s package manager. No. Bad.
-
Alien. For a brief time the driver for my printer was only distributed as a .rpm, I was on a .deb based system. There’s a thing called Alien that lets you do that.
-
Loose .debs. Haven’t encountered this one in awhile either, but…could be worse.
-Snap. No. Just. No.
Compared to almost all of these I’d prefer an AppImage. For example, go look at the process of getting an up to date copy of Chirp, the amateur radio programming software. The instructions are kind of “build it yourself,” they are flawed and borderline incorrect, and include no uninstall instructions. I would vastly prefer they just package the damn thing as an AppImage.
Compared to AppImage, I almost always prefer a Flatpak. Flathub is built into my distro’s GUI app center and is almost transparent to the user. Using Flatpaks with the terminal is complete rectal pus, but for most end users who prefer to do things graphically Flatpak works pretty well most of the time. It is not completely seamless, like Flatpak seems to suffer from all the drawbacks of sandboxing with none of the benefits.
If you are distributing to a wide audience, use Flatpak or publish to the various standard repos. If you’re a little niche thing that might distribute 200 or 300 copies ever, AppImage is probably simpler. Otherwise just…keep your repo private.
Thanks, yes fully agree. There are a ton if shitty distribution ways.
When I publish stuff on Github (its never big, always small tools) I never let people git clone, just download the needed parts.
Releases are meant for that, but still, putting software on repos may be annoying but its the correct way to do.
-
The only use case for Appimages
If users want to carry applications around on a thumbdrive, or run on a fully immutable system like TAILS, Appimages may be needed. But this is the only target, and it is not a standard use case.I guess I agree. This is precisely the case where I have ever used them. Namely to have a portable executable of my password manager on a stick together with a backup of the password database.
I had no idea they were being used elsewhere.
Nextcloud, Balena Etcher, Lunar Launcher and more are exclusively supporting Appimage, thats the big problem.
Counterpoint: I don’t like having more than one package manager on my system, which means things like Flatpaks and Snaps are out. With AppImages, I just double-click on the executable and off it goes.
I get that multiple package managers can be suboptimal (though I don’t have a problem with it as long as the integration is good).
But it still seems like a much, much better solution than just not having these applications managed by a package manager, as is the case with AppImages.
True. I would consider another package manager if it integrated into my system nicely and if I had more than a few applications outside my regular package manager. But I only have like two AppImages on my PC anyway, so I don’t mind updating them manually when I need to run them.
That is the case for me with Flatpaks. They integrate really well into Fedora Kinoite - you have OS updates and Flatpaks all in a central UI, everything works as expected from any “App Store”.
Thats flatpak with flathub. Also described in the post
So you prefer to not have any updates or secure verification, because you dont want a second package manager?
Dude you are the second package manager, and if you dont follow the whole gpg verification process I described in another comment, that is less secure.
You should definitely be checking the signatures before double clicking tho
Most shortsighted answer of the day. Great now you have this outdated executable on your system and you mabye are not even sure this was installed through appimage, because how should you know when your launcher is not telling you anything? golfclap
We’re also regularly debating Flatpak here. That password managers don’t tie into the browser and the desktop themes don’t apply. It’s also not the best solution and regularly confuses newer users.
That native messaging portal is probably developed somewhere. But for sure, also apps installing themselves “partly” as an extension of another, like Zotero and Libreoffice. This could be done though, okay.
Themes generally just work on KDE at least. At least light/dark themes, which may not really be the fanciest of choices
I’d be happy if people just cut down on advertising Chrome/Firefox and LibreOffice via Flatpak to new users. They should use the packaged version. That’s why we have distributions, to make the whole system a smooth experience and everything tie together.
Flatpak is slowly getting there and I think at least some distros have it preconfigured so the default GTK themes are in place.
Ultimately, I’d like sandboxing to be available natively in Linux, at least for desktop applications. And we can talk about a packaging format that is available to the user, allows pulling software directly from the upstream project, includes libraries and runtimes.
Yes SELinux confined users or apparmor could allow sandboxing apps the same way as flatpaks.
On 2GB of RAM systems that would make a lot of sense.
Chromium cant use its native sandbox, Firefox supposedly can.
But Librewolf and more should be used as Flatpak, unless you need multiple apps to chat between (native messaging) which doesnt work yet, its way more stable.
Yeah, I think we should extend on the sandboxing features like AppArmor, SELinux and Flatpak for desktop use. Look at MacOS and Android and what they’re doing for desktop users. That is currently not the Linux experience. Ultimately I’d like my system to have an easy and fine grained system to limit permissions. Force third-party apps to ask permission before accessing my documents or microphone. have sane defaults. make it easy to revoke for example internet access with a couple of clicks. make it so I can open an app multiple times. and have different profiles for work, private stuff and testing. This should be the default and active in 100% of the desktop applications. And apps should all use a dedicated individual place to store their data and config files.
Librewolf and more […] used as Flatpak, […] its way more stable.
That’s just not true. I’ve been using Linux for quite a while now. And I can’t remember my browser crashing in years, seriously. Firefox slowed down a bit when I had 3000 tabs open, but that’s it. How stable is your Flatpak browser? Does it crash minus 5 times each year? How would that even work? And what about the theming and addons like password managers I talked about in the other comment? Use the distro’s packaged version. It is way more stable. And as a bonus all the edge-cases will now work, too.
Most things already work. You know, desktops need to start with that, they need to implement popups for these permissions. And I guess apps also dont ask for permissions yet (like they do with Pipewire access), they just take it or fail.
So its again a problem of adapted apps.
Storage is all stored in
~/.var/app/and could be duplicated etc if you really want to. That would require some hacking, but you could have multiple profiles for apps. Tbh this is not hard to do at all, just rename the app folder to “appname-profile” and rename the active folder back to the apps name.A GUI for that would be interesting.
Browsers are a big example of good native packaging, as they get most attention. But for example on Debian, or Ubuntu, or many other platforms, I would prefer to use Flatpak Firefox (if firefox didnt have their deb repo now).
Chromium is hacky as Flatpak as the Sandbox is imcompatible and needed to be replaced.
For firefox there is no statement about this, hopefully soon. I use native browsers for the same reason as you.
Flatpak is the best solution.
Password manager is usualy an add on.
Themes not applying is wrong packaging, not flatpaks fault.
Flatpaks limitations are real but you should install as flatpak first and if not working, then use the native package or nix. And limitations in flatpaks should be advertised.
Hehe, No. It’s the sandboxing.
But with this approach you take over the answering questions to newbies… Why doesn’t the webcam show up in the videoconferencing? Why doesn’t my GTK / QT themes apply to some software and it’s a 2 page tutorial with lots of command line commands to fix that? Why can’t I install Firefox add-ons and on Windows and MacOS everything just works? Why is Linux so complicated and regularly stuff doesn’t work?
I had this argument multiple times now. There is an easy solution: Do it the other way around until you know what you’re doing and about the consequences. Distributions are there for a reason. They put everything into one package and do testing to make sure everything works together. They provide you with security patches if you choose the right distro. LibreOffice and a Browser even come preinstalled most of the times. If you do away with all of that, it’s now your job to tie the software into your desktop, your job to handle the sandboxing if there is addons that need to pierce the sandbox. Your job to make sure the Flatpak publishers do quick updates and keep the runtimes up-to-date if a security vulnerability arise within an used library…
I’m not directly opposed to using Flatpak. I’m just saying there are some consequences that aren’t that obvious. There are valid use-cases and I also use Flatpak. But in my experience hyping some of the available technologies without simultaneously explaining the consequences is regularly doing a disservice to new users.
Do you mean fedora not installing codecs by default and the flatpak version of firefox has it bundled, i.e. just works?
I don’t want to argument with you about that. If something doesn’t work as expected or intended, you’ve done a bad job. Stuff not working on linux isn’t exclusive to flatpak. It’s the fault of maintainers if people complain about a flatpak version compared to distro package.
More people have to use flatpak and report the bugs they experience. The more people focus on flstpak the less infancy bugs will appear.
I’ve got only recent runtimes installed. There’s no old runtime. I understand your concern though, but it’s less of a problem for maintained software. Moreover, you’ve got the same problrm for other package manager. Flatpakcan even improve upon this because it’s bundled.
There’s also a distinction to be made if it’s an official distribution channel or if someone else packaged it.
I mean it’s not even my own problem. I just have Spotify, Microsoft Teams and Zoom installed that way, and a few pieces of software that I’m testing. I use a rolling distro so I have the most recent versions of every software I need anyways. And I have the skills to configure stuff. So I myself don’t have an use-case for a spyware-riddled Chrome browser from Flathub or something. I have a nice LibreWolf from the unstable channel of my distro. Steam and all the other stuff is there, too. And it works almost flawlessly. Why would I trade that in for a 4GB version of the same software that has downsides?
It’s the newer users I’m concerned with. Their sub-par experience of Linux.
This is what I mean:
- https://github.com/keepassxreboot/keepassxc/issues/7352 (Maybe Keepass works as of now(?) I don’t think so but I haven’t tried. At least some addons do. But other’s don’t. It requires the permissions to be configured by the prople preparing both flatpaks that want to talk to each other.)
- https://itsfoss.com/flatpak-app-apply-theme/ / https://docs.flatpak.org/en/latest/desktop-integration.html
- All the issues people had with Steam, the graphics drivers, attaching gamepads/controllers or headsets, getting Discord and extras working. (Some of that seems to have been resolved in the meantime. They put quite some work into it.)
- Some distros don’t update Flatpak packages as part of their standard update mechanism. You need to learn to regularly run “flatpak update” or learn how to activate that.
- I have some packages still rely on old runtimes that are missing security patches. I suppose it’s the same for a lot of other people. And there isn’t a mechanism to warn you. You also need to learn how to figure that out.
- I don’t remember which of the video conferencing solutions this was, but I remember fighting with the webcam permissions and advice on the internet was to disable sandboxing entirely. I set the permissions a bit better but then also screen sharing wouldn’t work.
As I said, it’s okay for someone like me - and probably you - to use, and I don’t complain. I’m glad I have Flatpak available as a tool. But look at the issues I’ve linked above and the steep learning curve for the beginner. They need to learn what GTK is, what QT is, what desktop they use, learn what Flatseal is, use the CLI. They have no clue why it is even required to do that much work to get their Keepass set up. And that it’s not Linux’ fault but their decision from 2 weeks ago to install the browser that way. And their experience is just worse than it needs to be. And this isn’t unsubstianced, I’m speaking from experience. I’ve answered these questions over and over again. It’s already annoying to get the NVidia stuff set up reliably, find new software and adapt your workflow. And the switch from X11 to Wayland broke things like screen sharing/recording, anyways. And we’re now piling 20 other things on top, to learn and do manually if you happen to be one of the users who don’t use the default standard setup.
And nothing of that is “bad” or can’t be fixed… We’re making progress with all of that. And we’ll get there. All I can say with my experience helping people with their Linux woes and the current state of Flatpak: The “use Flatpak for everything” mentality is causing issues for some newer users. And experience shows: They rarely understand the consequences but heard the hype about Flatpak. And few of them can explain why they used Flatpak over the proper packages in their distro.
So my opinion in short:
- Flatpak is nice : yes
- try a Flatpak first, then the distro package if it doesn’t work: hard no
- you can get recent software on older distros with flatpak: yes
- you can recommend Flatpak: Yes, if you also explain the consequences of the sandboxing and pulling things from potentially unreliable third-party sources. You’re doing people a disservice if you don’t.
- some of this will change in the future: yes
- we should have more sandboxing: yes
I don’t get why we didn’t just do it macOS style; bundle everything into one directory with a standardised structure and wire up file managers etc. to run the correct executable inside it.
Because the FHS is a more sensible organization of files. Not every user needs to have their own executable for each program, that’s a mess.
macOS has both, a system wide /Applications and per-user ~/Applications. Not to mention that it doesn’t really matter on a single user system anyway.
Proper, integrated packaging is obviously preferred (though as a NixOS user I disagree that that implies an FHS) but this is about “stand-alone” packages. You’re missing the point.
opt
AppImages are great and easy to use and they can be very easily archived. Today I tried to archive a Flatpak package (yuzu) and it was a pain, complicated and gave up in the end. I end up archiving multiple versions of the AppImages and continue using the Appimage for this emulator. Also sometimes Flatpaks do not work correctly, and I (and any other user) have to figure out what settings and configuration, rights and other stuff is needed to setup with Flatseal. Recently I solved the open links issue with Flatpaks, and found out a certain portal was required to be installed. Also sometimes the theming is not correct too.
All in all, I use Flatpak still and AppImages too, each for their own reasons. The lack of repositories and not needing an installation for being functional is not a problem with AppImages, because that’s the entire point of it. They can be automatically generated and ready for download, regardless of any repository, directly on Github from the developers. There is even a program, RPCS3 (a ps3 emulator), which can check and update itself and list all changes since last update.
If you download AppImages from shady places, then off course its shady and insecure. Just like installing any software without knowing what you are doing is insecure. So that’s not a point against the format itself. The argument “Duplicated libraries” is hilarious, if we speak about AppImages vs Flatpak, because Flatpak has duplicated drivers (especially with Nvidia, I know how bad it is because I had Nvidia cards before) and desktop environment versions, just because certain versions of the application needs it.
I don’t understand these evangelism for packaging formats. Flatpak, AppImage, native system packages and other formats have their own uses and are all useful and not bad.
What do you want to achive with archiving, because of a potential takedown by Nintendo?
Just for your purpose you could just keep it installed and probably block it from getting updated. I am sure you could also backup the .flatpak file somehow, and all the dependencies would still be accessible.
flatpak runtimes are pretty bloated, when you use different versions etc. And its bad that you cant only use Flatpak, currently. But locally they use deduplication, so GNOME, KDE and Freedesktop.org will share at least some libraries.
But for sure, it may not be the best library management there is.
Its not evangelism, there are developers that thinl Appimage is an acceptable format and only support that. I dont know but guess some licenses prohibit user repackaging as Flatpak, so you have to stick with that pain.
The deduplication is only for one specific version, even if its installed on my operating system already. AppImages do not include the entire KDE system. And Flatpak will install multiple versions of drivers (Mesa in example) and other dependencies. While this is exactly what Flatpak was designed for and there are good reasons for, it is important to understand that was counter arguing your argument against AppImages for being bloated. Both approaches are good in their own way, depending on what you want or need.
The backup of Yuzu Flatpak was just a current example why someone would want do that. There can be any reason to backup specific software versions, which is not the topic of today. The topic is, that with Flatpak its a mess to backup and restore. Yes, you can copy the configuration and installed binary files, but that does not work on any other computer. You can backup the key and other important files as well, but then its complicated to restore them as well, that I just gave up. It’s probably not impossible, but not straight forward; a bad user experience.
Meanwhile I can just download an AppImage and copy the file and its archived. Done. In multiple versions. No extra software, knowledge or complicated dance to do this very simple and important task.
Good points.
As a humble linux user of the last year or two my experience has been that anything that is not in the Debian repo is a confusing nuisance. Nobody told me how to get appimages to integrate with my desktop. I had to rummage the internet and learn how. Compare this to a single click in Gnome software or simple command in the terminal for apps in the repo. I also installed flatpak, so I could get programs that weren’t available in the repo but nobody told me I would have to install and rummage Flatseal to enable them to work properly, that it would make my backups and restores take 900% longer and would rinse my data when they need updating. It’s been annoying enough that I’ve ended up learning how to install from source as well. Maybe it’s cool that I’ve learned how to do all this new stuff but to be honest I just feel like I’ve had to do loads of extra head-scratching and unnecessary work. I did it willingly because I’ve been committed to not being held back from using open source software but I couldn’t expect my friends and family to do any of this, so if I do get them onto Linux I can’t recommend these programs to them.
Current tier list:
- Debian repo
- .deb downloaded from a website!
- Enjoy using application, go for a bike ride.
- Make sure I’m free for a couple of hours, install from source.
- Appimage
- Do without given application
- Flatpak
You shouldnt need Flatseal as Flatpaks should have as little restrictions as need to make them work properly.
This is an app problem, on Android all apps start with 0 permissions and many work completely without.
I maintain a list of flatpak apps following modern standards. Those dont just work because their sandbox is full of holes, but because they are adapted to use portals etc.
So Flatseal is used to harden flatpaks, not weaken them, normally.
that it would make my backups and restores take 900% longer and would rinse my data when they need updating.
You mean their storage space? Yes, biggest problem. Not very well solved tbh compared to android where all apps are also sandboxed but they have sizes of 30MB or something.
Flatpaks should be preferred over many other formats though, as they just work, dont touch the system and are more secure, unlike Appimages.
I highly recommend to watch this talk that some commenter mentioned
Thanks for the links. I really want flatpak to work for me because I like the sandboxing but the storage thing is a bit of a killer for me at the moment and I could not for the life of me get Digikam, Shotwell or Rawtherapee to hand image files over to GIMP with the flatpak versions, whereas the repo versions were fine out of the box. Also, I feel like flatpak programs are much slower to open but that might just be me.
Flatpaks will always be a little slower, notably if you are on slow storage media.
Yes this is all native messaging I suppose. Flatpak apps can query an app list, just look at flatseal. So I think querying the installed flatpaks and handing it over to the system portal where you then choose the desired app is the modern workflow for this.
You might want to request that Digikam etc. implement portals for this file opening. Firefox can do for example but of course these are limited as long as apps dont modernize their workflow
I do hope flatpak can solve these things. I have the deb installs all working harmoniously at the moment, so I don’t want to touch them but will have another look at flatpak versions at some point in the future.
Downstream Distribution is simply very very work intensive. By having the system and apps come from a downstream origin, packagers need to follow upstream and keep up with versions. And as upstream doesnt officially support these packages, many will have bugs. Or like on Debian, packages will be unusable as they are too old with unfixed bugs for years.
Neither Android, nor Windows nor any other big OS do things that way, for a reason.
Removed by mod
AppImages can be double clicked and executed. They are not a pain to use.
i can understand that, but flatpaks are easier to upgrade and automatically integrated into your package manager, which (i believe) isn’t as straight forward for appimages. also there’s one major repo where you can find most apps (flathub) making app-hunting less daunting i feel like.
also, once your app is installed, it’s always in your system menu, so that doesn’t change much in the long runComfortable setup that carried over from Ubuntu LTS.
can’t you carry over flatpaks as well? you can probably copy /var/lib/flatpak or wherever they store their stuff from one system to another, or failing that, save all the app IDs you have installed, and re-install them onto your new system, backing up ~/.var to keep all your data!
Flatpack puts all app data in
~/.var?? Ewww! No thanks.not sure about the path, you should check flatpak’s docs for more accurate informations
but i believe so, yeah
on one had it’s a shame they’re not using xdg dirs, but on the other, i kinda get why – it’s neither config files, nor just data – it’s both, it’s a container
Removed by mod
