Announcement

Collapse
No announcement yet.

Snaps & Ubuntu Core Desktop Talked Up At FOSDEM 2024

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • user1
    replied
    Originally posted by ssokolow View Post

    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.
    Last edited by user1; 07 February 2024, 01:42 PM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by Britoid View Post

    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by user1 View Post
    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.)
    Last edited by ssokolow; 07 February 2024, 01:36 PM.

    Leave a comment:


  • Britoid
    replied
    Originally posted by Daktyl198 View Post

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

    Leave a comment:


  • Britoid
    replied
    Originally posted by Daktyl198 View Post

    I have bad news for you if you’re a fan of Flatpaks, buddy.
    Flatpak people realise the limitations of Flatpaks and have spent time trying to come up with future proof solutions (e.g. portals). Which, yes has taken a long time and imho too long, but at least they recognise it.

    Leave a comment:


  • user1
    replied
    Originally posted by Artim View Post

    Well, I can't talk for things like RHEL, any of the CentOS successors like Alma Linux, or OpenSuse, but they are at least one of the distros with the biggest focus on doing things the proper way instead of the easy way.
    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.

    Leave a comment:


  • Artim
    replied
    Originally posted by user1 View Post

    Exactly. And I'd say Debian cares about this more than any other distro.
    Well, I can't talk for things like RHEL, any of the CentOS successors like Alma Linux, or OpenSuse, but they are at least one of the distros with the biggest focus on doing things the proper way instead of the easy way.

    Leave a comment:


  • user1
    replied
    Originally posted by Artim View Post

    That may be true for distributions that don't give a damn about stability like Arch. Everybody else would have already dumped that package.
    Exactly. And I'd say Debian cares about this more than any other distro.

    Leave a comment:


  • Artim
    replied
    Originally posted by patrick1946 View Post

    Hmm. Do you think that packagers test their packages like release managers do? I know enough packages which are broken because they use a different library version.
    That may be true for distributions that don't give a damn about stability like Arch. Everybody else would have already dumped that package.

    Leave a comment:


  • patrick1946
    replied
    Originally posted by user1 View Post
    Particularly, I like the fact that packaging provides additional wall of security which you don't have if you get the software directly from the developer.
    Hmm. Do you think that packagers test their packages like release managers do? I know enough packages which are broken because they use a different library version.

    Leave a comment:

Working...
X