6 ms·

Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you dow

Neither are snaps. The future, for regular daily use, are appimages. Much like MacOS dmgs, these are a "single" file (from an end user perspective) that you download, double click, and run. That's it. Ideally we'd see more work in this area. I am slowly trying to figure out how to automate builds for GUI apps and I am considering somehow settings up an inexpensive server to pull, package, and submit appimages to appimagehub. A crowdsourced effort would be cool. Imagine a distro where by default if you place apps in ~/Applications you can just execute them. Comes with risks, but having them "signed" by appimage a lot of it would be mitigated. Linux, while excellent as a desktop, and I am referring to the many awesome distros available, is really user friendly. Let's make it even more user friendly.

jeroenhd 3y ago
AppImages waste even more disk space. At least with Flatpak I only need to install libraries once, with AppImages I'm getting a second copy of everything with every application I download. If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.
- gumballindie 3y ago
  Technically speaking appimages are compressed files so maybe someone clever can come up with an idea on how to dedupe them. With mass adoption this issue i think may be solved by someone concerned about disk space. Personally, and probably many casual users, are not as worried about space as they are about convenience. But I think your point is valid, and I think this would make an interesting side project for someone out there. For me, I'd like to see more adoption. The nice to haves will follow.
  - tomrod 3y ago
    Something like docker's layers?
    - entropicdrifter 3y ago
      At that point you're re-inventing Flatpak, to a large degree
