Join us on our own very special Reddit on /r/Linuxers.

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

By - | Views: 19,819

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 Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link
Article taken from GamingOnLinux.com.
Tags: Apps, Meta
27 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
49 comments
Page: «4/5»
  Go to:

sudoer 25 Jan
^^ 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
Samsai 25 Jan
Quoting: sudoerNo, 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.
Except that Arch also breaks the first point by also providing multiple versions of certain libraries for compatibility reasons. And I highly doubt Debian providing libfoo1 and libfoo2 significantly increases dependency resolution time, since those are treated as two separate packages. So, I think the speed different between Pacman and APT can be explained with something else.

Quoting: sudoerIMO, 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.
I have a feeling that regular computer users aren't going to read the manual from cover to cover to learn how to maintain their system. No matter how much fun Arch/Gentoo users seem to have doing it, I don't think it's the way forward for general adoption.
STiAT 25 Jan
Quoting: Samsai...

Since you are using Silverblue and I have yet to find sb else who does ... how does Silverblue do with additional disks? I mean immutable system means no writing to /etc, means not being able to add additional disks on boot time.

Example are the two disks where my games are, spanned to one LV which I usually just mount in /mnt/data, and which holds my steam library.

I could tell ostree to actually do that.. but doing that circumvents the whole idea of Silverblue.

For all the flatpaks/snaps, I still do not think it's really ready. They made huge leaps in the past year with integration, but issues remain.

I think Nitrux is interesting too, doing basically the same but based on AppImages, but it is not immutable.. which kills the point of treating an OS as just what it is, the base, as silverblue does.
Samsai 25 Jan
Quoting: STiATSince you are using Silverblue and I have yet to find sb else who does ... how does Silverblue do with additional disks? I mean immutable system means no writing to /etc, means not being able to add additional disks on boot time.
/etc and a few other directories (such as /home, naturally) are mounted writable. So, to mount disks you just edit /etc/fstab as you would ordinarily. Basically, Silverblue feels like just an ordinary distro up until you go to install software or run system updates. All of the regular system configuration, service management and all of that is basically the same as anywhere else.
sudoer 25 Jan
Quoting: SamsaiI highly doubt

well you can highly doubt anything, but the fundamental reason for Arch being a simpler, faster and less dependency-hell-prone distribution are those 2 simple facts, as stated here

QuoteIn Arch Linux, partial upgrades are unsupported and only a single version of each shared library [is] in the official repositories, in contrast to other (non-rolling-release) distros.

This simple rule avoids (for the most part) the intractable issue that dependency hell is NP-complete. Maintaining metadata for complex version resolution has the effect that Linux package managers are slow (2019).
https://bbs.archlinux.org/viewtopic.php?pid=1956215#p1956215
, the rest like the package manager, the simpler packaging, take advantage of those principles, leading to more efficient code with much less needs and to a faster, cleaner system.
You can find more material with details on the internet.

Quoting: Samsai
Quoting: sudoerIMO, 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.
I have a feeling that regular computer users aren't going to read the manual from cover to cover to learn how to maintain their system. No matter how much fun Arch/Gentoo users seem to have doing it, I don't think it's the way forward for general adoption.

Regular computer users -you mean Windows users...- will break their systems no matter how many flatpaks they will use, and will continue to feel helpless when they will try to access their file system to find their file from another drive, while the flatpak will be showing them its own cut from the rest filesystem.

It's better to tell them 2 simple things to do to maintain their systems and let them use the latest native software, than creating helpless users left in the dark and having a holy cluster-mess of new each time holy-grail universal packages added to the already available ones. Mind that they are already staying in the dark with MS Windows, with the difference that it works.


Last edited by sudoer on 25 January 2022 at 9:25 pm UTC
STiAT 25 Jan
Quoting: Samsai
Quoting: STiATSince you are using Silverblue and I have yet to find sb else who does ... how does Silverblue do with additional disks? I mean immutable system means no writing to /etc, means not being able to add additional disks on boot time.
/etc and a few other directories (such as /home, naturally) are mounted writable. So, to mount disks you just edit /etc/fstab as you would ordinarily. Basically, Silverblue feels like just an ordinary distro up until you go to install software or run system updates. All of the regular system configuration, service management and all of that is basically the same as anywhere else.

