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

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn 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'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Of course, there's nothing stopping you from using Flatpaks on Arch Linux, but I think the AUR addresses some of the biggest issues that distributions like Ubuntu, Debian, and Fedora don't handle well without Flatpak.

I'm a GNOME user that doesn't use any extensions :P

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

Does Flatpak have a package for php7.2/php7.2-fpm? Because that would certainly be less of a headache than compiling it from the AUR. I don't really think it's the type of thing you can package with a Flatpak, though. Otherwise, I personally don't have much use for it.

Quoting: ShinyaOsen

Quoting: pleasereadthemanualOn 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.

Use flatpaks on my arch install for handbrake, fre:ac, ungoogled chromium, and Jellyfin Media Player.
Reasons being handbrake has a bug in the arch repo that made HEVC/265 encode take 10 times longer(10fps on flatpak to 0.4fps on arch repo) aur versions dont fix this and the flatpak version is official the only thing I'm missing is fdk-aac which i only use when using 264. Fre:ac only available in AUR crashes constantly and the GUI doesn't show some times so pretty unusable and flatpak version is official. Ungoogled Chromium don't want to compile and flatpak is offical. Jellyfin media player don't want to compile and flatpak is official.
I'll be using the OBS flatpak in the next release as it will be official and have all features available with out needing to compile the missing features from the AUR.
On my laptop that is running opensuse tumbleweed I use the flatpak for asunder as on opensuse asunder isnt up to date and is deprecated since it uses gtk2 still and the creator endorsed the flatpak version.
Not that flatpak stuff is perfect switched off the Firefox flatpak after it bugged my profile and 264 videos playback can be bugged some days probrobly switch back to it sometime in the future again tho.

I suppose it's a matter of taste, for the most part.

From my perspective: I use plain FFmpeg, the brave-bin package (so no compilation), and only use basic features of OBS.

I'm not saying the AUR is without its issues, but it's a lot better than a PPA or nothing. I'll relay my own frustrating experience with the recent Anki situation. Anki was removed from the official repositories following an announcement from Anki that they were going to change their compilation process significantly yet again. I guess the maintainer just got tired of having to deal with it. Now there are 3 or 4 different versions in the AUR, and the best one for compilation is still incredibly involved and failed for me a few times. With the recent update, I couldn't get it to work at all and ended up using the official binary bundle (which worked fine).

Anki is not the typical AUR experience for me; it's very complicated and has a moderate chance of failing to compile. Most of it is stuff like Gazou and xow-git; small programs.

But it can also be better than the alternative. With Audacity 3.0+, all of the AppImages are broken, the Flatpak also seems to fail, and Arch doesn't maintain a version of it past 2.4.2 in the official repositories. The AUR package compiles within 5 minutes and works great. Aside from wxWidgets just being wacky in general, but nothing will fix that.

I personally would still rather contend with the AUR than Flatpak for software right now. Maybe that will change in the future.

Why would people want to use this on debian? People that worry so much about security should use Cubes OS anyway. The only thing any of these actually come in handy for is handling multiple versions of the same software (so pretty much wine), but other than that they don't offer any benefits that already existing solutions don't do better.

I like Flatpaks. They provide a reasonable compromise between compatibility guarantees and disk space usage thanks to runtimes, integrate fairly well while also providing decent sandboxing features and are easy to manage and typically get updated fairly regularly. I think they definitely should be embraced more, especially for the newbies, since you won't break your DE and display manager by installing them.

Flatpak is obviously not ready (at least yet) to be the sole software source. A fair amount of things like terminal utilities and developer tools either aren't installable through Flatpak or otherwise have some quirks and integration issues. At least for me on Fedora Silverblue, the best approach to software development right now is to run my IDE, linters, compilers and library dependencies off of a Toolbx container. So, I don't think Flatpak will be replacing distribution-specific package managers in the short-term for this sort of system-level software.

