Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak is not the future (2021)

ludocode.com

Post reply on HN
Print view View original

121–130 of 166 posts

Re: Flatpak is not the future (2021)

#121

Post by jeroenhd »

ibejoeb wrote: post #85
jeroenhd wrote: post #45

Earlier quoted context omitted.

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.

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?

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.

Re: Flatpak is not the future (2021)

#122

Post by banthar »

Tomte wrote: post #3

But it's the present. And a godsend. I'm using it for current Firefox, Zotero, Joplin and two or three more programs, none of which are packaged in Debian (except Firefox, but only the LTS version that doesn't work with all my extensions). Unless you can offer something better, I'll keep using it.

Zotero Flatpak comes with 4 year old Firefox binary and full access to your home directory.

The compromise currently being made here is your security.

Re: Flatpak is not the future (2021)

#123

Post by jeroenhd »

gnulinux wrote: post #90
jeroenhd wrote: post #45

Earlier quoted context omitted.

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.

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 t…

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

Re: Flatpak is not the future (2021)

#124

Post by Ferret7446 »

pmarreck wrote: post #11

It is strange to watch everyone fight about snaps, flatpaks, silverblue ad nauseam when Nix (or its full-OS version, NixOS, or the GNU alternative, Guix) has already definitively solved this problem but is still considered too arcane for most people to use. It only uses the disk space it must, AND every app only accesses the dependencies it needs. It's the best of all worlds (except for the learning curve, which is o…

> It's the best of all worlds (except for the learning curve, which is of course why it's considered "arcane")

Which is the most important one. "It's the best at everything except the thing that it needs to be good at, where it's one of the worst" is not a good marketing pitch.

Re: Flatpak is not the future (2021)

#125

Post by mcpackieh »

jeroenhd wrote: post #119
mcpackieh wrote: post #56

Earlier quoted context omitted.

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.

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,…

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

Re: Flatpak is not the future (2021)

#126

Post by Dan42 »

dcow wrote: post #88

Not dissenting generally, just want to point out that the author is wrong about the file permissions dialog thing: > This is the most complicated and brittle way to implement this. It’s also not at all how other sandboxed platforms work. If I want file access permissions on Android, I don’t just try to open a file with the Java File API and expect it to magically prompt the user. I have to call Android-specific APIs…

Fully agree. When the user selects a file via the file selection dialog, that automatically implies s/he has given permission to read that file. So the Flatpak libportal approach has really good UX. Having a second popup to grant access to the file would be horrible UX. Which is why apps ask for coarse-grained permissions like "access to all files" in order to bother the user as little as possible with multiple permission dialogs. Which then kinda defeats the point of sandboxing. I'm reminded of how Android apps need to know your "location" in order to scan for wifi networks.

In general I think all permission dialogs should be reframed as selection or confirmation dialogs.

• Open file dialog -> grants permission to read that file.

• Open file for edit dialog -> grants permission to read/write that file.

• Save as -> grants permission to read/write that file.

• Select which wifi network to connect to -> grants permission to use internet

• Do you want to display events in your neighborhood? -> grants permission to location data

• Select which camera & mic to use for this call -> grants permission to record video & audio

--

I have to say though, apart from that permissions thing, the author makes a lot of good points I hadn't realized before.

Re: Flatpak is not the future (2021)

#127

Post by pmarreck »

Ferret7446 wrote: post #124
pmarreck wrote: post #11

It is strange to watch everyone fight about snaps, flatpaks, silverblue ad nauseam when Nix (or its full-OS version, NixOS, or the GNU alternative, Guix) has already definitively solved this problem but is still considered too arcane for most people to use. It only uses the disk space it must, AND every app only accesses the dependencies it needs. It's the best of all worlds (except for the learning curve, which is o…

> It's the best of all worlds (except for the learning curve, which is of course why it's considered "arcane") Which is the most important one. "It's the best at everything except the thing that it needs to be good at, where it's one of the worst" is not a good marketing pitch.

Having surmounted (and benefited from) the learning curve of functional programming, I find your argument of "everything must be easy or it is by definition a failure" to be suspect, AND a cop-out.

Matrix algebra isn't easy either. Guess ML will never be a success! It's literally failing at the thing it needs to be good at!

Re: Flatpak is not the future (2021)

#128

Post by spenrose »

spenrose wrote: post #31

The #1 story on Hacker News at 2023:08:21T15:41Z is a 2021 discussion of Linux desktop packaging tools. Hypothesis: HN story up-voters are heavily drawn from Free / Open Source Software folks interested in issues that were broadly discussed in "tech" two decades ago (Linux for the desktop!) and are much less broadly discussed today.

Five net downvotes (and counting?) for this anodyne observation.

Re: Flatpak is not the future (2021)

#129

Post by akvadrako »

gnulinux wrote: post #90
jeroenhd wrote: post #45

Earlier quoted context omitted.

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.

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 t…

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

Re: Flatpak is not the future (2021)

#130

Post by pizza234 »

gnulinux wrote: post #90
jeroenhd wrote: post #45

Earlier quoted context omitted.

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.

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 t…

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

Post reply on HN