Live data from Hacker News

Flatpak Is Not the Future

ludocode.com

301–310 of 410 posts

Re: Flatpak Is Not the Future

#301
post #40

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

> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API.

In practice I don't really see a difference, I link against Qt on all platforms, win, mac, linux, wasm, android... and that's it.

Re: Flatpak Is Not the Future

#302
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…

I never said it doesn't work. And yes, i do have "anything substantive" against it. The fact that, as i mentioned, it is just a package manager. And a bad one.

> From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change.

This is what pisses me off. You, nor anyone else, can tell everyone else what >IThe real problem with flatpacks is that they don't solve the real problem, and they do it poorly.

Want to solve the problem of your program not running on multiple distros, or not running in 5 years ? Then look at why that is. For example; it's not that the zip file format will change, so why must i recompile my program every time libzip changes ? Or X11 to wayland transition; why does my program have to even care about that when all i want is a window and an opengl context ? (bdw the solution to the latter is SDL2)

Let's look back when flatpack started. Why did it start ? Maybe because GTK3 changed it's API ever so often ?

Linux doesn't have a good GUI toolkit. THAT is the biggest problem here.

I just fucking hate the "ohh, you just don't like change" people. That dismisses all further discussion. That is the real "hate" that people like you blame others of.

Re: Flatpak Is Not the Future

#303
post #286

Earlier quoted context omitted.

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

How so? I feel like this is just unfamiliarity / resistance to learning. It's not like these new tools prevent you from accessing their internals. The internals are all still "right there." They just have internals that have been engineered for efficiency over composability or observability. For example, journald. People know and understand "rotated-gzipped text .log files in a /var/log directory." People don't know,…

Yup. It's that the formats are less transparent and less familiar. Binary data doesn't play well with the traditional unix tools.

Re: Flatpak Is Not the Future

#304

Earlier quoted context omitted.

Yes, in order to increase their backwards compatibility Microsoft has, historically at least, done things like that. However, mostly they achieve backwards compatibility by just not breaking ABIs all the goddamned time. Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications c…

You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it. When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that t…

You misunderstand. I am saying that all that effort was spent chasing the long tail of compatibility, which is valuable if compatibility is one of your big selling points.

However, one need not go to such extremes to get a good amount of compatibility, just don't have a policy of breaking ABIs constantly the way Linux Desktop does.

Re: Flatpak Is Not the Future

#305
post #260
post #228

Earlier quoted context omitted.

Debian could provide their packages as flatpacks too. Not to mention that container images are still mostly built by using regular packages, aren't they? (So they are not as opaque, nor the regular packages go untested.)

So they are not as opaque Ok, say a wild CVE appears and it says libblip versions 1.3 through 2.0.4 have a severity-10 RCE vulnerability and should be patched ASAP. If the container images and flatpaks are not opaque, I presume you have a simple command that lists all vulnerable library versions that are present on all the machines you administer? And, subsequently, that you have an easy procedure to patch them all?

If Debian (or whatever org/group/project/initiative that) provides the images has a security policy, they can extend that to the images too.

Users don't run CVE checkers [0], at best they reluctantly click on the update button. Of course the authoritarian evergreen auto-update thing is what actually works in practice.

For example as much as snap's UX sucks it does auto update by default.

[0] Though they could, as files in container images are trivially accessible, after all it's their purpose. Plus there are metadata based approaches: https://github.com/TingPing/flatpak-cve-checker (plus the Flatpak project already spends some energy on ensuring that the base image is chechekd against CVEs https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/18... ) of course duplicating this effort, and building a parallel world besides packages is not ideal

Re: Flatpak Is Not the Future

#306

Earlier quoted context omitted.

SystemD is not harmful for distributions. Flatpak replaces high-granularity, properly managed dependencies and security updates with huge blobs.

Flatpaks are not meant to replace established package managers, but to act as a supplement to them. Flatapak's design decisions go to huge lengths to ensure they are a side-by-side system with default package managers e.g. the notion that Flatpak packages have a different XDG_CONFIG directory so as not to conflict with applications installed via the main package manager. Therefore the argument that they are harmful t…

> Flatpaks are not meant to replace established package managers, but to act as a supplement to them.

I'd be genuinely surprised if distributions like Fedora still use, or actively maintain, RPMs for any GUI software after a few years.

Re: Flatpak Is Not the Future

#307

Earlier quoted context omitted.

> On Windows and macOS, there are some SDKs the application can lean on. On Linux, the only stable "SDK" is the Linux kernel API. This is a very good observation I think. Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. Basically, they are failing to…

