Live data from Hacker News

Flatpak – Standalone Apps for Linux

flatpak.org

41–46 of 46 posts

Re: Flatpak – Standalone Apps for Linux

#41
post #33

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 works with X, it will just be less secure

Re: Flatpak – Standalone Apps for Linux

#42
post #14

While 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,…

Runtimes are not package dependencies. They are not separated from the app to allow dependency resolution. They are separated out in order to allow a different entity to maintain and update them. The idea is that they are pretty minimal (to some degree) and come with a well defined ABI and stability/lifetime guarantee.

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

#43

Earlier 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.

No need to nudge, `xdg-app` for Debian has already been in the works for quite some time[1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813308

Re: Flatpak – Standalone Apps for Linux

#45
post #31

Earlier 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.

Actually the sandbox used for Flatpak can also be used to run AppImages already now:

https://github.com/probonopd/AppImageKit/issues/152

Re: Flatpak – Standalone Apps for Linux

#46

Earlier 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.

bubblewrap works for sandboxing AppImages:

https://github.com/probonopd/AppImageKit/issues/152

Post reply on HN