[GTALUG] A find alternative: fselect

[D. Hugh Redelmeier]

| From: o1bigtenor via talk <talk at gtalug.org>

| > Rust culture and practice doesn't seem to like shared libraries..  I do.
| > (Just like I find the update model for persistent containers unfortunate.)

|  would you please explain the above last statement?

As I understand it, Rust programs are statically linked.  Furthermore,
a Rust program tree has copies of "crates" that only get updated when
you ask to have them upgraded (re-imported from crates.io).

Contrast that with C source.  System header files, referenced by
#include in the program, are updated whenever updates are supplied by
the distro and accepted when the sysadmin applies updates to the
host system.  Static and dynamic libraries are updated the same way.

So: if there is an update that fixes a bug, including a security bug:

- for a dynamic library, a system update will fix the bug in every
  binary program that uses it.  No re-compilation is needed.

- for a static library, a system update plus a re-link of each program
  that uses it will fix each of them.  Recompilation isn't needed but
  that isn't often an important advantage.

- for a header file, a system update plus a recompilation of each
  program that uses it will fix the each of them.

- For Rust: each Rust project must decide to update the version that
  is incorporated the crate.  I don't know that this is nearly as
  automated as Linux distro system updates are.  I don't get the
  feeling that performing such updates are part of the Rust culture.
  Then a project recompile/rebuild is required.

- for containers: for updates to libraries (or other components) the
  container must be rebuilt.  This must be done on a system that
  itself has been updated.  Since there are many container
  technologies, I cannot be more explicit.

Summary: one system-wide update that fixes a shared library, all C
programs on that system are fixed too.  This isn't true of Rust
programs.  This isn't true of things inside containers.

On the other hand, bug fixes might make a calling program behave
differently.  That change might actually destabilize some system.
Some folks thing stability is more important than bug fixes.

Also: Rust libraries are young and thus change more frequently than C
libraries.  Often for reasons other than bug fixes.  This may amplify
the previous argument for stability.

Windows has suffered from "dll hell" with undisciplined use of shared
libraries.  So much so that they often end up not being shared or
updated.  But the Unix world, generally, has not.  This Windows
experience has given shared libraries a bad name.

To a certain extent, if you link your C program statically, you can
execute its binary on any Linux distro.  This does not work with
shared libraries.

Shared libraries significantly reduce the size of programs.  Rust
binaries are probably quite a bit larger than C binaries.