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.
folks that have been doing this exclusively for 30 years
And yet the number of people I hear “just switch to Linux!” When the other person has been using Windows for 30 years blows my mind.
Inertia is a hell of a drug.
I wouldn’t tell a Windows developer with 30 years experience to just switch to developing for Linux.
Users are different. Most people who have used Windows for 30 years never touch anything outside of the desktop, taskbar and Explorer.
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.
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.
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).
There is a fully Rust based Unix-like OS out there, it’s called Redox and it’s very cool
It’s also a microkernel and intentional not POSIX compliant (but it’s close to compliant). I like the project, but it’s very experimental on purpose, so we should set our expectations accordingly. I’d love to see it become a success, but it may not be or it may only be successful in a smaller niche than the current Linux ecosystem.
That said, it seems very open to new contributors. I hope more people can help it along.
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 dereference
crash from undocumented function parameter invariants
My favourite, as that was the exact point the dev was making in his talk, that the stuff is badly documented and that the function signature would document it perfectly.
What kind of type signature would prove the first block of any directory in an ext4 filesystem image isn’t a hole?
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.
I imagine this mentality is frustrating because of how many times they have to explain that they weren’t forcing people to learn Rust and that the Rust bindings were second class citizens. They never said to rewrite the kernel in Rust.
That’s disengenuous though.
-
We’re not forcing you to learn rust. We’ll just place code in your security critical project in a language you don’t know.
-
Rust is a second class citizen, but we feel rust is the superior language and all code should eventually benefit from it’s memory safety.
-
We’re not suggesting that code needs to be rewritten in rust, but the Linux kernel development must internalise the need for memory safe languages.
No other language community does what the rust community does. Haskellers don’t go to the Emacs project and say “We’d like to write Emacs modules, but we think Haskell is a much nicer and safer functional language than Lisp, so how about we add the capability of using Haskell and Lisp?”. Pythonistas didn’t add Python support to Rails along side Ruby.
Rusties seem to want to convert everyone by Trojan horsing their way into communities. It’s extremely damaging, both to those communities and to rust itself.
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.
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.
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
You seem really invested in pointing out those shortcomings. I respect that.
How many vulnerabilities have the kernel Rust team introduced in the same time period on the same code?
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.
