I’m talking about things like “python3-blabla” and “libsomething”. How bad would it be if nobody used these library-packages and everyone just added all kinds of libraries as part of an application’s package?

  • 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍@midwest.social
    link
    fedilink
    arrow-up
    17
    arrow-down
    2
    ·
    1 year ago

    You may find out. This is what snap and flatpack do, basically. And containers, for that matter. They’re a sort of half-assed version of static linking where you get few of the benefits of either, and most of the downsides of both.

    • folkrav@lemmy.world
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      1 year ago

      They’re a sort of half-assed version of static linking where you get few of the benefits of either, and most of the downsides of both.

      I’m… very curious as to what you mean by this take.

      • Ok. It’s not entirely fair, but I think Snap is designed like something with an ulterior motive masquerading as a solution to a problem of questionable severity.

        Dynamic linking is a reuse solution, right? The benefits are that you reduce code duplication and size impact, and also get the benefit of wider positive impacts of bug and security fixes. But it was mainly developed as a way of reducing space requirements when disk and memory were far more constrained than today. Not only did you reduce at-rest size of programs, by dynamic linking also allows the OS to load code into memory once and re-use that across multiple programs. The downside is dependency hell, where OSes have to manage multiple versions, and poor vendor versioning practices where minor upgrades needed by some applications unexpectedly break others. This last point is one of the problems Snap and Flatpack are trying to solve.

        Statically linked programs minimize dependency hell. A statically linked binary can be copied around to nearly any machine of the same architecture and will run. And it will be runnable, through system upgrades, almost indefinitely. There are almost no dependencies, not even e.g. on a running Snap service on the machine. The downside is greater binary sizes, being impractical for GUIs, the loss of auyomatic distribution of bug and security fixes in dependencies, and only being available to statically compiled languages (outside of bundling software for interpreted VMs, which have always been hit-or-miss second-class citizens).

        So what does Snap get you?

        • A dependency on what is almost a system-wide VM: snap itself
        • Another service that needs to be running on the computer, or else you can’t run snap packages
        • Dynamic linking to libraries, but without the benefit of broad application of bug and security fixes rolled out in dependencies - the downside of statically linked binaries
        • The benefit of statically linked stability, but without the portability and independence of a statically linked binary
        • The loss of much of the dynamically-linked space savings, as library version isolation ends up reducing the ability of the OS to share code between programs.

        Fundamentally, automatic distribution of bug fixes, and stability through upgrades are conflicting goals; it is impossible to satisfy both. This is due to the essential truth that one tool’s bug fix is another’s breaking change.

        I made the comment that I believe Snap has an ulterior motive, and I feel as if this needs an explanation. If you compare Snap’s design to, say, appimage or Flatpack, it’s pretty clear that - by intention or not - Snap creates a walled garden where the Store controlled by one entity which has the ultimate say in what shows up there. It isolate software; if you look at what’s happening in the OSS space, projects that are packaged for Snap tend to be far more difficult to install outside of Snap - the authors often don’t even bother to provide basic building instructions that don’t require Snap. This has a chilling effect on other distributions - I am encountering more software that is only available through the Snap store; without build instructions ouside of Snap, it makes it harder for volunteers to create packages for other distros. It’s not a lot, but it’s a disturbing trend.

    • inZayda@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      i mean aren’t they more like distro independent package managers its not like its going to install a different library for every program unless they require specific versions, which ig could be true, but then youd have both installed anyways so ¯_(ツ)_/¯

      • I think it’s more accurate to say they will install different libraries for every package unless there’s a matching library already installed. I don’t think this is just semantics because, as you say, the former is what traditional distro managers do, whereas the latter is what Snap does. The Snap-based system will end up taking more space, with more different versions of the same library installed, than a traditional system over time. For that, you trade (arguably) fewer dependency-related issues, and more ability to concurrently run software with conflicting library versions. Regardless of the benefits, per the question OP posed, a Snap (or Flatpack) based distro will end up taking up more space.

        I haven’t run Gentoo in decade(s, almost), but IIRC you could configure it to build mostly statically-linked packages, which would pretty much net you OP’s hypothetical system. That would be even larger than a Snap-based system.

    • Sethayy@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      But you do get the simplicity, and following the real ‘free’ part of Foss you get the choice to do the fancy nerd magic if you want.

      But for most of us flatpaks are readily updated and easily installed, idfc about no gtk magicians spells.

      I think its a major step towards general linux acceptance

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

          End-users just see “huh, X distro doesn’t have Y app”. Application availability is a major component of adoption of a platform.

        • Sethayy@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          1 year ago

          As a mid-power user I almost exclusively use them just because I want my software up to date. for example using discover I can update all my godot installs on all my devices to the latest features I’m seeing everyone rave about. (this is mainly for the maintainers but it trickles down)

          Looking back into when I first was dipping my toes in linux though things like missing libraries and other scary looking apt errors essentially meant I didn’t go further from there and accepted not installing the package. I could see this frustrating lots of users early and causing them to return to windows as I did for a bit.

          edit to add on: I still consider it very important to have the option to install it through a deb let’s say, but more alike how one can compile from source with a thousand flags if they choose - just as long as its a choice

            • carly™@lemm.ee
              link
              fedilink
              English
              arrow-up
              2
              ·
              1 year ago

              In my experience Arch is pretty unstable, though. I’ve never had an Arch installation that didnt break by the end of the month. Flatpaks allow me to use a stable base like Debian while having certain programs more up to date.

              • Sethayy@sh.itjust.works
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                Exactly this is why I haven’t made the switch yet.

                Its like letting a package be managed per package instead of per distro, giving its devs some more fine grain control on stability vs update speed