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

161–170 of 410 posts

Re: Flatpak Is Not the Future

#161

Post by southerntofu »

trollied wrote: post #41

My experience with these is terrible. I install a JetBrains IDE via a package. I spent a very long time trying to debug a CMake problem that I assumed was my inexperience with CMake. After attacking various processes with strace, it dawned on me that the problems were caused by the IDE not being able to see files in /usr/local. A sandboxed dev environment! Lost for words... A relatively inexperienced dev would have a…

Can't upvote this enough. As other commenters have pointed out, understanding why certain features/patterns don't work in a given app due to sandboxing is a major hurdle.

Re: Flatpak Is Not the Future

#162

Post by southerntofu »

AnIdiotOnTheNet wrote: post #118
necovek wrote: post #22

The most important takeaway from this is, to me, the need to separate sandboxing from dependency management. However, as can be seen with AppImage, which seems to be strictly focused on dependency management, that results in bloat. It would be great if we could have a sandboxing solution that ignores the dependency management altogether. The problem is not with Flatpak or Snaps (or Docker). The problem is that the fr…

> Backwards compatibility is hard in software in general I disagree. Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop. That suggests the problem isn't hard, it's just that the culture of Linux Desktop is incompatible with the concept.

> Pretty much every desktop OS in the world manages to get quite a lot of backwards compatibility without a whole lot of trouble, except for Linux Desktop.

That's not at all my experience with Windows or MacOS. Sure some older apps work fine, but certainly not all of them.

Re: Flatpak Is Not the Future

#163

Post by mwcampbell »

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

Re: Flatpak Is Not the Future

#164

Post by josefx »

Gigachad wrote: post #58
0x0nyandesu wrote: post #17

Earlier quoted context omitted.

A typical system will end up with 10 versions of some .so library on disk. Sometimes more. Disk usage waste everywhere. You're better off having a package manager that can link multiple versions at the same time to the programs that need it instead of bundling.

it’s been tested and almost all library packages are only used by one other package on the system. And almost all of the sharing comes down to a very limited set of libraries. Flatpak solves this with platforms. You can base a package on the gnome platform for example and get a whole bunch of the most used libraries. But even without platforms, disk space is one of the most abundant resources right now. You could ins…

> it’s been tested and almost all library packages are only used by one other package on the system.

I have a KDE desktop, are you trying to imply that only one of the dozens of applications provided by it actually use Qt? That only one of the dozens of image related programs use libpng, libtiff,libjpeg, etc. ? Or are you just citing a highly misleading statistic?

Re: Flatpak Is Not the Future

#165

Post by southerntofu »

panick21_ wrote: post #96

> If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating sys…

> This sound like a luddite that is against machines.

The luddites were not anti-tech from a moral perspective, but understood mechanization of work to profit the bosses and go against the interests of workers (artisans) and therefore practiced sabotage. Despite this initial mischaracterization, i believe the metaphor holds and the author is against this application of this technology precisely because they believe it produces a net negative impact across the ecosystem.

Re: Flatpak Is Not the Future

#166

Post by mjg59 »

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

I'm trying to scope the "Just use system libraries" approach into one that's realistically achievable. I agree that this shouldn't be an extreme requirement, but it turns out that most app authors aren't terribly interested in restricting themselves to the libraries shipped in RHEL 7, so.

Re: Flatpak Is Not the Future

#167

Post by panick21_ »

ltbarcly3 wrote: post #145
panick21_ wrote: post #96

> If you are a Linux distribution maintainer, please understand what all of these solutions are trying to accomplish. All your hard work in building your software repository, maintaining your libraries, testing countless system configurations, designing a consistent user experience… they are trying to throw all of that away. Every single one of these runtime packaging mechanisms is trying to subvert the operating sys…

The whole point is that this is technically worse and only being used to try to bootstrap a walled garden where they (RedHat, Canonical for flatpack or snap) get paid a fee due to a monopoly on app distribution to their users. This is not 'the revolution' we should support. I encourage you to study the technical arguments until you understand them well enough that they become convincing.

> monopoly on app distribution to their users

And the argument that it is a walled garden is simply nonsense. Its not monopoly any more then any default repository is.

> I encourage you to study the technical arguments until you understand them well enough that they become convincing.

I have been using flatpak since it came out and many other people in this thread have already pointed out the failure of the technical arguments, no need to do that again.

Re: Flatpak Is Not the Future

#168

Post by southerntofu »

kirbyfan64sos wrote: post #151
david_draco wrote: post #116

Re security: This is probably best fixed by packaging apps with SELinux rules, which are enforced and cannot be disabled, plus responsive maintainers. There could be more than one app version to allow different SELinux rule strengths, per-app. Re disk space: no mention of Nix? That also solves updateability for security issues. Another solution is Gentoo's -- deliver the sources and recipes, (re)build as needed. That…

Making LSM-based rules for desktop applications is relatively complex and inflexible (what if the user wants to grant access to a file for a short amount of time? Portals let you do that). Are you rebuilding policies on the fly?

Is there a reason SELinux/AppArmor policies couldn't be live edited for that kind of purpose? As it is it would require root, but wouldn't it be possible to extend security rules with user rules which could add restrictions but not lift system-wide restrictions? This (hypothetical) way we'd package eg. GIMP with a user profile restricting it to ~/Documents and /media/USERNAME, but you could then grant it additional permissions (eg. to ~/Pictures).

Re: Flatpak Is Not the Future

#169

Post by asoneth »

A good illustration of why easy wins every time.

In my experience, Flatpack and their ilk make it easier for end-users to install applications and for developers to distribute them.

Alternatives may be orders of magnitude better from a performance, size, and/or complexity standpoint but until they're at least as easy for both end-users and developers they'll never reach critical mass.

Re: Flatpak Is Not the Future

#170

Post by southerntofu »

oleg_antonyan wrote: post #69

As Linux user and app developer (shameless plug https://github.com/olegantonyan/mpz/ ) I deliberately avoid snap/flatpak/appimage/etc. Instead, I suffer with Open Build Service https://build.opensuse.org/ . It's kind of cool, free and can build for multiple distros, but making it actually do so is a pain. But I still prefer this over flatpak&co both as user and as developer. It just doesn't look like "the future of a…

> Open Build Service

I heard about that before, but never tried. How in practice do you deal with conflicting library versions?

> It just doesn't look like "the future of application distribution", https://nixos.org/ does.

Strongly agree. I just find it sad that nix/guix doesn't have proper desktop integration (to my knowledge), and that nix requires nixGL hacks to start any GUI on foreign distros.

Post reply on HN