Flatpak Is Not the Future • Hacker News Board

Re: Flatpak Is Not the Future

#311

Post by Spivak » Tue, Nov 23, 2021, 6:38 PM UTC

tremon wrote: post #260

pas wrote: 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?

No because that’s not the model of Flatpak. If that library is in a runtime then that runtime is patched and updated. If that library is is part of the application then the app is patched and updated.

Just pretend that all Flatpak apps were statically linked. Would you have the same complaints? Or would you say that version $x of this app is also affected by the CVE?

In one situation you run apt update and another you run flatpak update.

Re: Flatpak Is Not the Future

#312

Post by oynqr » Tue, Nov 23, 2021, 6:44 PM UTC

smoldesu wrote: post #264

freebuju wrote: post #147

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…

Counterpoint: Flatpak doesn't really solve anything, and I have no reason to use a Flatpak'd version of a software when there's a native version in my system repos. A lot of people feel this way: they see it when Flatpak doesn't adopt their native system theme, they see it when they try opening a filepicker and it starts in some esoteric location, they see it when they want to edit files of a Flatpak'd app and need t…

Apps not adopting to your theme is a feature, at least when you ask some Gnome devs.

Re: Flatpak Is Not the Future

#313

Post by jcelerier » Tue, Nov 23, 2021, 6:45 PM UTC

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?

Vouching for AppImage too, I ship https://ossia.io like that

Re: Flatpak Is Not the Future

#314

Post by gens » Tue, Nov 23, 2021, 6:50 PM UTC

ahartmetz wrote: post #235

gens wrote: post #85

Earlier quoted context omitted.

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.

