Linux Kernel Gets More Infrastructure for Rust, Increasing Interest in the Language (sdtimes.com) 39
Linux 6.1 (released last month) included what Linus Torvalds described as "initial Rust scaffolding," remembers this update from SD Times But now, "work has already been done since the 6.1 release to add more infrastructure for Rust in the kernel, though still none of the code interacts with any C code."
And there's still no actual Rust code in Linux: "You need to get all those things that can make sure that Rust can compile, and you can do the debugging and all these things," explained Joel Marcey, director of advocacy and operations for the Rust Foundation, "and make sure that the memory safety is there and all that sort of stuff. And that has to happen first before you can actually write any real code in Rust for the Linux kernel itself."
Marcey explained that Linux is going to be doing this inclusion very piecemeal, with lots of little integrations here and there over time so they can see how it is working. "I would imagine that over the next year, you're going to see more small incremental changes to the kernel with Rust, but as people are seeing that it's actually kind of working out, you'll be able to maybe, for example, write Linux drivers or whatever with Rust," said Marcey....
According to Bec Rumbul, executive director of the Rust Foundation, Rust being added to the kernel is an "enormous vote of confidence in the Rust programming language." She explained that in the past other languages have been planned to make it into the kernel and ended up not getting put in. "I think having someone with the kind of intellectual gravity of Linus Torvalds saying 'No, it's going in there,' that kind of says an awful lot about how reliable Rust already is and how much potential there is for the future as well," she said.
Rumbul believes that there will be an increased interest in the language, which is still relatively new (It first made its debut in 2010) compared to some of the other languages out there to choose from. "I suspect that because Rust is now in the kernel, and it's just being talked about much ... more widely, that it will seem like an attractive prospect to a lot of people that are looking to develop their skills and their knowledge," she said. Rumbul hopes people will also be inspired to participate in the language as contributors and maintainers, because those are some of the less popular roles within open source, but are extremely critical to the health of a language, she explained.
The Rust Foundation also launched a new security team in September to ensure best practices (including a dedicated security engineer). Their first initiative will be a security audit and threat modeling exercises. "We want to basically shore up," Rust operations director Marcey tells SD Times, "to ensure that Rust itself is actually as secure as we always say it is."
In this year's Stack Overflow Developer Survey, 86.73% of developers said they love Rust.
And there's still no actual Rust code in Linux: "You need to get all those things that can make sure that Rust can compile, and you can do the debugging and all these things," explained Joel Marcey, director of advocacy and operations for the Rust Foundation, "and make sure that the memory safety is there and all that sort of stuff. And that has to happen first before you can actually write any real code in Rust for the Linux kernel itself."
Marcey explained that Linux is going to be doing this inclusion very piecemeal, with lots of little integrations here and there over time so they can see how it is working. "I would imagine that over the next year, you're going to see more small incremental changes to the kernel with Rust, but as people are seeing that it's actually kind of working out, you'll be able to maybe, for example, write Linux drivers or whatever with Rust," said Marcey....
According to Bec Rumbul, executive director of the Rust Foundation, Rust being added to the kernel is an "enormous vote of confidence in the Rust programming language." She explained that in the past other languages have been planned to make it into the kernel and ended up not getting put in. "I think having someone with the kind of intellectual gravity of Linus Torvalds saying 'No, it's going in there,' that kind of says an awful lot about how reliable Rust already is and how much potential there is for the future as well," she said.
Rumbul believes that there will be an increased interest in the language, which is still relatively new (It first made its debut in 2010) compared to some of the other languages out there to choose from. "I suspect that because Rust is now in the kernel, and it's just being talked about much ... more widely, that it will seem like an attractive prospect to a lot of people that are looking to develop their skills and their knowledge," she said. Rumbul hopes people will also be inspired to participate in the language as contributors and maintainers, because those are some of the less popular roles within open source, but are extremely critical to the health of a language, she explained.
The Rust Foundation also launched a new security team in September to ensure best practices (including a dedicated security engineer). Their first initiative will be a security audit and threat modeling exercises. "We want to basically shore up," Rust operations director Marcey tells SD Times, "to ensure that Rust itself is actually as secure as we always say it is."
In this year's Stack Overflow Developer Survey, 86.73% of developers said they love Rust.
In other news (Score:2)
In this year's Stack Overflow Developer Survey, 86.73% of developers said they love Rust.
What's the point of including four significant digits when the majority of those have never tried Rust?
Re: (Score:2)
Time and again it transpires that nobody of consequence actually uses rust, so the "rust evangelisation strike force" tries to turn this state of affairs on its head by faking. "Oh, rust has support in the linux kernel, must be a good systems language then!" Call it their big lie [wikipedia.org].
No, it never was, and never will be, or even have a shot at being a decent "systems language" until it sheds LLVM and therefore C++ as a dependency. A first step to that might be rewriting LLVM in rust. But that's not going to happen, Just Too Much Work. For comparison: How's rewriting a browser in rust going so far? That's what mozilla invented rust for. So why would anyone put in the work of rewriting linux in rust? Not gonna happen either. Its presence will sure bog down linux development and foster all sorts of funky incompatabilities. But hey, at least it has the right critical consciousness!
Of course nobody uses rust. Why reinvent the wheel yet again for yet another language that will go the way of all those past "silver bullet" languages that were supposed to make our lives easier (their collective motto should be "make trivial things easy; make complicated things impossible.")
Had to delete Firefox because of the absurd start-up times on high-RAM devices. With 32 gig, it was slow, with 128 gig it basically sat there with a blank frame for almost a minute. The weird part was, after deleting
Re: (Score:2)
Yeah like we still use Basic because it just was there from the beginning and of course Python was a fad ... wait.
Languages that suck like Basic tend to get replaced over time while some have a niche like Python. Java found a niche too as the 1990s COBOL replacement for large serverish environments. C is terrible and what caused DOS/Windows to suck and even Unix to a lesser extend due to memory problems, buffer overflows, pointer management and other issues.
Fine with your kennel was only 10K in size
Re: (Score:2)
Fine with your kennel was only 10K in size in 1970s Unix and only ran on 3 types of devices
I suspect that 1970s Unix ran on more different types of devices than Linux can today simply because there was so little hardware standardisation then. Two or three major CPU manufacturers? Try eight.
Rust as a simple low level language with safe memory handling is a Godsend in the 21st century
There is nothing simple about Rust. It's a huge source tree with massive dependencies.
Re: (Score:2)
at being a decent "systems language" until it sheds LLVM and therefore C++ as a dependency.
gcc has incorporated C++ for over a decade.
Re:Propaganda (Score:4, Insightful)
LLVM is used in the compiler framework for rust but C++ is not really a dependency of Rust, just the compiler. Of course, no one is going to rewrite LLVM in Rust: I don't think anyone sees LLVMs choice of implementation language as a problem one way or another, nor is it the right way to remove LLVM as a compiler dependency. The right way is to either reimplement rustc without LLVM, to implement it as a GCC front-end, or using libgccjit. All of those are being done, all of the projects having slightly different aims.
Just like there was never any intention of rewriting Linux in Rust. The aim is to enable the use of Rust in the kernel not to replace C.
Re: (Score:2)
Re: (Score:2)
Lots of things. A greater range of targets mostly. That some of the Rustc infrastructure is implemented in C++ is not seen as a problem. Probably because it isn't.
Re: (Score:2)
Re: (Score:2)
In this year's Stack Overflow Developer Survey, 86.73% of developers said they love Rust.
What's the point of including four significant digits when the majority of those have never tried Rust?
Grab the interest of bean counters?
Can they eliminate supply chain attacks? (Score:5, Interesting)
The Rust Foundation also launched a new security team in September... "to ensure that Rust itself is actually as secure as we always say it is."
I'm nervous about the possibility of supply chain attacks in the ecosystem. Rust isn't like C++ where you can choose one or two well trusted large libraries and have most of the features you want. The Rust standard library is decent but not extensive. Something as simple as easy exception creation/handling needs a third party library. And the third party libraries use third party libraries. It would be all too possible for someone to become a contributor, then slip in some malicious code. I think this is Rust's biggest vulnerability, and I hope it's addressed in the next couple years.
Re: (Score:1)
Re: (Score:2)
It is vulnerable to this same class of attacks, yes. True also with python, javascript, java and so on.
It is less vulnerable to standard library attrition -- as we see with the URL pakages in python where everyone uses requests, for example.
Win some, lose some.
Re: (Score:3)
That was an explicit decision during Rust development. It means that they can give strong future proof guarantees for the standard library, without having to give the same guarantee for all of Rust. Opens them for supply chain attacks, yes, but then is protection against backward compatibility attacks which was, effectively, what caused log4j.
Looked at another way, the problem is not supply chain attacks, but having a good set of dependencies, supported similarly to the Rust language for all the "standard"
Re: (Score:2)
> the third party libraries use third party libraries.
https://xkcd.com/2347/ [xkcd.com]
Re:Can they eliminate supply chain attacks? (Score:5, Interesting)
m nervous about the possibility of supply chain attacks in the ecosystem. Rust isn't like C++ where you can choose one or two well trusted large libraries and have most of the features you want.
Yeah it's not at all like C++. For one, C++ got heavy lobbying to get included in the Linux kernel, and was denied. So don't treat it like C++. Having said that...
The Rust standard library is decent but not extensive.
That's a deliberate design choice. The Rust maintainers WANT a small standard library. By having a small standard library, you don't find yourself having to live with bad past design decisions anywhere near as often, which is a big problem that C++ has.
Something as simple as easy exception creation/handling needs a third party library.
Well I have to ask, why on earth do you need exceptions to begin with? In C++ they're heavily HEAVILY abused, and in general shouldn't even be used at all. An exception is supposed to be an exceptional event, so what do C++ programmers do...Oh the file wasn't found? Better throw a "file not found exception" and unwind the stack so that we can catch it somewhere else. Oh and here's a scenario where a function might have nothing to return, so let's return a null pointer, so the caller can try to dereference it only to throw a null pointer exception, so that we can then unwind the stack so that it can then be caught somewhere else, so that...
It's madness. Do yourself a favor, and don't do that bullshit. You shouldn't even be allowing exceptions to occur to begin with, it's just shitty design. For example, it's much better to check if a variable has a null pointer first, rather than simply surrounding the code with a try/catch and then blindly dereferencing it (Java programmers tend to be really bad at this.)
This is why Rust uses option and result enums, and has no exceptions at all. Under the hood, these are standard Rust enums, which in C parlance are tagged unions. A Rust function that can return something never returns nothing only so the caller can throw an exception and unwind the stack. Option and Result give the programmer no choice other than to check if something is wrong first and then choose how to handle it. No blind dereferencing allowed. Besides, if something has really gone horribly wrong, that is, a truly exceptional event like say your binary executed an invalid opcode, your program should probably stop entirely, not unwind the stack and then do some convoluted bullshit with it later, because at that point you're almost certainly in a bad state where you shouldn't be trusting anything to work correctly. In Rust, this is called a panic. You can write your own panic handler, but unless you've got some profoundly good reason to do so (i.e. you're writing software whose outcome means life vs death) then why? It's already incredibly easy to write code in Rust that is guaranteed to never panic so long as the underlying hardware is functioning correctly. THAT is what exceptions should be for, not handling null pointers or files not being found.
The only good reason to do anything with exceptions at all in Rust, that I can think of, that aren't life or death scenarios, is if your code is calling into some badly written C++ library. Then yeah, you'll want to use maybe the catch-unwind crate.
This is not at all to say that Rust is perfect. Rust has a few warts, and here's one of them:
https://github.com/rust-lang/r... [github.com]
What you're talking about here isn't. Those are features, not bugs.
Re: Can they eliminate supply chain attacks? (Score:4, Insightful)
I think the point might be that (1) rust rightly uses result type for errors, (2) result type for errors is insufferable boilerplate in rust without either 'anyhow' or 'thiserror' third party crates (depending on whether you're writing an application or a library)
Re: (Score:2)
Yes indeed, thank you. I wrote "exceptions" so my point would be clear to non-Rust programmers, but I didn't realize I was creating an ambiguity. (I've never had to deal with C/C++ exceptions from Rust code.)
After I posted, I checked and found something nice: 'anyhow' doesn't depend on any other crates. If only the same could be said of 'clap', 'regex', 'rand', etc. (I see a lot of these crates have minimal mandatory dependencies, and the current version of 'cargo add' tells me which features are enabled an
Re: (Score:2)
Oh and here's a scenario where a function might have nothing to return, so let's return a null pointer, so the caller can try to dereference it only to throw a null pointer exception
That doesn't work in C++, which has no null pointer exception. Dereferncing a null pointer is undefined behavior and typically results in a segfault-style crash, same as in C.
What you describe is common (and, I agree, bad) in Java.
Re: (Score:2)
Firefox increments its release number every 4 weeks, linux kernel every 4 years (e.g. from 5.0 to 5.19, which took 4 years, then 6.0).
Re: (Score:2)
Billions of computers run Java.
None of them do it well.
Wanted : Linux dude with 15 years Rust experience (Score:2)
Can't wait for them recruiters!
Re: (Score:2)
Can't wait for them recruiters!
Funny
Re: (Score:2)
Can't wait for them recruiters!
I have a team in Bangalore with 15 years of Rust experience
Re: (Score:2)
Better to start over with a Rust-only kernel (Score:1)
Never underestimate Gall’s Law which states that. "all complex systems that work evolved from simpler systems that worked. If you want to build a complex system that works, build a simpler system first, and then improve it over time" That is
Re: (Score:2)
Re: (Score:2)
All the insults we give towards Windows apply to Unix equally. The bad design is from C and it is madness in the 21st century to be dealing with memory management and keeping track of these these things in a non safe environment. Rust is a Godsend
Toy Language (Score:2)
Rust isn't self hosting. It's another toy language.