Flatpak – An Insecurity Nightmare(oro.gay) |
Flatpak – An Insecurity Nightmare(oro.gay) |
Running up-to-date desktop apps like synology-drive, prusa slicer, keepassxc, kdenlive or even Steam at the same time without any conflicting dependencies and configurations tainting the distribution. And if you do not want to use it any more, you can simply remove it with little or even no traces left behind. I love the experience to get these -- including updates -- from within discover (KDE) or gnome-software.
And don't mix flatpak with snap. Different technology, I share mixed feelings about snaps.
$ sudo snap refresh --hold=forever
Auto-refresh of all snaps held indefinitely
flatpak does have some quirks but (as I see) it works most of the time and it definitely saves time for the developer to package an application
The sandboxing would be an easier sell if it allowed interconnections between apps as appropriate. Yes, I do want KeepassXC to be exposed to the KeepassXC extension in Firefox. Yes, I do want yabridge to expose VST instruments to BitWig. We don't want to be hardcoding support for individual pairs of apps either, so the mechanism would have to be generic.
Abstracting away filesystems also only goes so far. Running Filelight sandboxed for instance is just too slow to be useful.
And the distribution would be an easier sell if it allowed for standalone app downloads without going through a centralized hub with dedicated download tools.
Hopefully these are things we'll eventually see solved. Until then, it's still pretty damn good to be able to install many common apps regardless of distro specifics. An easy thing to take for granted, that. Used to be the answer to installation woes was "what's so hard about tracking down every dev dependency and compiling it yourself?" and it's nice that we're firmly moving on from that.
The author forgot Windows Vista which started this whole shitshow of granular permission popups ;)
But am I the only one who fundamentally does not want this permission popup crap on a desktop operating system? I explicitly want applications to access the data of other applications or even remote-control other apps, that's the base for building automated workflows where the result is more than the sum of its parts.
Let me define sandbox boundaries for whole groups of applications and special safe locations for actually sensitive data, not require each application to live in its own isolated sandbox.
Linux, Unix and most computers were designed from the ground up as open system where everything can access everything.
It’s absolutely not secure, but that’s not what flatpak is supposed to fix.
Flatpak is supposed to make installations of apps easier by sharing common dependencies across all distributions. That’s all. And in a way, it works.
It has downside even on that, people who have slow internet connection will require hours to download a simple calculator app whereas it took a few seconds before, but it works.
Now on the sandboxing part, you can’t fix a sinking ship with a chewing gum in the hole. The whole structure is not designed to work this way.
It has to come from yet another distribution where permission are enforced at the operating system level, like on macOS. It’s a lot of work, and then you got to get developers on board, so it will never happen and it’s fine. Linux is not macOS, it doesn’t have a trillion dollar company backing it up and it’s not unified.
You got to play with your strength, not your weaknesses.
In the modern world we do not share our computers with other users, and allow untrusted software to run on our machines from the internet. Without further sandboxing, it would execute as the user with access to everything for that user - which in practice means mostly everything.
Which is fine and the reason behind qubes OS decision to have passwordless sudo enabled on qubes.
KDE and GNOME in the 2000's already had everything in place, for vertical application development, frameworks and co, the only part missing was having OEM support for selling ready made systems, instead of reverse engineering hardware all the time.
Instead rebooting the experience, incompatible Gtk+ versions, multiple sound systems, a X Windows replacement that is yet to be widely available,....
Eventually the peace of mind is to use it the headless, time sharing approach that UNIX was developed for, and leave it at it, ssh and Web instead of telnet and X Windows of yore, into servers where OEMs actually care to support their hardware.
The only case where I do find Flatpak useful is to install proprietary electron based applications that do not interact with the rest of the system so much, but I try my best to avoid using those in the first place.
I have about 30 years of experience with running Linux. Rarely as my main system (though I did use this particular laptop for a few months in between two macs at some point).
I got rid of both snap and flatpak. I like the idea of those two. But they are just too much of a PITA to deal with. I'd like this stuff to work how it works on my mac: mount .app image, drag the app to the Applications folder and done. On Manjaro, if I want something, I just 'yay <package>' it.
I find it very telling how commercial application developers that actually do explicitly support Linux advertise their Linux support on their websites. Mostly it does not involve the words flatpak or snap. Just not a thing. Generally you'll find some link to a deb, rpm, or tar ball (in that order). And good luck with that. Yay does a fairly good job of converting deb files for use with arch based systems. It's how I installed Chat GPT Desktop on this thing before traveling, for example.
Basically the status quo for commercial application developers targeting Linux is to: 1) ignore distros repackaging other people's software 2) ignore niche package management solutions 3) just cover the basics which is Ubuntu (deb) first and then everything else. Which means you get a deb file, maybe an rpm, and not much else typically. What they typically don't do is work with half dozen app stores, distribution specific repositories, package managers, and other walled gardens to bend over backwards to distribute their software. None of them are large enough to be worth the overhead.
This system kind of works. There's no need for OpenAI to support Manjaro with a Manjaro specific package. Yay can work with a simple deb. All the developers have to do is make sure to statically link the essentials and not make too many distribution specific assumptions.
Everyone else is getting off dbus, is working to let the compositor have power, have authority. Dbus is this other system that has some security options but that rarely is well locked down.
And it's just wild to me that there's such ongoing protest against using Wayland protocol development that's so insistent, and it's especially annoying and frustrating seeing it from biased folk like Flatpak who want to make sure there is no discrete source of authority, who want to make sure they can own a chunk of the UX. DBus and their protocols make sure Wayland doesn't become the one way to run a good desktop, that you have to keep having multiple totally different messaging systems going. Fine, I don't begrudge you that as an option, but don't keep road blocking those who want to develop Wayland, please!