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

101–110 of 166 posts

Re: Flatpak is not the future (2021)

#101

Post by gumballindie »

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…

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.

Re: Flatpak is not the future (2021)

#102

Post by JohnFen »

jdiff wrote: post #64
prmoustache wrote: post #49

Earlier quoted context omitted.

Isn't that just because you aren't using a decent distro? I mean I am surprised that firefox or librewolf or whatever fork is not packaged by Debian in a current version.

That's kinda Debian's shtick. Its ethos is to be rock-solid stable no matter what. No changes but bug fixes, and it gets those in a very timely manner. It's an amazing distro for what it is, but in a desktop or workstation sometimes you just need up-to-date software and for that, Flatpak makes a whole lotta sense. Stable OS core with the latest applications shipped on top. It may not fit your own use case but it's on…

Yep. That "solid, not cutting edge" philosophy is one of the main reasons why Debian is my favorite distro.

Re: Flatpak is not the future (2021)

#103

Post by gumballindie »

butz wrote: post #94
gumballindie wrote: post #33

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

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.

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.

Re: Flatpak is not the future (2021)

#105

Post by JohnFen »

danShumway wrote: post #41

This debate will never die, but while people have been complaining about it, Flatpak has quietly just become a better way to package software for end users. My criteria is that I'm a user, I don't care about what's elegant to developers -- and I have fewer problems with Flatpak than I have with non-Flatpak software. The vast majority of Flatpak problems I do have as a user come down to sandboxing permissions that I a…

> 2 years later, I have literally never gotten a GoG native Linux installer to run without problems on the Steam deck.

That's actually interesting. For me, GoG's Linux installers have never given me a lick of trouble on Debian.

Re: Flatpak is not the future (2021)

#106

Post by JohnFen »

danShumway wrote: post #92
prmoustache wrote: post #72

Earlier quoted context omitted.

But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro. Whenever I have an app available as rpm, I choose the rpm over the flatpak version, for space saving purpose mostly. None of my apps crashes except one. And that is a piece of shit of a proprietary app that is not packaged by the distro maintainers: Microsoft Edge.

> But on the other hand, app crashes aren't something that common on linux. I mean at least on my distro Strong disagree, my experience is that app crashes are extremely common on Linux if you step outside of official repositories; I say this as someone who literally only runs Linux and nothing else. I'm not necessarily saying Windows is better but... it's not like nothing ever breaks. It's impressive how well develo…

> This is why people run games through Wine instead of using the Linux versions

They do? When I have a choice between the two, I'll take the Linux version every time.

Re: Flatpak is not the future (2021)

#107

Post by Timber-6539 »

padraic7a wrote: post #89
Timber-6539 wrote: post #19

Doesn't matter, Flatpak won over Appimages and Snaps in adoption numbers. And the example given here for GIMP having r/w permission to your home doesn't hold water. The distro-packaged app probably has the same permissions in comparison. At least with Flatpak, to deny it this permission is a simple toggle with Flatseal.

Did it? What adoption numbers? Number of distros? Number of applications? Ubuntu seems to dwarf other Linux distrobutions in terms of numbers of users. Are you saying more users have Flatpak installed than have Snap installed?

The numbers of app installs for popular software available from flathub.org but sure you can use the number of supported distros as an easy base. Including Ubuntu with a few workarounds.

> Ubuntu seems to dwarf other Linux distrobutions in terms of numbers of users.

I'd ask you the same thing. Based on what figures?

> Are you saying more users have Flatpak installed than have Snap installed?

Yes until Ubuntu's Snapcraft store provide download numbers. I can almost swear they used to provide this sometime back but can't see anything like that now.

Re: Flatpak is not the future (2021)

#108

Post by Timber-6539 »

prmoustache wrote: post #58
Timber-6539 wrote: post #19

Doesn't matter, Flatpak won over Appimages and Snaps in adoption numbers. And the example given here for GIMP having r/w permission to your home doesn't hold water. The distro-packaged app probably has the same permissions in comparison. At least with Flatpak, to deny it this permission is a simple toggle with Flatseal.

The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk. Untrustable apps aren't more trustable because they are delivered as flatpaks.

You missed my point.

> The point is the proponent raise the security flag like it is a huge advantage and you could trust anything coming from flathub while it is mostly pixie dusk.

Okay then, as you criticize Flatpaks give us your alternative to a trusted application.

> Untrustable apps aren't more trustable because they are delivered as flatpaks.

Nobody made this claim.

Re: Flatpak is not the future (2021)

#109

Post by denton-scratch »

I have one AppImage installed on one system (of four, at the moment). Zero flatpaks and snaps. That one AppImage appears to be available only as a Windows install or an AppImage. I dread any future where everything is an AppImage (or whatever).

Why not just ship everything with a complete OS? Hell, let's go the whole hog; hardware is also a dependency, it's not just libraries. So let's ship every app as a hardware appliance.

This is not why I use Linux.

Re: Flatpak is not the future (2021)

#110

Post by curt15 »

JohnFen wrote: post #6

Flatpacks solve no problem that I have, and bring their own headaches, so for me, flatpack is certainly not the future. Same with snaps, although I dislike snaps more.

What about transactional updates? Applications might have undefined behavior if their libraries or other assets are changed under their feet.
Post reply on HN