[GTALUG] why I like shared libraries -- no longer a popular position

[D. Hugh Redelmeier]

| From: David Collier-Brown via talk <talk at gtalug.org>

In this case, a simple bug needs to be fixed.  No interface change.  The 
number of packages to update is the number with copies of this buggy code.  
Copies count, references (shred libraries) are free.

Not as easy when interface changes (not additions) are desired or 
required.

| People discovered that there was an NP-complete problem with competing
| versions of library functions, but instead of addressing it, they kluged
| around it with static linking, snaps and flatpacks. And ended up with a
| different problem, as Hugh noted.

I guess that I've been spoiled by C's maturity.  The core libraries tend 
to mutate slowly and the Committee has as a base that revisions should not 
break programs (but they may break implementations).

(I think that they failed badly in this when the negated the promise of 
int max_t.  They refused to break ABIs so they broke programs.  Better to 
have eliminated intmax_t (a noisy change) than break it (a silent 
change).)

Languages like Rust and Go have libraries that have evolved and must 
evolve relatively quickly.  Even the core libraries.

In Linux, we see how major versions of GTK have stranded a variety of 
programs.  The switch from X11 to Wayland has also been difficult.

As time goes on, more of our work is adjusting to change rather than 
building change.  We don't write programs, we assemble them.  Then we have 
to shepherd the assembly through time.  A different skill set, one that I 
haven't developed well.

So: anything that makes this easier to do safely would be good.
Avoiding a problem (not just putting it off) is great.