[GTALUG] A find alternative: fselect

[Lennart Sorensen]

On Thu, Jun 13, 2019 at 02:12:22AM -0400, D. Hugh Redelmeier via talk wrote:
> 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.

Go has the same design flaw.  Giant static binaries.

Amazing how many new programing languages don't want to pay attention
to history and the security lessons already learned.

-- 
Len Sorensen