When i think of "desktop integration", i think about drag and drop not working between `ark` (a QT program) and `thunar` (a GTK program), and i think of folk writing blog posts about window theming. (there's also notifications, icons, etc, blablabla, that keeps getting worse (freedesktop is, that is))

To be honest, i don't care much about how programs look. But i do know many people do care.

Re: Flatpak Is Not the Future

#315

Post by betwixthewires » Tue, Nov 23, 2021, 6:56 PM UTC

So I love linux. Particularly, as a desktop system, I like Arch and derivatives of it, mainly for the pacman package manager and the Arch user repository.

But I have trouble finding packages, and I hate to compile. So I use Debian instead.

I would rather just use a distro that isn't ideal for me than start using flatpak and snap and all this other stuff. I really don't like how fragmented packaging is in the Linux world, but I will not use these prepackaged containers that have all dependencies included. They're worse.

Re: Flatpak Is Not the Future

#316

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

gens wrote: post #302

WastingMyTime89 wrote: post #187

Earlier quoted context omitted.

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 >I The real problem with flatpacks is that they don't so…

> The fact that, as i mentioned, it is just a package manager. And a bad one.

If you don’t mind me asking again, why is it bad? Because the rest of your post certainly doesn’t answer that question.

I understood that you don’t personally like that libraries change. Unfortunately, they most definitely do and no, preventing everyone on earth from ever releasing an incompatible library is not a realistic solution.

> I just fucking hate the "ohh, you just don't like change" people.

Well, you definitely are complaining about change a lot in a very impassioned way.

Re: Flatpak Is Not the Future

#317

Post by brnt » Tue, Nov 23, 2021, 7:10 PM UTC

curt15 wrote: post #202

southerntofu wrote: post #146

Earlier quoted context omitted.

I think it's great, but we're still far off from an ideal solution because it's not exactly fine-grained. For example, flatpak portals enable me to grant/block access to my home folder, but don't enable me to allowlist a specific folder in my home. So i'm stuck with the possibility that a vulnerability in the app can take over my entire system (eg. by rewriting ~/.profile), or with my app not accessing my home folder…

>As a user, I'd like to give Krita/Libreoffice permissions for ~/Documents and Tor Browser permissions for ~/Downloads. I don't know yet of a user-friendly method to achieve that. The filesystem permissions are a bit more fine-grained than "all of home or nothing". Your two examples are already possible to achieve by granting filesystem access to xdg-documents or xdg-downloads.

So many flatpaks do this incorrectly though. For Browser by default saves in the flatpaks home/Downloads directory (which is 15 layers deep from ~). You just gotta know to navigate up.

Signal let's you save attachments anywhere on disk, but only if you manually navigate to ~/Downloads, does it actually save (in a way visible and accessible outside of the app). You just gotta know.

I forgot what exactly the problem was with Vscode(/ium), but it also has a catch like that. You just gotta know.

Flatpak turns out to be the best compromise between distribution and cross distro compatibility, but there's still some low hanging fruit that could be improved.

Re: Flatpak Is Not the Future

#318

Post by joconde » Tue, Nov 23, 2021, 7:14 PM UTC

jcelerier wrote: post #297

goodpoint wrote: post #255

Earlier quoted context omitted.

>> - 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. > As opposed to what? Opposed to distributions providing targeted updates to each package. > Dynamic linking does not solve this problem, contrary to popular belief. On the contrary it provably works very well for distributions. >>- Long term…

> On the contrary it provably works very well for distributions. if it worked very well there wouldn't be a need for flatpak / snap / appimage / etc. How do I install an older or newer inkscape / ardour / krita in the latest debian stable / ubuntu / fedora / whatever without recompiling stuff ?

The sentence you're answering was about security. I don't think "fixing vulnerabilities faster" is something Flatpaks were created to solve. It was more of a solution to dependency hell, that makes vulnerabilities harder to fix and audit.

I see the same issue with Docker services I deploy: how am I supposed to check that the latest Nginx security update is included in all my docker-compose deployments? With shared libraries, it's as simple as "apt-get upgrade" then restarting the services. In Docker, I'd have to check that the latest versions of all images include the correct versions of all dependencies.

Re: Flatpak Is Not the Future

#319

Post by joconde » Tue, Nov 23, 2021, 7:31 PM UTC

danShumway wrote: post #309

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…

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

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

Does that mean I'll download one copy of libThatWasUpdated for every app that uses it?

Seems like this is exactly like iOS and Android work. I see the appeal (they are definitely more secure against malicious apps than Linux with apt-get), but the waste of space still bothers me. Docker has the same issue, and didn't really solve it with its layered filesystem (you always need several dependencies, but you can't merge images, so you'll need to install a new copy of some of them).

These packages also make it hard to audit the versions of security-critical code installed on my system. It's good that they can be updated separately by the OS, but at least when apt-get was upgrading shared libraries, I could be sure that all programs had the fix. Now I'll need to go dive into each package to know if it should be allowed to run, or if I should wait for the upgrade.

Re: Flatpak Is Not the Future

#320

Post by joconde » Tue, Nov 23, 2021, 7:40 PM UTC

WastingMyTime89 wrote: post #316

gens wrote: post #302

Earlier quoted context omitted.

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 >I The real problem with flatpacks is that they don't so…

> The fact that, as i mentioned, it is just a package manager. And a bad one. If you don’t mind me asking again, why is it bad? Because the rest of your post certainly doesn’t answer that question. I understood that you don’t personally like that libraries change. Unfortunately, they most definitely do and no, preventing everyone on earth from ever releasing an incompatible library is not a realistic solution. > I ju…

>> I just fucking hate the "ohh, you just don't like change" people.

> Well, you definitely are complaining about change a lot in a very impassioned way.

They are complaining about people who assumed an irrational reason for their opposition to something, while they have a rational one. I find that kind of assumption condescending ("let me, the rational one, explain to you how to get rid of your insecurities so you can appreciate how right I am") and kind of infuriating too.

> I understood that you don’t personally like that libraries change.

If you add breaking changes without maintaining the backward-compatible version for a reasonable amount of time, I'd argue your library isn't fit to be a dependency for anything important. I definitely wouldn't use it.

The Python package ecosystem may be a mess, but I still manage to use dozens of shared packages daily with quite rare breaking changes, even in libraries that see a lot of developments. I would prefer that we focus on improving API stability for shared libraries, instead of giving up and duplicating dependencies everywhere.