Its even worse when you force Firefox to use wayland its icon doesn’t even show.

Edit: Oh since everyone now is confused; I only have the flatpak version of Firefox installed yet it doesn’t use the pinned icon and doesn’t even use the firefox icon under wayland at all.

  • igorlogius@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    2
    ·
    edit-2
    1 year ago

    The problem with dependencies, that’s the only reason for people to look at flatpak.

    no, not really, flatpak is a distro agnostic way to build and distribute packages, which is HUGE for developers and distros, since those dont have to waste time to repackage (built+test) software to work on their systems and instead use that time to deal with other issues.

    flatkill.org

    The author should really take that site down. AFAIK, all the points are now invalid.

    • BeigeAgenda@lemmy.ca
      link
      fedilink
      arrow-up
      2
      arrow-down
      3
      ·
      1 year ago

      The point is still that you distribute a OS with your application, that’s just silly and lazy.

      • igorlogius@lemmy.world
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        1
        ·
        1 year ago

        silly and lazy

        Not really, if you think about how many distros there are and how many people are currently wasting time with re-packaging software over and over for them i think you’ll come to realize that this is a very clever and efficient move. The way it is done currently seems rather silly in comparison.

        Sidenote: You keep using the term OS … which is false in the sense, that flatpak doenst come with a direct hardware layer / kernel

        • BeigeAgenda@lemmy.ca
          link
          fedilink
          arrow-up
          2
          arrow-down
          2
          ·
          1 year ago

          Aside from the kernel you still need most libs, including glibc so it’s a OS without the kernel.

          Next evolution will then be to use flatpak from within flatpak or what?

          • igorlogius@lemmy.world
            link
            fedilink
            English
            arrow-up
            4
            ·
            1 year ago

            OS without the kernel

            just thought you wanted to use the term OS in a way that people will understand you. Saying OS without the kernel … sounds to me like i want a sandwich without filling .... .

            Next evolution will then be to use flatpak from within flatpak or what?

            Is this a joke about para-virtualization? - anyway, i think flatpaks abstraction and isolations make sense. Not to much and not to little. Just enought to keep an application isolated from the basesystem while using portals to interact with necessary apis.

            • BeigeAgenda@lemmy.ca
              link
              fedilink
              arrow-up
              1
              arrow-down
              2
              ·
              1 year ago

              Using the word OS puts across my point, because when you start packaging your toolchain with glibc and whatever libs you need for your application, you end up with a good part of the Linux file system. Yes there’s missing services and so on but they could run if needed.

              It’s not a virtualization joke, it’s more of a “we put flatpak in your flatpak so you can flatpak while you flatpak” recursion joke.

              • qaz@lemmy.world
                link
                fedilink
                arrow-up
                2
                ·
                1 year ago

                Most system libraries are included in runtimes that are shared among applications.

                • BeigeAgenda@lemmy.ca
                  link
                  fedilink
                  arrow-up
                  1
                  arrow-down
                  1
                  ·
                  1 year ago

                  Sounds more and more like flatpak is a distribution atop of a distribution.

                  Good you can share libs, although I can’t see sense in sharing more than the absolute basic libs, and even then some applications will need different versions of the basic libs.

        • BeigeAgenda@lemmy.ca
          link
          fedilink
          arrow-up
          3
          arrow-down
          3
          ·
          edit-2
          1 year ago

          Docker is made for servers, it’s totally a different usecase.

          I am not anti VM and docker, I just don’t think we need more levels of indirection in the OS, I also don’t think a distro based heavily on flatpak will be any good, one thing is sure it will be using a lot of diskspace and memory, as there’s no sharing of libs. And if flatpak starts sharing libs it just re-invented the GNU linker.

          • 𝒍𝒆𝒎𝒂𝒏𝒏@lemmy.one
            link
            fedilink
            arrow-up
            4
            arrow-down
            1
            ·
            1 year ago

            I mostly agree with those points.

            Flatpak does support sharing ‘libraries’ (although not in the way you mean), however from my perspective the main problem is developers referencing Kde-Framework-420.69.1, and others referencing Kde-Framework-420.69.1-rc1 or various other variations of very similar dependencies, which tends to eat up additional disk space. I’m personally not too bothered by it, but that’s only because I have the storage space for that.

            With flatpak’s shtick being isolation and a consistent runtime environment, I doubt there’ll be true sharing of linked libraries and the associated memory space, so excess RAM usage and disk space as you’ve mentioned.

            The distros based on Flatpak (can’t remember the names right now sadly) are mostly immutable ones, where the base system remains untouched, and in that scenario I think it makes the most sense, particularly in education.

            The instances I use flatpak are slightly similar to that, with the difference being the libraries available in the base system may be too old to run the application natively