Appimage for me ticks all the boxes for cross distro package as its very portable, simple to run, what are devs trying to do when creating snaps and flatpack?
Software deployment that tackles dependency hell in a secure fashion while providing, repeatable, atomic updates and rollback.
AppImage doesn’t even provide a proper update system.
Can you elaborate on update system? AppImage is just a format, right? Whereas flatpak is a format and an entire toolkit for downloading and running flatpaks.
You already said it. Flatpak and Snap both include an entire system around updates and rollback which provide some pretty strong guarantees for update success. AppImage does not. It’s got some libs available that an individual developer could use to implement their own update mechanism but isn’t a built-in. And besides, without a system-level component that manages install/update/rollback, you can’t have any guarantees about the update process. You’re back to the Windows-world per-app
update.exeparadigm (orupdate.shin Linux).
There’s software for that. Honestly, i prefer that over the ‘whole package or nothing’ approach in Flatpack, which still has ~/.var for packages hardcoded btw.
Just download .exes for windows and run them with WINE. Don’t have a single snap or flatpack application. If it doesn’t run then u didn’t need it in the first place 👉😎👉
You should quit in “satire”
No
Calm down ok
🤣
Distro packages and to some extent Flatpaks, use shared libraries which can be updated independently of your app.
So for example, if a vulnerability is discovered in say, curl, or imagemagick, ffmpeg or whatever library an app is using: for AppImages, this won’t be fixed until you update all of your AppImages. In Flatpak, it usually can be updated as part of a dependency, or distributed as a rebuild and update of the Flatpak. With distro packages, you can usually update the library itself and be done with it already.
AppImages are convenient for the user in that you can easily store them, move them, keep old versions around forever easily. It still doesn’t guarantee it’ll still run in distros a couple years for now, it guarantees that a given version will forever be vulnerable if any of its dependencies are because they’re bundled in, it makes packages that are much much bigger than they need to be, and you have to unpack/repack them if you need library shims.
Different kinds of tradeoffs and goals, essentially. Flatpak happens to be a compromise a lot of people agree on as it provides a set of distro-agnostic libraries while also not shifting the burden entirely onto the app developers. The AppImage developer is intentionally keeping Wayland broken on AppImage because he hates it and wants to fulfil his narrative that Wayland is a broken mess that won’t ever work, while Flatpak developers work hard on sandboxing and security and granular permission systems.
openSUSE’s Richard Brown has given multiple talks over the years comparing these three. I’d suggest anyone to look at those for a great rundown on how these universal package managers compare to one another. His most recent talk can be found here; in which he actually does some kind of recap as well.
My problem with all three is that trust, security, quality comes from package to package. There is no standard, and packages are isolated from each other. If there is an issue between multiple apps, developers just start pointing at each other. With distro like opensuse I know everything is tested properly including security bug coverage and package interoperability. I can even check it myself at openqa.opensuse.org
With flatpaks I am at mercy of each developer not being lazy and well informed about all current issues.
- ruins single source of truth over installed state
- thus kills validation and thus consistency and thus repeatability (the holy trifecta of release management)
- promotes dependency hell
- promotes redundant installs
- ‘hides’ installs from enterprise management (eg snmp)
- you will fail the audit
But other than being redundant and risky, totally cool.
Flatpaks have the concept of runtimes; instead of downloading the entire qt tooling for a qt app the app could just use the KDE runtime same goes for GTK with the Gnome runtime. Flatpaks also have dependencies which can be shared between multiple apps even when they are not part of their runtimes, they are called “baseapps”. Flatpak apps still use double the space my normal apps take on a fresh install, so I assume using appimages to replace them will leave no space on my SSD.
Before deciding to settle on using Flatpak I tried to search for appimage permissions and how to set them, but it seems there is no such thing? If that’s true then there’s another advantage for Flatpaks and Snaps.
Also with all due respect: Flatpak and Snap tooling are not maintained by Probonodb.
But where to get the AppImages from? Who’s maintaining? How to do Security Vulnerality Tracking for them?
Usually projects on github. Personally I use Appimages for things like Mypaint a digital drawing application, krita and most other KDE applications as to avoid all the dependency’s KDE has in its eco system or at least to put them somewhere easier to manage
Flatpak provides updates, management tools, an ecosystem of common components that don’t need to be repackaged with every executable, dependency management, cleaning up unused dependencies, warnings when you are using obsolete packages, and so on
My problem with appimage is that they never work. Every time I tried one, best case scenario it crashed with a random error message. All attempts to fix them were damn near impossible to debug.
It honestly felt like they were not universal enough and still relied on certain libraries being available on OS. Hopefully I’m wrong because that would completely defeat their purpose. I stopped wasting time on them after Plex and VLC both failed to run reliably and switched to flatpak that “just works” 100% of the time.
To be honest most of the time I look for an rpm anyway. Flatpaks are always a last resort. I’m on OpenSuse Tumbleweed.
This was my experience as well as a developer trying to package an application as an appimage. Creating an appimage that works on your machine is easy. Creating one that actually works on other distros can be damn near impossible unless everything is statically linked and self contained in the first place. In contrast, flatpak’s developer experience is much easier and if it runs, you can be pretty sure it runs elsewhere as well.
Appimages do not have repositories, unlike Flatpaks and Snaps. It’s harder to install or update them since there isn’t a package manager for the Appimages.
I don’t know about Snaps, but Flatpaks are sandboxed, which basically means more security, since apps won’t get access to your system without permission. It’s kind of like Android where apps have to ask for permission to things like camera access, filesystem access, etc.
While I do use Appimages, they remind me of Windows and having to go to websites to download stuff.
Personally, I prefer just installing software with my distro’s package manager and resort to Flatpaks or Appimages when it’s not available in the repos.
what are devs trying to do when creating snaps and flatpack?
Appimages are great for what they do. They’d be even better if we had convenient means of distribution. It’s easy for an intermediate-to-advanced user to go find the thing on some website, download it then
chmod +xit.A regular user, in contrast, finds comfort in centralized software repositories, where you only have to enter an app’s name and click install. Gnome and KDE, with the help of Appstream, provide Flatpaks for your convenience through Software and Discover, respectively.
It’s worth mentioning that Alexander Larsson (Flatpak) took some inspiration from Simon Peter’s (Appimage) klik when he was developing the precursor to xdg-apps and Flatpak, glick… What a mouthful :) Cheers!
Can confirm. I like Flathub.
Here is a revolutionising idea. Hear me out.
Use anything you want, because all of them are safe and speedy.
Flatpaks allow packaging together all dependencies with specific versions with the package. Snaps take it to the next level by allowing to run system integrated sandboxed programs, because Flatpaks cannot have system integration. Appimages are simply the equivalent of portable USB software on Windows.
Use anything you want
This is literally never helpful advice.
Far more helpful than creating religious cults around software tools.
There is no “religious cult”. Just users who want a better experience.
That is not how it works though, because I have been a part of these religious cults for basically forever. The hobbyist enthusiasm has a threshold, the cultism does not. It is animalistic nature to form and live as tribes. It does not become different just because the congregation tool is virtual instead of real.
It is in human nature to keep improving the state of things.
Hard disagree there. Look to capitalism
Capitalism is not human nature. It is formulated around abuse of human psychology. The documentary Century Of The Self by Adam Curtis will be something you love.
I still prefer to run everything built directly from reliable deb sources.
As an end user… sure, flatpaks and appimages and snaps are I guess neat if you are constantly distro hopping or something, at least in theory.
But uh, I have already found the ability to play games, develop games and other software, use basic daily software for everyday needs, and have a stable and predictable OS that doesnt crash or have insane misconfigurations caused by some esoteric conflict by just basing everything directly off of deb sources.
Every once in a while I will have to compile my own build, but this is rare and usually only occurs when trying out something experimental, or, also rare, something that doesnt have an actively and well maintained deb source. In that case its just a matter of doing a build from github when a new version comes out.
And I can do builds from github because I have saved a lot of storage space from not using bundled installers for all my software, allowing me to store the sources. This is also neat because it allows me to quickly /use/ one of those sources in a project, after I have already seen that it is stable via the software I use that is built on it.
Finally there is the security angle. Using a myriad of different containerized installers for everything is convenient in that you don’t have to directly worry about source management… until you do, when a source lib is discovered to have a critical flaw.
When a serious flaw is found in a source library… what’s gonna get updated faster? A containerized installer that you have to wait for the devs, who are busy managing tons of cross platform dependency issues and have to do a new safe stable build everytime any of their many dependencies for their many supported platforms? Or an app specifically built from source libs that either doesnt focus on cross platform, or has different teams specific to maintaining its different supported flavors?
In my experience, literally all of the time, the ‘direct from source’ software gets updated more quickly than the cross platform bundled installer.
Further, this whole approach here gives you experience with software that is built on source packages that, as you become more familiar with, and tinker with yourself, gives you insight into what source libs are well coded in terms of cpu/gpu/ram optimization, and which are resource hogs and should be avoided if youre interested in promoting and using software built off of efficient code. I enjoy learning from the good coding techniques of stable, lean and fast programs, and avoiding code that is comparatively unstable, boated, or slow.
AppImages suck because I can’t pin them to my dashboard, can’t set them to open at startup and can’t set them as default apps for the appropriate filetypes.
I like appimages because I can install them where I want and you can just make a symlink in the bin folder.
You can’t install them at all
I think AppImages suck as well, but this is not a reason for my dislike. A simple script that you can run on startup will fix that problem.
Okay well. I don’t have a script. I just use a computer.
If I need a script to make it work properly, it sucks.
You realize your computer won’t work without scripts, don’t you? And if you want your computer to do something it doesn’t do on its own, a simple script will make it do what you want. If that is your definition of sucking, then you need to go back to Windows, which is also loaded with scripts, by the way, so that sucks too.
You realize your computer won’t work without scripts, don’t you?
No, I don’t. In fact every Windows, Android or Mac computer I’ve used in my entire life works perfectly fine without manually running any scripts at all.
Use appimagelauncher Application that will add appimages to application menu
Use Gear Lever.
No.
Care to elaborate?
I don’t know what it is and don’t care. I’m tired of jumping through hoops just to install the software I need.
