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.

  • Snoopy@jlai.lu
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year 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 will have to open both apps and switch their windows.

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

  • BrianTheeBiscuiteer@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year 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
      0
      ·
      1 year 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.

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

      • okamiueru@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        1 year 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?

    • YamiYuki@lemmy.kde.social
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      Some developers don’t want to deal with building an app for multiple versions. Sure some DEBs can work without needing to deal with that, but some don’t.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Flatpak is a distro on its own, but with original dev support. Its like a Linux Distro replacing others.

      So it adds complexity but with the potential to remove it from the OS. For example Libreoffice, Browsers, Thunderbird etc are huge and its a good approach to use official versions here.

      • AMDIsOurLord@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        Then what’s the point in having different distros lol we don’t have duplication for the sake of duplication there are reasons why there are different distros, philosophies and packaging method. I see this mistake from many usually newer Linux users, there are different distros because there is a point in packaging the OS differently.

        Flatpak for example completely abandons makig apps use patched system libraries. Or having different packages for different init systems. Or , god forbid, supporting BSDs

  • jro@discuss.tchncs.de
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    the main drawbacks I see are related to the sandboxing of apps, e.g. that several firefox addons that I just, such as the KeePassXC connector don’t work in flatpak packaged firefox, because they require native messaging support which is unavailable in flatpak. There is a three year old bug report on this at github, and an even older bug report in the Firefox bugzilla. Unfortunately, there seems to be no capacity to solve this or this is not a priority, although this problem affects quite a few users. I have similar issues with the Flatpak packages Nextcloud client: Do to the poor system integration, neither autostart works not integration with Nautilus or other file managers, unless you do some manual tinkering (which isn’t particularly difficult, but with native packages it will just work™ out of the box.) These issues have been known for many years, yet there seems to be no activity to solve them.

    • corsicanguppy@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      1 year ago

      To say nothing of a signed manifest of contents. It’s like 1995-era package management was lost on the kids who built this dreck.

  • BigTrout75@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    Endlessly reading on social media that is not a good from Linux “gurus”. LOL

    It’s been great for me, but I wish it had a official gui for permissions management.

    • Communist@lemmy.ml
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      Are you aware of flatseal?

      If you are, is there an issue with using it for you?

    • samc@feddit.uk
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      I wish there was an option for an android style system where, when an application wants to use a permission for the first time, you get a pop up asking you to grant that permission.

      Or, more generally, just some way to ensure that (a) a flatpak isn’t granted the permissions it wants automatically and (b) I can then manually grant those permissions as conveniently as possible

  • rotopenguin@infosec.pub
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year 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.

  • arthurpizza@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    There’s still a few edge cases that Flatpak is not great for. The Flatpak version of Kdenlive video editor can’t see Whisper, which it uses to generate subtitles. The Appimage and native builds work flawlessly.

    I’m assuming these problems will be addressed eventually but it takes time.

    • exception4289@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      I ran into an issue with flatpak version of Kdenlive that it would render only the topmost V track if it was a simple still image.
      Preview worked fine.
      Luckily, someone in Kdenlive’s Matrix suggested that I use an appimage. I used my distro’s version and the final render was fine.

      Other than that I had positive experience with flatpaks in general.

  • Samueru@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 year ago

    Flatpak usually ships very outdated drivers.

    I’ve been in the support channel for yuzu linux, and you would not believe all the issues people have with games freezing, etc that are instantly fixed by using the appimage instead of the flatpak.

    Also flatpaks are non-xdg compliant, since it creates the useless ~/.var directory. And they have said over and over that they won’t fix that. So fuck them.

    Not to mention all the issues people have with their theming and integration into the system.

    Appimages are just simpler and better, the other day I was thinking how many issues would be fixed if Steam shipped as an appimage.

    • It would allow for shipping a patch glibc with EAC
    • It would allow for moving all the nonsense that steam puts in the home user dir, since appimages support a portable home.
    • It would allow for shipping the 32bit libraries instead of having to install them system wide.

    And depending on how you go about, appimages will even take less disk space than flatpaks or native packages even though you don’t get shared libraries with those, because they are compressed which reduces their size significantly.

    Like for example the LibreWolf appimage is 110MiB while a the native package for librewolf 300MiB. Same with LibreOffice, the appimage is 300MiB while the native package is 600 MiB.

    It also makes it easier to downgrade if you run into an issue, like I had to had an older appimage of ferdium because the latest version is affected by an electron bug that broke its zoom functionality.

    • Chewy@discuss.tchncs.de
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      Interestingly I’ve currently crashing issues with running CS2 through Steam native on NixOS, while the Steam flatpak works like it should.

      The part about drivers is true though, as GPL is the reason I’m using native Steam.

        • Chewy@discuss.tchncs.de
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          1 year ago

          I mean the native NixOS package of Steam (instead of flatpak), not that the Steam package uses native libs.

          I believe Steam on NixOS always uses the Steam runtime, because NixOS isn’t FHS compliant, thus apps wouldn’t find any libs. No, I don’t think there’s steam-native on NixOS.

  • duncesplayed@lemmy.one
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    I feel like this should be required reading for a lot of Linux users. That article is a couple years old now, but I think is even more true now than it was when it was written. Having a middleman (package maintainer) between the user and the software developer is a tremendous benefit. Maintainers enforce quality, and if you bypass them, you’re going to end up with Linux as the Google Play Store (doubly so if you try and fool yourself into thinking it won’t happen because “Linux is different”)

      • acockworkorange@mander.xyz
        link
        fedilink
        arrow-up
        0
        ·
        1 year 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.

      • wildbus8979@sh.itjust.works
        link
        fedilink
        arrow-up
        0
        ·
        1 year 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
          0
          ·
          1 year ago

          That’s a fairly good point. On mobile startup can be crucial because sessions are short in comparison to desktop where you have linger 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
            0
            ·
            1 year 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.

  • burgersc12@mander.xyz
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 year ago

    Take a look at this site that goes into the details of the shortcomings of Flatpak, its from 2020 but I’m sure some of this is relevant still

  • lemmyng@lemmy.ca
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    The biggest downside is that it’s only for distributing applications with a graphical user interface. Command line utilities still need another method of distribution.

        • aberrate_junior_beatnik (he/him)@midwest.social
          link
          fedilink
          English
          arrow-up
          0
          ·
          1 year ago

          Yep. But,

          sudo tee /usr/local/bin/nvim <<EOF
          #!/bin/sh
          flatpak run io.neovim.nvim "$@"
          EOF
          chmod +x /usr/local/bin/nvim
          

          (I haven’t tested this, that I use similar code for a different program)

          It sure would be nice if flatpak bundled some functionality to do this for you, though.

          @oldfart@lemm.ee

          • oldfart@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            1 year ago

            I don’t need to do it with native-installed programs. And they are properly integrated with the OS, if you install them:

            1. You get a menu entry in gui
            2. You get a binary or a wrapper in /usr/bin
  • BaalInvoker@lemmy.eco.br
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    As everything in life, yes, there is downside. Major downside is that it can occupy more space in your hd or ssd.

    However I think the downsides are not that bad to justify all the hatred some guys have.

    Flatpak positive sides are way more relevant then the downsides