7 ms·

I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn'

I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard. As a user I want to download the thing and run it. AppImages provide that. As an app developer I want to create one single package that works everywhere that users can just download. AppImages provide that. Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it. Most software is best installed by the native package manager. For the few exception AppImages are perfects.

red_trumpet 2y ago
What's the update story for AppImages? AFAIU you have to download updates by hand?
- cardanome 2y ago
  Yes. Things that are critical to update regularly should be handled by the package manager. I use AppImages when I want a specific version of a specific app. I never want them to be automatically updated because doing so might introduce breaking changes that might mess with my workflow. Imagine complex software like Blender or Krita updating automatically while you working on a specific project, possibly even breaking your saves, absolute horror.
- freedomben 2y ago
  There aren't centralized solutions that I know of, but there are projects such as AppImageLauncher[1] that can provide some automated management of that. It's not perfect but it is helpful. [1]: https://github.com/TheAssassin/AppImageLauncher https://github.com/TheAssassin/AppImageLauncher
- c-hendricks 2y ago
  Updating app images are solved if a few ways: https://docs.appimage.org/packaging-guide/optional/updates.html#making-appimages-self-updateable https://docs.appimage.org/packaging-guide/optional/updates.h...
- contrarian1234 2y ago
  My Arduino AppImage self-updates - so I know it's possible
triblemaster 2y ago
I disagree with you in that, only system software should be installed by the native package manager. Everything else should be AppImages.
- marcosdumay 2y ago
  What is "system software"?
  - vundercind 2y ago
    The stuff that gets your desktop started up into a usable state. Same as on any OS, macOS or Windows. The software that is expected to be there on a given version of the OS, that other software may depend on being at some particular (major, at least) version until there’s a new version of the OS. The stuff that updates when you update the OS. On macOS, the software that’s not an optional package manageable through the App Store (even if installed by default) or managed by Homebrew or what have you. You know, the system software.
    - AshamedCaptain 2y ago
      This is a distinction that should NOT exist. Like on phones, you end up with "software" that is just a glorified web browser and doesn't integrate with the rest of your system nor cannot access your hardware to its full extent. I.e. If I want to set up a script that makes Libreoffice trigger phone calls through a bluetooth modem, I should be able to. Otherwise it isn't really a computer. These "system" vs "non-system" almost always end up down this slippery slipe, and avoiding it is one of the reasons I enjoy desktop Linux for all its brokenness.
      - vundercind 2y ago
        It’s very nice when it exists because you can do whatever you need with user-facing software without risking system stability. Long-term stable versions of basic software, including gui libs, also provides a reliable target for software deployment.
throwaway38405 2y ago
The Linux community is self-selected and highly opinionated on everything. Concerning AppImages: I have no interest at all in them and although Flatpak still has its share of problems, basically all important communities adopted it (but Ubuntu). Flatpak integrates in your system, has sandboxes, has automatic updates, shares dependencies etc. Is Flatpak perfect or running w/o problems? Certainly not. But IMHO AppImages add nothing over Flatpak, but lack the unified infrastructure and integration into packet managers etc. We all would benefit from agreeing on one standard, and by now it looks like Flatpak is that one standard. So, I don't want to download random AppImages from the internet, I want a certified Flatpak which integrates with my system. (Being a member of the Linux community for longer than most people using Linux are alive by now, of course and invetible, once Flatpak is working and established, it will be replaced by some broken other solution. :-P)
freedomben 2y ago
I likewise love AppImages and wish more projects used them, but I also love Flatpak. The downside of Flatpak is the overhead it takes to learn what it does, how it works, and how to manage them. If you already know container stuff like docker/podman then it isn't too bad, but it's a non-zero cost and friction. I think most people don't like AppImages mostly because they don't provide any sandboxing. I think that's a silly reason myself, but I'm also an old, and us olds aren't terrified of using our computers like the youngs seem to be ;-). Though, other OSes are getting sandboxing for applications and Linux needs to not get left behind, so I'm glad it's being solved. I also think fragmentation is a (valid) reason people dislike AppImage also. It's nothing wrong with AppImage specifically, but that its existence harms adoption of Flatpak by making it easy for people to not use Flatpak. Personally I see them occupying different niches. I use App Images for things like Kdenlive, Logseq, Upscayl, and UHK Agent. Those could all be Flatpaks, but developer effort matters. If devs provide an App Image build I think we should be praising them from the rooftops for caring about Linux! Another reason is that it clashes with immutable OSes like Fedora Silverblue or SteamOS that are heavily container-based. What I'd love to see is a tool that takes an App Image and automatically builds it into a Flatpak (possibly with predefined metadata). Flathub could easily be populated this way so that it's easy for developers/distributors to package and ship, but also Flatpak is the standard.
- jwells89 2y ago
  Unpopular opinion maybe, but I think sandboxing and app packaging/distribution should be entirely separate components so the user can mix and match the two freely. Combining both into a single “solution” makes for inconsistency and trouble.
  - yjftsjthsd-h 2y ago
    Flatpak uses bubblewrap, and you can use that separately (directly or through ex. bubblejail).
