Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 17, 2022 17:45 UTC (Sun) by wtarreau (subscriber, #51152)
Parent article: Rustaceans at the border

I particularly despise automatic downloading of dependencies during build, and it's unrelated to the language. Many of us have already been bit by not being able to rebuild an old piece of software just because some dependencies were missing. For embedded systems as well as for some mission critical systems, you often need to be able to rebuild the same code 5 years later, to reproduce an equivalent system consecutive to a disaster, or to reproduce a production bug in a test environment. The kernel is one of such components you need to be able to reproduce, and it's really vital to be able to keep a local copy of *all* your dependencies and never rely on some $site that happily displays "this domain is for sale", or a download repository that displays "404 (as many have seen after trying to apply minimal fixes to very old debians for example after the repos were moved)".

Sure it's "more convenient for us developers" but developers' convenience is exactly what brings important costs in field (resource and problems). What made the success of linux is not just that it was opensource, but also that it was very reliable and reasonably easy to enter into. A reasonable balance needs to remain here. We don't need to see random code being injected all the time just to add a line on a resume like we're seeing dummy bug reports trying to be presented as security issues to get a CVE ID to the reporter.

I would like that the developers continue to make a little bit of effort to make sure that the code that builds today will build exactly the same in 10 years if I download the same tarball and build on the same system with the same tools. Right now the kernel stands by that critical promise because it's entirely self-contained. If some want other approaches, at least they should provide scriptable methods to retrieve everything and make sure one can always rebuild exclusively from these downloads.

to post comments

Rustaceans at the border

Posted Apr 17, 2022 23:08 UTC (Sun) by ssokolow (guest, #94568) [Link] (1 responses)

I think the "random code being injected all the time just to add a line on a resume" being undesirable is the important thing.

Cargo isn't NPM and they provide multiple layers of protection against kernel code failing to build ten years from now:

Crates.io is designed so that only the admins can remove things and they don't do that unless either they're legally compelled to or the thing in question is out-and-out malicious. Developers can cargo yank crate versions with security vulnerabilities to prevent new things from depending on them, but they're still available to be downloaded by any project that has them in the lockfile that Cargo automatically maintains, and you're encouraged to commit your lockfiles to version control alongside your code.
The cargo vendor command automates what the kernel devs currently do with things like zstd, providing something similar to the status quo, but while still preserving machine-readable info on where they came from that allows you to streamline monitoring for updates and auditing them for manually approved inclusion.
They care enough about forward compatibility and their v1.0 stability promise that, when they're considering making a change to the compiler or standard library in line with "We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations.", they've got a bot named Crater that can build and run the test suites for a chosen subset of the crates on crates.io, with "every single one" being a valid option. (Thank goodness for Microsoft donating the Azure time. It's a resource-expensive process.)
C has _Bool because too many people typedef'd bool. Rust has namespaces and editions so they can introduce new keywords like async and add new things to the prelude (the set of identifiers that get pulled into scope by default) without breaking existing code, because you have to opt into newer editions... and you can mix editions in the same build. They're just different frontends to produce the same underlying AST.
The compiler, standard library, etc. have an extensive test suite that gets run on every pull. (Another thing that would have become either prohibitively expensive or cripplingly slow with the growing number of platform targets without Microsoft donating Azure time.)
There are ongoing efforts to improve things further.

Rustaceans at the border

Posted Apr 19, 2022 17:48 UTC (Tue) by jsakkine (subscriber, #80603) [Link]

In this discussion I realized that it is better to experiment with the code rather than complain from the side. I did learn about "cargo vendor" command today, and it looks like a valid option for selected components. And I'm experimenting on bringing some of the stuff that I'm maintaining in the kernel to Rust. I'm also now following the vger list, which I also learned about thanks to this article.

One thing that might become obstacle is the state of Rust front-end support in GCC because it is hard to imagine that this could end up to mainline without being able to compile it fully with stock GCC. Also, in order to use Rust ever in the core would probably require full coverage of arch/*. But I guess the latter is not end of the world as far as drivers are concerned.