this post was submitted on 23 Jan 2024
521 points (98.7% liked)
linuxmemes
20483 readers
961 users here now
I use Arch btw
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules
- Follow the site-wide rules and code of conduct
- Be civil
- Post Linux-related content
- No recent reposts
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Great question! There is. What you’re describing is a package manager. Overall, they are a great idea. It means devs can create smaller “dynamically linked” executables that rely on libraries installed by the package manager. The w*ndows equivalent of this is using DLL’s. Another advantage is that urgent security updates can be propagated much faster, since you don’t have to wait for each app that uses a vulnerable library to update it on their own. Also, dynamically linked executables can help save on ram usage. With statically linked executables, everyone brings their own versions of some library, all off them off by a few minor revisions (which all have to be loaded into ram separately), whereas a bunch of dynamically linked executables can all pointed to the same version (only needs to be loaded once), which is what package maintainers often do. Finally, package managers eradicate the need for apps to include their own auto-updaters, which benefits both developers and users.
This model goes wrong when software depends on an outdated library. Even if the package maintainers still provide support for that outdated version, often it’s difficult to install two wildly different versions of a library at the same time. And apart from libraries, there are other things that a program can depend on, such as executables and daemons (aka background processes aka services), old versions of which are often even more difficult to get running along with their modern counterparts.
So when you say that the "W*ndows way kind of looks superior here", you are right about the specific edge case of running legacy apps. It just happens that the Linux crowd has historically decided that the other benefits of package managers outweigh this disadvantage.
There are tools for developers to bundle dependencies. Statically linked binaries, "portable" apps, AppImage, and so on... It's just that package managers are so widespread (because of the aforementioned benefits), few developers bother with these. The general attitude is "if you want a statically linked executable, go compile it yourself". And by the time it's time to make an "archiveable" version of an app because it's abandoned... nobody bothers, because it's, well, abandoned.
However, as disk capacity and ram size steadily increase, people are starting to question whether the benefits of traditional package managers really outweigh the added maintenance cost. This, combined with the recent development of a linux kernel feature called "namespaces", has spawned various new containerization tools. The ones I am familiar with are Docker (more suited for developer tools and web services), and Flatpak (more suitable for end-user desktop apps). I personally use both (flatpak as a user, and docker as both a user and a developer), and it makes my life a whole lot easier.
As for what makes it easier for users to get old apps working (which is what you're asking), well... that's sort of what we are discussing in this thread. Again, these tools aren't very widespread, because there is rarely a practical reason for running legacy programs, other than archivism or nostalgia. More often than not, modern and maintained alternatives are available. And when their is a practical reason, it is often in the context of development tools, where the user is probably skilled enough to just Dockerize the legacy program themselves (I did this a couple times at a job I used to have).