3 ms·

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 outsid

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.

davexunit 11y ago
>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.
- Afforess 11y ago
  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.
  - davexunit 11y ago
    The issues with bundling far outweigh the benefits.
    - aidenn0 11y ago
      I disagree.
      - davexunit 11y ago
        Become a distribution maintainer and you will change your mind.
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 ago
  It's funny how you listed e.g. libpng but not libjpeg which breaks the ABI very often.
  - ploxiln 11y ago
    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 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 ago
  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.

davexunit 11y ago

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

Afforess 11y ago
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.
- davexunit 11y ago
  The issues with bundling far outweigh the benefits.
  - aidenn0 11y ago
    I disagree.
    - davexunit 11y ago
      Become a distribution maintainer and you will change your mind.

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 ago
It's funny how you listed e.g. libpng but not libjpeg which breaks the ABI very often.
- ploxiln 11y ago
  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 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 ago
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.