> Basically, what Linux distributions have failed to do is to create a higher level SDK for their platforms - instead, they rely on a soup of libraries and on the package maintainer model to know which of these is which. At the same time, the tools which solve this really shine. You inevitably run into these issues with random third party dependencies on other platforms, too, but it's further from the norm, so you en…

It also makes some software under the Gnome umbrella incredibly hard to package for distributions.

Re: Flatpak Is Not the Future

#308
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…

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

I mean, on windows if I use a given libc, say msvcrt or ucrt (or heck, newlib with cygwin) I have to ship it anyways with my app. Linux makes that harder but in practice there's no way around this.

Re: Flatpak Is Not the Future

#309
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…

Worth noting that nothing about Flatpak necessitates that distro maintainers can't compile their own Flatpak apps the same way they currently do. Debian can still compile Firefox from source and patch out trackers and update dependencies, even if at the end of the day it bundles the changes back into another Flatpak app.

In fact, the lack of interdependence between apps makes this considerably easier, because a Debian upstream that sits in the middle and custom-compiles it's "official" software can release security updates immediately for critical apps with critical security flaws -- without waiting to make sure that the security fixes don't break some other app.

Flatpak does not require you to have a separate upstream for every app, or to get your updates straight from the developer. Debian can still be a middleperson and they can still do all of the same moderation/customization/legal analysis.

----

Very importantly, on security, Flatpak is a paradigm shift away from the existing model of needing complete trust for the entire app:

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

A big part of this is that you don't trust random developers with Flatpak, or even your own distro maintainers. Most applications do not need the level of access they have by default. The end goal of Flatpak (it is debatable whether it is achieving this, but the goal at least) is to significantly shrink the attack surface of your app.

If your calculator app doesn't have file access, or network access, or process forking, or any of these things because the runtime blocks them (and honestly, why on earth would it ever need those things), then it is a lot less dangerous for your dependencies to go out of date. A calculator should not need to worry about updating its dependencies, because it should not have access to anything that could be abused.

Now, that's an extreme example. Many apps will not be in the position of needing no privileges, but many of them will still be able to have their attack surfaces shrunk. Firefox for example really shouldn't have that much access to my filesystem. Apps should not (in general) share parts of the filesystem except in user-defined contexts. Many of them don't need Internet access at all.

Flatpak makes it easier for dependencies to go out of date, but it also (ideally) drastically reduces the number of potential security flaws you can have in the first place, and drastically reduces the ability of apps to exfiltrate data from other apps (again, this is the ideal, see X11 vulnerabilities + Wayland for how much of an ongoing process fixing Linux security is).

----

I would question a few things:

- Is the reduction in attack surface big enough to balance out the extra attention users/devs need to pay to updating dependencies?

- How many security vulnerabilities are due to dependency issues vs data exfiltration from the home folder, or from other apps that they have no need to access? Linux security is kind of a disaster in this area, how many vulnerabilities would we fix immediately just by sandboxing filesystem access so /home wasn't a free for all?

- Is this actually blocking maintainers from releasing security patches or making it harder for them to do so? I would argue no, I think the maintainers can do the exact same things they're doing today, and that their job may be even easier when they don't need to hold up an entire house of cards with every release.

- Is it better to trust Debian to try and patch out every tracker/telemetry, or is there an improvement to having apps that don't require Internet access just be flat-out unable to call home or send telemetry in the first place? I don't think this blocks maintainers from doing their jobs, and it means I just don't have to worry about trackers at all in my calculator app, even if I download it from a 3rd-party source.

----

The weak point here is other Linux vulnerabilities (gotta get off X11!), UX (an eternally hard problem to solve), and Flatpak immaturity/mistakes (I don't like that manifests are still a thing, portals are still being built, I think permissions could be better). But the fundamental concept here isn't bad. People rely on shared libraries/runtimes for a lot of things that they don't need shared runtimes to get.

And I can't stress enough: distros can still moderate and compile custom versions of Flatpak apps.

Re: Flatpak Is Not the Future

#310

Flatpak is the future of Linux desktop applications for so many reasons, but among them it allows users not to be caught up in the dependancy mess that plagues Linux distributions. Some of the criticism here does not belong to Flatpak. E.g Fedora's weird duplication of repositories is exclusively a Fedora problem. Has absolutely nothing to do with Flatpak. Applications such as VLC and GIMP which 'ship' with access to…

> Applications such as VLC and GIMP which 'ship' with access to whole filesystem permission is an eternal dilemma. Would you rather the authors ship without access to this permission and break app functionality ?

to give a data point, I work with a lot of artists who use Macs and none of them use mac app store apps because of endless issues when accessing the file system

Post reply on HN