313
One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"
(www.phoronix.com)
this post was submitted on 29 Aug 2024
313 points (100.0% liked)
Linux
1259 readers
83 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
The kernel is mostly written in C, by C developers... understandably they're rather refactor C code to make it better instead of rewritting everything in the current fancy language that'll save the world this time (especially considering proponents of said language always, at every chance they get, sell it as C is crap, this is better).
Linux is over 30yo and keeps getting better and more stable, that's the power of open-source.
This sounds exactly like the type of nontechnical nonsense they're complaining about: attacking a strawman ("they're trying to prevent people from refactoring C code and making them rewrite everything in the current fancy language") even after explicitly calling out that that was not going to happen ("and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code").
They said it wasn't going to happen but their plan will result in it happening, how do you square that?
You tell me how it will result in it happening. Who even has the power to force people to learn Rust?
Linus and GKH, if they merge something that breaks every time C programmers change a kernel API
And where did you find that they will do that?
Most reasonable people say c is good, rust is better
C is crap for anything where security matters. I'll happily take that debate with anyone who thinks differently.
[This comment has been deleted by an automated system]
Agree. I'm an absolutely awesome software dev myself - and I know C by heart (being my favorite language after assembler). However, with age comes humility and the ability to recognize that I will write buggy code every now and then.
Better the language saves me when I can't, in security critical situations.
Even if you manage to keep all memory accesses in your memory, while writing the code, there's a good chance you'll forget something when reviewing another person's MR. That's probably the main problem creator.
Still, a language that you are familiar with, is better than a new language that you haven't finished reading the specifications of. And considering that adding new maintainers comes with a major effort of verifying trustworthiness, I get how it would be harder to switch.
such a weird dichotomy in Windows – secure kernel space and privacy-nightmare user space … “we’re the only ones allowed to steal your data”
I think most people would agree with you, but that isn't really the issue. Rather the question is where the threshold for rewriting in Rust vs maintaining in C lies. Rewriting in any language is costly and error-prone, so at what point do the benefits outweigh that cost and risk? For a legacy, battle-tested codebase (possibly one of the most widely tested codebases out there), the benefit is probably on the lower side.
Isn't that exactly the strawman the maintainer got tired of?
Hmm... I admit I didn't follow the video and who was speaking very well and didn't notice hostility that others seem to pick up on. I've worked with plenty of people who turn childish when a technical discussion doesn't go their way, and I've had the luxury of mostly ignoring them, I guess.
It sounded like he was asking for deeper specification than others were willing or able to provide. That's a constant stalemate in software development. He's right to push for better specs, but if there aren't any then they have to work with what they've got.
My first response here was responding to the direct comparison of languages, which is kind of apples and oranges in this context, and I guess the languages involved aren't even really the issue.
Seeing as how 40% of the security issues that have been found over the years wouldn't exist in a memory-safe language, I would say a re-write is extremely worth it.
What debate? You offered zero arguments and "C bad tho" isn't one.
Do you believe C isn't crap when it comes to security? Please explain why and I'll happily debate you.
/fw hacker, reverse engineer
That's not how it works. You said:
Argue for your point.
Figure 2: https://sci-hub.se/https://link.springer.com/article/10.1007/s11416-021-00379-x
Link dropping is also not arguing.
Citing scientific research is. Now, please post your gut feeling in response.
You continue to be antagonistic. I don't think I want to waste my time here.
Lots of categories which Rust doesn't prevent, and in the kernel you'll end up with a lot of
unsafeRust, so it can't guarantee memory-safety in all cases.The biggest items on the graph are all out of bounds accesses, use-after-free and overflows. It is undeniable that memory safe languages help reducing vulnerabilities, we know for decades that memory corruption vulnerabilities are both the most common and the most severe in programs written in memory-unsafe languages.
Unsafe rust is also not turning off every safety feature, and it's much better to have clear highlighted and isolated parts of code that are unsafe, which can be more easily reviewed and tested, compared to everything suffering from those problems.
I don't think there is debate here, rewriting is a huge effort, but the fact that using C is prone to memory corruption vulnerabilities and memory-safe languages are better from that regard is a fact.
Maybe when you build some little application or whatever. When building the most used kernel in the world, there are probably some considerations that very few people can even try to understand.
True for people misusing it. If you want to argue the ease of mis-use, it's a fun talk.
Better in what ways? Rust's strong points are not to just make a program more stable, but more secure from a memory standpoint and I don't think Linux keeps improving on that
For 'sendmail' values of $C, this resembles another argument. Also, of course for $C=sysvinit.
From other discussions I've seen, the guy stepping down was frustrated by having C code rejected that made lifetime guarantees more explicit. No rust involved. The patch was in service of rust bindings, but there was 0 rust code being reviewed by maintainers.