But when it comes to day-to-day graphical application programs, the stuff majority of people would actually use, Flatpaks work just fine and provide a less fragile environment with a slight bit more safety guarantees and with a better way to target more distributions with a single package. AppImages might have their place for repository-less software distribution of, say, proprietary software that you just download off some website somewhere, but I've found AppImages to be often of poor quality and not actually meeting the cross-distro compatibility they often claim, plus they necessarily suffer from more library duplication than Flatpaks. Snaps on the other hand seem to win Flatpak in terms of being able to install terminal utilities and daemons, but beyond that they seem worse than Flatpaks in most ways, so it would probably be better if Flatpak just gained the ability to better install and use utilities.

Not that long ago I was still fully on-board with the distro-specific packaging approach, where software developers develop and package maintainers package, but I think this approach ultimately has too many drawbacks. It creates a potential for manpower issues, since either the developer needs to do much packaging work to target a multitude of distributions, or they need to rely on package maintainers to have the time and energy to do the packaging for them, which either way results in much duplicate work. It also reduces initial visibility, as software needs to filter through more layers before being generally available to users and increases the time between a new version being released and it being available to users, because some distros will freeze or hold back packages for varying amounts of time for varying reasons. If we want more developers to make application software for Linux, we need to make the process as smooth as possible and reduce the amount of work needed to get your software in front of as many users as possible.

I wonder if elementaryOS and their App Center helped pave the way for this.

Personally, I still mostly use only packages in my distros repo or self compiled. Simply because it's how I've always done things and it's guaranteed to work out the box.

In addition, I only need to run one command to update, I don't have duplicate libraries and I know where the package was compiled and can verify it with signing as opposed to Flatpak where anybody can upload a flatpak that contains anything from anyone (not official dev builds, no quality control etc).... granted they're going to start verifying it now.. but up until this point I deemed it a security risk.

But it's my choice and it's the way I'll continue to do things for so long as I can, I am also not a fan of the recent trend for immutable filesystems where it's set distro way or no way.. I don't want my OS dumbed down to the point of not being fully under my control like an android device, I want to be able to edit my /etc and other files if I choose.

I'll keep full control over my tux for as long as possible, I know this goes against everything the linux community is pushing for at the minute, but it's my opinion and my choice.

Quoting: BlackBloodRumI know this goes against everything the linux community is pushing for at the minute, but it's my opinion and my choice.

I'm not sure if it is what, "the Linux community," is pushing, rather the vocal minority of 'value added' OS developers.
People with a financial interest speaking for us and, in many instances, not giving us a choice.

My hope is that there will always be some distros who stick to the package managing way, probably Debian and Arch, but we all know Ubuntu will get rid of .deb for anything outside of the core system as soon as they can!

Quoting: pleasereadthemanual

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn 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'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

I look at it this way. The less dependencies on my root filesystem, the less chance of breakage I have when updating the OS or programs. I have encountered dependency hell issues on Ubuntu + Debian before; so that's one reason I like using Steam as a Flatpak, because I'm not introducing a bunch of 32-bit binaries to my filesystem.

A good case in point is the LTT video involving Pop OS and Steam. No, I'm not criticizing APT, since the fault was likely a packaging issue on System76's end. However, my point would be that installing Steam would've been a non-issue had he used the Flatpak.

This is the primary reason I avoid the AUR. It has nothing to do with trust. I did my research before switching to an Arch-based system, and most of the people I talked to told me that the majority of stability issues they'd run into with Arch involved programs installed from the AUR. I don't use the AUR because I don't want anything from outside the official repositories on my computer. Flatpak at least has the courtesy to not touch my filesystem and update independently of the core OS. Perhaps your experience running Arch is different, but I've been doing things this way for over a month now since installing EndeavourOS and have had zero issues with the OS itself.

As for Firefox, well I only have few extensions installed myself, uBlock included. I just like the sandbox because the way I see it, if my browser is somehow compromised then at least it's separate from the root filesystem. Also, I've noticed that using the Flatpak gives me a less identifiable fingerprint when checking https://www.deviceinfo.me/


