• joojmachine
    link
    fedilink
    arrow-up
    11
    arrow-down
    5
    ·
    3 years ago

    I am not in favour of these flatpacks/snaps or whatever these things are called

    If you don’t even know what they’re called (and snaps and flatpaks are definitely not the same thing, look into it) then why be so opinionated about it? learn why they exist and how they work.

    Packages should be distro packages, always.

    Easier said than done, that would only leave space for huge projects maintained by either a huge community or by a large corporation, with smaller projects struggling to maintain every single application out there, SPECIALLY if you want linux as a whole to grow and have more widely available software.

    Arch Linux is the perfect example of how failed this mindset is, where the main selling point of the distribution is how widely available every single software you need is there, but most of those are found not in the official repositories, but in an unnoficial, user-maintained and verified repository that unfortunately has the potential to be abused (either to spread broken packages or even malware, but fortunately, has been really well maintained for all these years).

    And the vendor of the software should never be responsible of packaging, thats literally the job of the distribution.

    That’s literally the job of the distribution until they’re faced with their limitations, be that licensing (flatpaks are basically the perfect way to have closed source applications if you need them), manpower to maintain said projects, or time to keep said projects polished and well maintained (in order to avoid other Linus moments™).

    Those are the main problems of encumbering package distribution to the distro maintainers, and the other big problem is f r a g m e n t a t i o n; seriously, try convincing a software developer to support linux when there are dozens of packaging formats depending on the distribution, the best you’ll ever get is either a .deb or a .rpm, flatpaks (and not snaps, because those are stupid) are an easy, surefire way to get an universal package available to every single distribution.

    I don’t see them as a substitute for distribution-maintained packages, but they are the best complement out there for when distros can´t maintain certain packages that are needed, and just shrugging them off like that is absolutely stupid.

    • adrianmalacoda
      link
      fedilink
      arrow-up
      14
      arrow-down
      5
      ·
      edit-2
      3 years ago

      Fragmentation isn’t real. The best way for developers to “support Linux” is to publish their source code and make it easy for users and distributions to build it. If it’s proprietary then that’s their problem, I’m not concerned with proprietary software.

      ed: For proprietary software, as silly as it may sound, the best approach to supporting “Linux” seems to be supporting Windows and then waiting for Valve/the community to support it using Wine/Proton.

      • joojmachine
        link
        fedilink
        arrow-up
        6
        arrow-down
        2
        ·
        3 years ago

        Yes, it does sound silly and it’s just plain and simply a bad take.

        You really, in your heart of hearts, believe that not supporting Linux and leaving the work to the already hands-full Wine devs is better than them supporting Linux with a native build on an universal platform?

        • adrianmalacoda
          link
          fedilink
          arrow-up
          8
          ·
          edit-2
          3 years ago

          It seems to be working out well for the “Linux gaming” people. Like I said, though, I’m not really concerned with the support of proprietary software on “Linux” or with the idea of the “universal platform” of “Linux.” The farther we move away from the idea of “Linux” being a “platform” the better.

          See also Let distributions do their job (Drew DeVault); note that the package manager I am using (GNU Guix) aims to make it easy to package different types of libre software projects using “importers” and it’s also possible to build packages directly from a specific git commit or reference.

      • NFT screenshotter@lemmygrad.ml
        link
        fedilink
        arrow-up
        4
        arrow-down
        2
        ·
        3 years ago

        ed: For proprietary software, as silly as it may sound, the best approach to supporting “Linux” seems to be supporting Windows and then waiting for Valve/the community to support it using Wine/Proton.

        terrible take, beyond the fact that a flatpak is infinitely more convenient than using wine to run a windows program, most programs outside of games are much more difficult to run on wine because most windows software makes their own toolkit among other components. Games are one of the few things that can be done so well through wine because they are generally built on similar base toolsets and engines.

        Also games are only being made to work so well on linux because the have a direct benefit to valve who wants more independence to sell their games without worrying about the platform they sell on being owned by microsoft/xbox. There is no software marketplace on desktops that would incentivize anything even remotely on that scale for regular software.