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

211–220 of 410 posts

Re: Flatpak Is Not the Future

#211

Post by fanatic2pope »

lobstrosity420 wrote: post #199

Unfortunately, Flatpaks are the new SystemD. As in, a solid technology which solves real world problems but will face immense resistance from a community filled with splinter groups that have their own pet technology on the same niche, and will accept absolutely nothing else as an alternative. There is simply no path to standardization in this community other than big players like Red Hat and Canonical strong arming…

For me both systemd and flatpak have made using Linux better, so I use them and basically ignore the political debates. If something better comes along, I'll use those too!

Re: Flatpak Is Not the Future

#212

Post by faho »

gnulinux wrote: post #192
faho wrote: post #48

Earlier quoted context omitted.

>"Nobody compiles for Linux" factually false, many of the most-played games on steam are Linux-native, and most others run flawlessly on Proton. The games that run on proton have not been compiled for linux.

E.g. factorio is compiled for linux.

Yes, linux-native games exist.

But games that run on linux via proton have not been compiled for linux, so mentioning them as a counter-argument to games not being compiled for linux makes no sense.

The broader context here is TFA rejecting the "steam runtime" idea, and for proton-based games proton is that runtime! They don't need anything from the system because proton/wine provides it.

Re: Flatpak Is Not the Future

#213

Post by bogwog »

southerntofu wrote: post #158
faho wrote: post #114

> How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game? If the steam runtime didn't exist, most gamedevs would only target the most popular distro - probably the current Ubuntu LTS, and you would have to…

Yet the steam runtime could be maintained/distributed using a more robust and explicit mechanism such as guix or nix, don't you think?

Guix is a great solution to this problem. It's a shame that there aren't any distributions based on it (afaik) besides the official GNU one, which is not very practical outside of a VM due to their aversion to anything proprietary.

Re: Flatpak Is Not the Future

#214

Post by fsflover »

goodpoint wrote: post #210
cunidev wrote: post #7

To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have…

So basically all the same drawbacks as in Windows, when you install third-party software?

Re: Flatpak Is Not the Future

#215

Post by guerrilla »

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…

> Valve only needs to maintain wine & proton for a distribution. The games themselves ? well, they are windows only. Nobody compiles for Linux. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine

This isn't true at all. I'm afraid you've misunderstood the situation. Get on steam and check for yourself. There are many games compiled for Linux specifically (in addition to other platforms) that do not require proton. They use some ubuntu or debian packages for their libraries and have no linkage to anything windows.

Re: Flatpak Is Not the Future

#216

Post by enriquto »

fullstop wrote: post #203
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…

> No. It doesn't. You still need to trust the people who package the thing. How is this any different than sudo apt install foo?

apt is not misleadingly advertised as a sandboxing environment. Flatpack is:

"Flatpak: Linux application sandboxing and distribution framework " [0]

"It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system." [1]

The whole point of a sandboxing environment is that you can run applications that do not want to be sandboxed. The flatpack proposition is directly contradictory with this basic requirement, in that it requires the application to be flatpacked to begin with.

[0] https://github.com/flatpak/flatpak

[1] https://en.wikipedia.org/wiki/Flatpak

Re: Flatpak Is Not the Future

#217

Post by account42 »

nousermane wrote: post #172
mjg59 wrote: post #150

People have tried to provide a packaging format that would allow apps to declare their depencies in a distribution neutral manner[1]. It was, uh, not a huge success. Let's take an extreme example. If I build an app on Ubuntu and then try to run it against the system libraries on Alpine, it'll fail, because Alpine is built against a different libc. We can simply declare Alpine out of scope and only support glibc based…

That was a very good summary of where flatpak (and snap, et al.) come from, thank you. Not a particularly convincing conclusion, though. Same problem that flatpak is solving (shiping binaries that would work across many distros) already have at least two solutions - static binaries (where possible, golang is great here), or shell wrappers that point dynamic linker to appropriate private /lib directory. Among the 3 so…

> or shell wrappers that point dynamic linker to appropriate private /lib directory.

You haven't needed shell wrappers to do that for a long time, just link with -Wl,-rpath,\$ORIGIN/whatever/relative/path/you/want where $ORIGIN at the start resolves to the directory containing the binary at runtime.

Of course other things like selecting between different binaries based on architecture or operating system still requires a shell script.

Re: Flatpak Is Not the Future

#218

Post by post-it »

southerntofu wrote: post #155
post-it wrote: post #120

Earlier quoted context omitted.

Package managers that integrate apt, flatpak, and (potentially) snap are a nice solution. Unfortunately, the one that happens to be on my system (Pop!_Shop) is awful .

Could you maybe elaborate, or link to more detailed criticism of Pop! Shop? I've also found that GNOME Software did a rather poor (though not that bad) job of exposing the multiple sources for a given package, but i believe this can be fixed with better UX (though i'm unaware of work being done in this space).

Pop!_Shop's UI frequently freezes when installing, searching, or even just opening an app's store page from the Gnome app menu. It also has some UI bugs, like the search bar being visible but un-interactable when on an app's page. It's definitely something that can be fixed with better UX. The actual selecting whether I want the apt version or flatpak version of a package works fine.

Re: Flatpak Is Not the Future

#219

Post by esarbe »

tored wrote: post #108
esarbe wrote: post #28

Don't know what to think about this blog post; it's not a very coherent critique, since it throws together various issues of user-packaging-formats that mostly specific to only one of the formats. And these don't seem to be 'inherent' in their design. Well, one is. Let's go through some of the issues: > Size My /var/lib/flatpak is 13 GB in size. That's a lot of space. On the other hand; that's about one game with con…

In my opinion the article was well written and well researched (many sources), and to separate different topics but relatable it used different sections. > Size As the author mentions, many users uses budget computers or something like a raspberry pi and not a big gaming rig, but you also have to consider the network usage, all that data needs to be downloaded, that in it self is a cost for the network for every comp…

Flatpaks (and Snaps) do require more space.

However; when compared to other operating systems - like Windows - these space requirements are negligible: a full installation of Window 11 takes north of 30GB, so even with five years of accumulated flatpak runtimes, this is still less than a third of a Windows installation.

Even budget computers can satisfy this. And once the runtimes are installed, your mostly good - there are only so many runtimes[0].

With regards to raspberry pi; yes, that's not what Flatpaks are aimed at, at least not now.

[0] https://docs.flatpak.org/en/latest/available-runtimes.html

Re: Flatpak Is Not the Future

#220

Post by hermitcrab »

I write commercial applications in Qt/C++ for Windows and Mac. People do ask me about Linux versions. It would be relatively straightforward to port the code to Linux. But the mess of different distributions and libraries really puts me off.

Is anyone here distributing a commercial Qt/C++ app on Linux? Are you using Flatpak or something else?

Post reply on HN