Flatpak Is Not the Future • Hacker News Board

Re: Flatpak Is Not the Future

#201

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

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…

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

Re: Flatpak Is Not the Future

#202

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

southerntofu wrote: post #146

curt15 wrote: post #65

Earlier quoted context omitted.

Flatseal gives users a GUI to manage the permissions of each app. Would that address your concern?

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.

Re: Flatpak Is Not the Future

#203

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

enriquto wrote: post #25

edent wrote: post #21

I agree with all of this and... I just don't care. I download a Flatpak from the Pop OS store and it works. It installs only in my profile, so another user on the same machine doesn't have access. You can't do that with a .deb! I've never got into dependency hell where I need to apt-get a specific version of a library from a dodgy PPA. If I uninstall it, Flatpak doesn't leave acres of cruft strewn around my disk. I d…

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

Re: Flatpak Is Not the Future

#204

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

the_duke wrote: post #181

mjg59 wrote: post #160

Earlier quoted context omitted.

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.

NixOS is the only sane Linux distro on the planet now. At the end of the day every distro wants their own app store.

Re: Flatpak Is Not the Future

#205

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

bogwog wrote: post #200

This gave me an idea: how about shipping an installer with an embedded appimage. The installer will check the system libraries for compatibility, and if compatible, it will install the application so that it uses the system libraries. If not compatible, it will install the appimage (and do the desktop integration stuff). I actually really like appimages for distributing games and small apps. The user experience is a…

In this scenario, what would be the point of deferring to the system libraries if you already shipped and made the user download the built in ones? As far as desktop integration goes, there is already a tool available that will setup the .desktop file for you when you first run an Appimage.

>The lack of sandboxing isn't a big deal in my eyes

It should be, executing random Appimages you've downloaded online is a huge security liability.

>Proper sandboxing needs some kind of gate keeper/moderator to pressure developers into following the rules

You make a good point in that a good moderation in the store is very important, but even lacking that you can still tweak the sandbox permissions yourself (very easily in fact with Flatseal) and it rocks to have that feature available to you.

Re: Flatpak Is Not the Future

#206

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

simiones wrote: post #173

zimbatm wrote: 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. 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…

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

Not really no. It's both simpler and more complicated.

At the very low level, everyone expects to get a POSIX system. At the user level, most users use either Gnome or KDE (well mostly Gnome to be honest but let's pretend) which provides what could be called a highlevel SDK for applications.

That leaves the layer inbetween which used to be somewhat distribution specific but is seeing more and more consolidation with the advent of systemd and flatpak.

Re: Flatpak Is Not the Future

#207

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

goodpoint wrote: post #201

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…

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 to distributions is absurd, as there is no aim to replace your precious "properly" managed dependencies and the option to never opt-in will be always available.

Re: Flatpak Is Not the Future

#208

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

southerntofu wrote: post #146

curt15 wrote: post #65

Earlier quoted context omitted.

Flatseal gives users a GUI to manage the permissions of each app. Would that address your concern?

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…

They already do with filesystem access. You can specify XDG folders or any specific folder you like[1].

[1] https://docs.flatpak.org/en/latest/sandbox-permissions.html#...

Re: Flatpak Is Not the Future

#209

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

pfranz wrote: post #88

mrweasel wrote: post #36

My main complaint about solutions, like Flatpak or Snap, is that they add another package manager. Now I have to manage two sets of packages. The baseline tools, like all the GNU standard Unix tools, and other command line tools are still managed by DNF, APT, whatever, and then another set of apps are managed by Snap. It's pretty confusing, especially if you never use the "app stores" otherwise. You quickly end up wi…

You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs, I often found myself building from source and installing into my homedir because package managers wouldn't accommodate, industries (like…

>You should point the finger at package managers. They never really addressed needs outside of system administration (to be fair, that's the problem they were trying to solve). Scripting languages came up with their own package system because package managers didn't fit their needs

I argue that's simply not true. Scripting languages came up with package managers because the largest platform (Windows) does not have a package manager. Actually that scripting languages implement package managers is a very good argument that their functionality is desired. As a side note, every language package manager is much worse in my experience than all of the system package managers I ever used.

Re: Flatpak Is Not the Future

#210

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

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 to maintain yourself.

- Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk.

- Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.