173
Is there a downside to Flatpak?
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Feb 2024
173 points (93.9% liked)
Linux
48077 readers
783 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
No, Flatpak isn't the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there's noone restricting the old / unrestricted ways of doing things... So apps usually don't port over to the portals.
Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don't get kicked from app stores for it, and because many users can still fall back to using the old system.
While what you say is true, the "portals" were an afterthought, an imposition to developers and a cumbersome and poorly documented solution. Just like the theming and most other things.
Instead of bluntly blocking things why can't Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path? A GUI capable of automatically enumerating those resources and a bunch of checkboxes like "app X and Y both have access to socket at
/var/run/socketYwould also solve most of the issues.Because the user getting a hundred popups on app start for various files the app needs isn't exactly a usable experience. Also, blocking the app's main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.
Aside from apps using the APIs meant for the purpose of permission systems, there's no good way to make it work.
It doesn't but until apps can declare on a simple config file what paths they require that's the way things should work. I guess that would motivate the developers who are packing into Flatpaks to properly list whatever files the application requires. If they don't, then the application will still work fine but be a bit annoying.
Yet, macOS does and things don't go that bad, on the example how do you think they do it for command line tools? The system intercepts the request, show the popup and wait for the user input. I've seen the same happening with older macOS applications that aren't aware it could happen and yes, the main thread is blocked and the application seems to crash.
I thinks it's way better doing it this way and still have a somewhat productive container and isolation experience than just bluntly blocking everything - something that also breaks apps sometimes.
They can, and always could. Apps aren't doing it, most Flatpaks have just blanket "allow ~/Downloads" or "allow all of home" permissions by default - or no file permissions, and you have to go grant them manually yourself.
Again, unless apps actually support it, no matter how good the security system is, it won't work out.