[deleted]
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.
[deleted]
Submitted 1 year ago by niemand@discuss.tchncs.de to [deleted]
Comments
sxan@midwest.social 1 year ago
folkrav@lemmy.world 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.
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?
- 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 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 ¯_(ツ)_/¯
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?
al177@lemmy.sdf.org 1 year ago
Oh, like back in the Before Times when everything was statically linked?
jasondj@ttrpg.network 1 year ago
How far you wanna go with this?
Your shell itself is actually a docker container that just runs bash and mounts the root filesystem, and everything in /bin is just an alias to a dedicated minimal container?
Illecors@lemmy.cafe 1 year ago
Your shell is not, actually, a docker container. kexec is not docker, or chroot, or container.
bassomitron@lemmy.world 1 year ago
Yeah, I was about to say as well… I’m a little skeptical on that being the case
folkrav@lemmy.world 1 year ago
People answering your comment seem to be skipping the question mark lol
sxan@midwest.social 1 year ago
Could you explain why shells are docker containers?
echo64@lemmy.world 1 year ago
You’re basically describing windows and osx.
Tb0n3@sh.itjust.works 1 year ago
Windows has DLLs. I think OP is asking how big it would be if everything were statically linked or didn’t use linked libraries. Like every single thing was a flatpak.
echo64@lemmy.world 1 year ago
Yeah, this is what windows and osx do. Two games/apps don’t share the same dlls. The os can do some stuff to reduce memory footprint if they do, but it requires them to be the same version, effectively the same dll.
Generally apps on windows and osx do not share libraries between apps, they ship the libraries they need and run them.
Synthead@lemmy.world 1 year ago
Not really. Windows has libraries, also.
theamigan@lemmy.dynatron.me 1 year ago
Well, back in the days of static everything, some OSes had every system command be a hard link to the same binary (just switching on
argv[0], like busybox) so they could still share library pages. This was a big deal when your workstation only had 8MB of core.jbk@discuss.tchncs.de 1 year ago
It’s not like we’re back to having 8MB disks though.
theamigan@lemmy.dynatron.me 1 year ago
Yes, waste and poor stewardship of resources for threadbare rationale is just great!
CondorWonder@lemmy.ca 1 year ago
I’m not sure how consistent it is but the static binaries I have for btrfs-progs are about 2x larger than their dynamic counterparts. If you statically compile it only the functions actually used are included in the binary, so it really depends on how much of the library is used.
sxan@midwest.social 1 year ago
This is a good way to look at it. Anything using a GUI would have a far worse ratio. Imagine statically linking a KDE application. Even for us tiling WM users, statically linking even the barest-bone X program would be huge.
A reasonably statically linked system would probably be in the range you suggest: about 2x. All the GUI stuff would be dynamic, and even so that accounts for half an install size; more if you install a DE like Gnome or KDE; statically link all of the rest of the headless stuff and double its size, and it’s probably close.
What would kill you would be all of the scripted stuff. If you bundled the entire python vm for every python tool, it’s more than doubling the size.
Zeth0s@lemmy.world 1 year ago
I guess nobody knows. It also really depends on the program installed. If you need all qt, jdk, java for each program with a ui… You’d run out of space soon
abbadon420@lemm.ee 1 year ago
Nobody knows and nobody wants to know. Some stones are better left unturned.
kinttach@lemm.ee 1 year ago
Is that basically the premise of NixOS?
BareMetalSkirt@lemmy.kya.moe 1 year ago
Not at all, each package has a regular dependency tree like on any other distro. The difference is that each package can see a different subset of dependencies so you can have multiple versions of a library. What would be a version conflict on most distros here just means you have two different libsomething side by side. The /nix/store on my desktop is roughly the same size as my Gentoo /usr.
Chobbes@lemmy.world 1 year ago
Packages can share dependencies in NixOS, and often do for packages in the same version of nixpkgs. It’s not quite the same as statically linking everything, but it basically gives you the perks of that with fewer downsides and other advantages.
skullgiver@popplesburger.hilciferous.nl 1 year ago
The norm for most Rust packages is to statically compile everything. That’s why every Rust application needs a rebuild and update every time a vulnerability is found in a package like RustTLS (which many projects don’t do). This allows a Rust program to run basically anywhere a modern enough version of the C library is installed, without any worries about dependencies, at the cost of disk space.
You end up with binaries tens or hundreds of megabytes that are kilobytes in size for most C code. GUI and networked applications are especially fat, because they’re often full of frameworks and other projects.
I would estimate the size difference as “10x the size of your /usr/bin, but without 99% of /usr/lib”. My /usr/bin is about 2.3GB in size, my /usr/lib is about 17GB.
In theory you could test this on a distro like Gentoo: if you edit the build scripts right, you can get the entire OS to be compiled with static compilation.