Fan of Flatpaks ...or Not?
-
This post did not contain any content.
I use Aurora DX so most of my apps are flatpaks. Its fine.
-
Enter the calm and quiet room
Pass out torches and pitchforks, guns and knives
“Snaps exist”
War erupts.
SNAP BAD
-
This post did not contain any content.
Just another tool in the toolbox. Use it or not, up to the user. I've even seen Slackware users who say they use Flatpak to ward off dependency rabbit holes.
-
The one "good" thing about containers is that you keep your DLL-like mess localized. Just one or a few related apps run in the container and if they want / need some weird library version, they can have it without breaking other things.
Yeah but that’s a huge benefit already. I am not savvy enough in the development side to know whether that’s a reward that justifies any of the frustrations people have. Personally I don’t really mind varying methods to do any one job, as long as it’s well-documented, easily managed, and does not create a higher load on the system in any respect.
-
Yeah but that’s a huge benefit already. I am not savvy enough in the development side to know whether that’s a reward that justifies any of the frustrations people have. Personally I don’t really mind varying methods to do any one job, as long as it’s well-documented, easily managed, and does not create a higher load on the system in any respect.
I view the delays during launch and the extra time spent during updates as a "load on the system."
Also, it entirely depends on your deployment environment. I develop system images that go out on thousands of devices deployed in "Cybersecuity Sensitive" environments, meaning: we have to document what's on the system and justify when anything in the SBOM (list of every software package installed on the machine) is identified as having any applicable CVEs... soooo.... keeping old versions of software anywhere on the machine is a problem (significant additional documentation load) for those security audits. Don't argue with logic, these are our customers and they have established their own procedures, so if we want their money, we will provide them with the documentation they demand, and that documentation is simplest when EVERYTHING on the system has ALL the latest patches.
The most secure systems are those that don't do anything at all. You can't hack a brick.
-
Size and gnome/GTK dependencies are main reasons why I don't use Flatpaks (I have nothing against gnome though, it just pulls in too much and KDE is worse in this regards, which is why I use Sway and River)
Naw fuck gnome and fuck GTK. Over invasive and controlling crapware.
-
flatpaks are fine and useful, i just wish we didn't move into a scenario where applications that used to be easily available in distro repos start moving away from them and are only available through flatpaks. distro packages are just so much more efficient in every way. flatpaks are easier on maintainers and developers but that comes at a cost to the user. i have about a dozen or less flatpak apps installed and already i have to download at least 2 gigs of updates each week. i run debian
Flatpacks a fucking insult to people with limited bandwidth.
-
I view the delays during launch and the extra time spent during updates as a "load on the system."
Also, it entirely depends on your deployment environment. I develop system images that go out on thousands of devices deployed in "Cybersecuity Sensitive" environments, meaning: we have to document what's on the system and justify when anything in the SBOM (list of every software package installed on the machine) is identified as having any applicable CVEs... soooo.... keeping old versions of software anywhere on the machine is a problem (significant additional documentation load) for those security audits. Don't argue with logic, these are our customers and they have established their own procedures, so if we want their money, we will provide them with the documentation they demand, and that documentation is simplest when EVERYTHING on the system has ALL the latest patches.
The most secure systems are those that don't do anything at all. You can't hack a brick.
Hey, like I said, great info for me to learn because I don’t know. I was only saying that I don’t mind because my situation is fine with it. Thanks for the info, it’s interesting. I’m sure for any situation there’s a better and worse solution and I’m sure that for any solution, there’s a situation that either likes or dislikes the approach.
-
Enter the calm and quiet room
Pass out torches and pitchforks, guns and knives
“Snaps exist”
War erupts.
War with who? I'm posting this from Kubuntu and I'd happily agree with you that Snap should fuck off and die. (In particular, the backend being controlled by Canonical makes it objectively bad compared to Flatpak.) Even among people like me who tolerate Snap (for now...), I really don't think you're gonna find anybody who actually likes it, let alone enough to champion it.
Can't start a war when there's a consensus!
-
Perhaps ironically, this is mocking a strawman. Flatpacks can be installed and managed using the terminal! Not only that but Linux-Distros have had graphical package managers for decades.
The primary reason that distros have embraced flatpack / snap / appimage is that they promise to lower the burden of managing software repositories. The primary reason that some users are mad is that these often don't provide a good experience:
- they are often slower to install/start/run
- they have trouble integrating with the rest of the system (ignoring gtk/qt themes for example)
- they take a lot more space and bandwidth
Theoretically they are also more secure... But reality of that has also been questioned. Fine grained permissions are nice, but bundling libraries makes it hard to know what outdated libraries are running on the systems.
As far as I know, I've only installed Flatpaks using the terminal. The most annoying thing about them for me is having to type out the fully-qualified name of the software (e.g.
org.mozilla.firefox
instead of justfirefox
), which is a very terminal-specific issue, LOL!