Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone with no article paywalls. Just good, fresh content! Alternatively, you can donate through PayPal, Liberapay or Buy us a Coffee. You can also buy games using our partner links for GOG and Humble Store.

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

By - | Views: 19,031

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: «5/5
  Go to:

slaapliedje 25 Jan
View PC info
  • Supporter Plus
Quoting: Purple Library Guy
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".

I've had a triple boot of Arch, Debian Sid and Windows 10 for years.

Arch is useful for some of those really niche programs that somehow don't make it into Debian, or are occasionally not updated by the maintainer and I want to test a beta version or latest version of something.

The problem is the majority of things are in AUR, and the binary repositories aren't that extensive (at least compared to Debian) and so you end up having to wait for compile times for many things. While modern processors make this fairly quick, I'd hate to be running it on an older CPU, which Debian runs like a champ on. The other problem is AURs are orphaned as often as Wal-mart kids. Someone decides they want an easy installer for something, whip up a PKGBUILD, then ignore it when there are new releases. Worse yet, if you don't pay attention, you'll end up having the wrong package installed because that one was orphaned, and someone created a new one, and no one commented in the original build.

Another issue I've ran into was due to some bug in upstream software. Ghostscript in this particular case, it made it so all my printing was just a page of pure black. It wasn't caught in any sort of QA, as QA'ing all binaries with such a smaller user base (this was years and years ago, so the user base was much smaller than it is now) wouldn't have been possible, but this was broken for like a month.

All distributions have their issues. Everyone assumes Debian is years out of date, but when it does a release, it is rather modern. Until of course it's inching toward the next release. But since they now have mainstreamed the backports, you can stay rather current even with sticking to "Stable". The same is becoming true even of the RHEL based distributions, as they are having their core be stable, and then you can add 'streams' for things like php. So you can have a solid/stable core, with newer application frameworks for your services.

