Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 29, 2025 15:42 UTC (Wed) by farnz (subscriber, #17727)
In reply to: Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ... by madscientist
Parent article: Vendoring Go packages by default in Fedora

The original motivation as documented by Sun engineering was that if they had to fix a system library in SunOS 3, it took months for the fix to be reliably rolled out across the customer base; Sun would ship tapes with the fix to ISVs and customers, but the fix wouldn't be fully rolled out until ISVs had shipped tapes with new binaries, and this whole process could take months.

The goal for Sun of dynamic linking in SunOS 4 was to let them maintain system libraries without being at the mercy of ISVs rebuilding their binaries against the bugfixed system libraries. Saving memory and disk space came later, after dynamic linking had been implemented in the 1980s and shown to do just that.

Don't just vendor - rebuild the ecosystem and persuade the vendor to work on software management ...

Posted Jan 30, 2025 18:19 UTC (Thu) by anton (subscriber, #25547) [Link]

Where can I find this documentation of Sun engineering? Reducing RAM and disk consumption was certainly an issue at the time, and the name "shared object" used in Unix systems (including SunOS) points to this aspect.

On Ultrix, which did not have dynamic linking, a number of utilities were linked into one binary (and argv[0] was used to select the proper entry point), in order to have only one instance of the libraries used by these utilities on disk and in memory.

On Linux, the uselib() system call for loading shared libraries was added before ISVs became relevant for Linux, so fixing libraries under indepenently developed software obviously was not the motivation to do it.