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.
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. 😂
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.
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.
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.
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.
removed by mod
Static binaries, or dynamic binaries whose project has documentation on what dependencies they need, are better than appimages. This is because appimages are a container with the actual files inside, creating a layer of abstraction, and appimages require libfuse to work.
Imagine the case in NixOS, where dynamically-linked binaries don’t work out of the box. You can patch or package these binaries, or just quickly use something like steam-run to emulate traditional Linux bin and lib paths, it works. With appimages, it won’t work unless you already have libfuse in your system, so you have to extract the appimage first.
Still, flatpaks as the only official alternative isn’t great for many reasons, and CLI/TUI programs are out of the equation. What is better is the devs distributing unpackaged binaries, jars, etc, and optionally flatpaks. Either way, Nix’s repository is huge so I don’t usually feel the need to run anything that isn’t a nix package.
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.
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
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.
Totally agree with basically every point here. You hit the nail on the head. App images are the .exe’s of the Linux world and I don’t understand how someone can say they love app images but hate Window’s portable exe’s. Even Windows doesn’t have nearly as many portable executable as they once did. And when they do, most people (even those who prefer app images) prefer an exe with a Windows installer.
Anyways, this is all to point out why I avoid app images if at all possible
As someone who didn’t have a computer and had to install everything on a USB drive at some point, I absolutely LOVE portable .exe’s. Don’t see why anyone would have a problem with it. Don’t see a problem with aopimages either.
I use Appimage this is a tool which make it easy to install Appimage and update it
flatpak?
Frying pan, meet fire.
I do not agree. AppImages can be double clicked and executed. They are not a pain to use. I have a few dozen AppImages besides a few Flatpaks and plenty native packages on Debian. Comfortable setup that carried over from Ubuntu LTS.
This poster advertises GrapheneOS propaganda, and I never take those security weirdos seriously anyway, so either way I do not consider their security arguments as valid. All of these people have a common theme – pushing people towards becoming dependent on them, their “repositories” and apps, forming cults around it and becoming self-approved security gurus and dishing out moronic advice.
If there was a way for these people to be able to rebrand one of the non-native packaging formats, they would shill the fuck out of it, just like GrapheneOS.
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.
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.
Appimages are awesome for the regular user. Single file, just double click to run anywhere. Snap and Flatpak should die a quick death and all the work should be used to improve Appimages. There’s no other concept for the end user as simple and clear as this.
I double clicked, the program didn’t run because it’s missing some dependencies
No it is not. Appimages are bad.
https://youtube.com/watch?v=4WuYGcs0t6I&t=456
Watch that talk. And also read the text I guess. Also comments under other comments.
Appimages are seriously broken
Some of these apps can’t work as flatpaks at all, because they require more access to the system, e.g. Davinci Resolve. AppImage allows that. I mean, heck, even Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives “outside” its sandboxing. So, yes, there are cases where AppImages do serve a purpose. Not most cases, but a lot of cases.
Have a look at GPU screen recorder, I think thats as much privileges as you need.
XDG-desktop portals are not yet complete. But for filesystem access and GPU de/encoding that should already work.
If the Davinci Resolve devs actually cared about Linux…
Have a look at GPU screen recorder, I think thats as much privileges as you need.
XDG-desktop portals are not yet complete. But for filesystem access and GPU de/encoding that should already work.
If the Davinci Resolve devs actually cared about Linux… I think the best way to run it is using uBlues image on Podman.
Are these access problems not solvable with XDG portals?
By the way, if you guys are interested here is a talk comparing Appimages Snaps and Flatpaks by Richard Brown, one the devs at Suse, a big contributer to openSuse and the guy who spearheaded the Desktop variante of MicroOS (the immutable openSuse Tumbleweed).
He isn’t to keen on appimages either because of a miriad of technical issues.
youtube.com/watch?v=4WuYGcs0t6I&t=456
For all the Grayjay/Newpipe/Freetube users
Very good video with additional points, will add them
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.
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.
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.
Thats flatpak with flathub. Also described in the post
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”.
Odd, this random github rant didn’t seem to sway my opinion.
To hell with user choice, only flatpak
It’s thanks to user choice that we aren’t all stuck on proprietary operating systems, so saying that isn’t great.
