[GTALUG] A find alternative: fselect

[o1bigtenor]

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

Gord

>   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.

Thank you for your explanation!!!

Given what you have described I'm wondering if 'Go' functions
similarly - - - and then maybe that is why LXD is currently only supported
when its installed using Snapd and the miasma forces updating - - -
no matter what (max 2 months).

I don't check weekly for system updates here but I do try to keep my
systems updated for security reasons but I am very very uncomfortable
when the right to control the timing of the updating is taken from me.

Thanking you for your assistance!!

Regards