41–50 of 127 posts
Regretfully a major Rust for Linux maintainer just stepped down yesterday, saying he doesn't have the energy to keep dealing with the constant nontechnical nonsense: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...
Unless the Linux developer community at large requested Rust in the kernel, this is good news.
Earlier quoted context omitted.
A redditor pointed out [0] that this is exactly what they would do to sink Rust adoption. Even if you agree with the substance of the argument, the delivery is rude and unhelpful. I hope this resignation is a wake-up call, and much of the onus is on C devs to be more collaborative. 0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
Why do C devs even have to be 'collaborative' about Rust modules? The latter would typically ingest C APIs, most likely via bindgen, making C code the "source of truth" about what the API is - because Rust modules are self-contained and C is the only stable ABI that Rust supports. All the type-checking smarts that the video talks about are purely on the Rust side. If a new 'raw' low-level C API is needed to build bet…
Earlier quoted context omitted.
> It's caused a lot of trouble so far and for what? The "for what" seems pretty obvious, no? It's the same reason you would use Rust over C in any other project. Memory safety and more modern PL features.
In my opinion, in the case of the Linux kernel, Zig (once it reaches 1.0) would be a much better, more natural, and less painful choice than Rust.
Earlier quoted context omitted.
Unless the Linux developer community at large requested Rust in the kernel, this is good news.
Good news for whom? The mental safe space of old time kernel developers? Or good new for users who will continue to have to deal with kernel panics and other memory issues.
I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welcome addition but until such a time I prefer for the project to remain C-focused so as not to close out a large fraction of the potential developer base. If that means that some 'competing' kernel gets written in Rust and takes over from Linux that'd be fine by me as well, may the best [1] kernel win.
Earlier quoted context omitted.
> Well, maybe that's exactly what should happen. Maybe rust should have never been allowed in the kernel in the first place. Can you clarify these two sentences? You say there should be a memory-safe kernel, and then you say Rust should never have been allowed, which is the opposite.
What they're getting at is that it probably would have been better if the Rust people had started their own kernel project, cherry-picked the pieces of Linux they wanted, and then made their own new thing without three decades of obsolete Unix/Linux baggage. This would mean they could spend their time actually writing software and and less time trying to convince a bunch of C programmers that their time is at an end…
Window GDI regions, CoreWrite, Drivers SDK
Android
Copilot+ PC firmware
Earlier quoted context omitted.
> Well, maybe that's exactly what should happen. Maybe rust should have never been allowed in the kernel in the first place. Can you clarify these two sentences? You say there should be a memory-safe kernel, and then you say Rust should never have been allowed, which is the opposite.
Meaning: Maybe there should be a competitor to Linux written in Rust BTW: There are a few Rust OS kernels, but none of those have the popularity of Linux of course.
Earlier quoted context omitted.
In my opinion, in the case of the Linux kernel, Zig (once it reaches 1.0) would be a much better, more natural, and less painful choice than Rust.
Like stated, zig isn’t stable yet. And in general the kit isn’t on a good level yet to replace C in Linux. And, there’s still no good and fast allocator: https://github.com/ziglang/zig/issues/12484
Earlier quoted context omitted.
Good news for whom? The mental safe space of old time kernel developers? Or good new for users who will continue to have to deal with kernel panics and other memory issues.
> users who will continue to have to deal with kernel panics and other memory issues. I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welco…
Suggesting making a new kernel is just total FUD. This is a multi decade project. It's like saying to a person who want some legislation in their country to change "why not make your own country, may the best country win". It's just so far removed from reality I'm very surprised I have seen this argument more then once.
Earlier quoted context omitted.
Like stated, zig isn’t stable yet. And in general the kit isn’t on a good level yet to replace C in Linux. And, there’s still no good and fast allocator: https://github.com/ziglang/zig/issues/12484
Kernel code shouldn't need a 'good and fast' allocator though, since preferably it shouldn't heap-allocate in the first place, or at least not frequent enough that allocator performance matters.
Regretfully a major Rust for Linux maintainer just stepped down yesterday, saying he doesn't have the energy to keep dealing with the constant nontechnical nonsense: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...
Unless the Linux developer community at large requested Rust in the kernel, this is good news.