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?
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.
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.
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.
It is very unfortunate. It’s fine to point out problems, but then when you become part of the problem, that’s not amazing.
He’s had the same meltdown with fuse2 being deprecated in favor of fuse3 which, guess what, also broke AppImage and we had a huge rant for that too.
Flatpak has a better chance of being forward compatible for the foreseeable future. Linux generally isn’t a very ABI/API compatible platform because for the most part you’re expected to be able to patch and recompile whatever you might want.
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 👉😎👉
Edit: someone DMed me and took this comment seriously. Bless ur heart
I hate all three. Why do we need to the same dependencies in a thousand different places? There’s gotta be something better between typical software repos and these stupid packed applications.
Aah yes, appimage, flatpak, snaps, progressive web apps, electron apps… The cross-compatibility of the lazy 21st century developer, where a simple IRC-like chat client comes with an entire operating system or an entire browser (which itself is an entire operating system too nowadays), takes up half a gig of disk space, and starts up in over 10 seconds with a multi-gigahertz multicore CPU.
It’s been that way since the dawn of computing. Developers will push hardware to its limits and the hardware people will keep making a faster chip. A lot of software was laggy as hell back in the day. Not to mention, it didn’t have any features compared to the stuff now. Plus our shit would crash all the time and take down the whole PC. Sure, you run across some shockingly fast and good apps but those have always been few and far between.
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.
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.
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.
Except Western imperialist countries have exploited hundreds of trillions of dollars from rest of the world, kept them subjugated for centuries, causing these luxurious software development cultures to not formulate in them. You are falsely equating software and politics being affected similarly and to a similar degree.
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
Interesting read, love stuff like this but it seems they’d be a lot of dev overhead to truly make something large and agnostic but still gotta commend it!
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.
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.exe paradigm (or update.sh in Linux).
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.
What do you mean by AppImage permissions? A sandboxing feature like “access only those directories, those /dev devices, …”
EDIT: obviously this isn’t just for AppImage, but I tested it with AppImage and it work well. Another tip: if you want a package manager for managing AppImage installations try zap (github.com/srevinsaju/zap)
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.
This may be a little bias but this is my understanding:
Flatpaks were the solution for reducing the duplication in Appimages and providing an automated way to do security updates. Flatpak got a chance to learn from Snap.
Snaps are basically a proprietary approach to creating and distributing Appimages that were created prior to the current Appimage tooling. They got to learn from the first generation of Appimages and decided to deviate from them early on.
Appimages were a stupid simple approach to a complex issue. Initial tooling was rough though and a lot of people, while they liked the idea, hated the requirements. Basically setting up an Ubuntu 18.04 environment for packaging was the only way to guarantee a truly portable image.
It left room for improvement and so decisions were made to try and fill that room. They were never bad, and devs weren’t really trying to do anything other than simplify the creation and distribution of existing Appimage functionality.
I still think flatpaks are the closest to the ideal solution but again, I’m biased.
IMO Flatpak is the best of them all. I don’t want to bother with repo packages that have complete and unnecessary access to my system. Flatpak neatly installs an app and isolates it, and if I no longer want it I can just easily click “Uninstall” on my Settings app without it leaving a mess or any trace behind, unlike repo packages that manage to screw something as simple as uninstalling itself.
Add comment