Earlier quoted context omitted.
If they have Gnome 3.20+, it should work on them. Unlike Snappy, flatpaks require Wayland, which means they won't have the security issues that snappy apps will (with X11): https://mjg59.dreamwidth.org/42320.html
So if you're using Wayland, they're equally secure, and if you're using X, you can use snappy but not flatpak? That doesn't seem like a great point for adoption of flatpak.
Flatpak – Standalone Apps for Linux
41–46 of 46 posts
Re: Flatpak – Standalone Apps for Linux
#42While I like idea I don't completely understand it. What 'runtime' is actually supposed to be? What if I need two runtimes? I will probably need to bundle one of them with the app. E.g. if I write a C++ Qt application I will use Qt runtime, if I write command line Python application I will use Python runtime, but if I write Qt application in Python I will need to bundle either Python or Qt with my app, correct? Also,…
If, above this, you need more dependencies, in the flatpak model you need to bundle them yourself. Such bundling can be done however you want. For instance you can reuse existing packages from some distro, you can build the yourselves, or whatever.
Technically you have to specify a runtime, or things will not run. But if you want you can create your own runtime that is empty and use that. This means you have to supply everything though, as you won't even have an ld.so.
Re: Flatpak – Standalone Apps for Linux
#43Earlier quoted context omitted.
Why do we need to standardize sandboxing if that means having to install an application to install applications that are supposed to not need external dependency handling? If Flatpak's main selling point is security, then it would be better served as as a sandboxing tool for AppImage rather than falling for NIH syndroming as is unfortunately too common in Red Hat's world.
Because as the old name indicated, xdg-app is/was a Freedesktop project (though much of the docs are at Gnome, making one ponder porous project boundaries). And Freedesktop is all about defining that one canonical (heh) distro (making "free" something of a misnomer at best). Observe flatpak becoming part of Fedora shortly, and then Poettering style "nudging" implemented to get Debian and the rest to adopt it.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813308
Re: Flatpak – Standalone Apps for Linux
#44Re: Flatpak – Standalone Apps for Linux
#45Earlier quoted context omitted.
The whole point of flatpak is to standardize better security cross-platforms. Allowing "some other tool" to do that for you, just means most apps and most users will not take advantage of that security.
Why do we need to standardize sandboxing if that means having to install an application to install applications that are supposed to not need external dependency handling? If Flatpak's main selling point is security, then it would be better served as as a sandboxing tool for AppImage rather than falling for NIH syndroming as is unfortunately too common in Red Hat's world.
Re: Flatpak – Standalone Apps for Linux
#46Earlier quoted context omitted.
As far as security goes, couldn't this be solved by a separate tool, in the good ol' Unix style? And it would be up to downstream to handle AppImage files with it for sandboxing, or not.
Now i wonder if the likes of Firejail works with Appimage. As in yes, i see nothing that prevents you from applying existing sandboxing techniques around Appimage distributed software.