- Zetaphor 2y ago
  Greetings fellow UHK user, the best keyboard.
giancarlostoro 2y ago
Literally this. One thing both Apple and Windows have that Linux does not is, every software has an easy universal package for their respective platform. For Linux if its even in your main package manager its like whatever was "stable" in 2022 or whenever the last major version of Debian / Ubuntu came out, and that's all you get. It's annoying to no end. I now just download AppImage every chance I get.
- throwaway38405 2y ago
  ... sorry, this sounds to good to be true. Usually it works like this (forced to use macOS at work and Windows from time to time for special software): One installs some software from trusted websites (VSCode, VLC, Firefox, etc.) on macOS/Windows, and then when one just wants to get some work done: Update-PopUps, yay. They annoy the hell out of me, especially because there is no unified system for macOS/Windows. Break my flow, wait for download, privilege escalation, installation and starting again. Thank you very much. This happens multiple times a week especially for packages like VSCode, VLC, Office, Outlook, Firefox, KeepassX, Calibre... packages which you don't want to be outdated, ever. It is f*cking ridiculous that I have to take care of this BS in 2024. On my Linux boxes I login and work. Updates have been silently downloaded and installed for the packages and/or flatpaks and everything is up to date, no annoying update-popups which break my flow and I know that I have the latest version of all software especially security sensitive packages. At the end, you can pick your poison. Having integrated/working package management with silent updates is one of my killer features of Linux/Flatpak. I want to set it up one time (automatically) and never have to think about or deal with it again.
  - _factor 2y ago
    When combined with Flatseal as an easy to use privilege granting system, it really is hard to beat.
- jbstack 2y ago
  Unless something has drastically changed since I switched to Linux around 10 years ago, Windows did not at all have a "universal package". Instead, installing software meant manually downloading an installer from the vendor's website and then manually interacting with that installer through a GUI. Windows installers come in a variety of different (even custom written) formats which essentially make it impossible to automate package management in a universal way.
