Flatpak Is Not the Future • Hacker News Board

Re: Flatpak Is Not the Future

#181

Post by the_duke » Tue, Nov 23, 2021, 2:18 PM UTC

mjg59 wrote: post #160

renonce wrote: post #152

Earlier quoted context omitted.

> 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. Have you looked into Nix?

Doesn't Nix ship its own version of every library dependency rather than using system libraries?

Nix allows each package to use a specific version of a library and let's them co-exist via unique paths.

In NixOS the whole system works this way, so there aren't really any global system libraries, except for the graphics system.

Re: Flatpak Is Not the Future

#182

Post by southerntofu » Tue, Nov 23, 2021, 2:19 PM UTC

xet7 wrote: post #44

It seems that Flatpak, Snap and AppImage are the present and future of packages that work on multiple distros. There are no other new alternatives in the article.

You may be interested to check out nix/guix. They're certainly not perfect either, but they represent a radically-different paradigm which can be worth researching.

Re: Flatpak Is Not the Future

#183

Post by nousermane » Tue, Nov 23, 2021, 2:20 PM UTC

mwcampbell wrote: post #163

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…

> but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. Why should that requirement be considered so extreme when, in the Windows world, applications are often required to work as far back as Windows 7 (or were until a year or two ago)?

On Windows, .dll files are automatically searched in quite a few places, including current directory, directory where .exe was launched from, and PATH environment variable. Meaning it is far easier for apps to ship private libraries.

Plus, when linux apps try to ship private libraries, as official chrome packages do, that gets quite some backlash from distro maintainers.

Re: Flatpak Is Not the Future

#184

Post by mjg59 » Tue, Nov 23, 2021, 2:22 PM UTC

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…

If reducing duplication is a goal, static linking or shipping private copies of libraries works against that. Building against standardised runtimes works much better in that respect.

Re: Flatpak Is Not the Future

#185

Post by yoz-y » Tue, Nov 23, 2021, 2:23 PM UTC

mwcampbell wrote: post #163

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…

> but if we want good cross-distribution support we're still going to be limited to what's shipping in the oldest supported version of RHEL. Why should that requirement be considered so extreme when, in the Windows world, applications are often required to work as far back as Windows 7 (or were until a year or two ago)?

But on Windows most applications bring in copies of all of their dependencies. And ask for a 20th version of VC redistributable to be installes.

Re: Flatpak Is Not the Future

#186

Post by esarbe » Tue, Nov 23, 2021, 2:23 PM UTC

AnIdiotOnTheNet wrote: post #125

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…

> There's no way you can make a software run on all systems without requiring at least some infrastructure. Do you want your 64-bit AppImage to install everywhere? To bad! it requires 64-bit glib to be installed. Distributing applications with multiple architecture binaries and the correct one selected at run time is a solved problem. The original MacOS did it as far back as the 68k/PPC transition and the concept has…

And then you want to run it on Alpine which isn't even compiled with glib and everything falls apart.

I think I know what you want to say (please correct me if I'm wrong); you can always provide more formats or reduce dependencies and go deeper.

But to me there's no reason to do that. Some infrastructure is always required, even if you just reduce it to the kernel. Demanding that a piece of software be installable without any (p)requirements whatsoever seems not something that is demanded from anything besides Flatpak (or Snap). So to complain that Flatpaks require a specific service is not a valid complaint.

Given how common Flatpak nowadays is - almost all distros support it out of the box - I would even say that this complaint is not even valid with regards to Flatpaks.

Re: Flatpak Is Not the Future

#187

Post by WastingMyTime89 » Tue, Nov 23, 2021, 2:23 PM UTC

gens wrote: post #47

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…

I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.

You are replying to a comment explaining to you why Flatpak actually works with a dismissive sentence implying it's just a bad technology. Do you have anything substantive justifying your opinion?

From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.

Re: Flatpak Is Not the Future

#188

Post by southerntofu » Tue, Nov 23, 2021, 2:25 PM UTC

tonetheman wrote: post #98

End users do not care about this. If the download works then they are happy. A non-flatpak example is Electron. No one cares how big it is. It works. I download huge games from Steam all the time and have never looked at the size of a game even a single time... in years. Disk space is still cheap on end users machines. As long as the calculator works I do not care how much disk space it takes up.

> No one cares how big it is.

As someone who's helped many friends/neighbors struggling with limited disk space (whether on desktop or Android), i don't think this is true at all. I mean, end-users are usually not conscious what a reasonable size is for an app and will often uninstall one app to install another one instead of complaining of app bloat. They're still very much suffering the problem and care for it.

Re: Flatpak Is Not the Future

#189

Post by wander_homer » Tue, Nov 23, 2021, 2:27 PM UTC

riidom wrote: post #30

From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working". What kinda annoys me though is that file dialogs open in the background. Now I am used to check for it, but when the main window is still in front, yet blocked, because focus is i…

> From my subjective (user) point of view, flatpak is pretty fine. Yes, I do get annoyed whenever I run flatpak update and see 5-10 updates to drivers or runtimes in the range of ~100MB each. But I also want applications to be "just working".

For most updates those download sizes are not really representative for the actual update size. For example right now I had two updates available with a total size of 336.5 MB + 275.2 MB. However `flatpak update` actually only had to fetch 17.4 kB + 4.4 kB and was done in a few seconds.

Re: Flatpak Is Not the Future

#190

Post by xtracto » Tue, Nov 23, 2021, 2:30 PM UTC

Meh... i used to install tarballz, hunting for .so files, then RPMs hunting dealing with circular RPM dependencies, then DEBs dealing with unmet dependencies. As I age all that got boring. I hate Snaps because of how intrusive is with the system.

Flatpak brings Linux to what OSX had like 10 years ago. It just works

Regarding download size? Even I, living in a third world country, have an internet connection good enough to not care about download sizes...

Regarding file redundancy. If that is much of a problem for anyone, I'm sure that could be dealt with at the file system layer: hash/detect duplicate files and compact them, then copy on write. Personally, HDD space hasn't been an issue for me on PC or laptops in a long time.

Flatpak finally just work and we have the technology to make it usable. Moreover I argue that flatpak IS the future as those 2 previous points will become more irrelevant as time goes by.