8 ms·

Shared libraries aren't just about reducing disk space and bandwidth consumption; it's also about fixing bugs in one place fixing it for all consumers. It requi

Shared libraries aren't just about reducing disk space and bandwidth consumption; it's also about fixing bugs in one place fixing it for all consumers. It requires discipline to only fix bugs and not break consumers, though, and therein lies the devil.

jblow 7y ago
The notion that it's about fixing bugs in one place is revisionist. It's not what people thought they were for when they were introduced.
- klodolph 7y ago
  This isn’t history, the relevant question is what shared libraries are for, not what they were intended to be for.
- acdha 7y ago
  That’s a really broad claim to toss around with no documentation. It wasn’t true at least as far back as the 1990s and I would especially want a citation for the belief that there was a unified single voice across so many different engineering teams.
antpls 7y ago
Shared libraries just don't work anymore. That's one of the reasons behind Go and containers. That way, the users always have working applications. Some applications may take more time to be up to date with their dependencies, but at least some of them can be updated asap without worrying about the others. For example, I use Debian 10 stable on my laptop, on which I installed Snapd. I then installed Firefox with Snap, and I can be confident that Firefox will have the latest security updates, while keeping the system stable (some parts of the system are probably unsecure, but at least everything still work, they will be updated later) Although, I would like to point that, while the storage space issue is solved with current tech, the bandwidth is still an issue when on mobile data.
- geggam 7y ago
  The idea of this is great. On your personal system it probably works really well. In reality tracking thousands of containers on top of operating systems which are using different methodologies gets really complex and in reality isnt ever really done well. At least in my experience. ( granted fortune 100 / 500 never does anything well :) ) What seems to be happening is the burden of the developer to maintain dependencies is now shifted to operations to maintain the automation that manages the various versions of containers because the complexity is too great to do it any other way. What I see happening in the application of this model is very similar to train wrecks. You see the crash coming for a long time but cant do anything to stop it.
jiveturkey 7y ago
It's also about memory consumption.

jblow 7y ago

The notion that it's about fixing bugs in one place is revisionist. It's not what people thought they were for when they were introduced.

klodolph 7y ago
This isn’t history, the relevant question is what shared libraries are for, not what they were intended to be for.
acdha 7y ago
That’s a really broad claim to toss around with no documentation. It wasn’t true at least as far back as the 1990s and I would especially want a citation for the belief that there was a unified single voice across so many different engineering teams.

antpls 7y ago

Shared libraries just don't work anymore. That's one of the reasons behind Go and containers. That way, the users always have working applications. Some applications may take more time to be up to date with their dependencies, but at least some of them can be updated asap without worrying about the others. For example, I use Debian 10 stable on my laptop, on which I installed Snapd. I then installed Firefox with Snap, and I can be confident that Firefox will have the latest security updates, while keeping the system stable (some parts of the system are probably unsecure, but at least everything still work, they will be updated later) Although, I would like to point that, while the storage space issue is solved with current tech, the bandwidth is still an issue when on mobile data.

geggam 7y ago
The idea of this is great. On your personal system it probably works really well. In reality tracking thousands of containers on top of operating systems which are using different methodologies gets really complex and in reality isnt ever really done well. At least in my experience. ( granted fortune 100 / 500 never does anything well :) ) What seems to be happening is the burden of the developer to maintain dependencies is now shifted to operations to maintain the automation that manages the various versions of containers because the complexity is too great to do it any other way. What I see happening in the application of this model is very similar to train wrecks. You see the crash coming for a long time but cant do anything to stop it.

jiveturkey 7y ago

It's also about memory consumption.