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