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

Flatpak Is Not the Future

ludocode.com

Post reply on HN
Print view View original

31–40 of 410 posts

Re: Flatpak Is Not the Future

#31

Post by AnonCoward4 »

enriquto wrote: post #25
edent wrote: post #21

I agree with all of this and... I just don't care. I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb! I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA. If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk. I d…

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…

You can override permissions (there is even a GUI called Flatseal for that). You are also not able to do any of that with distro package managers like apt or dnf. Ultimately you need to trust either.

Re: Flatpak Is Not the Future

#32

Post by anothernewdude »

> If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.

No, you just trigger the download on install to get the 15th version of the runtime

Re: Flatpak Is Not the Future

#33

Post by spaniard89277 »

I don't know about others, but I use snap basically for apps that are not in the repository, and I can avoid the PPA mess.

Currently the only app in my laptop with snap is Brave. I remember when I wrote the apt install brave, there was a line in the console suggestig to use snap.

So for me, as long is anecdotal, it's fine. I agree with the author, it's too much bloat, it doesn't matter that disk space is cheap.

Re: Flatpak Is Not the Future

#34

Post by hules »

sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

Firefox is larger on macOS because it contains 2 archs (x86_64 and arm64), not because it bundles of full runtime -- also the compression algo of dmg files is typically quite bad (zlib or bzip2), which is not helping.

Re: Flatpak Is Not the Future

#35

Post by enriquto »

AnonCoward4 wrote: post #31
enriquto wrote: post #25

Earlier quoted context omitted.

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…

You can override permissions (there is even a GUI called Flatseal for that). You are also not able to do any of that with distro package managers like apt or dnf. Ultimately you need to trust either.

What I mean is that permissions and accesses concern the operating system, not the software packaging. I don't understand why flatpack needs to deal with those, providing a false (and pernicious) aura of protection. I already run third-party software inside containers or virtual machines. No need for a GUI nor a flatpack-only solution like flatseal. It just looks pointless.

Re: Flatpak Is Not the Future

#36

Post by mrweasel »

My main complaint about solutions, like Flatpak or Snap, is that they add another package manager. Now I have to manage two sets of packages.

The baseline tools, like all the GNU standard Unix tools, and other command line tools are still managed by DNF, APT, whatever, and then another set of apps are managed by Snap. It's pretty confusing, especially if you never use the "app stores" otherwise. You quickly end up with: apt install and apt install gimp, but now that's a different Gimp than the one in App Store. You also can't really remove Gimp from apt, because it's weird that apt can't install everything.

I haven't really used Flatpaks, but Snaps is confusing (to me at least), because it's doesn't actually replace APT and pollute the output of "df" and "mount".

I'm also concerned that some packages will never be updated, or stuck on a library with security issues. Perhaps that me, but I'd rather that that one application breaks.

Re: Flatpak Is Not the Future

#37

Post by galcerte »

sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

> This OTOH does not exist. Linux gamers are 1% of either the gaming market or the desktop computing market. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine. Which is what Valve maintains

First off, 1.13% of Steam users are on Linux [1], and given how many users Steam has, just 1% of that population should be able to make quite a fuss. Secondly, Valve does need those containerized runtimes even if most games run on Proton, since Proton also depends on those libraries, so not sure why you're dismissive...

[1]: https://www.phoronix.com/scan.php?page=news_item&px=Steam-Li...

Re: Flatpak Is Not the Future

#38

Post by alkonaut »

enriquto wrote: post #25
edent wrote: post #21

I agree with all of this and... I just don't care. I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb! I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA. If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk. I d…

> it works No. It doesn't. You still need to trust the people who package the thing. A working packaging system would give the user ultimate power to manage access to resources by each app. Overriding or mocking, if the user so decides, whatever access does the app believe to need. Flatpack does not give you such power, it removes this power from you and assigns it to the packagers. Thus, not only it doesn't work: it…

Is there any difference in trust between package maintainers and flatpack packagers?

If anything, isn't the flatpack situation better in that regard because the end user is more likely to have a sandbox?

Re: Flatpak Is Not the Future

#39

Post by andrepd »

sandGorgon wrote: post #20

The short (but polite) rebuttal to this is - OSX. DMG files are similar sized and proven to be very successful. For e.g. - firefox ( https://www.mozilla.org/en-US/firefox/all/#product-desktop-r... ). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb. Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb…

That just not true. "All Linux users dual boot" where's your data to say that? "Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton.

And 1.2% is slightly more than half the mac market share on steam. Should mac users also be ignored?

Re: Flatpak Is Not the Future

#40

Post by zimbatm »

There is a deep trend happening in software development.

As the number of dependencies for building an application grows, it becomes exponentially harder to shake the tree. This used to be the role of Linux distributions, they were acting as a push-back force, asking projects to support multiple versions of C libraries. This was acceptable because there is not C package manager.

Now that each language has their own package manager, the role of distributions have faded. They are even viewed as a form of nuisance by some developers. It's easier to support one fixed set of dependencies and not have to worry about backward-compatibility. This is something all distributions have been struggling with for a while now, especially with NodeJS.

This trend is happening on all platforms, but is more pronounced in Linux because of the diversity of the system libraries ecosystem. On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API.

Post reply on HN