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 Jan 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.

For 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.

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.

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 Jan 2022 at 1:50 pm UTC

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.

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 Jan 2022 at 4:07 pm UTC

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.

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 Jan 2022 at 5:24 pm UTC

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.

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 Jan 2022 at 5:22 pm UTC

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.

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.

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.

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.

...

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.

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.

/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.

I 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

In 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.

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.

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 Jan 2022 at 9:25 pm UTC

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.

/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 Jan 2022 at 9:13 pm UTC

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...

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.

I 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

In 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.

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.

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 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 Jan 2022 at 9:26 pm UTC

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.

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.

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.

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 Jan 2022 at 9:40 pm UTC

I 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

In 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.

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.

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 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).