Flathub and Flatpak packages are the future of Linux apps, according to more people, and GNOME are continuing to invest in it. They have some big plans to improve it too.
Writing in a new blog post on the GNOME Foundation website, they went over a number of things and not just Flathub related but that's what we're going to focus on for this article. The plans actually sounds pretty good!
Firstly, Flathub is going to gain a way to process and verify apps from first-party teams. As in, developers who directly publish their app and manage the Flatpak package process for Flathub. A way to actually properly distinguish official apps from community builds will be quite important for so many reasons (security, privacy and so on). Not only that but GNOME want to give developers a way to collect donations and subscriptions too, which is also important to help make it more sustainable. Sounds like it's possible a way will be added for developers to share some of the revenue with Flathub too, ensuring it too is sustainable.
To improve the experience further another part of the plan is to support multiple repositories, to enable a split between these first-party apps and community contributions, and have one where only free and open source apps live. That way, users get more of a choice on what they see and it just gives a little more control over all. Part of the hope is that they can get GNOME Software and KDE Discover to support all this, and note it all like verify apps and such. Think of it like see a nice big blue tick in whatever software store you use to see clearly it's official.
You can see the plans in a bit more detail on their original Discourse post.
Also be sure to check out a pretty good video overview on Flatpak from Nick at The Linux Experiment:
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Direct Link
Direct Link
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
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
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
0 Likes
AussieEevee Jan 23, 2022
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.
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.
3 Likes, Who?
slaapliedje Jan 24, 2022
Quoting: pleasereadthemanualFor proprietary games, sure. And for distributions on a slow release schedule with frequently like Debian, Ubuntu LTS, and even Ubuntu proper, sure.The downside of that of course is you don't get notified when there is a new .sh installer.
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.shinstall script like GoG games do than be required to deal with Flaptak. I see no place for it on distributions like Arch Linux.
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.
0 Likes
pleasereadthemanual Jan 24, 2022
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.
2 Likes, Who?
BlackBloodRum Jan 24, 2022
Quoting: AussieEeveeTo be honest, if it ever gets to the point where I HAVE to use Flatpaks, I'd probably go back to Windows.I can't go back to windows.. no way no how.
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.
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.
1 Likes, Who?
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
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
0 Likes
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.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.
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.
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
0 Likes
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
1 Likes, Who?
Quoting: sudoerWaitaminute. 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.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.
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.
0 Likes
^^ 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
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
0 Likes
Patreon
PayPal
See more from me