Actually, the better question is: When will they replace most desktop Linux programs?

  • key@lemmy.keychat.org
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

    God I hope not. Especially not snap, it’s so painful and slow. AppImage works fine enough I guess. I don’t want an ecosystem where more and more developers go with these only and neglect being able to install at a system level.

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

      That is unfortunately the future because maintaining packages for a million different distros is painful to say the least. The best you can hope for is native packages for the top 10 distros. Everyone else will have to deal with flatpak.

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

        Doesn’t that just depend on whether or not the people maintaining are happy with the flatpak experience? If they’re not, they’d probably keep maintaining their packages.

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

          There are a limited number of build systems and most build systems have some form of dependency management built into them.

          Upstreaming modifications so projects can be built using standard build commands is a more monotonous than difficult.

          Doing that lets distributions reuse build pipelines accross multiple projects, which simplifies their support burden.

          Similarly there are also a limited number of packaging formats and 3 main distributions which most things branch from. Configuring a project to produce an aur, deb & rpm for their base OS layout (e.g. Arch, Debian & RHEL) is again monotonous but helpful to have upstream.

          Take an Electron App, this is based on Node.js and will use NPM or Yarn to build and retrieve dependencies.

          While both support script extensions, the convention for NPM building and releasing is:

          • npm install
          • npm build --if-present
          • npm test --if-present
          • npm publish

          NPM provides libraries to create, aur, rpm and deb artefacts. You would add them as additional scripts, which are called as part of prepublish script (which gets called as part of publish).

          There is no reason that can’t live upstream.

        • TGRush@forum.fail
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          The problem here is that most packages aren’t maintained by developers, but rather by independent package maintainers from respective distributions.

          In my eyes, this adds another potential point of failure outside the control of the developer of a given tool.

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

            In my eyes, this adds another potential point of failure outside the control of the developer of a given tool.

            On the contrary. The Fedora maintainers saved all their Audacity users when audacity introduced a spyware in their build. The flatpak had the spyware for months while the Fedora release of audacity was made secure by the maintainers. I value this, if you remove the people doing it then you remove value for everyone. It all comes down to how much you value your privacy.

            Windows has a fantastic model where every software just work. It’s great! The result is an abomination of devs stealing your data or doing whatever mess on your computer. “Free software” was synonymous of red alerts and we used programs like Adaware or whatever cleaner software. Each months there was another new cleaner utility. When was the last time you cleaned your distro?

            Try to expand the scale of flatpak and you’ll see that you will hit the same problems that any other distro.

            • TGRush@forum.fail
              link
              fedilink
              arrow-up
              0
              ·
              1 year ago

              I don’t really see Fedora maintainting a patched version of audacity as a fault of Flatpak, though.

              Flathub is designed to allow developers to publish their own software in the way they intended. So Flathub and Flatpak are doing exactly what they’re designed to do

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

                Well, I can’t give you a better example of the effect of auditing softwares for your desktop. One source, Fedora, had the app patched, while the other, official on flathub, published the flawed version on purpose.

                You’d prefer to run the flatpak version of audacity with the spyware on? I don’t buy that.

                Flathub is designed to allow developers to publish their own software in the way they intended. So Flathub and Flatpak are doing exactly what they’re designed to do

                Okay, so it’s another way to phrase that you really preferred the version of flatpak with the spyware, since it’s the version intended by Audacity. With flatpak and flathub you are alone.

                Fedora and their maintainers offer you a layer of no-nonsense, you should think twice before writing it off. I don’t think that you fully realize the quality of what you have right now in your hands in term of desktop. Popularity has a price and Windows users paid the price for it.