guilhas 2y ago
Although I like appimages more compared with flatpack and snap I think they are all worse than the other packaging methods With a NixOS configuration I can install almost all software I use in a single command Even in window I mostly use scoop/chocolatey
mid-kid 2y ago
While I'd love to see good tooling for AppImages appear, it's just not made for it. The fundamental problem is that AppImages are literally just an archive with a bunch of files in them, including libraries and other expected system files. These files have to be selected by the developer. It's really hard to tell which libraries can be expected to exist on every distribution, which libraries you can bundle and which ones you absolutely cannot due to dependence on some system component you can't bundle either, or things like mesa/graphics drivers. There's tools to help developers with this, "linuxdeploy" is one, but they're not perfect. Every single AppImage tutorial will tell you: Test the AppImage on every distribution you intend this to run on. At the end of the day, this situation burdens both the developer (have I tested every distribution my users will use? both LTS and non-LTS?) as well as the user (what is this weird error? why isn't it working on my system?), and even if this all somehow works, newer versions of distributions are not guaranteed to work. Flatpak, for all its bells and whistles, at least provides one universal guarantee: Whatever the developer tests, is exactly what the user will experience. I think this is a problem that needed solving for many people. ...it hurts a lot to say this as a longtime flatpak avoider, still always prefer distribution packaging, but I've come to accept that there's a genuine utility to flatpak, if only to cover for letting users test different versions of software easily, and similar situations that distributions just cannot facilitate no matter how fancy their package manager.
- spacebeer 2y ago
  It can also happen for Flatpak not to work on some distros.
threePointFive 2y ago
AppImage is a good distribution format, but IMO is not comparable to your system's package manager or Flatpak for that matter. For starters, when you downloads an AppImage, you are just getting the binary. Documentation, Desktop and Service files, and update tracking are all things that are missing from a vanilla AppImage deployment that your system package manager always provides (Flatpak and Snap only handle some of those sometimes). The missing piece is perhaps some sort of AppImage installer which can be registered as the handler for the AppImage filetype. When ran it could read metadata (packaged as part of the AppImage?) and generate the support files. Ideally would also maintain a database of changes to be rolled back on uninstall and provide a PackageKit or AppStream provider to manage updates with your DE's store. Now none of that addresses dependency duplication, but thats clearly not in scope for AppImage.
- _factor 2y ago
  How big of a problem is dependency duplication on 1TB drives?
  - indrora 2y ago
    The issue is memory. Every library in an app image has a unique memory space and so you have a bunch of copies of sometimes very large libraries sitting in memory rather than one copy from disk mmapped into memory and page duplicated all over the place.
    - eklavya 2y ago
      Linux has had support for not doing duplicate pages for a long time now. I am forgetting the name of the feature but essentially this duplication is a solved problem.
      - e12e 2y ago
        For different minor versions and builds of libraries?
      - 2y ago
eikenberry 2y ago
IMO AppImage fell short by not requiring upgrading support in all appimages. I don't want to have to monitor random sites for updates to my applications. So after trying to use them for a time I moved on. Currently experimenting with both flox and flatpaks as they both handle this aspect reasonably.
hamandcheese 2y ago
Personally I dislike AppImages, Snap, Flatpack, Docker, etc. for one main reason: If an app is so hard to distribute in any other way, that to me is a red flag that the app is not up to my quality standards or otherwise violates my sensibilities in some way. On my Linux desktop, I am very much in the camp of "that which exists without my knowledge exists without my consent". (I fully recognize that I am extreme outlier in general, and perhaps a slight outlier among Linux users. Just offering one perspective, I make no claims that this it the correct perspective for most Linux users.)
- II2II 2y ago
  > If an app is so hard to distribute in any other way, that to me is a red flag that the app is not up to my quality standards or otherwise violates my sensibilities in some way. I have run across the periodic application that violates both my quality standards and sensibilities, yet I find indispensable. An example here is the e-reader software KOReader. It makes zero sense as a desktop application since it is designed to run on dedicated tablets hardware with e-ink screens. It is not packaged by many distributions, likely because few people would be interested in maintaining such a package. So why would I want to use it on a desktop? Because the breadth and depth of features are unmatched. In my case, I am willing to put up with a quirky black and white touch based interface[1] in order to have access to those features on my laptop. So I use the AppImage. While I dislike the mentioned distribution formats for the reasons you mentioned, some software is so wonderful[2] that it's warts should be ignored. [1] It does have keyboard controls. In verifying a couple of details for this post, I also discovered that it can be controlled from a gamepad. Connecting my laptop to a television and sitting back to read a book with only a gamepad in hand is something that I am going to have to try one day. [2] And sometimes that wonderfulness extends beyond features. The lua based portions of KOReader are sufficiently clear that I was able to create a profile for an e-reader (tablet) that is so new to the market that it isn't yet supported in the release version (the e-reader is only about a month old, while release versions of the software come out every four to eight weeks).
  - hamandcheese 2y ago
    Yep, that is super reasonable. I also will use them if that is my only option. So in that sense I guess I'm am thankful they exist, I just don't want them to become to default or even mainstream.
burningChrome 2y ago
>> Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it. After using Ubuntu for years, this change made myself and many others I know switch. I've been on MX for the past two years and love it.
- Eduard 2y ago
  what is MX?
  - burningChrome 2y ago
    MX Linux- https://mxlinux.org/ https://mxlinux.org/
    - Zetaphor 2y ago
      That website conveys very little useful information for understanding what makes this distro unique. I don't know what antiX or Mepis are. Why would I choose this over a more well known and presumably better supported distro?
      - deadbunny 2y ago
        It has more information on the front page about the distro than the debian website has about debian. I guess debian shouldn't be used either. Also antix has a hyperlink which clicking would have answered your question as to what antix is.
okanat 2y ago
> I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard. > As a user I want to download the thing and run it. AppImages provide that. Because Linux userspace libraries aren't designed to handle long term binary compatibility. There is no guarantee that a simple package upgrade or a simple distro version upgrade will not break things. There is no guarantee that an Appimage will continue working 3 months later. If it relies on web communication, there is no guarantee that the application will stay secure since you have to bundle core system libraries like OpenSSL with your application (unlike Windows and MacOS). I will even go and say especially GNU stuff is made specifically to make reasonable (imo at least 5 years) binary only i.e. closed-source software friendly distribution hard. It is the culture adopted by all middle layer libraries and desktop environments too. The only supported form is source and every piece of software in Linux world assumes it is built as a part of an entire distro. That's why Snap and Flatpak actually install a common standardized base distro on top of your distro or why Docker in its current form exists (basically packaging and running entire distro filesystems). Only way to get around it is basically recreating and reengineering the entire Linux userspace as we know it. Nobody wants to do that. Creating long term stable APIs that allow tweaking is very difficult, requires lots of experience in designing complex software. Even then you fail here and there and forced to support multiple legacy APIs. Nobody will do that unless they are both very intelligent and paid well (at the same level as an Apple, Microsoft or Android engineers). It is not fun and rewarding most of the time.
- AshamedCaptain 2y ago
  > That's why Snap and Flatpak actually install a common standardized base distro on top of your distro or why Docker in its current form exists (basically packaging and running entire distro filesystems). And neither method really works for the desktop usecase, because one expects things to actually integrate with the desktop, and that often requires IPC, not just dynamic libraries. So if you bundle an entire filesystem with all libraries you've made things WORSE. Accessibility & I-Bus will break almost guaranteed every other release...
- loup-vaillant 2y ago
Zambyte 2y ago
As a user I don't want to deal with updating all my software individually. AppImages also provide that. I would be perfectly fine with AppImage format packages being shipped through my package manager, but I don't want to download isolated software from the web when I can avoid it. FWIW my package manager of choice is GNU Guix, which solves all of the same problems as snap and flatpak in a much more elegant way.
TwoNineFive 2y ago
> I don't get why Loudly declaring your ignorance is not an opinion. If really cared, you would go look at the large volume of the well-thought-out complaints. But you don't.
alpaca128 2y ago
> As a user I want to download the thing and run it. AppImages provide that. Yes. And no. About 70-80% of AppImages I downloaded in the past didn't even start. 100% of my installed Flatpaks have been running fine on any distro I tried. I would love a world where Flatpak was redundant, but it very clearly isn't.
- jcelerier 2y ago
  I'm curious, could you try this one and tell me if it starts ? so far it works in all the mainstream distros I could try but if there's someone out there who cannot open it with an OS less than a decade old, I want to make sure I can fix that : https://github.com/ossia/score/releases/download/v3.2.0/ossia.score-3.2.0-linux-amd64.AppImage https://github.com/ossia/score/releases/download/v3.2.0/ossi...
anton96 2y ago
>>> Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it. To me that also raises the issue of Snap/Flatpacks and Wayland both handling part of sandboxing/capabilities. Ultimately if you want to handle how your apps can be run and got resort back to lower primitive and you’re handling very different things like files acces(Snap/Flatpacks) and visual elements(Wayland) and maybe got back to the Linux kernel to handle that.
bmicraft 2y ago
AppImages are nice as a user, but it seems the lead dev is intentionally not adding support for wayland (besides some other odd choices) so it feels like a dead end technology
- Gormo 2y ago
  In what way is AppImage interacting with the display server in its own right such that it would need to be specifically updated to support Wayland?
  - bmicraft 2y ago
    I don't know enough about that to tell you something specific
tapoxi 2y ago
AppImages don't solve the discoverability or upgrade problem. I'm on an immutable distribution (Fedora Kinoite) so installing native packages is discouraged. I have everything running in Flatpaks, even Steam and all games. I haven't experienced any performance impact. I think Snaps do something weird with squashfs, but Flatpaks just set up and manage symlinks to dependencies via ostree.
Gormo 2y ago
> I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard. AppImages are good for certain use case. Recreational vehicles are also good for certain use cases. But just as a I don't live in RV parked in my garage when I'm at home, I don't use AppImages as my primary way of running locally-installed software on my main system. > As an app developer I want to create one single package that works everywhere that users can just download. You should just release source tarballs (or static binaries if you're not FOSS), and let the distros do their job of packaging and distributing the software. AppImages are fine to maintain in parallel for specific use cases, but I just want normal software binaries running in the OS environment I've already set up to my liking, not embedded in someone else's encapsulated runtime environment that's inconsistent in dozens of ways from my system config. > Most software is best installed by the native package manager. For the few exception AppImages are perfects. Exactly. But static builds are far superior to AppImage.

