One Of The Rust Linux Kernel Maintainers Steps Down - Cites "Nontechnical Nonsense"

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.

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

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).

There is a fully Rust based Unix-like OS out there, it’s called Redox and it’s very cool

That's pretty well answered here: http://vger.kernel.org/lkml/#s15-3

Why not React?

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.

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

Agreed. 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.

Who is Ted Ts' in this context?

It’s Ted Ts’o, the maintainer of the ext4 filesystem amongst other things.

little shit

Though you’re still accurate despite his seniority.

Totally

Phoronix comments were always dumb, like, infuriating bad, I don't even read them anymore, the moderation on that site don't give a fuck about toxicity in there

Phoronix comments are a special place on the internet. Don't go there for a good discussion.

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.

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?

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.

They will write kernel in Ada

GNU isn't punchy though; as soon as any punchy word get's associated with them, people will use that word instead, and we'll just get GNU/Thermite or GNU/Abson or something.

Maybe a pipe dream, but I would love to see RedoxOS get some traction. A rust based microkernel is a promising concept.

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.

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 unsafe feature 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?

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.

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.

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.

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.

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.

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

Arch people tell you "I use arch BTW"

Rust people make PRs rewriting your code in rust.

Rust people are worse.

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 const everywhere).

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.

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.

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

Unix -> Linux -> Ferrix?

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?