Background-Story: I did a “flatpak update” on a remote client and every package wants the PW for downloading and for installing again. I had to enter the password like 30 times or more.

  • Kusimulkku@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    9 months ago

    Inter process messaging seems to be have quite some attention right now. I don’t think it’s very far now, if KeepassXC/Firefox issue I’m following is any indication.

    When two flatpacks package the same library, they duplicate memory use.

    Maybe I misunderstood you, but if they share the same library, the memory deduplication is already happening? I found this https://github.com/flatpak/flatpak/issues/4997

    I’ve been running fairly low ram machines and I genuinely haven’t noticed any difference. Maybe I haven’t run enough of them at the same time and them having different (not shared) libraries. I wonder what the benchmarks are on this. I’ve only seen threads where people say it uses a bit more but no real comparison.

    end-all, be-all package format.

    I’m not sure if that’s the direction. I think flatpak is specifically targeting GUI apps, with the “system” packages being traditional packages. And I think that’s a good solution, that way you’d have a tighter system layer that could even be immutable and you’d have a separate application layer, so they don’t mess with each other. Good for preventing breakage of the system if there’s somehing fucky with some app.

    • acockworkorange
      link
      fedilink
      arrow-up
      1
      ·
      9 months ago

      I think that deduplication ticket refers to library flatpacks. Like both flatpacks depend on a third one, and the contents of that third one will be loaded only once in memory.

      I was taking about libraries packaged together with two apps. I don’t think the OS will know that two files located in different locations are actually the same and can be loaded only once in memory.

      If that is solved, I’d be really glad to hear. Especially the decisions involved in handling multiple versions.

      Whereas about how much of the system goes in flatpacks, once you’ve put your DE and apps on it, that’s like 80% of a typical desktop software load. There’s not much left and, like you said, the rest can be immutable. You may argue the DE is part of the base system, and I’d agree with you, but many people don’t.

      Veering off topic for a bit… TBH it feels a little too much like Windows for my taste. When apps have a package maintainer, you can choose the level of stability you want and developers can focus on adding features / optimizing. When you remove that layer, the developers need to figure out how stable to keep their app to cater to most users, and if you are not comfortable with that, tough luck.

      • Kusimulkku@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        9 months ago

        They do talk about how the library deduplication in memory is an OS feature and nothing to do with flatpak so it’s possible that the same library being shared might be dedupped whether it is in same runtime or not. But I don’t know. In any case, I guess extra RAM use is possible but I don’t think (from personal experience and reading up on it) that it’s very noticeable. Not to mention a lot of the used libraries do come with the runtimes, so that alleviates the issue if the dedupping isn’t happening.

        Whereas about how much of the system goes in flatpacks, once you’ve put your DE and apps on it, that’s like 80% of a typical desktop software load. There’s not much left and, like you said, the rest can be immutable. You may argue the DE is part of the base system, and I’d agree with you, but many people don’t.

        I think the intention is to keep at least some parts of the DE outside of it, but the apps that make it as flatpaks. So for KDE I think it would be something like the shell, file indexer, “low level” stuff like that out and image viewer, media player, browser, “apps” like that in flatpaks. Which does break the DE up but makes sense to me, with “system” being separated from “apps”.

        Veering off topic for a bit… TBH it feels a little too much like Windows for my taste. When apps have a package maintainer, you can choose the level of stability you want and developers can focus on adding features / optimizing. When you remove that layer, the developers need to figure out how stable to keep their app to cater to most users, and if you are not comfortable with that, tough luck.

        You could have “stable repos” for flatpaks, maintained by distros but I feel like it would take away some of the point of it (being to ease distro repo maintainer workload). Some devs will be happy that there’s no “meddling” distro maintainers, which is a complaint I’ve sometimes seen from devs. I think the idea that the apps come straight from the devs is both good and bad. Good in that it’s how the dev intended and updates are possible much quicker. Bad in that often the modification distros do serve a good purpose, of making the app better fit in to the whole or fixing stuff that misbehabes but for whatever reason hasn’t been fixed upstream.

        • acockworkorange
          link
          fedilink
          arrow-up
          2
          ·
          9 months ago

          Nothing further to add, I’d just like to thank you for the engaging discussion. Have a good one!