Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

[ssokolow]

Also, instead of the current state of permission management, it needs a dynamic permission system, similar to what Android already has.

That's literally what portals are. They're XDG's answer to Android Intents.

It's a much slower and more involved process to retrofit dynamic permissions on an API not designed for them like POSIX than with something like Android where the new touch-based paradigm justified bootstrapping an entire new ecosystem in the eyes of users.

(And the manifest permissions are the "temporary hacks" to get a solution now while they work to get a solution they intend to stand behind in perpetuity. They're basically re-treading the path Android took when it started with manifest permissions and then migrated to dynamic permissions.)

[ssokolow]

The only performance overhead of Flatpaks is the time to setup the namespaces (near instant, systemd is already doing it anyway) and that the Flatpak won't be able to use the fs cache of shared libraries that were used to boot your machine, but they can use the shared cache of other flatpaks with the same library version combination.

There's no extraction, no mounting of anything, no decompression (other than that of your filesystem).

...plus, if using an immutable distro with something OSTree-based like rpm-ostree, I don't see why you wouldn't be able to share the "same library version combination" caching between system packages and Flatpak-installed packages.

[user1]

That's literally what portals are. They're XDG's answer to Android Intents.

It's a much slower and more involved process to retrofit dynamic permissions on an API not designed for them like POSIX than with something like Android where the new touch-based paradigm justified bootstrapping an entire new ecosystem in the eyes of users.

Ok, but in the end will it have on screen notification like "do you want to allow app X to access you /home folder?" This is what I mean by dynamic permissions like on Android.

Edit: Yeah, ok. I guess you meant exactly that.

[Daktyl198]

The only performance overhead of Flatpaks is the time to setup the namespaces (near instant, systemd is already doing it anyway) and that the Flatpak won't be able to use the fs cache of shared libraries that were used to boot your machine, but they can use the shared cache of other flatpaks with the same library version combination.

There's no extraction, no mounting of anything, no decompression (other than that of your filesystem).

And yet, benchmark’s consistently show that in many cases, Flatpaks run slower than standard packages. In many cases, they do run at similar speeds, but not every time which means that there’s still improvements to be made a decade later.

Every year for the last 6 years has been “the year we all switch to flatpak”, but not even Fedora (owned and operated by the makers of flatpak) default to it as far as I know. Only security nuts (who actually modify and take advantage of the flatpak sandbox) and fanboys go out of their way to use Flatpaks for more than a couple apps that aren’t available in the standard repos.

[Artim]

Yeah, I was just thinking about regular user distros. Idk how things are in RHEL / CentOS / Alma Linux and other such distros. Regarding OpenSUSE, I'm not sure if they give such amount of attention to package stability like Debian (at least in regards to Tumbleweed, since it's a rolling release), but they certainly do a much better job than Arch. Unlike Arch, I've never heard about Tumbleweed needing manual intervention after updates (unless you have proprietary drivers) and if there is a broken package found, it should get fixed pretty quickly. OpenQA of course helps them a lot.

well, Arch is made to be broken every other day, if they weren't rolling, they would be crashing

[Artim]

Flatpaks are the same age as snaps (a decade old!) and have almost all of the same issues that snaps have. The only area Flatpaks are better are speed (and they’re still slower than standard packages, sometimes by a lot) and slightly better permission control.

Red Hat has just managed to brainwash people into saying that Ubuntu is a bad company while RH are the magical saviors of Linux, so anything Ubuntu is bad and anything RH does is good.

Tell me when Flatpaks are stable (don’t introduce bugs) and are also ACTUALLY sandboxed, since 95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs.

You are hillarious. Find a single piece of software without any bugs, I dare you. And also, if you can prove that "95% of applications distributed as Flatpaks break out of the sandbox by default because of point 1: bugs", then go ahead. Right now you are only spreading lies and misinformation. Canonical must have paid you a lot for that.

[Artim]

And yet, benchmark’s consistently show that in many cases, Flatpaks run slower than standard packages. In many cases, they do run at similar speeds, but not every time which means that there’s still improvements to be made a decade later.

Every year for the last 6 years has been “the year we all switch to flatpak”, but not even Fedora (owned and operated by the makers of flatpak) default to it as far as I know. Only security nuts (who actually modify and take advantage of the flatpak sandbox) and fanboys go out of their way to use Flatpaks for more than a couple apps that aren’t available in the standard repos.

you are litterally the only person claiming that everyone will switch to Flatpak. That will probably never happen, that's not what it's made for.

[Artim]

Ok, but in the end will it have on screen notification like "do you want to allow app X to access you /home folder?" This is what I mean by dynamic permissions like on Android.

Edit: Yeah, ok. I guess you meant exactly that.

Ideally, it will be much better, not needing any stupid notifications. Just look at file access permissions. Absolutely no need for any of that nonsense Android uses. If an app wants to access a file outside its scope, through a portal it communicates that to the underlying distro, the file picker (soon not necessarily Nautilus, but your default one) lets the user select the file and the system automatically (or with your words, dynamically) grants permissions for that one file by implicit means. And probably the same would happen if you use a file from your file explorer with that app. Your proposal would - that only reflects the worst practice Android follows - is the absolute opposite of how permissions should be used. E.g. some Office App should not have access to all of /home. Why should it? There's no reason to give it access to anything that the user doesn't choose to handle in the app. Of course this gets more difficult with stuff like media players who are supposed to create a collection of all media on your system, or DigiKam, that's supposed to do that for your images. But since the user rarely just dump files anywhere, it's not that hard to grant access to just a handful of directories.

[muncrief]

I've never liked either Flatpaks or Snaps, as they encourage incompatibility by essentially packaging a partial mini-distro along with an application. This just seems ludicrous, wasteful, and counterproductive to me.

However during experimentation with them I was never able to get a Snap to work at all, while Flatpaks were mostly, if not completely, functional. But as I said, neither really seems suitable for permanent installation, and I wish the goal were still set on Linux distribution compatibility, like the now failed LSB idea. But just because LSB failed doesn't mean everyone should just throw up their hands and go with distro within a distro ideas like Flatpak and Snap.

[woddy]

I read the comments a bit... are they different ways of packaging the packages or do you trust the dev. of the application and you should otherwise you have no reason to use it or you trust your distribution, you have to trust someone... but if you buy bread you should trust whoever sells it to you and does it. The problem with distributions is that they often lag behind in versions with unresolved security bugs, furthermore if you install many system applications you risk weighing down the system and creating regressions in the convoluted management of dependencies, the applications tested by the distributions are only the default ones , don't think that Ubuntu, Debian etc. I test the 1000+ applications available and if they create regressions, they don't, it would be impossible. Personally I prefer flatpak and you can manage sandbox permissions as you like, with KDE you can do it from the system settings.