Last edited by CyborgZeta on 22 January 2022 at 7:36 pm UTC

Quoting: CyborgZeta

Quoting: pleasereadthemanual

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn 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'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

I look at it this way. The less dependencies on my root filesystem, the less chance of breakage I have when updating the OS or programs. I have encountered dependency hell issues on Ubuntu + Debian before; so that's one reason I like using Steam as a Flatpak, because I'm not introducing a bunch of 32-bit binaries to my filesystem.

A good case in point is the LTT video involving Pop OS and Steam. No, I'm not criticizing APT, since the fault was likely a packaging issue on System76's end. However, my point would be that installing Steam would've been a non-issue had he used the Flatpak.

This is the primary reason I avoid the AUR. It has nothing to do with trust. I did my research before switching to an Arch-based system, and most of the people I talked to told me that the majority of stability issues they'd run into with Arch involved programs installed from the AUR. I don't use the AUR because I don't want anything from outside the official repositories on my computer. Flatpak at least has the courtesy to not touch my filesystem and update independently of the core OS. Perhaps your experience running Arch is different, but I've been doing things this way for over a month now since installing EndeavourOS and have had zero issues with the OS itself.

As for Firefox, well I only have few extensions installed myself, uBlock included. I just like the sandbox because the way I see it, if my browser is somehow compromised then at least it's separate from the root filesystem. Also, I've noticed that using the Flatpak gives me a less identifiable fingerprint when checking https://www.deviceinfo.me/

In my experience dependency hell is a very rare situation to get into. It was common in the early days of package managers and is still common on development-grade distros (think fedora rawhide).

However most stable distros like Debian, Fedora, RHEL, SUSE (and co) won't land you into a dependency hell unless you add third party repos that offer the same or conflicting packages to what the core repos already contain.

Once third party repos start replacing core packages, that's where the conflicts really start to happen.

It may also occur in smaller less experienced distros like "Pop_OS!" (I only heard about that one for the first time about a month ago)

If you stick to stable releases of well known and well established distros using only official repos you'll likely never end up in dependency hell.

Of course, you'll at some point need or want a package that's not available in your distro by default. We've all been there.

If you need to add a third party repo make sure you set your package managers repo priorities correctly, your distros default repos should always have highest priority over anything third party.

This ensures that core libraries don't end up stuck on some third party repository version that since got dropped.

Oh and don't add random repos from the internet.. use well known ones only.

Ofc, from a new end user perspective that's complicated and can cause confusion. Flatpak could really shine here. That is for packages you simply couldn't have otherwise by default.

In fact I'd say that's a great compromise for new users. But I still feel packages that are available by default should be installed from a properly maintained repository to ensure the best consistency and compatibility.

In regards to sandboxing there are ways to get a similar result, for example see SELinux, a properly fine tuned SELinux policy can do wonders for your system security.

Quoting: JSVRamirez

Quoting: BlackBloodRumI know this goes against everything the linux community is pushing for at the minute, but it's my opinion and my choice.

I'm not sure if it is what, "the Linux community," is pushing, rather the vocal minority of 'value added' OS developers.
People with a financial interest speaking for us and, in many instances, not giving us a choice.

My hope is that there will always be some distros who stick to the package managing way, probably Debian and Arch, but we all know Ubuntu will get rid of .deb for anything outside of the core system as soon as they can!

I think some will definitely remain, for example those with an interest in the enterprise market will want to have their own fully controlled repos (Think RHEL) and in an enterprise environment I highly doubt admins would be happy about needing to hunting on flatpub for their packages instead of a simple "dnf install package" and they'll need to be able to confirm package integrity and orign.

So there is hope to being able to stay with proper linux distros :-D.

(I think debian would want to remain the same also)


Last edited by BlackBloodRum on 22 January 2022 at 8:28 pm UTC

Quoting: CyborgZeta

