One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"
One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"
Wedson Almeida Filho is a Microsoft engineer who has been prolific in his contributions to the Rust for the Linux kernel code over the past several years. Wedson has worked on many Rust Linux kernel features and even did a experimental EXT2 file-system driver port to Rust. But he's had enough and is now stepping away from the Rust for Linux efforts.
From Wedon's post on the kernel mailing list:
I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them.
...
I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.
Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."
Oof, that video... I don't have enough patience to put up with that sort of thing either. I wonder how plausible a complete Rust fork of the kernel would be.
It's always been this way. Except that it was kernel developers arguing with kernel developers over C code. Now it's relative newcomers arguing with kernel developers over Rust code that the kernel devs don't necessarily care about. Of course it's going to be a mess.
A fork is of course possible, but operating systems are huge and very complex, you really don't want to alienate these folks that have been doing exclusively this for 30 years. It would be hard to keep the OS commercially viable with a smaller group and having to do both the day to day maintenance, plus the rewrite. It's already difficult as it is currently.
Rust will be a huge success in time, long after the current names have lost their impetus. This is not a "grind for 4 years and it's done" project.
That person in the audience was really grinding my gears. Just let the folks you're talking to answer you; no need to keep going on your diatribe when it's based on a false assumption and waste the whole room's time.
let's not lose focus of what's important here, and that is a room full of people hearing my voice and paying attention to me for as long as I manage to hold it
I wonder how plausible a complete Rust fork of the kernel would be.
It sounds highly impractical, and it would probably introduce more issues than Rust solves, even if there were enough people with enough free time to do it. Any change must be evolutionary if it's going to be achievable.
NOT a fork of Linux, but Redox is aiming for a Unix-like OS based on Rust – but even with “source compatibility” with Linux/BSD and drivers being in userspace, my guess would be hardware drivers are still going to be a big speed bump
All you need nowadays for a decent Unix-like is compatibility with a handful of Linux softwares and a web browser. Hell, if you could get WINE working on your kernel you could maybe support as many Windows apps/games as Linux for free.
The big issue, as I see it, is performant drivers for a wide range of hardware. That doesn't come easy, but I wonder if that can be addressed in a way I'm too inexperienced to know.
But projects like Redox are a genuine threat to the hegemony of Linux - if memory safety isn't given the true recognition it deserves, projects like Redox serve to be the same disrupting force as Linux once was for UNIX.
Redox also takes some inspiration from Plan9 and https://doc.redox-os.org/book/ch05-00-schemes-resources.html is interesting. Also reading https://drewdevault.com/2022/11/12/In-praise-of-Plan-9.html made me a bit more interested in things trying to be more Plan9-like than Unix-like.
Just fork and port Ext4 to Rust and let the little shit sit in his leaking kiddy pool out back.
There's certainly a history of Unix and Unix-like forks; which is rather simple compared to the Linux distro forks (go right to the big pic).
You should do it. The Linux kernel is a C project. You can't change a 30-year project on a dime. Make your own project with Rust and hookers.
Why not React?
Ted Ts'o is a prick with a god complex. I understand his experience is hard to match, we all have something in our lives we're that good at, but that does not need to lead to acting like a fucking religious fanatic.
I understand his experience is hard to match, we all have something in our lives we're that good at
At some point, that mix of experience and ego becomes a significant liability. He's directly hurting the adoption of Rust in the kernel, while the C code he's responsible for is full of problems that would have been impossible if written in safe Rust.
CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereferenceAgreed. His experience might be useful if he were there to engage, but he’s clearly not. It seems like he just wanted to shout down the project and it seems like he was somewhat successful.
No intention of validating that behavior, it's uncalled for and childish, but I think there is another bit of "nontechnical nonsense" on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages...?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that's likely just as tiring as the defensive C people when you want to include Rust in the kernel.
People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.
That is the most sensible look into this so far.
Who is Ted Ts' in this context?
He's the guy you hear vexing rust in the video posted. While both languages have their pros and cons, he chooses to just blast this other guy by repeating the same crap over and over without letting him reply. Basically the kind of person with a "I win because I'm louder" demeanor.
Who the fuck is this little shit? Can't they even be a little considerate towards rust? Just because they have 15 years worth of inertia for C doesn't mean they can close their eyes and say "nope, I'm not interested". I do not see how the kernel can survive without making rust a first class citizen
It’s Ted Ts’o, the maintainer of the ext4 filesystem amongst other things.
little shit
Though you’re still accurate despite his seniority.
There's really only one valid response to Ted Ts'o:
If you think you can do better with C, prove it.
CVE-2024-42304 — crash from undocumented function parameter invariants
CVE-2024-40955 — out of bounds read
CVE-2024-0775 — use-after-free
CVE-2023-2513 — use-after-free
CVE-2023-1252 — use-after-free
CVE-2022-1184 — use-after-free
CVE-2020-14314 — out of bounds read
CVE-2019-19447 — use-after-free
CVE-2018-10879 — use-after-free
CVE-2018-10878 — out of bounds write
CVE-2018-10881 — out of bounds read
CVE-2015-8324 — null pointer dereference
CVE-2014-8086 — race condition
CVE-2011-2493 — call function pointer in uninitialized struct
CVE-2009-0748 — null pointer dereference
The comments from that article are some of the most vitriolic I've ever seen on a technical issue. Goes to prove the maintainer's point though.
Some are good for a laugh though, like assertions that Rust in the kernel is a Microsoft sabotage op or LLVM is for grifters and thieves.
This is a little off topic and admittedly an oversimplification, but people saying Rust's memory safety isn't a big deal remind me of people saying static typing isn't a big deal.
Totally
There's always going to be pushback on new ideas. He's basically asking people questions like "Hey how does your thing work? I want to write it in rust." and gets the answer "I'm not going to learn rust.".
I think rust is generally a good thing and with a good amount of tests to enforce behavior it's possible to a functionally equivalent copy of the current code with no memory issues in future maintenance of it. Rewriting things in rust will also force people to clarify the behavior and all possible theoretical paths a software can take.
I'm not gonna lie though, if I would have worked on software for 20 years and people would introduce component that's written in another language my first reaction would be "this feels like a bad idea and doesn't seem necessary".
I really hope that the kernel starts taking rust seriously, it's a great tool and I think it's way easier to write correct code in rust than C. C is simple but lacks the guardrails of modern languages which rust has.
The process of moving to rust is happening but it's going to take a really long time. It's a timescale current maintainers don't really need to worry about since they'll be retired anyway.
I apologize if this is more nontechnical nonsense as Im not a coder, but if the projects are open source, cant he just read and translate the code?
For the same reason spoken languages often have semantic structures that make a literal translation often cumbersome and incorrect, translating nontrivial code from one language into another without being a near expert in both langauges, as well as being an expert in the project in question, can lead to differences in behaviour varying from "it crashes and takes down the OS with it", to "it performs worse".
From a developer standpoint you're taking someone's baby, cloning it into a language they don't understand and deprecating the original. Worse, if you're not actually interested in taking over the project you've now made it abandonware because the original developer lost heart and the person looking for commit counts on GitHub has moved on.
Obviously these extremes don't always apply, but a lot of open source relies on people taking a personal interest. If you destroy that, you might just destroy the project.
The video attached is a perfect example of the kind of "I'm not prepared to learn anything new so everyone else is wrong" attitude that is eating away at Linux like a cancer.
If memory safety isn't adopted into the kernel, and C fanaticism discarded, Linux will face the same fate as the kernels it once replaced. Does the Linux foundation want to drag its heels and stuff millions into AI ventures whilst sysadmins quietly shift to new kernels that offer memory safety, or does it want to be part of that future?
If Linux gets rewritten in Rust it will be a new kernel, not Linux. You can make new kernels, even in Rust but they aren't Linux. You can advertise them at Linux conferences but you can't force every Linux dev to work on your new Rust kernel.
There is no "your" new rust kernel. There is a gigantic ship of Theseus that is the Linux kernel, and many parts of it are being rewritten, refactored, removed an added all the time by god knows how many different people. Some of those things will be done in rust.
Can we stop reacting to this the way conservatives react to gay people? Just let some rust exist. Nobody is forcing everyone to be gay, and nobody is forcing everybody to immediately abandon C and rewrite everything in rust.
Nobody is proposing rewriting the whole kernel in Rust.
Is a single line of code in the kernel completely unchanged since its birth?
Linux is whatever the Linux Mark Institute says it is.
the crew on the Ship of Theseus would like a word with you. Because if you strip out every subsystem and replace them with a different language, everyone would still call it Linux and it would still work as Linux.
Linux isn't "a bunch of C code" it's an API, an ABI, and a bunch of drivers bundled into a monorepo.
I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.
Maybe that's not a bad thing? If you ask me the GNU people are missing a trick. Perhaps if they rewrote Hurd in Rust they could finally shed that "/Linux".
They will write kernel in Ada
Maybe a pipe dream, but I would love to see RedoxOS get some traction. A rust based microkernel is a promising concept.
omfg, that guy in the video...
Video url:
At the cost of sounding naive and stupid, wouldn't it be possible to improve compilers to not spew out unsafe executables? Maybe as a compile time option so people have time to correct the source.
the semantics of C make that virtually impossible. the compiler would have to make some semantics of the language invalid, invalidating patterns that are more than likely highly utilized in existing code, thus we have Rust, which built its semantics around those safety concepts from the beginning. there’s just no way for the compiler to know the lifetime of some variables without some semantic indication
At the cost of sounding naive and stupid
It may be a naive question, but it's a very important naive question. Naive doesn't mean bad.
The answer is that that is not possible, because the compiler is supposed to translate the very specific language of C into mostly very specific machine instructions. The programmers who wrote the code, did so because they usually expect a very specific behavior. So, that would be broken.
But also, the "unsafety" is in the behavior of the system and built into the language and the compiler.
It's a bit of a flawed comparison, but you can't build a house on a foundation of wooden poles, because of the advantages that wood offers, and then complain that they are flammable. You can build it in steel, but you have to replace all of the poles. Just the poles on the left side won't do.
And you can't automatically detect the unsafe parts and just patch those either. If we could, we could just fix them directly or we could automatically transpile them. Darpa is trying that at the moment.
Thank you and all the others that took time to educate me on what is for me a "I know some of those words" subject
Meaning a (current) kernel is actually a C to machine code transpiler?
The problem is that C is a prehistoric language and don't have any of the complex types for example. So, in a modern language you create a String. That string will have a length, and some well defined properties (like encoding and such). With C you have a char * , which is just a pointer to the memory that contains bytes, and hopefully is null terminated. The null termination is defined, but not enforced. Any encoding is whatever the developer had in mind. So the compiler just don't have the information to make any decisions. In rust you know exactly how long something lives, if something try to use it after that, the compiler can tell you. With C, all lifetimes lives in the developers head, and the compiler have no way of knowing. So, all these typing and properties of modern languages, are basically the implementation of your suggestion.
Modern C compilers have a lot of features you can use to check for example for memory errors. Rusts borrow-checker is much stricter as it's designed to be part of the language, but for low-level code like the Linux kernel you'll end up having to use Rust's
unsafefeature on a lot of code to do things from talking to actual hardware to just implementing certain data structures and then Rust is about as good as C.Compilers follow specs and in some cases you can have undefined behavior. You can and should use compiler flags but should complement that with good programming practices (e.g. TDD) and other tools in your pipeline (such as valgrind).
If you write unsafe code then how should it compile?
I’d like to add that there’s a difference between unsafe and unspecified behavior. Sometimes I’d like the compiler to produce my unsafe code that has specified behavior. In this case, I want the compiler to produce exactly that unsafe behavior that was specified according to the language semantics.
Especially when developing a kernel or in an embedded system, an example would be code that references a pointer from a hardcoded constant address. Perhaps this code then performs pointer arithmetic to access other addresses. It’s clear what the code should literally do, but it’s quite an unsafe thing to do unless you as the developer have some special knowledge that you know the address is accessible and contains data that makes sense to be processed in such a manner. This can be the case when interacting directly with registers representing some physical device or peripheral, but of course, there’s nothing in the language that would suggest doing this is safe. It’s making dangerous assumptions that are not enforced as part of the program. Those assumptions are only true in the program is running on the hardware that makes this a valid thing to do, where that magical address and offsets to that address do represent something I can read in memory.
Of course, pointer arithmetic can be quite dangerous, but I think the point still stands that behavior can be specified and unsafe in a sense.
This has been done to a limited extent. Some compilers can check for common cases and you can enforce these warnings as errors. However, this is generally not possible as others have described because the language itself has behaviors that are not safe, and too much code relies on those properties that are fundamentally unsafe.
I admit I'm biased towards C-languages out of sheer personal preference and limited exposure to Rust but I am wondering, are there any major technical barriers to Rust replacing these languages in it's current form anymore?
I know there has been a lot of movement towards supporting Rust in the last 6 years since I've become aware of it, but I also get flashbacks from the the early 00's when I would hear about how Java was destined to replace C++, and the early 2010's when Python was destined to replace everything only to realize that the hype fundamentally misunderstood the use case limitations of the various languages.
Its mainly a matter of stabilizing existing features in the language - there are rust modules in the linux kernel as of 6.1 but they have to be compiled with the nightly compiler.
Rust is a very slow moving , get it right the first time esque, project. Important and relatively fundamental stuff is currently and has been useable and 99% unchanging for years but hasnt been included in the mainline compiler.
Also certain libraries would be fantastic to have integrated into the standard library, like tokio, anyhow, thiserror, crossbeam, rayon, and serde. If that ever happens though itll be in like a decade.
Oh and try blocks.
I see. Thanks for the explanation.
3min 30s, sample for context
If you keep watching for 10 minutes, it's an interesting discussion. Too bad they had to cut it short due to time.
Who was the guy that had a lot of pauses with mmmmmm when talking?
Count Hasimir Fenring
You can't teach old dogs new tricks.
You actually can. And it's not that hard. I had a 14 year old German shepherd mix, who learned several new tricks before her death. I taught a partially blind 79 year old to use a computer, general internet, and email, and was communicating with her [via email] for a number of years before she lost the rest of her vision.
Old dogs, as it were, absolutely can learn new tricks.
Sorry, I just don't like this idiom, because it puts people in a box in which they do not belong.
Many years ago at work, when PCs started to spread, I taught a 60 years old lady how to use one. She never saw a PC before yet she learned pretty well, and I saw much younger people not learning.
Being willing to learn doesn't depend on age, it's a mindset, either you have it or you don't, and if you do have it, it will last your entire life.
That's very wholesome to hear! :) Thank you for sharing. I'm glad it's not the case.
My grandpa taught himself to text when he was 89. He just wrote a translation table:
A = 2
B = 22
C = 222
D = 3
...You can, but you can't turn a 30 year project on a dime. They're understandably frustrated that newcomers keep coming and screaming RUST RUST RUST RUST RUST
yeah but this isn't newcomers making noise. This is seasoned devs making meaningful contributions, and getting reactionary responses
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").
Most reasonable people say c is good, rust is better
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
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.
at every chance they get, sell it as C is crap, this is better
For 'sendmail' values of $C, this resembles another argument. Also, of course for $C=sysvinit.
C is crap for anything where security matters. I'll happily take that debate with anyone who thinks differently.
No idea what you’re being downvoted. Just take a look at all the critical CVSS scored vulnerabilities in the Linux kernel over the past decade. They’re all overwhelmingly due to pitfalls of the C language - they’re rarely architectural issues but instead because some extra fluff wasn’t added to double check the size of an int or a struct etc resulting in memory corruption. Use after frees, out of bounds reads, etc.
These are pretty much wiped out entirely by Rust and caught at compile time (or at runtime with a panic).
The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.
You can write safe C, if you know what you’re doing (but as shown by the volume of vulns, even the world’s best C programmers still make slip ups).
Rust forces safe(r) code without any of the cognitive load of C and without having to go out of your way to learn it and religiously implement it.
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.
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.
Some next level deaf going on. That's not what was being discussed.
The defensiveness proves just how out of touch and unqualified to comment some people are.
What is so hard to understand, C Is a fucking security issues?
I feel like the time to hide information behind YouTube links is over. Feels like a link to a paywall article at this point.
RUST ppl feel like ARCH ppl. yes it might be better than some other setup yadda yadda, but they are so enervating.i'd rather switch back to windows11 than read another post/blog on how som crustians replaced this or that c library. just shut up already.
The sad thing is, there are other languages better at replacing C/C++ due to closer resemblance, except they're rarely used due to lack of trendy technology that is being hyped in Rust. D lost a lot of ground due to its maintainers didn't make it an "immutable by default" language at the time when functional programming paradigm was the next big thing in programming (which D can still do, as long as you're not too fussy about using
consteverywhere).It was never about replacing C with a new language for the sake of novelty, it was about solving the large majority of security vulnerabilities that are inherent in memory-unsafe languages.
If Rust were to implode tomorrow, some other memory-safe language would come along and become equally annoying to developers who think they're the first and only person to suggest just checking the code really hard for memory issues before merge.
Arch people tell you "I use arch BTW"
Rust people make PRs rewriting your code in rust.
Rust people are worse.
People are dumb as hell, it's fucking open source, go maintain the c fork, and let the those who want to improve the fucking shit cve producing codebase make a rust fork. And see which one people will use, and we all know that the rust fork will have wider adoption, it's a no brainer.
No one is forcing them to maintain the Linux kernel, no one is telling them to stop writing patches, they can't because you can download the code and work on it as you like.
It's people who know they will be irrelevant because they spent decades producing shit software, and they can't even be bothered to learn a new language to improve stability and security for the whole fucking userbase. Give me a break, what a bunch of whiners.
This is such a dumb take. For as much as I'd like to have a safer language in the kernel you need the current developers, the "big heads" at least because they have a lot of niche knowledge about their domains and how they implementation works (regardless of language) People shouldn't take shit like this from the ext4 developer, but it doesn't mean we should start vilifying all of them.
This guy's concerns are real and valid but were expressed with the maturity of a lunatic child, but they are not all like this.
If anything, the constant coddling of a few aging individuals within the kernel and the protection of their comforts is why Linux has been so slow to adopt technologies and paradigms that developers are begging for.
Linus complains of dev burnout starving the kernel of contributors, but the processes and technologies driving kernel development are antiquated, and the very suggestion of change is either discarded or makes you the target of a public shaming by Linus himself.
Yes and the big heads in this case don't want to share that knowledge, because why? Because they are treating the kernel like their pet project that they own and control, and they don't wanna lose that control, rather looking at the bigger picture.
It's kinda obvious that rust is the way forward as google has clearly shown, so why are they gatekeeping?
It's people who know they will be irrelevant because they spent decades producing shit software
So the Linux kernel is shit software now? Just because it's not written in the newest programming language? Kind of a hot take.
No because it is buggy and have a bunch of security flaws.
Nobody can maintan a fork of the linux kernel on their own or even with a team. It's a HUGE task.
There already is rust in part of the linux kernel. It's not a fork.
But I agree with your first statement, people are dumb as hell, me included lol
No shit
Unix -> Linux -> Ferrix?
old white man scared of losing their jobs or their commits going insigificant...who cares. Lets move on.
Lemmy comment not mentioning the race of someone challenge (IMPOSSIBLE)
the guy speaking off camera in the linked 3min 30s of the video is Ted Ts'o, according to this report about the session.
Losing their jobs? Uh what?
