Thread replies: 7
Thread images: 2
Thread images: 2
File: LarryFan(´・ω・`).jpg (33KB, 408x517px) Image search:
[Google]
33KB, 408x517px
Can we rethink our shared library linking paradigm, specifically with regards to GNU/Linux, for a second?
As far as I can tell we have 2 choices:
1) Our current system which allows software to share common code reducing disk space and allowing that software to use upgraded libraries without having to be recompiled.
---
downsides: Although on paper it's foolproof, in practice it leads to our environments being fairly delicate, distro maintainers having to re-invent the wheel all the time (the REAL reason you can't install shit from one distro on another has nothing to do with package manager, it's that that piece of software was tediously trimmed to work on a particular setup and not on any other), and the inability to install multiple versions of most software without using "prefixes" or other containers.
OR
2) No linking. Software is rock solid and can be run and compiled on just about any environment.
---
downsides: Small bug fixes always require a complete recompile (when that fix is in a piece of common code used redundantly in 100's of programs on your machine, and when similar fixes come out routinely every few days it can be quite tedious), this method also requires more disk space
Are these really the only 2 choices? With all the intelligent people that have contributed to our software development over the years we really can't come up with anything better?
I mean, I can pull an alternative out of my ass right now. Why not add an additional layer of symlinks whereby each program links to its own personal symlinks instead of ones shared by the entire system. By default those personal links can just point to the system-wide libraries as usual, however in the case that something breaks you can just force those personal links to point to _exact_ versions of what it requires and then you're _guaranteed_ to always get running software.
This can be handled automatically by the package manager.
Why is nobody trying to solve this sort of thing anymore?
>>
>>60223015
>Why is nobody trying to solve this sort of thing anymore?
Flatpak does
>>
>>60224118
You mean Appimage
>>
>>60224145
Appimage doesn't link to shared libraries, its basically op’s number 2 solution.
With flatpak, developer can choose between libraries packed on framework or use its own
>>
>>60223015
Shared libraries are shit. RAM is abundant these days; there's no reason to have this massive amount of interdependency just to shave off a few kilobytes on executable sizes.
>>
File: screenfetch-taeyeon.png (10KB, 981x311px) Image search:
[Google]
10KB, 981x311px
>>60223015
Shared libraries are fine and they work just great for distributions and they should keep on using them. There are real advantages to doing so.
Problems arise when you're writing your own little piece of software and you want to distribute that to a broad user-base across distributions and you do not want to give them the source. Making a static binary for your own little software project is just fine.
>>
>>60223015
>Are these really the only 2 choices?
no, but shared libraries is better than big binaries insanity
>add an additional layer of symlinks whereby each program links to its own personal symlinks
GNU Stow
Thread posts: 7
Thread images: 2
Thread images: 2