[jeroenhd]

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.

[gnulinux]

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.

[pizza234]

> 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).

[gnulinux]

I used Ubuntu and even Debian for many years. I strongly disagree with you, actually I find Arch significantly more stable than Ubuntu. At least in Arch when dependencies are broken, both X and Y are swiftly upgraded.

At this point, I'm also tired of convincing others that linux package management is broken beyond repair. Until you experience my pain, you won't be convinced. I understand many people will never be able to sympathize with my pain but all I can truthfully and honestly say is that I'm a very experienced GNU/linux user, I used all kinds of distros from Ubuntu to Fedora to Arch to Gentoo and, no, it's all a complete and utter mess when it comes to dependency management. I end up spending hours every month fixing broken versions. The sweet spot is using pacman for very basic things, and AppImage for everything else. I don't care about memory efficiency, I want `MuseScore4.appimage` to contain everything about the app, I want it to behave exactly the same every single time I click on it. No, I don't tolerate even the slightest behavior difference, I do not want glibc to upgrade from x.y.z.t to x.y.z.t+1 because it causes insanity when t+1 causes a behavior change in some random software synthesizer I happen to use. I know that this probably doesn't make sense to 99% of users, but maybe I have a special case. Case in point, in the year 2023 while trying to ship a lot of work I'm producing, a single update broke tons of my workflows, and I finally decided that anything not frozen in AppImage is cursed. If it doesn't work you, I respect your patience and expertise, I just hope some people can understand the pain other users go through.

I have a degree in CS, I write code full time, I manage linux containers in my day job, and I still can't manage the mess I have at home in my local Ubuntu/Arch installs. I don't know how people who don't know how to code do, but all I know is that I'm done spending hours at a time on fixing glibc at this point. I just want to work on my hobbies, thank you very much.

EDIT: And before people come here, no, OSX and Windows are even worse. I won't consider using them either.

[mcpackieh]

Zypper has excellent dependency resolution, it hasn't given me any trouble. DNF is just as good, from what I hear. Apt and yum are an earlier generation of package manager, and I've seem them get themselves into jams on more than one occasion so I understand what you're saying and can sympathize with your perspective, but those shortcomings aren't inherent to the premise of traditional package management.

I use AppImage for the sort of software that won't get packaged (proprietary or obscure) and zypper for pretty much everything else (excepting a few programs I build myself due to reasons.)

[pizza234]

This is very gross disinformation and/or incompetence (which explains why "others" won't listen).

The default Debian tools, apt and apt-get (and related tools, like gdebi/aptitude) won't put the system in an inconsistent state, unless the user forces them to do so. Dpkg will do, which I suspect is the tool you're using.

Even when one adds a repository with incompatible package versions (say, the system is Focal and the repository distribution is Mantic), the upgrade will stop before upgrading the packages.

What's happening is that you're forcing broken dependencies, likely to chase the "latest and greatest versions", then complaining that the package manager is broken.

[gnulinux]

Uh... Such is linux life, when you're hit with issues and complain, it's "This is very gross disinformation and/or incompetence". No wonder some people won't bother dealing with it.

Again, I truthfully experienced all of this and my day job is to handle things like this, so I personally know that it's neither of those things.

What's happening is a variety of issues (not one) and it can be anything from package maintainer not knowing whether a version is incompatible with their package, to dependency being noted wrong in package. For example, if I write package X and depend on numpy, but don't realize numpy 2.24 breaks it, Debian will happily accept the update breaking my package for users. It's the maintainer's fault but ultimately if the OS didn't upgrade dependencies for every program it would have worked. Which is why freezing dependencies is the way to go in terms of stability.

There are countlessly other scenarios, for example using a program compiled outside of Debian and dyn linking then Debian upgrading the dependency not knowing about the 3rd party program. It's all a trap for broken software.

[akvadrako]

Flatpak doesn't have that problem. Each app specifies the exact versions of runtime libraries it wants and files are de-duplicated.

[jeroenhd]

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).

[gumballindie]

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.

[gumballindie]

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]

Something like docker's layers?

[entropicdrifter]

At that point you're re-inventing Flatpak, to a large degree

[mcpackieh]

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.

[jeroenhd]

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".

[mcpackieh]

> AppImages aren't easy to use (you can't double click them like on Windows

Uh, but that's exactly how they work. What file manager are you using them that doesn't recognize them? Also you can just chmod+x them and execute them.

As for their size, my XPS13 has a 250GB SSD too, not easily upgradable, but AppImages just aren't a significant burden to me. Once a month or so I move downloaded media to my NAS, but all of my AppImage applications together add up to maybe 15GB or so, the redundancy in them is really the least of my concerns.

[jeroenhd]

When I double click an AppImage, I get ab error ('Could Not Display "Something.AppImage"\n There is no app installed for "AppImage application bundle" files. Do you want to search for an app to open this file?'). That's in Nautilus. If I click on the file from the Firefox download thingy, it asks me how I want to open "file links" with no suggestions for what to do next. Thunar asks me to pick a program to open "AppImage application bundle" files with, but has no recommended application.

Dolphin does seem to support AppImages natively and will execute the file (after clicking through two security prompts). I guess KDE users are AppImage's target audience, then?

[JohnFen]

> 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.

[rpgbr]

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.

[gumballindie]

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.

[mcpackieh]

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.

[ibejoeb]

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]

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/ 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.