Latest Patches Sent Out For Adding Rust Support To The Linux Kernel

[9Strike]

Oh please don't add fucking cargo as a kernel dependency. Rust, ok if it helps, but cargo is literally the definition of distro-unfriendly software.

[bug77]

Let me guess. They're following Firefox's lead in abusing the environment variable for building rustc itself which grants stable/beta-channel access to unstable language features which are only supposed to be accessible on nightly channel.

Why would you guess that? There are always unstable features in the stable and beta channels, why would you assume they're also pulling in some more?

[bug77]

Oh please don't add fucking cargo as a kernel dependency. Rust, ok if it helps, but cargo is literally the definition of distro-unfriendly software.

Not one line says anything about cargo.
As far as I have seen, cargo works very well for a purely Rust project. If that doesn't work for you, you can always work with rustc directly.

[cesarcafe]

Rust? In the kernel? Why not Python? Or even better: Java.

[dragonn]

Rust? In the kernel? Why not Python? Or even better: Java.

You level of ignorance doesn't even fit in our solar system.

[cynic]

Rust? In the kernel? Why not Python? Or even better: Java.

ehm sir, you seems confused.

aren't you mistaking rust with ruby? are you?

[oleid]

Oh please don't add fucking cargo as a kernel dependency. Rust, ok if it helps, but cargo is literally the definition of distro-unfriendly software.

It is there temporarily. To re-build the standard-library with the aforementioned "no abort if allocation doesn't work"-features. And the standard library is only used for the tests.

[ultimA]

I think most people would consider improved security and stability more important than -O3

But is Rust's security really that much better? -O3 is irrelevant (I don't care about that either), but as for security, real world shows Rust's most advertised feature, its "better security compared to C++" is very limited and over-estimated. There is no shortage of memory memory-related CVEs in Rust crates, both double-drops/frees and dereference of invalid memory. See link below.
Or even more shocking, Firefox has about 20% of its native code in Rust, yet the share of memory-related CVEs (percentage-wise) is basically still the same as in any other non-Rust project (about 70%).

Sources:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

https://www.openhub.net/p/firefox/an...guages_summary
https://www.cvedetails.com/product/3...?vendor_id=452

[oleid]

Or even more shocking, Firefox has about 20% of its native code in Rust, yet the share of memory-related CVEs (percentage-wise) is basically still the same as in any other non-Rust project (about 70%).

Well, Firefox only being 20% rust is part of the problem. Many CVEs in firefox are about dealing with C interfaces in a safe way.

[ultimA]

Well, Firefox only being 20% rust is part of the problem. Many CVEs in firefox are about dealing with C interfaces in a safe way.

Sure, and because it is not completely written in Rust, I am not expecting Firefox to be free of memory-related issues. But if it is 20% Rust, I do expect it to have almost 20% (or at least 10%) less memory-related issues, which is not the case at all. One might argue the reason is memory-related issues are not guaranteed to have the same occurrence rate in all parts of the code. But it is safe to assume that Mozilla didn't choose to rewrite exactly those parts in Rust that are the least likely to have security issues, so I'm pretty sure this doesn't explain it.