red_trumpet 2y ago

What's the update story for AppImages? AFAIU you have to download updates by hand?

cardanome 2y ago
Yes. Things that are critical to update regularly should be handled by the package manager. I use AppImages when I want a specific version of a specific app. I never want them to be automatically updated because doing so might introduce breaking changes that might mess with my workflow. Imagine complex software like Blender or Krita updating automatically while you working on a specific project, possibly even breaking your saves, absolute horror.
freedomben 2y ago
There aren't centralized solutions that I know of, but there are projects such as AppImageLauncher[1] that can provide some automated management of that. It's not perfect but it is helpful. [1]: https://github.com/TheAssassin/AppImageLauncher https://github.com/TheAssassin/AppImageLauncher
c-hendricks 2y ago
Updating app images are solved if a few ways: https://docs.appimage.org/packaging-guide/optional/updates.html#making-appimages-self-updateable https://docs.appimage.org/packaging-guide/optional/updates.h...
contrarian1234 2y ago
My Arduino AppImage self-updates - so I know it's possible

triblemaster 2y ago

I disagree with you in that, only system software should be installed by the native package manager. Everything else should be AppImages.

marcosdumay 2y ago
What is "system software"?
- vundercind 2y ago
  The stuff that gets your desktop started up into a usable state. Same as on any OS, macOS or Windows. The software that is expected to be there on a given version of the OS, that other software may depend on being at some particular (major, at least) version until there’s a new version of the OS. The stuff that updates when you update the OS. On macOS, the software that’s not an optional package manageable through the App Store (even if installed by default) or managed by Homebrew or what have you. You know, the system software.
  - AshamedCaptain 2y ago
    This is a distinction that should NOT exist. Like on phones, you end up with "software" that is just a glorified web browser and doesn't integrate with the rest of your system nor cannot access your hardware to its full extent. I.e. If I want to set up a script that makes Libreoffice trigger phone calls through a bluetooth modem, I should be able to. Otherwise it isn't really a computer. These "system" vs "non-system" almost always end up down this slippery slipe, and avoiding it is one of the reasons I enjoy desktop Linux for all its brokenness.
    - vundercind 2y ago
      It’s very nice when it exists because you can do whatever you need with user-facing software without risking system stability. Long-term stable versions of basic software, including gui libs, also provides a reliable target for software deployment.

