“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.”

Linux has no owner, really, aside from Linus. How can IBM wrangle a reversal in the sale of it back to Novell who has no more devs to maintain it - because they sold it - and they put it on the shelf for 20 years until it’s dead?

I don’t get how this is like how Unix was killed; at all.

I am sorry, but these rust evangelist’s are a bit ridiculous. Rust is I great language. But saying that the Linux kernal not having a future because not everyone will adapt a new programming language is stupid. Does he not realize he is putting alot more technical burden on the remaining maintainers that need to learn a completely different language because he decided the kernel suddenly neeeds rust, thanks I guess?

In a different article, he said he had issues with the ext4 maintainer who was acting high and mighty about C despite being responsible for a number of huge CVEs from code that he wrote.

That being said, I don’t really see the benefit of rewriting modules in Rust.

Technically, it’s still not a 1:1 replacement because Rust will many times not generate the exact same machine code as C, which does result in a small loss of speed (and in some small cases, vice versa).

It’s acceptable for anything new, but unless there’s a notoriously painful part of the kernel, there’s no pont in redoing existing parts and even core userspace binaries.

C quite literally makes you manipulate memory like a caveman holding a machine gun, but that’s important because it’s exactly what the machine is doing, which is required when you need to maximize efficiency. In Rust, you’d have to abstract some of that to the compiler to handle your logic which doesn’t match what a machine is doing. There is no such thing as “borrowing” and “ownership” in machine code.

From an outsiders perspective, a lot of the “politics” seemed to be that Rust devs would try to change behavior they saw as bugs and Linus would have to be like: “it doesn’t matter, we don’t break userspace functionality with changes we make to the kernel! [not a direct quote, but a paraphrase]”

Devs not wanting to learn Rust is something I’m not at all equipped to comment on since I don’t know C or Rust (some C++, python, Powershell and a few other scripting languages though) so I can’t say how difficult that transition would be, but at the very least it seems like they must not be convinced of its need.

Anyone with more knowledge able to chime in on if it seems this is a self induced problem on their end or genuinely something the other kernel devs are being difficult to work with?

ETA: My memory of this seems to be completely incorrect! Sorry for the misinformation!

I think there’s a problem with the ‘C only’ devs refusing to be accomodating to the Rust developers. Instead of being stubborn; why not provide them what is needed and help the Rust team learn how to maintain what is needed themselves?

None of the reasons I’ve seen mentioned are legitimate reasons for refusing to at least help them a few times, and helping them to learn how to do the onerous task themselves so they can keep it off the main plate for too long.

C devs do not need to learn Rust to provide critical information; they need only be present and cooperative with Rust devs to help them find, convert, and localize data structures for Rust use. They can stand to sit and pair code with their Rust Dev counterparts long enough to teach a Rust Dev counterpart how and what they need to look for in C code. It’s not that big of an ask, and it’s not something that really is a large ask. Provide the bindings for a short period of time, and work on training a team of Rust Devs to maintain the bindings.

That way both sides are stepping up to meet the others and the data isn’t being sat on by the C-only Devs.