Simon Josefsson wrote:
> > Your syslogd argument is not convincing for me,
> > so far.
>
> Agreed! The argument is a strawman and needs to be qualified before
> becoming a justifiable argument to add complexity.
Thanks for admitting this. So, we can concentrate on coreutils in the
discussion.
> Taking it to the extreme, essentially
> all shared library calls should be converted into dlopen, with graceful
> fallback when the library isn't available, and that seems just weird and
> somehow exposing a deeper problem.
That's a valid approach in specific situations. For instance, the format
string checker in GNU gettext depends on libxml2. But we did not want
libgettextpo.so to depend on libxml2; therefore Daiki Ueno wrote a small
substitute module that is just good enough for that special case.
But in other situations it is not possible. For example, libcurl has a
lot of dependencies:
$ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4
linux-vdso.so.1 (0x000076c127171000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14
(0x000076c127025000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0
(0x000076c127003000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1
(0x000076c126fe3000)
libldap.so.2 => /usr/lib/x86_64-linux-gnu/libldap.so.2
(0x000076c126f80000)
liblber.so.2 => /usr/lib/x86_64-linux-gnu/liblber.so.2
(0x000076c126f6f000)
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
(0x000076c126f20000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5
(0x000076c126f0b000)
libssl.so.3 => /usr/lib/x86_64-linux-gnu/libssl.so.3
(0x000076c126dfd000)
libcrypto.so.3 => /usr/lib/x86_64-linux-gnu/libcrypto.so.3
(0x000076c126600000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
(0x000076c126da5000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1
(0x000076c126ce2000)
libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1
(0x000076c126cd1000)
libz.so.1 => /usr/lib/x86_64-linux-gnu/libz.so.1 (0x000076c126cb3000)
libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x000076c126200000)
libunistring.so.5 => /usr/lib/x86_64-linux-gnu/libunistring.so.5
(0x000076c126019000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
(0x000076c125e00000)
libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6
(0x000076c126c66000)
libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8
(0x000076c1265a9000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
(0x000076c126523000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
(0x000076c126c4b000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
(0x000076c126457000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
(0x000076c126c1f000)
libcom_err.so.2 => /usr/lib/x86_64-linux-gnu/libcom_err.so.2
(0x000076c126451000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
(0x000076c126444000)
libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1
(0x000076c126421000)
/lib64/ld-linux-x86-64.so.2 (0x000076c127173000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x000076c125c25000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
(0x000076c125c0e000)
libkeyutils.so.1 => /usr/lib/x86_64-linux-gnu/libkeyutils.so.1
(0x000076c126012000)
libresolv.so.2 => /usr/lib/x86_64-linux-gnu/libresolv.so.2
(0x000076c125bfb000)
libffi.so.8 => /usr/lib/x86_64-linux-gnu/libffi.so.8
(0x000076c125bea000)
If here the dependencies to the crypto libraries were made optional
("Recommends"), it would mean that accessing web sites over https would
not be possible any more. Yes, there are use-cases for this mode (namely,
accessing http servers running on localhost), but they don't warrant
dependency surgery.
> Dependency bloat is a real complex problem too, though. We thought we
> solved this with shared libraries, but this problem seems to come back
> in a different form today, leading to the dlopen() approach. Maybe we
> will go back to static linking (most of the Go ecosystem). We know how
> to re-compile large sets of binaries easily today, and doing so has
> other QA/compiler advantages, so maybe the argument for shared libraries
> is weaker today than it used to be.
Shared libraries really solved the problem. It makes it possible to run a
desktop (like KDE, with kate and kmail) on a laptop with 1 GB of RAM (slow,
sure). The static linking approach, as seen in Go and Rust ecosystems, is
a waste of RAM for most use-cases.
The real challenge is that the software world has reached unprecedented
levels of composability:
- libgmp implements bignum arithmetic,
- Crypto libraries need bignum arithmetic, hence use libgmp.
- Web access needs crypto libraries (and an HTML parser and a CSS library).
- Many applications, including IDEs, embed a web browser.
- Soon, IDEs will also embed a container that includes an LLM execution engine
for locally running LLMs.
And so on...
There are distros that no longer package the SAGE package (sagemath.org)
because they could not cope with the levels of composition therein.
Bruno
