🙈🙉🙊Jun 26, 2020
Drew DeVault
Over half of your libraries are used by fewer than 0.1% of your executables.
Jun 26, 2020 at 12:31amWeb
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 threadChrisJun 26, 2020
@sir Thanks! Lower N of packages and binaries, but basically the same system, therefore, to no one's surprise. The same results.
Show threadbirdyJun 26, 2020

@sir @viralstitch If interested, here’s how it looks from NixOS:

den@raznix:/tmp$ time find /nix/store -type f -executable -print | xargs ldd 2>/dev/null | awk -f libs.awk | sort -rn > results.txt find /nix/store -type f -executable -print 2,73s user 11,64s system 3% cpu 6:42,87 total xargs ldd 2> /dev/null 224,75s user 171,96s system 97% cpu 6:47,84 total awk -f libs.awk 9,32s user 1,59s system 2% cpu 6:47,84 total sort -rn > results.txt 0,00s user 0,00s system 0% cpu 6:47,84 total den@raznix:/tmp$ wc results.txt 1558 3116 27306 results.txt den@raznix:/tmp$ head -n20 < results.txt 74311 linux-vdso 74311 ld-linux-x86-64 74301 libc 54033 libpthread 50798 libdl 47967 libm 37971 librt 30477 libz 26778 libgcc_s 21663 liblzma 18912 libpcre 18439 libffi 18314 libglib-2 17857 libuuid 17832 libgpg-error 17459 libstdc++ 17447 libgcrypt 16875 liblz4 16802 libcap 15599 libresolv
Show threadDrew DeVaultJun 26, 2020
@sojka @viralstitch isn't this kind of bunk because nixos ships a different dynlib for every single program, and /usr/lib and /usr/bin are a sham?
Show threadSashanoraa (old)Jun 26, 2020
@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.
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.

Show threadabortretryfailJun 26, 2020
@sir
And the two that do use the same library require different versions.