"I will do everything I can do to stop this", where "this" is a sub-project that has been explicitly approved by project leadership, is not an appropriate justification for blocking some minor patch whose only "fault" is that it contributes to the approved sub-project.
I'm afraid the full quote is too long to be a title for an HN article. I think my title accurately reflects the author's sentiment. The precise quote is:
> Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project:
Please also feel free to read the post, and the underlying LKML messages.
>On Wed, Jan 29, 2025 at 10:33:22PM +0100, Danilo Krummrich wrote:
> I accept that you don't want to be involved with Rust in the kernel, which is
> why we offered to maintain the Rust abstraction layer for the DMA coherent
> allocator as a separate component (which it would be anyways) ourselves.
>Which doesn't help me a bit. Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this. You might not like my answer, but I will do
everything I can do to stop this. This is NOT because I hate Rust.
While not my favourite language it's definitively one of the best new
ones and I encourage people to use it for new projects where it fits.
I do not want it anywhere near a huge C code base that I need to
maintain.
You have either pasted the wrong link, or are editorializing the title.
Absolutely. Linux is a unix-like kernel written in C.
This is what Linux is at a fundamental level, and is not going to change unless this is an effort the majority of Linux developers are willing to support.
Accommodating those trying to introduce a new language was never a good idea. They should have been told to go work on their own kernel.
This whole Rust in Kernel will not end well. We can spend all the time of the World bean counting half-percentages of who is more at fault but regardless of the Holy accounting this will not end well for Linux.
When being challenged for anything both sides tend to be despicable zealots, but given the 30+ years of C in Linux I tend to side to keep it that way, since the whole "everything is better and secure if done with Rust" is starting to become an annoying myth and the "aggressive victim" mentality a not so small part of the community has manifested throughout the most recent years does not bode well to the kernel of an OS that powers most of the World.
IMO its more like choosing a lesser known evil, because the new ones already demonstrated not being better.
PS: I also blame Linus for this. When you're the "Benevolent Dictator" having the foresight to avoid these brewing nasty civil wars is where you get the credits for all those accolades. He failed miserably.
> IMO its more like choosing a lesser known evil, because the new ones already demonstrated not being better.
First, I would disagree re: the 2nd part. Rust has obviously demonstrated itself, specifically in kernel space, but also almost everywhere else systems programming matters. I don't know what more it needs to do.
Second, why must we choose? I (and I think the R4L folks would agree) don't think it's necessary for us to choose between C and Rust, if you're simply writing drivers in Rust. The reason this seems like such a fit by Mr. Hellwig is that this is obviously premature. Why don't we see how it works first, before screaming about how it will never work.
> This whole Rust in Kernel will not end well.
Third, I think you may discount how important the Rust energy/mindshare is. If it's not Linux, it will be FreeBSD or some other kernel, and that will be where all the interesting kernel development will be happening in 10 years. FWIW, I'd much rather have arbitrary Linux binaries work on my Rust-y kernel 10 years from now, I'd much rather my cutting edge driver code works on a system we can use now, etc.
I hope this will usher in an era of less rudimentary kernel systems, because of how hard complex things in C are to get correct. For instance, OSS filesystem development has mostly stood still since ZFS. That is -- years later, bcachefs and btrfs are still chasing ZFS. Can you imagine a new filesystem, built for NVME and async IO, with ZFS feature parity, and additional wild features only available on enterprise storage (3D RAID anyone?, clustering, distributed filesystems...), which ships and becomes stable in years not decades?
Instead Linux users who prefer stability prefer to drive an antique, the equivalent of Porsche 356. Okay for its time, and for certain workloads fast, but only because it still lacks so much.
This is exactly why I blame Linus, this discussion (a civil one, hopefully ) but also nasty wars inside the kernel would not exist if he had the "straightforwardness" as he likes to use as an excuse for many of his sins, to say NO to this.
IMO your points are valid, but from a practical perspective they are out of place. Their place is not in the existing Linux kernel.
> Third, I think you may discount how important the Rust energy/mindshare is.
I'm very much aware of it and I'm also old enough to see how it plays out and how it ends.
That feverous energy would be much better applied in a fork. With all the problems of current old Linux, with all the advantages of Rust and energy/mindshare of the community, a fork is a no-brainer.
Think of all the energy not wasted in this civil war and all the not screaming happening while everyone is busy out-coding each other try to prove the other side wrong. Linux is not the Holy Sanctity, it will end when a new better thing appears. Do that thing.
Linus knows this and wanted to have the cake while eating it too. This is the result.
>This is exactly why I blame Linus, this discussion (a civil one, hopefully ) but also nasty wars inside the kernel would not exist if he had the "straightforwardness" as he likes to use as an excuse for many of his sins, to say NO to this.
You're making the pure assumption that he secretly wants to cancel the project but is afraid to, rather than that he (and Greg KH, and many other maintainers) actually wants the experiment to succeed for a variety of reasons. Which he is actually quite "straightforwards" about, if you look up his actual words on the matter.
I have a hard time believing that you wouldn't be annoyed if some almost completely unrelated maintainer hard NACKs your patch and every suggestion you offer just because they hold a grudge against the language you used.
reply