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 ¯_(ツ)_/¯
Comment on [deleted]
sxan@midwest.social 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.
inZayda@lemmy.blahaj.zone 1 year ago
sxan@midwest.social 1 year ago
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 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
sxan@midwest.social 1 year ago
That’s interesting. Snap and Flatpack seem to me to be mainly of benefit to the distro maintainers; I don’t see much, if any, benefit to users.
Why do you think it’ll affect end-user acceptance of Linux?
folkrav@lemmy.world 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.
sxan@midwest.social 1 year ago
Oh, I thought you were saying that it would make Linux more mainstream. Sorry, I misunderstood you.
Yeah, it is going to drive more new Linux users to Ubuntu; personally, I think that’s a core motivation in its deaign.
Sethayy@sh.itjust.works 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.
sxan@midwest.social 1 year ago
Do you mean Snap/Flatpack? If so, you will probably have even more up-to-date software if you used a rolling release distro like Arch.
folkrav@lemmy.world 1 year ago
I’m… very curious as to what you mean by this take.
sxan@midwest.social 1 year ago
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?
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.