Asahi Linux lead developer Hector Martin resigns from Linux kernel

Post by pverghese » Sat, Feb 08, 2025, 3:52 AM UTC

iknowstuff wrote: post #428

arp242 wrote: post #195

Earlier quoted context omitted.

> Arguably his reprimand of Martin is a clear signal that he will never show Rust any favor That doesn't really have anything to do with Rust; but with Hector's behaviour. Threatening a social media campaign to out people is completely toxic behaviour. This is a long-term contributor who is perhaps a bit abrasive, not Jimmy fucking Saville. Other than that, it's not a binary yes/no question; no one is really against…

> no one is really against some Rust in some parts of the kernel Dude, this was literally caused by a stubborn maintainer, Hellwig, saying he wants NO second language in the kernel at all, and his explicit vow to do anything he can to stop it.

Post by steveklabnik » Sat, Feb 08, 2025, 3:53 AM UTC

wahern wrote: post #496

roca wrote: post #444

Earlier quoted context omitted.

> Refactoring can be painful in Rust when it involves very low-level changes in semantics I don't know what this is about. In my experience, refactorings that change the semantics of APIs are much easier in Rust than in C. E.g., change assumptions about the lifetimes of pointers passed into APIs: the Rust compiler will tell you where you need to change anything; the C compiler will happily compile your code and you'l…

Right, and while sometimes a lot of code needs to change in Rust, it's often largely mechanical, at least in typical contexts (e.g. user land development). But Rust won't automatically detect changes in semantics that happen across FFI boundaries. And I didn't argue that refactoring is easier in C than Rust. For one thing, it's an inapt comparison in the context of a mixed C and Rust kernel codebase in which the vast…

Post by wahern » Sat, Feb 08, 2025, 3:57 AM UTC

steveklabnik wrote: post #503

wahern wrote: post #496

Earlier quoted context omitted.

Right, and while sometimes a lot of code needs to change in Rust, it's often largely mechanical, at least in typical contexts (e.g. user land development). But Rust won't automatically detect changes in semantics that happen across FFI boundaries. And I didn't argue that refactoring is easier in C than Rust. For one thing, it's an inapt comparison in the context of a mixed C and Rust kernel codebase in which the vast…

Just to be super clear about it, Rust does not do strict aliasing. That’s a totally different set of rules than Rust’s aliasing rules.

Post by Ar-Curunir » Sat, Feb 08, 2025, 3:59 AM UTC

dinkumthinkum wrote: post #434

AndyKelley wrote: post #422

I've been saying this for years now: the rust4linux folks are putting so much effort into trying to upstream their work, seems like they should instead put that effort into maintaining a fork. Arguably it would be less hours spent porting than arguing with humans. Certainly more pleasant! Then one of two things will happen: * Rust will prove its worth and their fork will be the better operating system. Distros will s…

[flagged]

Post by elcritch » Sat, Feb 08, 2025, 4:02 AM UTC

rednafi wrote: post #465

There will be a similar drama when Zig reaches 1.0. There will be a bunch of Ziggers trying to get it into the kernal. The Rust fad is already slowing down. Maybe it's a good idea to wait 10-15 years before trying to rewrite the universe in a "memory safe" language and pushing that upstream.