throwaway38405 2y ago

The Linux community is self-selected and highly opinionated on everything. Concerning AppImages: I have no interest at all in them and although Flatpak still has its share of problems, basically all important communities adopted it (but Ubuntu). Flatpak integrates in your system, has sandboxes, has automatic updates, shares dependencies etc. Is Flatpak perfect or running w/o problems? Certainly not. But IMHO AppImages add nothing over Flatpak, but lack the unified infrastructure and integration into packet managers etc. We all would benefit from agreeing on one standard, and by now it looks like Flatpak is that one standard. So, I don't want to download random AppImages from the internet, I want a certified Flatpak which integrates with my system. (Being a member of the Linux community for longer than most people using Linux are alive by now, of course and invetible, once Flatpak is working and established, it will be replaced by some broken other solution. :-P)

freedomben 2y ago

I likewise love AppImages and wish more projects used them, but I also love Flatpak. The downside of Flatpak is the overhead it takes to learn what it does, how it works, and how to manage them. If you already know container stuff like docker/podman then it isn't too bad, but it's a non-zero cost and friction. I think most people don't like AppImages mostly because they don't provide any sandboxing. I think that's a silly reason myself, but I'm also an old, and us olds aren't terrified of using our computers like the youngs seem to be ;-). Though, other OSes are getting sandboxing for applications and Linux needs to not get left behind, so I'm glad it's being solved. I also think fragmentation is a (valid) reason people dislike AppImage also. It's nothing wrong with AppImage specifically, but that its existence harms adoption of Flatpak by making it easy for people to not use Flatpak. Personally I see them occupying different niches. I use App Images for things like Kdenlive, Logseq, Upscayl, and UHK Agent. Those could all be Flatpaks, but developer effort matters. If devs provide an App Image build I think we should be praising them from the rooftops for caring about Linux! Another reason is that it clashes with immutable OSes like Fedora Silverblue or SteamOS that are heavily container-based. What I'd love to see is a tool that takes an App Image and automatically builds it into a Flatpak (possibly with predefined metadata). Flathub could easily be populated this way so that it's easy for developers/distributors to package and ship, but also Flatpak is the standard.

