@sir Thanks! Lower N of packages and binaries, but basically the same system, therefore, to no one's surprise. The same results.
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
Here is the filtered version:
den@raznix:/tmp$ time find /nix/store -type f -executable -print | grep bin | xargs ldd 2>/dev/null | awk -f libs.awk | sort -rn > results.txt den@raznix:/tmp$ wc results.txt 1126 2252 18464 results.txt den@raznix:/tmp$ head -n20 < results.txt 12637 linux-vdso 12637 libc 12637 ld-linux-x86-64 7939 libpthread 7114 libdl 6746 libm 5098 librt 4895 libz 3877 libgcc_s 3041 libstdc++ 2758 libuuid 2661 liblzma 2582 libpcre 2442 libgpg-error 2426 libgcrypt 2398 libglib-2 2370 libblkid 2361 libcap 2252 libffi 2242 liblz4
nixos ships a different dynlib for every single program This is not entirely true. Each individual program (derivation in terms of Nix package manager) is linked with the required library versions, so two completely different versions of the same program can coexist in the system without problems, but duplication is excluded, since for each program the checksum from its derivation source is calculated, and these checksums are used as a key in Nix store. In fact, the derivations of programs is no different from the derivations of related libraries.
/usr/lib and /usr/bin are a sham? Oh yeah!
den@raznix:~$ ls -al /bin/** /usr/** lrwxrwxrwx 1 root root 75 Jun 24 13:49 /bin/sh -> /nix/store/lb3hli8d9536g45mndwfwyi6fpny0blh-bash-interactive-4.4-p23/bin/sh /usr/bin: total 12 drwxr-xr-x 2 root root 4096 Jun 24 13:49 . drwxr-xr-x 4 root root 4096 Jan 31 2019 .. lrwxrwxrwx 1 root root 66 Jun 24 13:49 env -> /nix/store/9v78r3afqy9xn9zwdj9wfys6sk3vc01d-coreutils-8.31/bin/env den@raznix:~$ ls -al /lib* zsh: no matches found: /lib*
@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.
@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.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!