• yaaaaayPancakes@lemmy.world
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      Flatpack isn’t without its own quirks and flaws. There is no One True Way. Being open-source, there shouldn’t be one.

      It is definitely slow though, mostly on first run.

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

        Being open-source

        Yeah, that. That’s exactly the problem. To quote @Puzzle_Sluts_4Ever above, who put it much better than I could:

        . . . the main issues boil down to concerns over some parts of the Snap ecosystem being closed source, Canonical’s ongoing efforts to try to get some of the Red Hat “premium linux” money, and arguments that other solutions (e.g. flatpaks and appimages) are “just as good, if not better”. And it doesn’t help that Canonical/Ubuntu is increasingly pushing snap as “the only solution” for some applications.

        When you speak of no single One True Way and things being completely open source, Canonical/Ubuntu have already left the chat.

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

        There should be one way for sandboxed shit, since the alternative of package managers already exists

        We don’t need snap, app image, flatpak all to compete. We need shit that just works

      • nick@campfyre.nickwebster.dev
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        Gotta be honest, as a dev I tried to make a Flatpack of my app and gave up. Making a snap was much easier. Of course, I also offer it as a .deb, .rpm, Pacman package, etc. too

    • shininghero@kbin.social
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      I still don’t even know what problem snap and flatpak were intended to solve. Just apt or dnf installing from the command line, or even using the distro provided store app, has always been sufficient for me.

      • jj4211@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        1 year ago

        The idea is that the application may want libraries asynchronously of the distribution cadence. Worse, multiple applications may have different cadence and you want to use both (some app breaks with gnome 45 and so it needs gnome 44, and another app requires gnome 46).

        Or some pick forks of projects that neglected to change the shared object name or version, so you have two multimedia applications depending on the same exact library name and version, but expecting totally different symbols, or different ‘configure’ options to have been specified when they built the shared library.

        So we have this nifty mount namespace to make believe the ‘filesystem’ is whatever a specific application needs, and for that to be scoped to just one.

        There’s also an argument about security isolation, but I find that one to be unfulfilled as the applications basically are on the honor system with regards to how much access it requests of the system compared to a ‘normal’ application. So an application can opt into some protection so it can’t accidentally be abused, but if the application wants to deliberately misbehave it’s perfectly allowed to do so.

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

        Modern Linux distros tend to have configuration and dependency issues where certain packages if installed the “Linux Way” doesn’t completely work as desired at times depending on the distro or even a desktop spin (which might have different default libraries installed than the “main” one). Flatpak is a single configuration meant to work one single way across all distributions and has become more of a standard, usable way for Linux applications to just work.

        Use Flatpak. Easy to install and easy to tweak from flatseal or similar GUI Flatpak permission tweakers if you want more flexibility at the possible cost of security.