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

231–240 of 410 posts

Re: Flatpak Is Not the Future

#231

Post by ahartmetz »

fsflover wrote: post #214
goodpoint wrote: post #210

Earlier quoted context omitted.

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?

Of course, it's basically the same distribution model. Everything but the kernel and a very basic set of runtime libraries are shipped with the application. Except, I guess, that the basic Windows runtime libraries cover more security-relevant functionality than the same with Flatpak. I'm thinking of SSL, for example.

Re: Flatpak Is Not the Future

#232

Post by mjg59 »

account42 wrote: post #222
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…

> and now apps can't target any functionality newer than 3 years old You can optionally support newer functionality with a single binary by dynamically loading libraries resolving functions at runtime using dlsym or API-specific mechanisms (e.g glxGetProcAddress).

Sure, you could dlopen() different SONAMEs until you find one that works, and now you just have to somehow deal with the structs having changed between versions, and the prototypes of functions not being compatible, so yes it's technically possible but nobody is going to bother

Re: Flatpak Is Not the Future

#233

Post by account42 »

nousermane wrote: post #183
mwcampbell wrote: post #163

Earlier quoted context omitted.

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

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

You can get the same behavior on Linux by linking with -Wl,-rpath,\$ORIGIN (minus the PATH env var, use LD_LIBRARY_PATH for that).

Re: Flatpak Is Not the Future

#234

Post by nextaccountic »

sho_hn wrote: post #66
nextaccountic wrote: post #52

Earlier quoted context omitted.

Just use a deduplicating filesystem. Both btrfs and xfs can deduplicate identical files.

This is misleading. While btrfs and xfs have some dedup functionality, it must be invoked explicitly (e.g. by using `cp` with the `--reflink` argument). For application installation to benefit from this, business logic would have to pre-identify identical files and make such references. There have been some experiments in btrfs to enable inband dedup on arbitrary writes, but nothing that made it in there as yet. Note…

Dedup can be run periodically, with crontab or systemd timers. Here's an example of that: https://aur.archlinux.org/packages/duperemove-service

Re: Flatpak Is Not the Future

#235

Post by ahartmetz »

gens wrote: post #85
alvarlagerlof wrote: post #81

Earlier quoted context omitted.

And AppImage integrates poorly with desktops.

Desktops integrate poorly with desktops.

What do you mean? When I think of "...integrate poorly with desktops", I think of Electron apps. These also have a Flatpak-like distribution (but not security) model. And a "best effort" integration model. Basically, whatever is possible without lifting too much of a finger.

Re: Flatpak Is Not the Future

#237

Post by cromka »

hermitcrab wrote: post #220

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?

Just use AppImage. They can download it as-is from your website and simply run locally. No need to deal with distributions and their package managers.

EDIT: if you use CMake, which I guess you do, you can integrated it using CPack and an external generator: https://github.com/AppImage/AppImageKit/issues/160#issuecomm...

Re: Flatpak Is Not the Future

#238

Post by pas »

addicted wrote: post #133
hules wrote: post #34

Earlier quoted context omitted.

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.

That still does not change the argument that file size does not matter. In fact, this reinforces it. OSX believes file size matters so little they’re willing to double file size simply so users don’t have to pick x64 or x86 when downloading the app (and if they’re using the App Store the App Store could do it for them, but even that Apple thinks is too much complexity).

Folks who have the money for Apple stuff have money for large SSDs and fast unmetered Internet.

Aaaand folks who live in the Apple universe have been accustomed to accept that they are holding it wrong, and that there's someone whose job is to figure out what's the official best way to do things. If it involves downloading 130 megs it's 130 megs. No problem. The UX and end result is worth it for them.

Re: Flatpak Is Not the Future

#239

Post by kayodelycaon »

WastingMyTime89 wrote: post #187
gens wrote: post #47

Earlier quoted context omitted.

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

> Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.

A lot of the vocal people who pick linux are people who want complete control over their systems. Things like wayland, systemd, and flatpak take away some of that control.

Post reply on HN