Isn't that a risk and circumvents the whole idea? I mean.. you have profile.d which gets executed and could do all kind of stuff there. Even modifying the ostree... using systemd in example


Last edited by STiAT on 25 January 2022 at 9:13 pm UTC
Samsai 25 Jan
Quoting: STiATIsn't that a risk and circumvents the whole idea? I mean.. you have profile.d which gets executed and could do all kind of stuff there. Even modifying the ostree...
Who's going to modify it though? You'd still need root and none of the recommended ways to install software grant root access to any installation procedure. You would have to pipe some script off the net into sudo bash and at that point the script could just dd your drive full of garbage anyway. The immutability is not primarily a security feature but a stability feature: it ensures atomic and transactional system updates so that the software is always in a consistent state.
Quoting: sudoer
Quoting: SamsaiI highly doubt

well you can highly doubt anything, but the fundamental reason for Arch being a simpler, faster and less dependency-hell-prone distribution are those 2 simple facts, as stated here

QuoteIn Arch Linux, partial upgrades are unsupported and only a single version of each shared library [is] in the official repositories, in contrast to other (non-rolling-release) distros.

This simple rule avoids (for the most part) the intractable issue that dependency hell is NP-complete. Maintaining metadata for complex version resolution has the effect that Linux package managers are slow (2019).
https://bbs.archlinux.org/viewtopic.php?pid=1956215#p1956215
, the rest like the package manager, the simpler packaging, take advantage of those principles, leading to more efficient code with much less needs and to a faster, cleaner system.
You can find more material with details on the internet.

Quoting: sudoerIMO, 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.
Quoting: SamsaiI have a feeling that regular computer users aren't going to read the manual from cover to cover to learn how to maintain their system. No matter how much fun Arch/Gentoo users seem to have doing it, I don't think it's the way forward for general adoption.

regular computer users -you mean Windows users...- will break their systems no matter how many flatpaks they will use, and will continue to feel helpless when they will try to access their file system to find their file from another drive, while the flatpak will be showing them its own cut filesystem.

It's better to tell them 2 simple things to do to maintain their systems than having a holy cluster-mess of ignorant helpless users left in complete darkness and a handful of holy-grail universal packages just adding to the already available ones.
You know, the strange thing here is that you're advocating for Arch and telling me it's the future, but the more I read of what you're saying, the more significantly my impression of Arch is getting worse.

Before your first post my opinion was that Arch was not for me since I'm more a simple user type, but that it was nonetheless pretty cool. As this conversation goes on, I've started to think maybe Arch is actually kind of a stupid idea, and its popularity an artifact of the failure of Linux to make desktop inroads while it continues to dominate various other spaces, so that far too many Linux users are actually computer developers, tinkerers etc. who happen to use some desktop functions. Talking to you, I'm starting to think that if mindsets associated with Arch take hold more broadly, it will actively hinder both wider adoption of desktop or gaming-oriented Linux and the development on the Linux desktop of what most people would consider "usability".


Last edited by Purple Library Guy on 25 January 2022 at 9:26 pm UTC
slaapliedje 25 Jan
View PC info
  • Supporter Plus
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.

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
wtf? AUR has so many versions of particular packages, it's insane. Like I've seen some that are specific git versions instead of release versions. I've definitely had more dependency breakage / conflicts than I have even running Debian Sid. Arch is great, but don't make it out like it is perfect. This is actualy what worries me about SteamOS 3 being Manjaro based, though I think Manjaro tends to be far more conservative than the main Arch repos.
Boldos 25 Jan
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.
With all due respect, I *heavily* disagree with these statements.

Yes, rolling release distros are great for lots of reasons, but not for heavy "production corporate" use.
Rolling release is the very definition of all the possible and impossible risks when used in corporate production environments, either as a server infrastructure (you really do not want an ever-changing rolling release distro as a prod server) or as a corporate desktop (people will definitely not thank you for constantly changing program UIs, feature sets and/or format compatibility capabilities).

If you are still unsure about the above, just check with you Windows 10-cursed colleagues, because twice a year, their "rolling-relese" OS force-changes lots of bigger and smaller things for them, and I tell you - people are NOT excited about it!

So yes, rolling release is certainly great for lots of use cases, but for strictly professional/corporate scenarios only TLS will do...


Last edited by Boldos on 25 January 2022 at 9:40 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: Liberapay or PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.