this post was submitted on 13 Feb 2025
333 points (97.7% liked)
Linux
50408 readers
888 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If we are going to be honest, let’s not be misleading.
Nobody is looking to replace C in the kernel just to switch out the language. This is not a “rewrite it in Rust” initiative.
What the R4L folks want is to be able to write “new” code in Rust and for that code to call into the C parts of the kernel in an idiomatic way (idiomatic for Rust). So they need to create Rust interfaces (which they, the R4L side, are doing). This whole controversy is over such an example.
At this point, we are talking about platform specific drivers.
Now, new kernel code is written all the time. Sometimes newer designs replace older code that did something similar. So yes, in the future, that new code may be written in Rust and replace older code that was written in C. This will be a better design replacing an inferior one, not a language rewrite for its own sake.
Core kernel code is not getting written in Rust for a while though I do not think. For one thing, Rust does not have broad enough architecture support (platforms). Perhaps if a Rust compiler as part of GCC reaches maturity, we could start to see Rust in the core.
That is not what is being talked about right now though. So, it is not a reasonable objection to current activity.
If R4L authors want to use Rust so badly, then still:
Maintain your own tree! Let's see how simple and clean these interfaces are over the longer haul.
They will get mainlined if they are technically superior.
It was merged into mainline, in 6.1, over a year ago.
https://docs.kernel.org/rust/index.html
Then this isn't being blocked?
I don't know if the code marcan was talking about is still going to be merged. It wasn't actually being blocked, but that doesn't mean it was approved either.
So, not blocked, merged in, already maintaining a tree, just one maintainer isn't sold yet on the implementation.
Im just not seeing a problem then? Aside from the person experiencing burnout, which I get. But burnout may not indicate a cultural problem, either. Especially if the person is coming off of a rough year, personally.
I doubt you care but others may want to know that you just hit the nail on the head. Just not the way you think.
All the Rust folks want is for “technically superior” solutions to be accepted on their merits. The exact problem is that some influential Linux folks have decided that “technically superior” is not the benchmark.
Take the exact case that has led to the current debate. The maintainer said explicitly that he will NEVER accept Rust. It was NOT a technical argument. It was a purely political one.
In the Ted Tso debacle. a high profile Rust contributor quite Linux with the explicit explanation that the best technical solutions were being rejected and that the C folks were only interested in political arguments instead of technical ones.
If it was true that “technically superior” solutions were being accepted, the R4L team would be busy building those instead of arguing.