Maybe do the trendy thing and link your whole distro together with your app (a.k.a containers)?
Producing software that can simply launch is so wildly complex that the solution is... to snapshot an entire operating system install to run the application.
That’s INSANE. But it’s unfortunately required. https://xkcd.com/1987/
> Now, for the worst of all — one that combines all the aforementioned issues, and adds even more. Bundling (often called vendoring in newspeak) means including the dependencies of your program along with it. The exact consequences of bundling vary depending on the method used.
Let’s consider this statement at face value. The WORST thing a program can do is... include the things the program needs to run? So programs should... NOT include the things they REQUIRE to run?
I get it. I understand the argument. But if you take just a half step back it should be clear how utterly broken the whole situation is.
Programs that bundle dependencies have a radically reduced need for snapshots, VMs, or containers. Such tools do provide a variety of value. But they don’t become virtually requirements to merely launch a program without error.
Ship your damn dependencies says I. Either statically or dynamically, but ship them.
To put it another way, what do you think the relative popularity of distributing your own internal software via a private apt repo is compared to bundling it as a stateless container and putting it on a registry? Some big companies that pre-date containers do it with apt. Most don’t. For good reason.
I'm sure a similar solution could also work with apt.
What's new is containers and k8s. People will put more into that, for dev and critical sw.
However, for full desktop or OS it's probably cargo-cult or hard to scale and maintain.
This solved a huge problem for us in the geointelligence ground processing community. The various product generation algorithms tend to all be native code, but they're produced by different contractors, on different delivery schedules, some of whom are no longer on contract at all to provide updates. What do you do when four of them all depend on libxerces-c but all four depend on a different version? Tell them to stop pinning dependencies and update? How, if they're not on contract to do it? Tell the US Congress to get off their butts and award more money to the backing agencies so they can get their developers back on contract? Good luck. In practice, what we ended up doing, without wanting to stripe certain applications to only run on specific servers when some of them are used a ton more than others, was to install dependencies on an NFS mount shared by all the fast compute hosts, into application-specific subdirectories, and then set PATH and LD_LIBRARY_PATH before calling the executable that did all the work.
This system was terrible! But before containers, it was the best we could do. Now we just deploy each individual processing algorithm in its own container, and they can depend on whatever they want, all using standard system path under the illusion they have an entire OS and filesystem all to themselves. and never clash with each other.
We agree 100% on the problem. I enthusiastically agree with all of your complaints.
My point is that Linux model of system-wide shared libraries and PATH/LD_LIBRARY_PATH bullshit is terrible. And the fact that containers are required to resolve that spiderweb nightmare is a damning indictment on the Linux library model.
Containers are one possible solution. An alternative is for those applications to bundle their dependencies. If all applications bundled their dependencies then everything would “just work”. No need to hack bullshit envvars. No need to containerize.
Yes that means it’s harder to deploy security fixes. But if everyone is using containers then also those images need to be updated. At which point what have you even gained?