jwells89 2y ago
Unpopular opinion maybe, but I think sandboxing and app packaging/distribution should be entirely separate components so the user can mix and match the two freely. Combining both into a single “solution” makes for inconsistency and trouble.
- yjftsjthsd-h 2y ago
  Flatpak uses bubblewrap, and you can use that separately (directly or through ex. bubblejail).
Zetaphor 2y ago
Greetings fellow UHK user, the best keyboard.

giancarlostoro 2y ago

Literally this. One thing both Apple and Windows have that Linux does not is, every software has an easy universal package for their respective platform. For Linux if its even in your main package manager its like whatever was "stable" in 2022 or whenever the last major version of Debian / Ubuntu came out, and that's all you get. It's annoying to no end. I now just download AppImage every chance I get.

throwaway38405 2y ago
... sorry, this sounds to good to be true. Usually it works like this (forced to use macOS at work and Windows from time to time for special software): One installs some software from trusted websites (VSCode, VLC, Firefox, etc.) on macOS/Windows, and then when one just wants to get some work done: Update-PopUps, yay. They annoy the hell out of me, especially because there is no unified system for macOS/Windows. Break my flow, wait for download, privilege escalation, installation and starting again. Thank you very much. This happens multiple times a week especially for packages like VSCode, VLC, Office, Outlook, Firefox, KeepassX, Calibre... packages which you don't want to be outdated, ever. It is f*cking ridiculous that I have to take care of this BS in 2024. On my Linux boxes I login and work. Updates have been silently downloaded and installed for the packages and/or flatpaks and everything is up to date, no annoying update-popups which break my flow and I know that I have the latest version of all software especially security sensitive packages. At the end, you can pick your poison. Having integrated/working package management with silent updates is one of my killer features of Linux/Flatpak. I want to set it up one time (automatically) and never have to think about or deal with it again.
- _factor 2y ago
  When combined with Flatseal as an easy to use privilege granting system, it really is hard to beat.
jbstack 2y ago
Unless something has drastically changed since I switched to Linux around 10 years ago, Windows did not at all have a "universal package". Instead, installing software meant manually downloading an installer from the vendor's website and then manually interacting with that installer through a GUI. Windows installers come in a variety of different (even custom written) formats which essentially make it impossible to automate package management in a universal way.

guilhas 2y ago

Although I like appimages more compared with flatpack and snap I think they are all worse than the other packaging methods With a NixOS configuration I can install almost all software I use in a single command Even in window I mostly use scoop/chocolatey

mid-kid 2y ago

