Basically title.

I’m wondering if a package manager like flatpak comes with any drawback or negatives. Since it just works on basically any distro. Why isn’t this just the default? It seems very convenient.

  • TCB13@lemmy.worldEnglish
    111·
    10 months ago

    but I suspect something will come along to address these issues and snatch the market away from Flatpak.

    I believe it could only be fixed by a team from GNOME or KDE, they’re the one in a position to develop something like Flatpak but deeply integrated with the system instead of trying to get around it.

    For what’s worth Apple did a very good job when it came to the isolation and containerization of desktop applications, but again only possible because they control both sides.

    Apple enforces a LOT of isolaton, they call it sandboxed apps and it is all based on capabilities, you may enjoy reading this. Applications get their isolated space at ~/Library/Containers and are not allowed to just write to any file system path they want.

    A sandboxed app may even think it is writing into a system folder for preference storage for example - but the system rewrites the path so that it ends up in the Container folder instead. For example under macOS apps typically write their data to ~/Library/Application Support. A sandboxed app cannot do that - and the data is instead written beneath the ~/Library/Containers/app-id path for that app.

    And here’s how good Apple is, any application, including 3rd party tools running inside Terminal will be restricted:

    I bet most people weren’t expecting that a simple ls would trigger the sandbox restrictions applied to the Terminal application. The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.

    I believe this was the best way to go about things but it would require to get a DE team to make it in a cohesive and deeply integrated with the system. Canonical could do it… but we all know how Canonical is.

    • Zamundaaa@discuss.tchncs.deEnglish
      3·
      10 months ago

      The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.

      No, Flatpak isn’t the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there’s noone restricting the old / unrestricted ways of doing things… So apps usually don’t port over to the portals.

      Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don’t get kicked from app stores for it, and because many users can still fall back to using the old system.

      • TCB13@lemmy.worldEnglish
        21·
        10 months ago

        While what you say is true, the “portals” were an afterthought, an imposition to developers and a cumbersome and poorly documented solution. Just like the theming and most other things.

        Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path? A GUI capable of automatically enumerating those resources and a bunch of checkboxes like "app X and Y both have access to socket at /var/run/socketY would also solve most of the issues.

        • Zamundaaa@discuss.tchncs.deEnglish
          2·
          10 months ago

          Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path?

          Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience. Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.

          Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.

          • TCB13@lemmy.worldEnglish
            1·
            10 months ago

            Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience

            It doesn’t but until apps can declare on a simple config file what paths they require that’s the way things should work. I guess that would motivate the developers who are packing into Flatpaks to properly list whatever files the application requires. If they don’t, then the application will still work fine but be a bit annoying.

            Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too. Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.

            Yet, macOS does and things don’t go that bad, on the example how do you think they do it for command line tools? The system intercepts the request, show the popup and wait for the user input. I’ve seen the same happening with older macOS applications that aren’t aware it could happen and yes, the main thread is blocked and the application seems to crash.

            I thinks it’s way better doing it this way and still have a somewhat productive container and isolation experience than just bluntly blocking everything - something that also breaks apps sometimes.

            • Zamundaaa@discuss.tchncs.deEnglish
              1·
              10 months ago

              until apps can declare on a simple config file what paths they require

              They can, and always could. Apps aren’t doing it, most Flatpaks have just blanket “allow ~/Downloads” or “allow all of home” permissions by default - or no file permissions, and you have to go grant them manually yourself.

              Again, unless apps actually support it, no matter how good the security system is, it won’t work out.