I think that will kill the kernel in the long run.

You can't rewrite a kernel driver in Rust that hasn't already been written in C. Rust troons can't write drivers and C boomers can't write Rust.

Enjoy long compile times and prefixing literally everything in the kernel with UNSAFE UNSAFE UNSAFE multiple times in each line of code because you need to do unsafe things in a fast kernel.

this rust in kernel shitstorm seems a much worse problem than anything rust was supposed to solve.

In other recent news, the Nouveau lead maintainer quit: https://lists.freedesktop.org/archives/nouveau/2025-February/046677.html He refers to Ts'o's "thin blue line" comment (at https://lore.kernel.org/lkml/[email protected]/) and some bullshit about inclusivity in his e-mail.

we should switch back to 2.6 kernel

Those 30 million lines of C code are going to turn into 100 million lines of Rust code that takes 2 days to compile

>>25491433 lol what a faggot zero fucks given, his drivers were dog shit anyway did he think this would cause an uproar or something?

Why change a system that is working for 25 years? Makes no sense to me.

waiting for the day its abandoned and removed like all other random shit added to the kernel

just feed the entire codebase to deepchink or some other llm and let it fix it/port it #YOLO

>>25491102 As soon as Torvalds retire, everything there will turn to shit

>>25495429 By now Kernel would already better of with someone else.

>>25495189 Rust tends to create briefer programs. They could well turn into 10 million lines of Rust. But organization breaks down at such a large scale and I don't know if they'd be able to take advantage of Rust's ability to express the same ideas more briefly. >>25495483 Would be fun to leave a Rust tranny in charge just to watch what happens. Linux is corporate, so nothing of value would be lost if it went wrong.

>>25495483 he keeps unstable bullshit out of it. if he is gone, it will turn into windows

>>25495535 >it will turn into windows Have you been living under a rock? Already happened.

Stability is achieved through time. If you rewrite something you gonna have a shit ton of bugs unless you have insanely good test automation.

>>25495429 For a while I was afraid that the technically weak and inoffensive Greg K-H would follow Linus, but he's about the same age and I gather from some of Linus's e-mails that he wouldn't turn over the project to that kind of person. Well, I wouldn't mind switching to Genode if they could import most of Linux's drivers.

>>25495559 The visual design of Windows 11 is fine. Looking similar to it is not a problem. Besides, you can argue about who copied whom. I don't say that Windows looks fine for reasons other than that it looks fine to me. I don't like Windows and I hated the look of Vista and Windows 7 with the fire of a thousands suns.

>>25491102 Rust for Linux has no future. Linus killed it with weak leadership, allowing Cniles to drive away Rust people. Cniles killed it by being Cniles. A clean cut is needed, Rust people will write their own OS sooner or later and replace Linux. It will happen quicker than people think since Linux has a lot of bloat that isn't required, a new OS can be a lot leaner. >>25491131 >I think that will kill the kernel in the long run. The failure to move to a better development process will, not the botched attempt at improving it. >>25491141 >You can't rewrite a kernel driver in Rust that hasn't already been written in C. Rust troons can't write drivers and C boomers can't write Rust. "Rust troons" are superior coders to your average Cnile. Ofc they write drivers from scratch. Just look at the GPU driver for arm macbooks. Rust filters people for intelligence since the language is very difficult to master. >>25491147 >Enjoy long compile times Dumb myth. Rust compile times improved due to multiple efforts in multiple areas. Compile times are still a bit longer than in most other languages, but that's entirely on purpose. The Rust compiler checks 9001 things for you, producing vastly higher quality code. My Rust project compiles under 1 second, since it's set up properly. Compile time is an absolute non-issue. >and prefixing literally everything in the kernel with UNSAFE You clearly do not understand the need for unsafe at all. You need unsafe rust in drivers specifically since the compiler cannot gurantee hardware behaviour. If your hardware directly copies shit into memory with DMA, guess what, has to be unsafe code. Using "unsafe" for this is rust's design working as intended: It gives you safety gurantees by default where possible. But for direct hardware access, this safety gurantee cannot be uphold technically. So Rust allows you to selectively drop it to write your driver without having to change the language. Unsafe code is a small portion of the driver usually, the majority can be safe code. The benefits over using C is still huge. >UNSAFE multiple times in each line of code because you need to do unsafe things in a fast kernel. Do you suffer from severe mental retardation? Rust offers zero-cost abstractions, unsafe in non-driver kernel code is not required whatsoever. You also don't have to spam unsafe, you wrap unsafe code in a block. >>25495372 >Why change a system that is working for 25 years? Makes no sense to me. C was designed on a PDP-11 with a few kb of memory. It was intended for simple, small programs you can keep entirely in your head. Writing millions of lines of code in it is retarded. You need higher level abstractions to not produce 9001 bugs and reason reasonably over your overall problem. But the solution is not to re-write linux. It will be a new OS from scratch in Rust.

Gnu/troonix

>>25491102 >https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/ What a monumental idiot. >needing to worrying about language issues, including an upstream language >community which refuses to make any kind of backwards compatibility guarantees Rust has editions, which solves backward compatibility issues. You simply specify which rust edition your code is written in, and the compiler will compile it. Yes, new editions might break compatibility. This is fine. You can choose to update your old code and re-write it to be compatible with a new edition, or keep it as old edition code. What the fuck is the problem? This is a non-issue Cniles turn into an issue in their mind because they cannot comprehend sane version control and high quality, well designed tooling that automatically solves problems for you. >and which is *actively* hostile to a second Rust compiler implementation The Rust compiler, like all Rust tooling, is the best in the industry by far. It is the gold standard against which other compilers need to be measured. It is, however, not yet even feature complete. It works, it compiles code, and it gives you the best error messages by far. Yet it should and could be better. Why THE FUCK would you waste your time writing a second compiler before you finish the first one? Fucking Cniles have 4 different compilers for their ancient toy language and they're all objectively hot garbage.

>>25496153 why are you getting excited for a compiler that is not even finished for this shit Rust language? it's currently slower than c and the compile time is longer, it's not a real competitor

how do you do fellow rustaceans

>>25496153 >Why THE FUCK would you waste your time writing a second compiler because the rust community is a hostspot of mental illness, and delusional people cannot be trusted with security; they will act maliciously even without outside incentives, simply to advance some cause imagined by their broken brains or to get back at perceived nemeses

>>25496153 I was somewhat with you but the editions part is beyond retarded, this would scale like aids in a project as big as the linux kernel with all its subsystems. you dont want to deal with different editions of a langauge that may or may not work with the other parts. finish the standard, keep it stable, finish the compiler, then people can consider using it for long term projects. I hope it goes the way of bcachefs and gets booted from the kernel due to sheer retardation in maintenance and instability.

>>25495531 >Rust tends to create briefer programs truly youve never coded in rust ever

>>25496121 >The benefits over using C is still huge Because it has better static code checkers? Why not just tack that unto C or C++?