The whole purpose of Flatpaks/AppImage is for third parties (either commercial, or open source projects that don't have the ability/capacity to package their software for every distribution.

The fact that Ubuntu has diverged from Debian so much and causes dependency hell is the fault of Ubuntu (and well every other Debian distro I've used, unless they pull directly from the Debian repos). This, I'm sure, has irritated more than one developer out there. "Oh just make a .deb package, and it'll work everywhere..." nope, because you may have required libblah-12 and Ubuntu has libblah-13...

Ha, sorry for the rant. The reason there are so many distributions is because there hasn't been the 'perfect' one that scratches all itches. Every few years I've done some distro hopping... and still come back to Debian. I've been doing this since '97 or so... When it was still possible to install Debian off of floppy disks! (that was a long weekend).
STiAT 25 Jan
Quoting: Samsai
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.

Point taken, I still think there will need to be technology innovations or adoptions to make it really "immutable" and you can automatically mount hard drives without actually every having to touch any root file system. Or generally making really the whole root file system read only.

But I take your point about the applications, which isn't actually true with flatpak though, since they do have file access and you only need one bug there to exploit it. And as of the current state, there is no difference in flatpaks <where> in the FS they potentially could access, if they can get privileged out of the container - they are.

As a stability feature - yes, that's pretty much clear that's a good feature I'm certainly interested in. It's basically how I do treat my main system (despite driver installs - this nvidia driver :D .. but that could be installed into ostree too).

I get where they're going. Maybe not there yet 100 %, but the distinction of making it a stable base and having apps work independently of the base makes sense. I actually like the approach. Maybe too early for me to switch there yet though, I'm really not prepared to do development containers for everything I do :D.


Last edited by STiAT on 25 January 2022 at 11:28 pm UTC
To be honest, there is no such thing as a "perfect" distro that does everything "right".

Why?

Because what is right for one person, is the exact opposite of what someone else wants from their distro.

But that's the beauty of Linux see, we can use the distro that fits our needs best, we are not tied to using a specific one, so if it doesn't fit us then we can move on.

With that said, I always say that Arch has great documentation and I would highly recommend anyone who wishes to learn more about Linux and how it really works to use it for a while.

It's a great distro imo, however as for "stable" - I wouldn't say so. System breaking changes may occur with the only notification being the blog on the Arch website - for avid Arch fans this is no big deal, but for a new Linux user they wouldn't understand why this happens.

While in my opinion stable releases are better than rolling for a new user (stable package versions, less instant changes etc etc) there are rolling distros that even a new user could find usable, for example OpenSUSE Tumbleweed.

Tumbleweed can be installed via GUI, uses btrfs by default with snapshots fully enabled - so if updates break it, rolling back to a working system can be done in less than 5 minutes even for a newbie. Heck, even if you bust the configuration yourself you can rollback in less than 5 minutes.

Now that is what I call new user friendly. If we break out of the rolling releases, there's always OpenSUSE Leap that also has snapshots, failing that new users may find Mint comfortable.

Generally for new users, I aim to give them a comfortable experience that won't leave them needing to run a command line or getting confused, so my go-to is usually Mint for a complete newbie.

Arch would probably have most new users running away screaming about how Linux is still all terminal based and old fashioned that doesn't work. Rightfully so, Arch is not aimed at complete novices, it's aimed at people that want more fine grained control over their system, people who like to tinker and those who want to learn more about the technical side of Linux.

Now, me personally I always use whatever fits - I stopped the whole "distro fanboy" thing a number of years ago - although Fedora will always hold a special place in my heart .

I use a combination of RHEL, Debian, Fedora, Arch and OpenSUSE systems - using each system where they fit best for the task at hand.

Anyway, it's also why I'm not a big fan of Flatpak, if I'm using RHEL for example - I don't want a nightly build of apache that I need to update everyday, I want a version I can install and leave running that's stable and secure, hence RHEL and proper SELinux policies - For example, I only just rebooted one RHEL server that had over 4 months uptime, it was secure though thanks to kernel kpatch's which address security vulns (live patching kernel without full reboot - great since a reboot would take around ~5 minutes due to slow bios checks) and system services just being rebooted with systemctl, thus all up to date and working. This is an example of a strength of RHEL.

But as I wrote before, each distro has their strengths and advantages - that's why we get to pick which ones work for us best.

We should never get to the point of depending on Flatpak, because it's usage case will not fit everybody and their individual setups. Linux's ability to adapt and fit different users needs is one of it's biggest strengths, by taking that away by requiring users to always use a Flatpak version is very dangerous and will make a lot of people angry.
Quoting: Purple Library GuyThat video says "Flatpak is the future". Well, I'm willing to believe Flatpak is (the future of proprietary software on Linux). I don't think it would be such a good idea for every damn application and utility, the open source ones, the main Linux software ecosystem, to be using Flatpak instead of normal package management.

Why not Open Source apps? I use Kdenlive Flatpak and it's very much better than the RPM package I could get (when I was using Fedora Workstation) from RPMFusion, and Kdenlive Flatpak is an official compilation, so if it fails I can report directly to Kdenlive developers.

Many Linux users don't want solutions, they want patches that mitigates things but don't solve anything, because if you don't use Linux typing one thousand of commands per day because of mediocre software available for Linux, you aren't a true Linux user.
Quoting: EduardoMedina
Quoting: Purple Library GuyThat video says "Flatpak is the future". Well, I'm willing to believe Flatpak is (the future of proprietary software on Linux). I don't think it would be such a good idea for every damn application and utility, the open source ones, the main Linux software ecosystem, to be using Flatpak instead of normal package management.

Why not Open Source apps? I use Kdenlive Flatpak and it's very much better than the RPM package I could get (when I was using Fedora Workstation) from RPMFusion, and Kdenlive Flatpak is an official compilation, so if it fails I can report directly to Kdenlive developers.

Many Linux users don't want solutions, they want patches that mitigates things but don't solve anything, because if you don't use Linux typing one thousand of commands per day because of mediocre software available for Linux, you aren't a true Linux user.
I use Mint. I never touch a command line, I can't remember a package ever breaking. Flatpak solves a problem I don't have, by introducing a bunch of bloat. For as long as open source stuff is being maintained, and depends on libraries that are fairly current, normal packaging should be fine.

Closed stuff, on the other hand, typically doesn't get maintained for nearly as long as it may be used. A solution that bundles the libraries it needs with it is going to come in handy. If my old Loki copy of Alpha Centauri had been done as a Flatpak, maybe I could still play it today without masses of workarounds.
View PC info
  • Supporter
As long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.


Last edited by pleasereadthemanual on 28 January 2022 at 12:57 pm UTC
ObsidianBlk 28 Jan
I'm an Arch user... have been for at least a decade. I've only really dabbled in Flatpak itself, but, honestly... given we're obviously all Linux gamers... Flatpak (or some iteration of it) is one of the core changes to Linux that will help break Microsoft. The simple reasoning behind this is, the biggest game developer complaint for Linux is "it's fractured". Flatpak (though not perfect) goes a long way to homogenize the distributions in a way that will make it easier for developers to develop their games for Linux and distribute them for Linux and not a specific distro. Furthermore, if we want more games, we need more players, and those players still find Linux complicated/confusing. While Flatpak will not automatically solve that problem outright, given that Flatpak (in theory) works for all Linux distros, then users will have a more reasonable expectation that if the package/game is on Flatpak it'll probably work on there distro. These are huge deals if we want more games. To get those games we need to make the road easier for the developer and the gamer.

Honestly, I don't really see Flatpak as being that drastically different than Docker, and docker has been a huge boon in the network space.

In the end, I doubt the traditional package manager is going away. At worst you'll see a duality in that Flatpak will be automatically installed along side your distro's native package manager and there'll be a toggle for which source if your default package source. Even more likely, the command line distro tools will remain separate, for the CL-jockies.
slaapliedje 28 Jan
View PC info
  • Supporter Plus
Quoting: pleasereadthemanualAs long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

 
apt source <package name>

or if you want to download and build, add -b.

If it's not in the repos, most source trees have a 'debian' folder, so you should be able to build it fairly easily on any deb based distribution. If it doesn't have a Debian folder, then there are now tools to try to automate that. Though I haven't needed to use those, so not sure exactly how they work.

PKGBUILDs are very simple to make and really are one of the shining things about Arch. Documentation is the other one. The only other free operating system that has comparable documentation would be FreeBSD, in my experience.
View PC info
  • Supporter
Quoting: slaapliedje
Quoting: pleasereadthemanualAs long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

 
apt source <package name>

or if you want to download and build, add -b.

If it's not in the repos, most source trees have a 'debian' folder, so you should be able to build it fairly easily on any deb based distribution. If it doesn't have a Debian folder, then there are now tools to try to automate that. Though I haven't needed to use those, so not sure exactly how they work.

PKGBUILDs are very simple to make and really are one of the shining things about Arch. Documentation is the other one. The only other free operating system that has comparable documentation would be FreeBSD, in my experience.
The package I was trying to build from source was yt-dlp about half a year ago. I spent about an hour looking around, but there didn't seem to be a clear-cut way to do it, so I inevitably just gave up and built it from source "the normal way". I'm not sure about the other reasons for building from source, but I'm so used to using Pacman to manage packages that I build with `makepkg` because it's an easy way to keep track of packages and cleanly uninstall them.

I made the mistake of using pip to install protonvpn a year ago...never again. Using pip is a surefire way to create an unmanageable mess of packages that Pacman inevitably gets confused with.

The documentation is really a goldmine. I always find myself there, learning new things about software that often the upstream developers haven't bothered to document. I've heard about FreeBSD, but haven't had the occasion to look into it.
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.