Hacker News Reader

Comment by Afforess | Hacker News Reader

I disagree that bundling is a bad thing. Shared libraries are just as bad as a solution as the windows DLL hell. With shared libraries, you have to trust outside developers will not change function signatures or break your dependencies in some way. You have no recourse if this happens, and it does happen all too often.

It seems like an impossible mandate to ask a developer to support updating their code against new signatures and updated libraries for eternity, especially when their project is finished and feature-complete and they've moved onto newer projects. Developers bundle because we can't trust other developers not to break the rules, and are tired of the deathmarch of fixes.

View on HN

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.

It's funny how you listed e.g. libpng but not libjpeg which breaks the ABI very often.

libjpeg 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

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.

API 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.

>With shared libraries, you have to trust outside developers will not change function signatures or break your dependencies in some way.

With bundled libraries, the user has to trust outside developers, that didn't write those libraries, to stay on top of critical security updates to those libraries and releases new versions of their software with the relevant patches. This is completely unsustainable, both for the developer and the user.

Both solutions have flaws. This is a no-win, but it's worth understanding that neither solution is a silver bullet. I commented because the anti-bundling camp seems to think there are no benefits to bundling, and that is obviously false.

Yes, both solutions are unsustainable. Finding a better solution is where the discussion should be, not nitpicking which side is less broken.

The issues with bundling far outweigh the benefits.

I disagree.

Become a distribution maintainer and you will change your mind.

Reply on news.ycombinator.com