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.

  • je t'aime 💘@jlai.lu
    link
    fedilink
    arrow-up
    60
    ·
    edit-2
    10 months ago

    There is some drawback. The main one : app can’t communicate with each other.

    Example firefox and his extension keepass. As keepass can’t communicate with firefox, you have to open both apps and switch their windows.

    You can use flatseal to manage communication between apps but that’s not an easy process and may prove a security issue if you don’t understand the technical jargon.

  • TCB13@lemmy.world
    link
    fedilink
    English
    arrow-up
    46
    arrow-down
    2
    ·
    edit-2
    10 months ago

    Yes, I love it and don’t get me wrong but there are many downsides and they all result from poor planning and/or bad decisions around how flatpak was built. Here are a few:

    • Poor integration with the system: sometimes works against you and completely bypasses your system instead of integrating with it / using its features better. To me it seems more like the higher levels are missing pieces to facilitate communication between applications (be it protocols, code or documentation) and sometimes it is as simple as configuration;
    • Overhead, you’ll obviously end up with a bunch of copies of the same libraries and whatnot for different applications;
    • No reasonable way to use it / install applications offline. This can become a serious pain point if you’re required to work in air gapped systems or you simply want to level of conservation for the future - it doesn’t seem reasonable at all to have to depend on some repository system that might gone at some point. Note that they don’t provide effective ways to mirror the entire repository / host it locally nor to download some kind of installable package for what you’re looking for;
    • A community that is usually more interested in beating around the bush than actually fixing what’s wrong. Eg. a password manager (KeePassXC) and a browser (Firefox/Ungoogled) both installed via flatpak can’t communicate with each other because developers seem to be more interested in pointing fingers on GitHub than fixing the issue.

    Flatpak acts as a restrictive sandbox experience that is mostly about “let’s block things and we don’t care about anything else”. I don’t think it’s reasonable to have situations like applications that aren’t picking the system theme / font without the user doing a bunch of links or installing more copies of whatever you already have. Flatpak in general was a good ideia, but the system integration execution is a shame.

    • Beej Jorgensen@lemmy.sdf.org
      link
      fedilink
      arrow-up
      12
      ·
      10 months ago

      The double-edged sword of isolation.

      On the one hand, poor communication between apps and waste of storage.

      On the other, relative safety from malicious applications, or from otherwise-safe applications built on top of a thousand libraries none of which have been audited by the dev.

      I don’t know how it’s going to go down, but I suspect something will come along to address these issues and snatch the market away from Flatpak.

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        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.de
          link
          fedilink
          English
          arrow-up
          1
          ·
          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.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            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.de
              link
              fedilink
              English
              arrow-up
              1
              ·
              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.world
                link
                fedilink
                English
                arrow-up
                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.de
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  edit-2
                  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.

      • okamiueru@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        Do you know if flatpak leverages the memory side of this? With shared libs, you only keep one copy in memory, regardless of how many applications use it. Makes application launch faster, and memory usage lower.

        For flatpak, it of course will load whatever it needs to load, but does it manage to avoid loading stuff across other flatpaks?

  • BrianTheeBiscuiteer@lemmy.world
    link
    fedilink
    arrow-up
    32
    arrow-down
    1
    ·
    10 months ago

    For me it’s lacking in user friendliness. Go easy on the downvotes if I’m doing it the hard way.

    • Flatpaks aren’t really single-executables. You have to use to the flatpak command to run them.
    • I can’t just say flatpak run firefox, I have to use the full app-id which could be quite long.

    Yes, I could make this simpler with scripts or aliases but how hard would it have been for Flatpak to automatically do this for me?

    • Miyabi@iusearchlinux.fyi
      link
      fedilink
      arrow-up
      13
      arrow-down
      2
      ·
      10 months ago

      I’m using KDE and when I download a flatpak it automatically creates a .desktop file. I think gnome does this too if I’m not mistaken. I do have to restart or relogin for it to put the file there but that’s not that bad IMO.

      • caseyweederman@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        I think I’ve been having an issue with the Steam Flatpak where after updating, the .desktop file breaks. If not, my icon is broken for different reasons. Either way, I’ve been running Steam through the command line for ages.

      • Miss Brainfarts@lemmy.blahaj.zone
        link
        fedilink
        arrow-up
        3
        arrow-down
        2
        ·
        10 months ago

        I’m on Endeavour xfce and the .desktop files are just there immediately. I never even knew this wasn’t the case on other systems

      • Bizzle@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        10 months ago

        I don’t put anything on my desktop but if I put Firefox in my krunner (alt-f2) box the flatpak shows up right away after installation

  • kugmo@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    28
    arrow-down
    2
    ·
    edit-2
    10 months ago
    • overly verbose way to launch them in terminal
    • can sometimess not even respect your gtk/qt theming
    • sandboxing/permission system can lead to you trying to figure out which directory you need to give access to when you want to save file if it wasn’t preconfigured
    • uses its own libraries and not system libraries, want to play the hit new AAA game with steam flatpak? get fucked it requires a mesa commit that was merged 8 hours a go and you’re stuck on 23.0.4 and can’t use the git release.

    Flatpak probably has it’s specific uses like trying to use one piece of proprietary software that you don’t trust and don’t want to give it too much access to your system, or most GUI software clients having an easy way to install Discord on your Steam Deck (no terminal usage, Linux is easy yay), but native packages 99% of the time work better.

  • rotopenguin@infosec.pub
    link
    fedilink
    English
    arrow-up
    25
    arrow-down
    1
    ·
    10 months ago

    The worst part of flatpaks is that they don’t get to see the actual path of files that they open. Instead, they get a /var/run/1000/blah proxy. The proxy is forgotten after you reboot, so any flatpak that memorized that path is holding a bunch of dead links.

  • AMDIsOurLord@lemmy.ml
    link
    fedilink
    arrow-up
    24
    arrow-down
    1
    ·
    10 months ago

    1- It takes a lot of space. jUsT bUy a bIgGeR dRiVe --stfu I’m not going to spend money for you to waste it

    1- a) Everyone assumes you’re an American with 20Gbps symmetrical fiber optic. My internet can’t handle 2+ Gb downloads for a fucking 50 Mb app bro

    2- Duplicate graphics drivers. Particularly painful with Nvidia

    3- It puts a lot of security work with distro library trees straight into the shitter

    4- Horrendously designed system for CLI apps (flatpak run org.whocares.shit.app)

    5- Filesystem isolation has many upsides for security but also it can cause some pain (definitely nitpicking)

    • shapis@lemmy.ml
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      10 months ago

      All of this. Plus often it just doesn’t work.

      And no. I do not want to blind fiddle with the permissions to fix it.

    • robojeb@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      10 months ago

      Where in America is there 20Gbps symmetrical fiber? Everywhere I know tops out at 1gbps if you are lucky that your ISP isn’t shit, and lots of areas are still on slow cable.

      In my area my options are 200mbps cable or 100mbps ADSL (which inexplicably costs more than the cable Internet)

      • S_H_K@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        Maybe is an hyperbole I have optic fiber straight to my door here and is 10gbps tops but usually it works around 80% of that with some conditions. And it’s not symmetrical I don’t recall the up speed tho.

  • danielfgom@lemmy.world
    link
    fedilink
    English
    arrow-up
    24
    arrow-down
    3
    ·
    10 months ago

    It’s HUGE. That’s the biggest downside for me. I’m always use a deb/native package first because they are way smaller.

    • hornedfiend@sopuli.xyz
      link
      fedilink
      arrow-up
      12
      arrow-down
      1
      ·
      10 months ago

      Of course they are. they share dependencies with other software. flatpaks bundle all dependencies,which is great for sandboxing,even though some sort of break the rule and share some,they are still sandboxed.

      Unless you “firejail” or “bubblewrap” your software, security is much better OOB for flatpaks.

      • soFanzy@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        10 months ago

        That’s a myth. Security of flatpaks depends entirely on the given permissions, and since most flatpaks just set their own permissions on installation, or require filesystem access to work, there is no meaningful difference in security OOB.

  • jan teli@lemmy.world
    link
    fedilink
    arrow-up
    23
    arrow-down
    3
    ·
    edit-2
    10 months ago

    Some people don’t like it because it uses a bit more storage and can start a bit slower, (I think) they can’t be used for system packaged, and I’ve also had some issues with theming

      • wildbus8979@sh.itjust.works
        link
        fedilink
        arrow-up
        5
        ·
        10 months ago

        Using flatpak on low end devices (like Linux phones), I can tell you from experience, the speed liss is noticeable. Specially for application startup. As is the resource overhead.

        • GravitySpoiled@lemmy.ml
          link
          fedilink
          English
          arrow-up
          4
          ·
          edit-2
          10 months ago

          That’s a fairly good point. On mobile startup can be crucial because sessions are short in comparison to desktop where you have longer sessions and startup time is negligable (even the slow startup times of snaps could be ignored for e.g. a video editing session)

          Low specs shouldn’t keep the community from moving into newer technology.

          • wildbus8979@sh.itjust.works
            link
            fedilink
            arrow-up
            3
            ·
            10 months ago

            Precisely. I’ve been playing with Mobian on a One Plus 6 (works great) and while I really like the idea of using mostly sandboxed app much like things work on Android, right now it certainly negatively impacts the experience.

      • acockworkorange@mander.xyz
        link
        fedilink
        arrow-up
        2
        ·
        10 months ago

        One thing I always wondered is whether libraries in memory would be duplicated or not. I have seen a lot of people talking about storage space which is cheap and shouldn’t really be the focus for desktops. But I haven’t seen anything about in memory usage.

  • SethranKada@lemmy.ca
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    1
    ·
    10 months ago

    It’s great for user apps, gui apps, and sandboxing. It’s terrible for cli apps, libraries, development, and integration.

  • aberrate_junior_beatnik@midwest.social
    link
    fedilink
    English
    arrow-up
    19
    arrow-down
    1
    ·
    10 months ago

    I think its biggest weakness is also its biggest strength: isolation. Sometimes desktop integration doesn’t work quite right. For instance, the 1password browser extension can’t integrate with the desktop app when you use flatpak firefox.

  • Pantherina@feddit.de
    link
    fedilink
    arrow-up
    14
    arrow-down
    1
    ·
    edit-2
    10 months ago
    • no OS level components
    • duplicate libraries as some core apps (editor, filemanager, Desktop) cannot be flatpaks (yet?)
    • old runtimes etc. dont force developers to keep them updated. Often thats because or 3rd party packagers though
    • complicated packaging, I heard that the Flatpak builder is better for certain languages.
    • theming issues I heard (on Fedora Kinoite Wayland it just works, and I can also force themes per app)
    • bad permissions by default (best we have though)
    • bad run commands (this could easily be fixed, and I have a script for it)

    For OS components / packaging every part, Snaps may work, but for GUI apps they seem subpar and nobody really cares.

    Nix may be way better for installing just anything compartimentalized, but there is no permission system (thats why packaging is easier).

    But Flatpaks are really great overall, Bubblewrap, KDE Settings / Flatseal, Portals, official app support. Its really really important.

    • Justin@lemmy.kde.social
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      complicate packaging, XML sucks (are there good editors or something?), I heard that the Flatpak builder is better for certain languages.

      What has XML got to do with it? Flatpak manifests are either JSON (not great but OK) or YAML, which is great.

      • kamiheku@sopuli.xyz
        link
        fedilink
        arrow-up
        17
        arrow-down
        1
        ·
        10 months ago

        YAML, which is great

        countries:
          - fi
          - se
          - no
          - dk
        
        => { "countries": ["fi", "se", false, "dk"] }
        
        • Justin@lemmy.kde.social
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          10 months ago

          Probably JSON. I haven’t been involved in Flatpak for a long time but I’ve never seen XML. JSON is quite close to XML in it’s layout sometimes I find so easily mistaken.

  • PerogiBoi@lemmy.ca
    link
    fedilink
    arrow-up
    13
    ·
    10 months ago

    I’ve had my first downside with flatpak.

    VSCode’s flatpak version won’t let you use certain packages because they’re installed on the system and flatpak is a sandbox with no access. You need to enable some stuff but I’m far too lazy to troubleshoot that shit.

    I got the Snap version so I’m ready for the hate.

  • MNByChoice@midwest.social
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    10 months ago

    Why isn’t this just the default?

    One may notice that for every new method, the old ways stay around, possibly forever. It is not the default because there were things that worked prior to flatpak. The distros that from before flatpak have likely added the capability, but won’t likely change their default for another decade, or more.