3 ms·
That is with regards to the points raised in the article, specifically, how hard it is to manage dependencies, and their security, when you have 300 of them ins
by whytevuhuni 2y ago
That is with regards to the points raised in the article, specifically, how hard it is to manage dependencies, and their security, when you have 300 of them instead of 12.
For a developer, crates.io makes managing dependencies a breeze. For a user, they might just download a static binary, or a FlatPak, and they'll be happy.
But for system binaries? Those need to be part of a small base, with trusted dependencies. The crates.io model works against that; the massively distributed ownership of micro-dependencies makes trusting the security of your system almost impossible. Statically built binaries means that updating your system means re-downloading the entire OS on every security update.
The only solution to this is to ditch crates.io and vendor a small base of dependencies, the same way the Linux kernel does it, the same way Firefox does it, and the same way the Rust compiler does it. Using crates.io is really hard.
- nightpool 2y agoSetting aside whether or not I agree with the premise that smaller dependencies are worse for building system binaries (I think Nix provides a compelling counterargument), how is vendoring Rust dependencies "like C" (the same way Firefox and the kernel do) a regression from building C? All Linux dependencies are already vendored, and even without access to crates.io, getting access to Rust's language features is still a Pareto improvement over C, not a regression.