Live data from Hacker News

Flatpak is not the future (2021)

ludocode.com

51–60 of 166 posts

Re: Flatpak is not the future (2021)

#51

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…

I don't know, the only flatpak packaged application I tried to use today is crashing at startup and it just makes it more annoying to debug and do an actual bug report.

https://docs.flatpak.org/en/latest/debugging.html

An average user would just say that app is shit, linux is shit, I go back to windows!

Re: Flatpak is not the future (2021)

#52
post #15
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.

> Firefox should be able to just use the mozilla's official build which comes with an auto-updater (and it implements the sandbox itself, so no need for another one on top). > Zotero > Joplin both electron shells. also come with their sandbox already. most rolling release distributions would just package these with a system-provided electron build.

I always assume Electron apps are going to be more vulnerable than your average app. They tend to have the same vulnerabilities as web browsers (who are a big target for exploits given the reach) but have 2 additional layers of "bureaucracy" (the App's own update schedule and Electron's) before the underlying vulnerable engine is patched.

Re: Flatpak is not the future (2021)

#53

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

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.

Re: Flatpak is not the future (2021)

#54
I was kinda forced into flatpaks with Fedora silverblue and 10 months later I don't really mind them. They are good enough for a laptop with no special requirements. I have Dino, Steam, Gnome Tweaks, Fractal, Signal, Gimp (crashes a lot), Firefox (because it comes with codecs, unlike the Fedora flatpak), Transmission, Chromium (mostly to run Teams and Outlook for work).

Re: Flatpak is not the future (2021)

#55

I wonder if the author of the article feels differently about Flatpak today (a great deal has changed in the past 2 years, and Flatpak seems to have a vibrant future today).

There are a lot of points that are still valid.

Like the fake security feeling people have using flatpak because of the advertised sandboxing, the size of the software being downloaded or the slower startup of applications.

Re: Flatpak is not the future (2021)

#56

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

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.

Re: Flatpak is not the future (2021)

#57

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…

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

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

Re: Flatpak is not the future (2021)

#58

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.

Re: Flatpak is not the future (2021)

#59

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…

I don't know, the only flatpak packaged application I tried to use today is crashing at startup and it just makes it more annoying to debug and do an actual bug report. https://docs.flatpak.org/en/latest/debugging.html An average user would just say that app is shit, linux is shit, I go back to windows!

I guess millage may vary, the only thing I can say is that there are multiple instances (particularly GoG which the article seems to praise) that literally never work on some of my systems.

The few times I've run into Flatpak crashes, they're architecture problems that would have been present in any version of the app, so I'd be doing that work regardless. They're harder to debug in Flatpak, but also heck debugging crashes every time I try to install a piece of software. I'll happily take the added complexity of needing to boot a shell into the sandbox if it means I get to debug 50% fewer problems (and in practice Flatpak tends to reduce my number of issues by way more than 50%).

The average user is never going to open a debugger, minimizing the number of crashes is more important for that user than making the crashes easier to debug.

Re: Flatpak is not the future (2021)

#60
Just goes to show the amount of third-party fragmentation that goes on in the Linux Desktop ecosystem which tons competing alternatives of alternative system components and now installers all in conflict and fighting against the users system.

Snaps are only available in the default install in Ubuntu and Flatpaks is not in the default install of other Ubuntu-based distros [0]. Even other distros have neither in their default installs.

It is not the same thing with macOS with its first party installation methods provided by Apple that just works.

[0] https://www.omgubuntu.co.uk/2023/02/ubuntu-flavors-no-flatpa...

Post reply on HN