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.

  • @[email protected]
    link
    fedilink
    13
    edit-2
    1 year ago
    • What problem?
    • How is it already solved?

    This comment chain feels like talking to a brick wall. It’s just “don’t use flatpak” over and over again but with different words.

      • @[email protected]
        link
        fedilink
        9
        edit-2
        1 year ago

        Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions

        So if I checked the permissions with flatseal and that statement isn’t true for any of my flatpacks…where do we go from here?

        • Hovenko
          link
          fedilink
          11 year ago

          You can uninstall your package since you are not able to use it anymore. lol

        • @[email protected]
          link
          fedilink
          -11 year ago

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

            • @[email protected]
              link
              fedilink
              01 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?

                • @[email protected]
                  link
                  fedilink
                  -11 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
                    link
                    21 year ago

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

            • @[email protected]
              link
              fedilink
              0
              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.

              • 𝒍𝒆𝒎𝒂𝒏𝒏
                link
                fedilink
                31 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