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

151–160 of 410 posts

Re: Flatpak Is Not the Future

#151

Post by kirbyfan64sos »

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?

Re: Flatpak Is Not the Future

#152

Post by renonce »

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…

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

Have you looked into Nix?

Re: Flatpak Is Not the Future

#153

Post by kirbyfan64sos »

user0123895264 wrote: post #140
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…

I might be imagining it, and there might be another cause, but I stopped using Elementary after the latest release after many things moved to Flatpaks because I kept running out of memory. (On Endeavour/Arch, installing everything natively, I no longer have the problem.)

If I had to guess, the update might have just introduced a memory leak somewhere else in the system?

Re: Flatpak Is Not the Future

#154

Post by southerntofu »

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…

> Now that each language has their own package manager, the role of distributions have faded.

Yet most language-specific package managers are deeply flawed compared to distro package managers. But i agree with your sentiment that beyond LTS for enterprise, the deb/rpm packaging paradigm is becoming obsolete. I believe nix/guix form an interesting new paradigm for packaging where there is still a trusted third party (the nix/guix community and repo) but where packaging doesn't get in the way of app developers.

I'm especially interested in how these declarative package managers could "export" to more widely-used packaging schemes. guix can already export to .deb, but there's no reason it couldn't produce an AppImage or a flatpak.

Re: Flatpak Is Not the Future

#155

Post by southerntofu »

post-it wrote: post #120
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…

Package managers that integrate apt, flatpak, and (potentially) snap are a nice solution. Unfortunately, the one that happens to be on my system (Pop!_Shop) is awful .

Could you maybe elaborate, or link to more detailed criticism of Pop! Shop? I've also found that GNOME Software did a rather poor (though not that bad) job of exposing the multiple sources for a given package, but i believe this can be fixed with better UX (though i'm unaware of work being done in this space).

Re: Flatpak Is Not the Future

#156

Post by southerntofu »

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…

> Nix/Guix seems like the only one that's trying something different enough to address some of those other use-cases, but the cat's out of the bag for most people.

Maybe that's because nix and guix don't interop despite having rather similar principles, and because we mostly don't have GUI for it (like GNOME Software has integration for flatpak) nor desktop integration (like AppImageLauncher). Are you aware of work being done in this space?

Re: Flatpak Is Not the Future

#157

Post by mwcampbell »

> The state of software development is downright miserable in 2021.

This tired refrain shows an obscene lack of gratitude for all the things that just work. Yesterday evening I participated in a Twitter Space on gratitude for all the great things we have as software developers, and I will repost the recording here when it's available.

Edit: My mistake; the recording was already posted: https://www.youtube.com/watch?v=U10SuAHV8kQ

Re: Flatpak Is Not the Future

#158

Post by southerntofu »

faho wrote: post #114

> How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game? If the steam runtime didn't exist, most gamedevs would only target the most popular distro - probably the current Ubuntu LTS, and you would have to…

Yet the steam runtime could be maintained/distributed using a more robust and explicit mechanism such as guix or nix, don't you think?

Re: Flatpak Is Not the Future

#159

Post by teekert »

0x0nyandesu wrote: post #17
capableweb wrote: post #16

Earlier quoted context omitted.

Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.

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.

Snaps can do this

Re: Flatpak Is Not the Future

#160

Post by mjg59 »

renonce wrote: post #152
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…

> 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. Have you looked into Nix?

Doesn't Nix ship its own version of every library dependency rather than using system libraries?
Post reply on HN