AppImages are completely different thing versus Flatpak and Snap.
I used to hate AppImages until I had Snap forced on me. Then i thought AppImages weren’t so bad and I fled Snap by running straight into the arms of Flatpak
I don’t think Flatpak “won”. Flatpak makes sense for it’s use, but AppImages also make sense for other uses, and even Snap has it’s place.
It just happens that Flatpak has become the more “popular” method on many desktop Linux set ups, as Flathub integrates well into software stores and the shared dependencies can be more efficient (if you use a lot of Flatpaks).
AppImages are great for self contained portable apps with minimal local dependencies needed, and especially if something is pretty much “feature complete”. They aren’t quite as convenient in terms of keeping them updated or integrating into desktop environments seamlessly (they can be if you visit AppImageHub and install the AppImageLauncher - doesn’t work for me thought - but even then they’re not really as well integrated into desktop environments as Flatpaks have become).
If you were to use lots of programmes, AppImages would potentially take up more space than the same apps in a Flatpak setup because AppImages do not share dependencies while Flatpaks can (if dependencies are the same version). But AppImages are also ultraportable and can run on an even broader range of distros and setups than Flatpaks. AppImages don’t require any installed tool locally to run, while Flatpaks need Flatpak installed. Both Flatpak and AppImage are bloaty compared to direct installs from a distros repos, but thats a trade off for their benefits (containerised, easily deployable across different distros etc).
Snap is proprietary particularly around snapd’s hardcoded dependence on Canonical servers despite being otherwise open source. So it’s not really been embraced by most distros outside the Ubuntu ecosystem, and even then there are Ubuntu derived distros that deliberately remove Snap. Snap does have its strengths in the server space (which Flatpak is not designed ofr), but Docker is the more popular system for this. Snap is still used “widely” in the sense that Ubuntu is widely used and Snap is its default, but outside that ecosystem Docker is much more extensively used (and probably on a lot of Ubuntu servers too). Snap in the desktop set up is also slower than Flatpak due to how it works, which adds to the perception they’re “worse”. Still Snap is convenient in the Ubuntu server space for deploying software.
Flatpak and AppImages aren’t going anywhere. Who knows with Snap; probably not going anywhere?
I fucking love appimages. I dont have any issues with Flatpak. I just like appimages more and i can get them for almost all of my stuff. So idk if flatpaks won. But i also dont care.
I love flatpaks and your attitude
I like both flatpaks and appimages why does everything have to be a victory and defeat
Because it’s nice for devs to have a single package type to build per OS
Yeah, it’s called .deb
Well that’s not gonna work on rpm based distributions now is it
How is that my problem
How is that my problem
Well let’s break it down…
You thought:
Yeah, it’s called .deb
Was an acceptable response to:
Because it’s nice for devs to have a single package type to build per OS
Your problem was your stupidity.
But now your problem is everyone knowing about it.
Why can’t they do that already? Just choose whichever one you want it’s trivial for me to run whichever as a user
Just not snaps.
AppImage and flatpak are fine though
Whats wrong with snaps? My only “issue” with appimages is i tend to leave them in my downloads folder and lose them
The snap store is a shit show of security issues.
Forced migration to snaps.
Performance issues.
Proprietary back end.
Slow to install
Slow to start
Eat up RAM
Eat up disk space
They screw up access to devices.
They automatically update themselves without user confirmation.
Fuck snaps. Fuck Canonical.
My issues with snaps are:
- The server software is closed source and centralized
- They create many block devices that can slow down booting the PC.






