4 ms·
The instability of libraries is enabled by the bundling culture of the ecosystem. System libraries are extremely API and ABI stable, including libc, libz, libp
by ploxiln 11y ago
The instability of libraries is enabled by the bundling culture of the ecosystem.
System libraries are extremely API and ABI stable, including libc, libz, libpng, xlib, gtk+2, glib2, etc.
npm enables bundled libraries to have their own bundled libraries, and also encourages trivially small "libraries", so the explosion of sub-dependencies is entirely unmanageable and the best you can do is let every lib bundle its own copy of every other lib and try to forget about it all.
But long-lived large linux distros, with useful applications like firefox and gimp, and a large number of common supporting libraries, show that it doesn't have to be that way. You can have just one zlib, you can have just one gtk+2, you can install bugfix and security updates for them.
- legulere 11y agoIt's funny how you listed e.g. libpng but not libjpeg which breaks the ABI very often.
- ploxiln 11y agolibjpeg is silly, but that's why everyone uses libjpeg-turbo now, which maintains API/ABI compatibility with libjpeg v8 http://www.libjpeg-turbo.org/About/Jpeg-9 http://www.libjpeg-turbo.org/About/Jpeg-9 And if it comes to having a library or two with two ABIs/APIs, like gtk2 and gtk3, or libjpeg7 and libjpeg8, that's not a big deal - those two lines have different "sonames", and it's just those two versions to manage globally, rather than a per-app multitude.
- aidenn0 11y agoAPI and ABI stability are good, but also no guarantee of non-breakage. A glibc change to the memcpy implementation broke hundreds of programs a few years back. Note that it is conceivable that there were security vulnerabilities introduced by this change.