While I'd love to see good tooling for AppImages appear, it's just not made for it. The fundamental problem is that AppImages are literally just an archive with a bunch of files in them, including libraries and other expected system files. These files have to be selected by the developer. It's really hard to tell which libraries can be expected to exist on every distribution, which libraries you can bundle and which ones you absolutely cannot due to dependence on some system component you can't bundle either, or things like mesa/graphics drivers. There's tools to help developers with this, "linuxdeploy" is one, but they're not perfect. Every single AppImage tutorial will tell you: Test the AppImage on every distribution you intend this to run on. At the end of the day, this situation burdens both the developer (have I tested every distribution my users will use? both LTS and non-LTS?) as well as the user (what is this weird error? why isn't it working on my system?), and even if this all somehow works, newer versions of distributions are not guaranteed to work. Flatpak, for all its bells and whistles, at least provides one universal guarantee: Whatever the developer tests, is exactly what the user will experience. I think this is a problem that needed solving for many people. ...it hurts a lot to say this as a longtime flatpak avoider, still always prefer distribution packaging, but I've come to accept that there's a genuine utility to flatpak, if only to cover for letting users test different versions of software easily, and similar situations that distributions just cannot facilitate no matter how fancy their package manager.

spacebeer 2y ago
It can also happen for Flatpak not to work on some distros.

threePointFive 2y ago

AppImage is a good distribution format, but IMO is not comparable to your system's package manager or Flatpak for that matter. For starters, when you downloads an AppImage, you are just getting the binary. Documentation, Desktop and Service files, and update tracking are all things that are missing from a vanilla AppImage deployment that your system package manager always provides (Flatpak and Snap only handle some of those sometimes). The missing piece is perhaps some sort of AppImage installer which can be registered as the handler for the AppImage filetype. When ran it could read metadata (packaged as part of the AppImage?) and generate the support files. Ideally would also maintain a database of changes to be rolled back on uninstall and provide a PackageKit or AppStream provider to manage updates with your DE's store. Now none of that addresses dependency duplication, but thats clearly not in scope for AppImage.

_factor 2y ago
How big of a problem is dependency duplication on 1TB drives?
- indrora 2y ago
  The issue is memory. Every library in an app image has a unique memory space and so you have a bunch of copies of sometimes very large libraries sitting in memory rather than one copy from disk mmapped into memory and page duplicated all over the place.
  - eklavya 2y ago
    Linux has had support for not doing duplicate pages for a long time now. I am forgetting the name of the feature but essentially this duplication is a solved problem.
    - e12e 2y ago
      For different minor versions and builds of libraries?
    - 2y ago

eikenberry 2y ago

IMO AppImage fell short by not requiring upgrading support in all appimages. I don't want to have to monitor random sites for updates to my applications. So after trying to use them for a time I moved on. Currently experimenting with both flox and flatpaks as they both handle this aspect reasonably.

hamandcheese 2y ago

Personally I dislike AppImages, Snap, Flatpack, Docker, etc. for one main reason: If an app is so hard to distribute in any other way, that to me is a red flag that the app is not up to my quality standards or otherwise violates my sensibilities in some way. On my Linux desktop, I am very much in the camp of "that which exists without my knowledge exists without my consent". (I fully recognize that I am extreme outlier in general, and perhaps a slight outlier among Linux users. Just offering one perspective, I make no claims that this it the correct perspective for most Linux users.)

II2II 2y ago
> If an app is so hard to distribute in any other way, that to me is a red flag that the app is not up to my quality standards or otherwise violates my sensibilities in some way. I have run across the periodic application that violates both my quality standards and sensibilities, yet I find indispensable. An example here is the e-reader software KOReader. It makes zero sense as a desktop application since it is designed to run on dedicated tablets hardware with e-ink screens. It is not packaged by many distributions, likely because few people would be interested in maintaining such a package. So why would I want to use it on a desktop? Because the breadth and depth of features are unmatched. In my case, I am willing to put up with a quirky black and white touch based interface[1] in order to have access to those features on my laptop. So I use the AppImage. While I dislike the mentioned distribution formats for the reasons you mentioned, some software is so wonderful[2] that it's warts should be ignored. [1] It does have keyboard controls. In verifying a couple of details for this post, I also discovered that it can be controlled from a gamepad. Connecting my laptop to a television and sitting back to read a book with only a gamepad in hand is something that I am going to have to try one day. [2] And sometimes that wonderfulness extends beyond features. The lua based portions of KOReader are sufficiently clear that I was able to create a profile for an e-reader (tablet) that is so new to the market that it isn't yet supported in the release version (the e-reader is only about a month old, while release versions of the software come out every four to eight weeks).
- hamandcheese 2y ago
  Yep, that is super reasonable. I also will use them if that is my only option. So in that sense I guess I'm am thankful they exist, I just don't want them to become to default or even mainstream.

burningChrome 2y ago

>> Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it. After using Ubuntu for years, this change made myself and many others I know switch. I've been on MX for the past two years and love it.

Eduard 2y ago
what is MX?
- burningChrome 2y ago
  MX Linux- https://mxlinux.org/ https://mxlinux.org/
  - Zetaphor 2y ago
    That website conveys very little useful information for understanding what makes this distro unique. I don't know what antiX or Mepis are. Why would I choose this over a more well known and presumably better supported distro?
    - deadbunny 2y ago
      It has more information on the front page about the distro than the debian website has about debian. I guess debian shouldn't be used either. Also antix has a hyperlink which clicking would have answered your question as to what antix is.

okanat 2y ago

> I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard. > As a user I want to download the thing and run it. AppImages provide that. Because Linux userspace libraries aren't designed to handle long term binary compatibility. There is no guarantee that a simple package upgrade or a simple distro version upgrade will not break things. There is no guarantee that an Appimage will continue working 3 months later. If it relies on web communication, there is no guarantee that the application will stay secure since you have to bundle core system libraries like OpenSSL with your application (unlike Windows and MacOS). I will even go and say especially GNU stuff is made specifically to make reasonable (imo at least 5 years) binary only i.e. closed-source software friendly distribution hard. It is the culture adopted by all middle layer libraries and desktop environments too. The only supported form is source and every piece of software in Linux world assumes it is built as a part of an entire distro. That's why Snap and Flatpak actually install a common standardized base distro on top of your distro or why Docker in its current form exists (basically packaging and running entire distro filesystems). Only way to get around it is basically recreating and reengineering the entire Linux userspace as we know it. Nobody wants to do that. Creating long term stable APIs that allow tweaking is very difficult, requires lots of experience in designing complex software. Even then you fail here and there and forced to support multiple legacy APIs. Nobody will do that unless they are both very intelligent and paid well (at the same level as an Apple, Microsoft or Android engineers). It is not fun and rewarding most of the time.

AshamedCaptain 2y ago
> That's why Snap and Flatpak actually install a common standardized base distro on top of your distro or why Docker in its current form exists (basically packaging and running entire distro filesystems). And neither method really works for the desktop usecase, because one expects things to actually integrate with the desktop, and that often requires IPC, not just dynamic libraries. So if you bundle an entire filesystem with all libraries you've made things WORSE. Accessibility & I-Bus will break almost guaranteed every other release...
loup-vaillant 2y ago

Zambyte 2y ago

As a user I don't want to deal with updating all my software individually. AppImages also provide that. I would be perfectly fine with AppImage format packages being shipped through my package manager, but I don't want to download isolated software from the web when I can avoid it. FWIW my package manager of choice is GNU Guix, which solves all of the same problems as snap and flatpak in a much more elegant way.

TwoNineFive 2y ago

> I don't get why Loudly declaring your ignorance is not an opinion. If really cared, you would go look at the large volume of the well-thought-out complaints. But you don't.

alpaca128 2y ago

> As a user I want to download the thing and run it. AppImages provide that. Yes. And no. About 70-80% of AppImages I downloaded in the past didn't even start. 100% of my installed Flatpaks have been running fine on any distro I tried. I would love a world where Flatpak was redundant, but it very clearly isn't.

jcelerier 2y ago
I'm curious, could you try this one and tell me if it starts ? so far it works in all the mainstream distros I could try but if there's someone out there who cannot open it with an OS less than a decade old, I want to make sure I can fix that : https://github.com/ossia/score/releases/download/v3.2.0/ossia.score-3.2.0-linux-amd64.AppImage https://github.com/ossia/score/releases/download/v3.2.0/ossi...

anton96 2y ago

>>> Snap and Flatpacks are solving problems that don't need solving for most people. Shitty sandboxing that doesn't even work and makes my app slower? I don't want it. To me that also raises the issue of Snap/Flatpacks and Wayland both handling part of sandboxing/capabilities. Ultimately if you want to handle how your apps can be run and got resort back to lower primitive and you’re handling very different things like files acces(Snap/Flatpacks) and visual elements(Wayland) and maybe got back to the Linux kernel to handle that.

bmicraft 2y ago

AppImages are nice as a user, but it seems the lead dev is intentionally not adding support for wayland (besides some other odd choices) so it feels like a dead end technology

Gormo 2y ago
In what way is AppImage interacting with the display server in its own right such that it would need to be specifically updated to support Wayland?
- bmicraft 2y ago
  I don't know enough about that to tell you something specific

tapoxi 2y ago

AppImages don't solve the discoverability or upgrade problem. I'm on an immutable distribution (Fedora Kinoite) so installing native packages is discouraged. I have everything running in Flatpaks, even Steam and all games. I haven't experienced any performance impact. I think Snaps do something weird with squashfs, but Flatpaks just set up and manage symlinks to dependencies via ostree.

Gormo 2y ago

> I don't get why parts of the Linux community are so resistant to embrace AppImages and provide first class integration for them. Decent desktop integration isn't that hard. AppImages are good for certain use case. Recreational vehicles are also good for certain use cases. But just as a I don't live in RV parked in my garage when I'm at home, I don't use AppImages as my primary way of running locally-installed software on my main system. > As an app developer I want to create one single package that works everywhere that users can just download. You should just release source tarballs (or static binaries if you're not FOSS), and let the distros do their job of packaging and distributing the software. AppImages are fine to maintain in parallel for specific use cases, but I just want normal software binaries running in the OS environment I've already set up to my liking, not embedded in someone else's encapsulated runtime environment that's inconsistent in dozens of ways from my system config. > Most software is best installed by the native package manager. For the few exception AppImages are perfects. Exactly. But static builds are far superior to AppImage.