On Thu, Jun 13, 2019 at 1:12 AM D. Hugh Redelmeier via talk <[email protected]> wrote: > > | From: o1bigtenor via talk <[email protected]> > > | > 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 --- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