Quoting: pleasereadthemanual

Quoting: CyborgZeta

Quoting: pleasereadthemanualOn 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'm on an Arch-based system and use several Flatpaks. Firefox and Thunderbird for better Plasma integration and the sandbox, with everything else for being more convenient and not bloating my system with dependencies.

Also, I never touch the AUR, and Flatpak helps with that.

Using Flatpak and saying that it results in fewer dependencies is somewhat of a strange argument to me. Sure, you need to download more make dependencies for some AUR packages, but you can immediately uninstall them after compilation. With Flatpak, the more applications you use, the more duplicate runtimes/shared libraries (just different versions) you end up with. That's bloat in terms of RAM (having to run multiple of the same runtime) as well as hard drive space.

I don't know how effective Flatpak is at sandboxing applications, and because I use almost entirely free software or applications I trust, or applications that aren't distributed via Flatpak anyway (Microsoft Office), I wouldn't get much benefit out of it anyhow. For Firefox, I use uBlock Origin and block Javascript, remote fonts, the usual blocklists, disable WebGL and hardware acceleration, and that gives me more assurance than any sandbox would.

I look at it this way. The less dependencies on my root filesystem, the less chance of breakage I have when updating the OS or programs. I have encountered dependency hell issues on Ubuntu + Debian before; so that's one reason I like using Steam as a Flatpak, because I'm not introducing a bunch of 32-bit binaries to my filesystem.

This is the primary reason I avoid the AUR. It has nothing to do with trust. I did my research before switching to an Arch-based system, and most of the people I talked to told me that the majority of stability issues they'd run into with Arch involved programs installed from the AUR. I don't use the AUR because I don't want anything from outside the official repositories on my computer. Flatpak at least has the courtesy to not touch my filesystem and update independently of the core OS. Perhaps your experience running Arch is different, but I've been doing things this way for over a month now since installing EndeavourOS and have had zero issues with the OS itself.

As for Firefox, well I only have few extensions installed myself, uBlock included. I just like the sandbox because the way I see it, if my browser is somehow compromised then at least it's separate from the root filesystem. Also, I've noticed that using the Flatpak gives me a less identifiable fingerprint when checking https://www.deviceinfo.me/

From a stability perspective, sure, I can see the virtues of Flatpak. And it might be a good way to go for newbies in the future—but only if it's more reliable than ordinary binaries. I've seen people having more issues with Flatpak packages (including Steam; I've heard people say they couldn't get Proton to work through the Flatpak version, etc.). So while the stability of the system overall is improved, Flatpak packages themselves may not be reliable—this is one reason I always go to the AUR first, because I know things will generally "just work". Flatpak packages by their nature are far more complex and prone to issues you won't find in ordinary binaries. I hope this is improving over time, but I wouldn't have a clue.

It's good that you don't avoid the AUR out of trust issues. The trust level should be exponentially higher than installing a PPA binary that somebody has compiled for you versus a short bash script that you can examine closely for issues. AUR packages can certainly be less reliable, that's true, but it depends on the package. AUR packages are exactly the same as ordinary Arch packages; the only difference is that they aren't in the official repositories. They are all built with PKGBUILDs. The differentiating factor is the quality of packaging.

Take Anki as one example: it was dropped from the official repositories, but seems to still be maintained by developers/packagers for Arch. The quality of this package should be high. AUR packages are also compiled inside of a fakeroot and don't touch the root filesystem until after they've been compiled, and then most only enter the root filesystem (with your permission) to add the package to the PATH and maybe add some documentation. I personally haven't faced any stability issues with the packages I've used, as you speculate.

I'm not saying that you should use the AUR if you don't want to and you're doing something that's already working for you, but that it's certainly a valuable place to find software.

Perhaps it's separate from the root filesystem, but your most important information tends to be in your home directory, which software don't need any permissions to access. The best way to protect against malware and exploits, unfortunately, is to not get hit in the first place. Relevant xkcd.