Comment by rcxdude
10 months ago
Indeed, but where is the 'real' solution? If no-one higher up is going to step in and merge the patches despite the blocking maintainer, how is "the process" going to move R4L forward?
(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
They can merge regardless. The maintainer nacked something they don't even own, they were asked for a review as a courtesy as it wraps their subsystem.
That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
Sometimes there's no win-win-win solution.
I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
> "I think people who write C should stop unless it's to fix security bugs and should do something else"
That's pretty harsh. C has provided so much value to the world and security isn't the most important thing in the world - functionality is. Not saying security isn't important overall though.
And also, imagine another Rust competitor comes up in 5 years called "Moose" and M4L comes up, competing with R4L?
Of course, internal combustion engine motorcycles too, but I hate the aggressively noisy noxious little shits whizzing around my code, I mean, me. :)
... but I'm aware that it's simply not realistic. These are raw thoughts not "working policy" . My problem is that old software is just barely functional (huurah, we achieved the barely standing equivalency from civil engineering) and we are not spending enough resources on that, nor on security.
And probably my Linux honeymoon period ended after ~10-20 years of work (and/or personal) use, and I feel every point of Marcan's letter, even though I never did kernel development, only the usual troubleshooting and trying to figure out which bug/patch/feature has what status.
But, of course, as long as this blessed circus continues to deliver every ~3 months a new version with this velocity it'll keep going. And Linus is right, if we don't like it maybe (:p) it's on us to accept that. And also maybe Drew's humble suggestion will be the prescient one.
https://lore.kernel.org/rust-for-linux/208e1fc3-cfc3-4a26-98...
https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...
If Moose is better I expect people to fairly consider it, and when the consensus forms that yes it's at least as good as C then I want the C people to realize their own responsibility in maintaining critical infrastructure, and I want them to at least have a plan on how to improve, because even in civil engineering the baseline for "barely" has increased a lot over the past decades. (And of course in many cases arguably society has overshoot that, for example with the 2-stairs requirements and so on, where these concerns drastically disincentivize evolution of population centers and transportation networks.)
2 replies →