Drew DeVaultJun 26, 2020
Over half of your libraries are used by fewer than 0.1% of your executables.
Show threadChrisJun 26, 2020

@sir

find /usr/bin -type f | xargs sudo ldd | awk '/^\s/ { print $1 }' | sort | uniq -c | sort -n | tail

292 libicudata.so.67
292 libicuuc.so.67
298 libresolv.so.2
344 libglib-2.0.so.0
356 libpcre.so.1
370 libffi.so.7
411 librt.so.1
499 liblzma.so.5
587 libstdc++.so.6
738 libgcc_s.so.1
799 libz.so.1
1106 libm.so.6
1179 libdl.so.2
1284 libpthread.so.0
2400 /lib64/ld-linux-x86-64.so.2
2413 libc.so.6
2413 linux-vdso.so.1

Show threadChrisJun 26, 2020
@sir This is kinda the opposite of what you were talking about, but... checks out.
Show threadDrew DeVaultJun 26, 2020
@viralstitch there are some commands you can run here https://drewdevault.com/dynlib.html
Dynamic linking

Show threadSashanoraa (old)
@sir @viralstitch the security argument isn't that the download size of updates is big(or at least that's not the argument I've heard). It's that if there's a bug in, openssl for instance, every program on your system would have to ship a patch to fix it. The fear is that some won't. I don't have data on this so I can't say if the fear is founded or not but it seems plausible.
Jun 26, 2020 at 6:09amWeb
Show threadDrew DeVaultJun 26, 2020

@zethra @viralstitch they don't have to ship a source code patch, it's not like 1000 upstreams are suddenly going to have to make changes to accomodate. If it were, then dynamic linking would cause the same problem.

Instead the distros just kick off 1,000 jobs to their builders, get a cup of coffee, and check on it in a few hours.