One of the downsides seems like since the developer packages everything together, I’m reliant on them to push out changes. For example if some dependency needs a critical security update then I’m relying on every flatpak author to apply that change and push out a new version. But if I’m installing packages directly, I can update that one package and be done with it across my system.
this post was submitted on 09 Jun 2023
41 points (100.0% liked)
Linux
48003 readers
1338 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Not all dependencies are packaged by the dev. Flatpacks run on top of runtimes which are basically bundles of libraries (most of the important common ones) that are updated independently. A dev only needs to include libraries not in the runtimes.
But tons of libraries used out there are not in those runtimes, and this scenario still applies to them.
Thanks, I didn't know that.
Never thought of this scenario. Do they address it?
That's why runtimes are the way they are: for most simple desktop applications, they shouldn't really need much on top of what is already included in the GNOME, KDE, or Freedesktop runtime they depend on. (If you're curious, flatpak run org.gnome.Platform and poke around). Those runtimes get regular updates within each branch for important bug fixes. Alas, many applications add at least one or two external libraries they need to build / distribute themselves, and some applications add a lot of them. But it isn't like every application bundles its own libssl or something.
Most of the time, dependencies are handled by the runtimes. Those are updated routinely and do get security updates too.
In theory, the CI/CD would generate the package automatically when the git repo get tagged for release if they do configure for it, so it should be able to release it rather quickly. For instance, I get endless amount of update from Kate editor on Flatpak, because it constantly get tagged for minor releases.
I've found flatpak to have taken several design decisions that almost seem tailor made to make it hard to use. I use an app launcher as I use I3 to run apps, except I can't use it for flatpak because it doesn't just make stuff available on the path, I'd have to make a wrapper script or something at which point I've decided to use another app or package. It also had an issue where everytime I got a gpu driver update it updated every single flatpak fair enough but it kept all the old versions! It was using double digit percentage of my disk for no reason, and the response on issue for this on the repo was just this is intended behaviour.
If it wants to get mass adoption they need to work on letting it get out of the way of people trying to use it.
I think Flatpak is already good enough to be useful, and improving fast enough that it might be viable as the default way to distribute graphical apps for the majority of distros in the nearish future. I personally still prefer native apps, but I recognize those inherently involve massive duplication of effort, and that effort could be much better used in other places. If we're going to move to a universal packaging format, then for me personally Flatpak seems like the clear winner already, and that gulf is only widening. I just hope it doesn't stay so centralized around Flathub.
I am usually not a huge fan of such tools but I am kinda ok with flatpak. The fact that it doesn't need a daemon (or even root) and the relatively sane CLI makes it passable and I use it when the alternative is more painful.
One particularly fitting use case seems to be managing non-Steam packages on the Steam Deck. It funny to see non-Linux users managing to install and use all kinds of stuff through it.
In an interesting case of timing, I read an article a few days ago complaining about (among other things) the fact that Flatpak's aren't always isolated and it's not always obvious at first glance whether they are...
...and later that day I was reading about the Minecraft Fracturizer malware that tries to infect every .jar on your system, and at least one launcher's Flatpak was isolated enough that it could only infect the temporary filesystem used to run the game.
I think my biggest issue with flatpak is still the attitude it and its proponents have towards disk space. The idea that space usage isn't really a concern, and it's okay to require users to download 2GB of platform libraries that they probably already have to install their first flatpak boggles my mind. Because of this, it always seemed hostile towards distro packagers. (If you just used more flatpaks, the bloat will be amortized!)
The permission popups on gnome a recent thing?, i know you get popups on both kde and gnome for screensharing. But i haven't heard about this and the last time i used gnome was about 3 months ago
Yeah, permission popups are absolutely a thing. The system for that is called Portals: https://docs.flatpak.org/en/latest/portal-api-reference.html. The idea is an application asks for the tightest sandbox it needs to run, and then uses the Portal API to request capabilities at runtime, such as access to specific files or permission to start automatically. The catch is you can't just make legacy applications magically use an API like that: it requires work on both ends. But it's certainly happening, bit by bit :)
view more: next ›