undefined | Better HN

0 pointsalerighi3y ago0 comments

Having two ways to update the system doesn't either seem great to me. Having the same software that can be installed from two sources neither.

Also as far as I remember flatpack is something more complex than a simple package format, it has a runtime where each application runs in an isolated container where it can access only some of the resources (e.g. the filesystem). This adds to me useless complications to a system.

I think that the best approach to the integration of third party software is the one followed by ArchLinux, that is the AUR: a series of build instructions, maintained by the community, that allow you to package practically any piece of software that exists.

0 comments

2 comments · 1 top-level

Gigachad3y ago· 1 in thread

The requirements for something that updates the OS and updates/manages applications/games is extremely different. Traditional package managers work but they are far from ideal.

They are completely inadequate for closed source software like games. Flatpak provides a stable platform you can target and it just keeps working across distros and in to the future while rpm/deb packages require constant maintenance.

Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do. The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.

alerighiOP3y ago

> They are completely inadequate for closed source software like games

Why? What difference does make the license of the software? The only trouble is that the developer of the proprietary software has to package it in a number of formats and have repositories to download updates (that are HTTP servers with some special files in it). In reality to this day you just have to package a .deb, and if you want .rpm. For other distros these packages can be converted practically automatically (this is what is done with ArchLinux AUR for proprietary packages like Spotify or Chrome that are installed from the deb version).

> working across distros

This doesn't have a lot to do from the packaging format but on how you write the software. If you dynamically link 2000 system libraries you can as well use flatpack but the software will not work since typically on Linux the ABI is not that stable. If you have a single statically linked binary with MUSL libc you can as well package it as a deb and run it on Debian 4 that it will probably work.

> Flatpak also provides a long list of essential features like permissions, sandboxing, portals, etc which most other OSs do

They are not essentials. And they cause more problems to the user than what they solve. And don't talk me about using containers for security, since they don't provide any useful and proven safe isolation. On the other end you have SELinux/AppArmor that you can apply easily on any executable regardless of the packaging format.

> The future of linux is likely immutable OS images with something like OSTree, and then flatpak for end user apps.

This is wanting to go in the direction of what Apple does on macOS/iOS where the / is immutable. I think that people use Linux because it's different, if not they would just buy a MAC. These are complications that gets you in the way.

Linux users wants to be able to build the system by picking the components they want, not the components that Canonical or Red Hat decided that they must be present in their distribution.

j / k navigate · click thread line to collapse