Flathub to verify first-party apps and allow developers to collect monies

Look at it from the application developer point of view:

deb/rpm and even AUR requires a maintainer; It's extra work for the developer that takes them away from the actual code to do packaging.

Programs these days update quickly, multiple times per day. It is not feasible to have a volunteer package maintainer for each distro.

Also look at it from the end user point of view:

Installing/updating a program by doing something that is not just clicking a button is too hard for most people.

Naive users depend on latest version of niche programs to do stuff; they have to be easily installable and upgradable.

Linux wide adoption depends on this. It doesn't matter for us that already know how to use linux the way it is, but it will make a huge difference for wide adoption.

With Flatpaks, the app developer makes a single package for all distros and that is it; If the application is open source, the package maintainers can still package it differently if they want. But the developer can have a single target and reproduce the bugs in a replica of the same environment; Flatpaks are a dream for end user application developers.


Last edited by nosklo on 23 January 2022 at 12:09 pm UTC

To be honest, if it ever gets to the point where I HAVE to use Flatpaks, I'd probably go back to Windows.

Choice is good, but there is just far too many things I hate about flatpaks. I just don't think it's a viable alternative to debs.

Quoting: pleasereadthemanualFor proprietary games, sure. And for distributions on a slow release schedule with frequently like Debian, Ubuntu LTS, and even Ubuntu proper, sure.

On a rolling-release distribution like Arch? No way. All of the packages are up-to-date, and if they're not, they are up-to-date in the AUR. Flatpak is way too much complexity for me. I tried it when I was new to GNU/Linux and it confused the hell out of me. I'm sure I could manage it now, but I don't want to. I don't mind AppImages because they tend to manage themselves and aren't particularly ambitious. However, even they tend to have less features than the non-sandboxed version (see the Cinelerra-GG handbook for the differences).

I'd rather games come with a .sh install script like GoG games do than be required to deal with Flaptak. I see no place for it on distributions like Arch Linux.

The downside of that of course is you don't get notified when there is a new .sh installer.

So I think the negatives of AppImages is that they will cause duplication of libraries. Flatpak actually depend on the flatpak library version it needs, so should take care of that problem, though it still won't use system libraries, so does cause duplication there. Flatpack installed packages having their own library downloading seems like it could be a different security layer than say one you got via 'apt install <package>' though.

But for sure, Flatpak / AppImage is useful for distributions that are a little bit slower to release updated software.

AUR also has some downsides, like people getting bored of maintaining the PKGBUILD, and it becoming orphaned.

While checking to see if Flatpak supports musl-based distributions like Alpine (it does), I found the antithesis to this article: Flatpak is Not the Future. Well-reasoned and includes points that I simply didn't know about.

Quoting: AussieEeveeTo be honest, if it ever gets to the point where I HAVE to use Flatpaks, I'd probably go back to Windows.

Choice is good, but there is just far too many things I hate about flatpaks. I just don't think it's a viable alternative to debs.

I can't go back to windows.. no way no how.

It'll be BSD for me next if I have to, I don't mind it I've had past experience with it so I'm fairly familiar with it.

Flatpak is the future for stale distros still living in the '90s. For rolling distros (which IS the future) it's useless and stupid.

Switch to a rolling distro and you will never have dependency hell issues again, nor bloat your system with disputable package formats. Having a big amount of different flatpaks can also lead (internaly) to dependency hell.


Last edited by sudoer on 25 January 2022 at 1:50 pm UTC

Quoting: sudoerFlatpak is the future for stale distros still living in the '90s. For rolling distros (which IS the future) it's useless and stupid.

Switch to a rolling distro and you will never have dependency hell issues again, nor bloat your system with disputable package formats. Having a big amount of different flatpaks can also lead (internaly) to dependency hell.

I don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

So if it was genuinely the case that some particular "rolling release" distro did not suffer dependency hell, it would have to be because of a superior package management system or people doing packaging for the distro just being really good at it. To call things what they are, since there's only one really significant rolling release distro (well, technically Debian but nobody thinks of it that way, particularly not people evangelizing about rolling release distros), it would have to mean either the Arch maintainers just happen to be wiz, or pacman was significantly superior to debs at avoiding dependency issues.

If it's the latter, maybe everyone should just be switching to pacman. But is it really even true that Arch is better at avoiding dependency problems? And are those even much of a deal any more?


Last edited by Purple Library Guy on 25 January 2022 at 4:07 pm UTC

Quoting: Purple Library GuyI don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

No, the secret is in the libraries, check the 2 points here.

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

And furthermore, the AUR is such a good system which contains all the scripts for the user to build the software, always against the newest libraries! Plus it has ONE version, not 20 different PPAs with prebuild binaries, 10 different OBS places with incompatible/dummy-packages and whatever.

IMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

see: https://www.youtube.com/watch?v=rmXNLK3pWko&t=1644s


Last edited by sudoer on 25 January 2022 at 5:24 pm UTC

Quoting: sudoer

Quoting: Purple Library GuyI don't think it's plausible that the difference is between "rolling" distros and distros with discrete releases. All that "rolling" means is that what you have is a snapshot of current development, it has no implications for dependency hell--or, if it does, the implication would be that some of the time, changes may have been made in different areas and not cleaned up before a "release" (because it's always live, there is no release) which might cause dependency problems.

No, the secret is in the libraries, check the 2 points here

Therefore, pacman is faster and what appears to be as "superior" from the rest, by not having to calculate millions of breaking possibilities.

IMO, instead of hand-holding Linux users with untransparent/dark noob-friendliness, all it takes is to educate the user how to maintain his system, which in the case of Arch is super easy if you take some time to read it.

Waitaminute. So as far as I can tell, that link says Arch always uses just the latest versions of all libraries, and then deals with the problem of applications that might need different versions of a library by just dumping applications that can't keep up.
Well, sure, that's one way to avoid dependency issues, but it's not much use if I want to use that application. And it has nothing to do with either being a rolling release or pacman managing things better. It's just a very ruthless approach to running a distro.

^^ That is what a true rolling release is, and that is how you avoid dependency hell once and for good. Desktop Linux is constantly evolving and moving forward, and this is the right approach.
Servers on the other hand based on prehistoric libraries and kernels can use flatpaks, snaps, appimages, whatever they desire to "patch" their fundamental problem. Those package formats were developed for servers in the first place if I remember correctly.


Last edited by sudoer on 25 January 2022 at 5:22 pm UTC