- mcpackieh 3y ago
  Optimizing for disk space in 2023 seems misguided at best, all computers come with hundreds of GB at least, often one TB or more. Most people never fill these unless they download media, and people who download media have additional hard drives anyway. Ease of use, RAM usage, startup time and security should all rank higher than disk space.
  - rpgbr 3y ago
    Until a few years ago Apple was shipping new Macs with 120 GB. Probably same was (is?) happening with Windows vendors. TB-level disk space isn’t ubiquitous yet.
    - mcpackieh 3y ago
      Okay but how much dedupable dependencies does the average AppImage user have across his programs? A few hundred megabytes? A few gigabytes at most? Even 120 GB is big compared to this problem.
    - gumballindie 3y ago
      The difference between apple products and non apple products is that you can easily upgrade them. My core i9 laptop (a cpu that easily competes with anything apple can offer, so it should be fine for heavy workloads, albeit at bateryy cost), has 5600 mhz ram speed, 7 gb / s dual nvme support, both of which upgradeable. Most folks i know with non mac laptops can at least upgrade their hard drives and often ram. Disk space and ram not an issue for non apple users. TB disk level is absolutely feasible outside that platform. You can buy 2TB nvmes capable of 5 gb / s for less than 100$ easily.
  - JohnFen 3y ago
    > all computers come with hundreds of GB at least There's a whole range of tiny/small computers that run Linux and that absolutely don't have hundreds of GBs of storage space.
  - jeroenhd 3y ago
    I'm not going through the effort to upgrade my 250GB system SSD because a random podcast app can't figure out how to distribute a binary without shipping half an OS. Most people aren't going to upgrade their storage at all. We're talking about Linux users here, not your run-of-the-mill generic end user. If you download an AppImage, you're most likely an advanced computer user. Maybe you don't download media yourself, but you'll probably have huge node_modules/cargo/venv/maven directories slowly clogging up your drive. AppImages aren't easy to use (you can't double click them like on Windows and they all have to provide a mechanisms of their own to register a shortcut in the system menu), their startup time is affected by the compression tying all the files together, the security is no better than any other application (worse, in fact, because when I update my system's openssl client I'll still need to wait for every AppImage program to publish a security update with the patches included, which usually takes months or longer). I don't know about RAM usage, but the duplicate libraries being loaded by the executables will cause at least a few megabytes of unnecessary RAM usage. AppImage is mostly there to help the developer spread the software. The benefit for the user is "at least there's something I can run, I guess".
- ibejoeb 3y ago
  I'm not familiar with details of any of these packaging formats. Are they all single-file? Is there any technical reason they couldn't be unpacked to allow the fs to deal with the deduping?
  - jeroenhd 3y ago
    AppImage is basically a runnable .zip file. It contains a loader and an application with all of its dependencies, packed into a single file. If the image was uncompressed, basic extent-based deduplication could save space, but as far as I know the compressed AppImages just don't match up the files like that. I don't believe Snap natively offers any deduplication. Snap also uses compression (squashfs as far as I can tell) so deduplicating filesystems are equally powerless. Flatpak has its own deduplication system (that will confuse df/du if you try to run it and often leads to confusion about download time). Through tools like https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ you can check how effective the dedup process on Flatpak is. On my machine, Flatpak is using 10.5GB of disk space, but reports 13.75GB of files. Running duperemove on /var/lib/flatpak found two identical extents (belonging to cached files) that didn't get deduplicated already. As for why they couldn't be unpacked: I don't know. They'd take up more disk space, I suppose. Many standard Linux file systems don't have any form of deduplication mechanism built in, so I'm not sure what the balance would be. I would appreciate the ability to decompress AppImages/snaps without writing custom wrappers for them, but if you're on ext4 like many (most?) Linux users, you'll only see the downsides.
- gnulinux 3y ago
  As far as I'm concerned this is a good thing. I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y. In the last 2 decades I used linux I had this issue so many countless times that as far as I'm concerned nix-style, or AppImage-style "waste space" solution is strictly speaking better. Sick and tired of this "upgraded MuseScore3 to MuseScore4, so now Ardour is broken" insanity, this is not how software is supposed to work. I want each package to have its own dependencies, period.
  - gumballindie 3y ago
    Ah yes, that too. I dread the moment i mess up dependencies. I just want the app to run. I don't care about whatever libs.
  - jeroenhd 3y ago
    Linux has definitely come up with the worst solution to DLL hell, but Flatpak solves this problem neatly without dumping huge files all over my disk (and without making me manually create shortcuts for them). It also solves the update problem much better (update applications all at once rather than open them one by one and waiting for the "there's an update, click here to download" popup to show up). I generally stick to the distro repos exactly because external software is a pain to run, with Flatpak as a fallback for applications not packaged in any repo. More and more third party applications are being compiled statically, though, which has solved a lot of issues for me when it comes to these externally managed programs (though it also causes annoying security issues).
  - akvadrako 3y ago
    Flatpak doesn't have that problem. Each app specifies the exact versions of runtime libraries it wants and files are de-duplicated.
  - pizza234 3y ago
    > I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y This is not "Linux", it's users who mess around with (and ultimately break) dependencies in order to get the latest version of programs at any cost. If one uses, say, an Ubuntu version and 3rd party repositories for that version only, they're not going to get any dependency issue, since all the programs will share the same library versions (dependency bugs do happen once in a long while, but they're rare, and they're exceptions).
cookiengineer 3y ago
While I love bleeding edge packages, normal users don't want to have to deal with compilation workflows and they expect software to work a year after it has been installed. To name an example: steam is a nightmare, even though they try their best to host and ship as many libraries from ubuntu as possible. The experience with botched steam installations shifted my perspective a bit, and I think for these desktop use cases, especially of proprietary software, AppImages are the way to go. It's the easiest way to guarantee behavior and stability of software, while not putting the virtualization burden upon the end users.
- gumballindie 3y ago
  Exactly. Download an app, double click it, enjoy it. Life's too short for faffing around with package managers and their idiosyncrasies :-)
PurpleRamen 3y ago
Do appimages have a proper well maintained store now with a good cli for maintaining them? When I last year moved to portable Apps, I check out flatpak, appimages and snap, and move to flatpak, and some appimages. But while flatpaks are easy to maintain, the appimages are basically dead weight. Some can be updated, some not. There were a number of different tools for maintaining them, not one-for-all. Similar there were multiple stores/sites for finding new appimages, not seem particular trustable. It was not very impressive at the time.
- gumballindie 3y ago
  Currently, and that's an issue I've also encountered, there are apps on appimagehub.com. Which is why I am hoping more effort will be put in populating it. But i don't think it should have a cli package manager, i think it should be gui based, and focused on convenience. I don't think it should replace apt, yum or pacman. Just a new way of managing packages that is focused on convenience. And perhaps a convention that in a distro if you download any apps to ~/Applications then these will be auto updated provided they are sourced from an "app store". Trust can be fixed with a set of built in security certificates as apt does, but in a basic, low maintenance good enough fashion. When I switch to casual user mode, or even for daily work, good enough is ok as long as its super convenient.
lairv 3y ago
I've encountered appimages a few time and wasn't really convinced. Maybe I'm missing something but here's what I found annoying: - need to move the x.appimage somewhere in your $PATH - need to create an alias like nvim.appimage -> nvim - no way to automatically update - the application isn't listed in your application list on ubuntu On the other hand `sudo snap install nvim --classic` brings me all of the above without any work from me
- dcow 3y ago
  These are entirely solvable problems, at least. Just sounds like the UX isn’t there yet.
- JustinGarrison 3y ago
  Snap and flatpak run a daemon to integrate into your system. Appimage has an optional daemon to give you the same integration https://github.com/probonopd/go-appimage https://github.com/probonopd/go-appimage Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list. Only other thing you might want to do is symlink a friendly name for cli
butz 3y ago
AppImages sounds good on paper, but when you download one, get library errors and there's nothing you can do about it, you start thinking that Flatpak with its runtimes was not so bad idea after all.
- gumballindie 3y ago
  The question is which method is more prone to issues. Perhaps a QA process of sorts could be builtin to the "app store" to at least be able to boot the app without errors? Also I am not saying flatpaks or apt should go away. Just saying that it would be nice to have a realiable way to download a package and run it, no hassle.
arrakeen 3y ago
i completely agree. for me, the only issues i've had with appimages are "housekeeping" UX: * i know they can technically be updated but i really have no idea how. would be cool to see a de-facto solution similar to sparkle[0] on mac * i use appimagelauncher[1] to integrate with my menus etc but sometimes it works and sometimes it doesn't? i haven't really figured out the rhyme or reason [0] https://sparkle-project.org/ https://sparkle-project.org/ [1] https://github.com/TheAssassin/AppImageLauncher https://github.com/TheAssassin/AppImageLauncher
kvdveer 3y ago
I feel appImage is missing metadata. I'd be great when the user downloads an appImage, it is automatically linked to the mime types is can handle, shows up in relevant menus, and can properly register itself to any services it needs (e.g. Cron). It could also do with an update mechanism.
david2ndaccount 3y ago
This works for MacOS because there are system frameworks you can rely on being installed (like AppKit) and that actually have backwards-compatibility (at least for a while). Linux distros don’t have this (not even for glibc), so you’d have to literally everything in your app image folder. Every GUI app bundling QT or other gui framework would be a ridiculous waste of space.

jeroenhd 3y ago

AppImages waste even more disk space. At least with Flatpak I only need to install libraries once, with AppImages I'm getting a second copy of everything with every application I download. If AppImages were actually directories, like they are in macOS, I could at least run duperemove to fix the disk space issue on BTRFS, but with full images that become a lot harder.

gumballindie 3y ago
Technically speaking appimages are compressed files so maybe someone clever can come up with an idea on how to dedupe them. With mass adoption this issue i think may be solved by someone concerned about disk space. Personally, and probably many casual users, are not as worried about space as they are about convenience. But I think your point is valid, and I think this would make an interesting side project for someone out there. For me, I'd like to see more adoption. The nice to haves will follow.
- tomrod 3y ago
  Something like docker's layers?
  - entropicdrifter 3y ago
    At that point you're re-inventing Flatpak, to a large degree
mcpackieh 3y ago
Optimizing for disk space in 2023 seems misguided at best, all computers come with hundreds of GB at least, often one TB or more. Most people never fill these unless they download media, and people who download media have additional hard drives anyway. Ease of use, RAM usage, startup time and security should all rank higher than disk space.
- rpgbr 3y ago
  Until a few years ago Apple was shipping new Macs with 120 GB. Probably same was (is?) happening with Windows vendors. TB-level disk space isn’t ubiquitous yet.
  - mcpackieh 3y ago
    Okay but how much dedupable dependencies does the average AppImage user have across his programs? A few hundred megabytes? A few gigabytes at most? Even 120 GB is big compared to this problem.
  - gumballindie 3y ago
    The difference between apple products and non apple products is that you can easily upgrade them. My core i9 laptop (a cpu that easily competes with anything apple can offer, so it should be fine for heavy workloads, albeit at bateryy cost), has 5600 mhz ram speed, 7 gb / s dual nvme support, both of which upgradeable. Most folks i know with non mac laptops can at least upgrade their hard drives and often ram. Disk space and ram not an issue for non apple users. TB disk level is absolutely feasible outside that platform. You can buy 2TB nvmes capable of 5 gb / s for less than 100$ easily.
- JohnFen 3y ago
  > all computers come with hundreds of GB at least There's a whole range of tiny/small computers that run Linux and that absolutely don't have hundreds of GBs of storage space.
- jeroenhd 3y ago
  I'm not going through the effort to upgrade my 250GB system SSD because a random podcast app can't figure out how to distribute a binary without shipping half an OS. Most people aren't going to upgrade their storage at all. We're talking about Linux users here, not your run-of-the-mill generic end user. If you download an AppImage, you're most likely an advanced computer user. Maybe you don't download media yourself, but you'll probably have huge node_modules/cargo/venv/maven directories slowly clogging up your drive. AppImages aren't easy to use (you can't double click them like on Windows and they all have to provide a mechanisms of their own to register a shortcut in the system menu), their startup time is affected by the compression tying all the files together, the security is no better than any other application (worse, in fact, because when I update my system's openssl client I'll still need to wait for every AppImage program to publish a security update with the patches included, which usually takes months or longer). I don't know about RAM usage, but the duplicate libraries being loaded by the executables will cause at least a few megabytes of unnecessary RAM usage. AppImage is mostly there to help the developer spread the software. The benefit for the user is "at least there's something I can run, I guess".
ibejoeb 3y ago
I'm not familiar with details of any of these packaging formats. Are they all single-file? Is there any technical reason they couldn't be unpacked to allow the fs to deal with the deduping?
- jeroenhd 3y ago
  AppImage is basically a runnable .zip file. It contains a loader and an application with all of its dependencies, packed into a single file. If the image was uncompressed, basic extent-based deduplication could save space, but as far as I know the compressed AppImages just don't match up the files like that. I don't believe Snap natively offers any deduplication. Snap also uses compression (squashfs as far as I can tell) so deduplicating filesystems are equally powerless. Flatpak has its own deduplication system (that will confuse df/du if you try to run it and often leads to confusion about download time). Through tools like https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ https://gitlab.com/TheEvilSkeleton/flatpak-dedup-checker/ you can check how effective the dedup process on Flatpak is. On my machine, Flatpak is using 10.5GB of disk space, but reports 13.75GB of files. Running duperemove on /var/lib/flatpak found two identical extents (belonging to cached files) that didn't get deduplicated already. As for why they couldn't be unpacked: I don't know. They'd take up more disk space, I suppose. Many standard Linux file systems don't have any form of deduplication mechanism built in, so I'm not sure what the balance would be. I would appreciate the ability to decompress AppImages/snaps without writing custom wrappers for them, but if you're on ext4 like many (most?) Linux users, you'll only see the downsides.
gnulinux 3y ago
As far as I'm concerned this is a good thing. I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y. In the last 2 decades I used linux I had this issue so many countless times that as far as I'm concerned nix-style, or AppImage-style "waste space" solution is strictly speaking better. Sick and tired of this "upgraded MuseScore3 to MuseScore4, so now Ardour is broken" insanity, this is not how software is supposed to work. I want each package to have its own dependencies, period.
- gumballindie 3y ago
  Ah yes, that too. I dread the moment i mess up dependencies. I just want the app to run. I don't care about whatever libs.
- jeroenhd 3y ago
  Linux has definitely come up with the worst solution to DLL hell, but Flatpak solves this problem neatly without dumping huge files all over my disk (and without making me manually create shortcuts for them). It also solves the update problem much better (update applications all at once rather than open them one by one and waiting for the "there's an update, click here to download" popup to show up). I generally stick to the distro repos exactly because external software is a pain to run, with Flatpak as a fallback for applications not packaged in any repo. More and more third party applications are being compiled statically, though, which has solved a lot of issues for me when it comes to these externally managed programs (though it also causes annoying security issues).
- akvadrako 3y ago
  Flatpak doesn't have that problem. Each app specifies the exact versions of runtime libraries it wants and files are de-duplicated.
- pizza234 3y ago
  > I'm completely and utterly tired of fixing the next 14916498th bug that's caused by package X and Y having shared dependency Z, then X updating Z to Z+1 and breaking Y This is not "Linux", it's users who mess around with (and ultimately break) dependencies in order to get the latest version of programs at any cost. If one uses, say, an Ubuntu version and 3rd party repositories for that version only, they're not going to get any dependency issue, since all the programs will share the same library versions (dependency bugs do happen once in a long while, but they're rare, and they're exceptions).

cookiengineer 3y ago

While I love bleeding edge packages, normal users don't want to have to deal with compilation workflows and they expect software to work a year after it has been installed. To name an example: steam is a nightmare, even though they try their best to host and ship as many libraries from ubuntu as possible. The experience with botched steam installations shifted my perspective a bit, and I think for these desktop use cases, especially of proprietary software, AppImages are the way to go. It's the easiest way to guarantee behavior and stability of software, while not putting the virtualization burden upon the end users.

gumballindie 3y ago
Exactly. Download an app, double click it, enjoy it. Life's too short for faffing around with package managers and their idiosyncrasies :-)

PurpleRamen 3y ago

Do appimages have a proper well maintained store now with a good cli for maintaining them? When I last year moved to portable Apps, I check out flatpak, appimages and snap, and move to flatpak, and some appimages. But while flatpaks are easy to maintain, the appimages are basically dead weight. Some can be updated, some not. There were a number of different tools for maintaining them, not one-for-all. Similar there were multiple stores/sites for finding new appimages, not seem particular trustable. It was not very impressive at the time.

gumballindie 3y ago
Currently, and that's an issue I've also encountered, there are apps on appimagehub.com. Which is why I am hoping more effort will be put in populating it. But i don't think it should have a cli package manager, i think it should be gui based, and focused on convenience. I don't think it should replace apt, yum or pacman. Just a new way of managing packages that is focused on convenience. And perhaps a convention that in a distro if you download any apps to ~/Applications then these will be auto updated provided they are sourced from an "app store". Trust can be fixed with a set of built in security certificates as apt does, but in a basic, low maintenance good enough fashion. When I switch to casual user mode, or even for daily work, good enough is ok as long as its super convenient.

lairv 3y ago

I've encountered appimages a few time and wasn't really convinced. Maybe I'm missing something but here's what I found annoying: - need to move the x.appimage somewhere in your $PATH - need to create an alias like nvim.appimage -> nvim - no way to automatically update - the application isn't listed in your application list on ubuntu On the other hand `sudo snap install nvim --classic` brings me all of the above without any work from me

dcow 3y ago
These are entirely solvable problems, at least. Just sounds like the UX isn’t there yet.
JustinGarrison 3y ago
Snap and flatpak run a daemon to integrate into your system. Appimage has an optional daemon to give you the same integration https://github.com/probonopd/go-appimage https://github.com/probonopd/go-appimage Handles making it executable, automatic upgrades, no need to move it to your $PATH, and adds the application to your app list. Only other thing you might want to do is symlink a friendly name for cli

butz 3y ago

AppImages sounds good on paper, but when you download one, get library errors and there's nothing you can do about it, you start thinking that Flatpak with its runtimes was not so bad idea after all.

gumballindie 3y ago
The question is which method is more prone to issues. Perhaps a QA process of sorts could be builtin to the "app store" to at least be able to boot the app without errors? Also I am not saying flatpaks or apt should go away. Just saying that it would be nice to have a realiable way to download a package and run it, no hassle.

arrakeen 3y ago

i completely agree. for me, the only issues i've had with appimages are "housekeeping" UX: * i know they can technically be updated but i really have no idea how. would be cool to see a de-facto solution similar to sparkle[0] on mac * i use appimagelauncher[1] to integrate with my menus etc but sometimes it works and sometimes it doesn't? i haven't really figured out the rhyme or reason [0] https://sparkle-project.org/ https://sparkle-project.org/ [1] https://github.com/TheAssassin/AppImageLauncher https://github.com/TheAssassin/AppImageLauncher

kvdveer 3y ago

I feel appImage is missing metadata. I'd be great when the user downloads an appImage, it is automatically linked to the mime types is can handle, shows up in relevant menus, and can properly register itself to any services it needs (e.g. Cron). It could also do with an update mechanism.

david2ndaccount 3y ago

This works for MacOS because there are system frameworks you can rely on being installed (like AppKit) and that actually have backwards-compatibility (at least for a while). Linux distros don’t have this (not even for glibc), so you’d have to literally everything in your app image folder. Every GUI app bundling QT or other gui framework would be a ridiculous waste of space.