True in some situations, but a fundamentally flawed approach to FOSS. Indeed, if you are statically linking noncritical code, than for maintainability it is ea

True in some situations, but a fundamentally flawed approach to FOSS. Indeed, if you are statically linking noncritical code, than for maintainability it is easier to version-lock an entire OS with the build tree in a VM. Thus, the same input spits out the same audited binary objects every time. In some situations it is unavoidable (see Microsoft or FPGA ecosystem). However, a shared object library ecosystem is arguably a key part of FOSS when it works properly on *nix. As it is fundamentally important to keep versioned interoperability with other projects to minimize library RAM footprints etc. Additionally, all projects have a shared interest in maintaining each others security, rather than trying to waste resources on every application that has legacy stripped static obfuscated vulnerable leaky objects. "Reuse [shared objects], Reduce [resource costs], and Recycle [to optimize]." Sounds like familiar advice... =) like how some git solutions don't handle large binary artifacts well or simply implode. Good luck, and maybe one can prove all those cautionary stories wrong. YMMV =)