On Sat, 24 Jun 2023 10:14:01 -0400
grg <grg-webvisible+...@ai.mit.edu> wrote:
> I agree usrmerge is a good thing, but I'd say it's actually adding
> bloat rather than trimming it: post-usrmerge there are (at least) two
> paths for every binary, two linkings for every library. pre-usrmerge
> there was usually just one on a given machine (even if different
> machines had different ones).
This isn't quite accurate. While there are multiple valid search paths
to binaries and multiple possible link paths for libraries, the
shell and runtime linker only care about the first ones they find. For
example:
$ which nohup
/usr/bin/nohup
$ ldd /bin/nohup /usr/bin/nohup
/bin/nohup:
linux-vdso.so.1 (0x00007ffdf9729000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1647dd0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1647fd4000)
/usr/bin/nohup:
linux-vdso.so.1 (0x00007ffcf42e0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3234636000)
/lib64/ld-linux-x86-64.so.2 (0x00007f323483a000)
It's a bit like multipath I/O: there are (at least) two paths for every
LUN but the multipath driver usually only cares about one at a time.
This isn't bloat. It's redundancy. It keeps the system running in spite
of failures.
> if we were trimming bloat we'd e.g. eliminate /bin, /sbin, /lib*
> completely (or the reverse, eliminate /usr completely) and have just
The accepted UsrMerge makes this possible: just delete the /bin, /lib,
/lib64 and /sbin symbolic links. Done. Your machines will be unusable
after doing this, but you can very easily do it. NB: I don't recommend
doing this.
--
\m/ (--) \m/
_______________________________________________
Discuss mailing list
Discuss@lists.blu.org
http://lists.blu.org/mailman/listinfo/discuss
