It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.
Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.
The news coverage of kernel mailing list stuff is always so needlessly breathless.
From my understanding, it’s not Hellwig’s job to maintain the Rust side of the code. They can find multi-language codebases a pain all they want and throw a gigantic tantrum focused towards the R4L project - it doesn’t affect the code that they are responsible for. I don’t see why the whole R4L project couldn’t just be removed if R4L is not maintained by those who develop and support it.
but I will do everything I can do to stop this.
Is an open admission of Hellwig to sabotaging the R4L project.
Seeing the R4L folks as saboteurs or anything close is not in evidence. This isn’t the '90s, we have the means to be a lot more productive in regards to coding and managing codebases, and historical maintenance problems are irrelevant. If the R4L team is truly sabotaging the codebase by adding too much complexity or overhead, there are levers that can be pulled to change their direction without blindly rejecting or hindering their efforts.
Again, so much of the discussion around kernel mailing list exchanges excludes the context that what hellwig is talking about is not rust in the kernel at all or even r4l but a split code base.
I dealt with a c/c++ codebase once and it was beyond my meager abilities to handle both those ostensibly similar languages at the same time and I had people who were very knowledgeable in c involved with the project.
So when someone says “I think a split codebase is cancer to the Linux kernel” or “I will oppose this (split codebase) with all my energy” I’m like “yeah, that makes sense.”
I also need to clarify that I don’t think anyone is sabotaging anyone else and my intent in bringing up the simple field sabotage manual was to point out that the behaviors don’t necessarily indicate sabotage but fall into a broad category of behavior that isn’t gonna solve problems or get anywhere which is why it’s included in the manual.
I wasn’t aware it was circulating in social media recently and about fifteen years ago when I got exposed to it the main lessons to draw were not that people doing those things were active saboteurs but that those behaviors can lead to waste of energy and resources and they’re the first thing to avoid interacting with.
My exposure to and understanding of the manual was “here are some things to avoid in your own life” not “here’s how to throw a wrench into their plans!”
I don’t think the R4L project is for naught or is impeding progress. I see their good faith and their efforts. A split codebase can just be chopped off at the base and business can move on as usual at any point.
If Linux kernel maintainers are against potential improvements being found to the existing C code as a result of parallel development, then perhaps they should require the Rust developers to suggest what the added/changed code could look like in C (if possible) and their reasons for changing the implementation in Rust before they can push their implementation (forcing R4L to shoulder the brunt of the work) - or force R4L to stick to close-approximations and working within the existing system to properly change existing functionality through established processes.
I apologize that I misrepresented his arguments, I of course meant to say that his problem was a split codebase and I understood as much, I just misspoke. Other comments have enlightened me to better understand his arguments and concerns since I posted, as well.
You: […] have been generally trying to jam their code everywhere
I suppose your earlier statement was just stuck in my head, and I was wondering to what extent they have “infected” the codebase with Rust.
And I learned about the manual when a creator I was linked was talking about how there are parallels between the manual and the decline/failure of the U.S. education system, but I similarly disagreed with them that the issues of the U.S. education system are due to internal or external sabotage (through any methods described in the manual, whether intentional sabotage or not) or anything close to it. This was before Trump.
I don’t think that rust in the kernel is for naught or impeding progress. I think the patterns of expanding the scope of conversation to the absolutely philosophical level that some rust mailing list exchanges have done and kicking decisions up the chain or requesting a set of accommodations be made to the existing processes and methods fall broadly into the tactics outlined in the simple field sabotage manual.
I think it’s that behavior that isn’t going to get anywhere or solve problems.
I don’t think that the kernel codebase has been infected with rust. I think that especially after Linus said “sure, see what happens” to the suggestion of taking in rust work rust devs have been making tons of commits and sometimes it’s accepted, sometimes it’s rejected and often a border is created and there’s friction along it like this example.
It’s surprising to see that statement get brought up in the news considering it’s immediately followed by a parenthetical specifically enumerating a multi language code base as the subject not rust specifically.
Iirc it’s even preceded by something to the effect of “I like rust, it’s good and there’s nothing wrong with projects that use it”.
The news coverage of kernel mailing list stuff is always so needlessly breathless.
From my understanding, it’s not Hellwig’s job to maintain the Rust side of the code. They can find multi-language codebases a pain all they want and throw a gigantic tantrum focused towards the R4L project - it doesn’t affect the code that they are responsible for. I don’t see why the whole R4L project couldn’t just be removed if R4L is not maintained by those who develop and support it.
Is an open admission of Hellwig to sabotaging the R4L project.
Seeing the R4L folks as saboteurs or anything close is not in evidence. This isn’t the '90s, we have the means to be a lot more productive in regards to coding and managing codebases, and historical maintenance problems are irrelevant. If the R4L team is truly sabotaging the codebase by adding too much complexity or overhead, there are levers that can be pulled to change their direction without blindly rejecting or hindering their efforts.
Again, so much of the discussion around kernel mailing list exchanges excludes the context that what hellwig is talking about is not rust in the kernel at all or even r4l but a split code base.
I dealt with a c/c++ codebase once and it was beyond my meager abilities to handle both those ostensibly similar languages at the same time and I had people who were very knowledgeable in c involved with the project.
So when someone says “I think a split codebase is cancer to the Linux kernel” or “I will oppose this (split codebase) with all my energy” I’m like “yeah, that makes sense.”
I also need to clarify that I don’t think anyone is sabotaging anyone else and my intent in bringing up the simple field sabotage manual was to point out that the behaviors don’t necessarily indicate sabotage but fall into a broad category of behavior that isn’t gonna solve problems or get anywhere which is why it’s included in the manual.
I wasn’t aware it was circulating in social media recently and about fifteen years ago when I got exposed to it the main lessons to draw were not that people doing those things were active saboteurs but that those behaviors can lead to waste of energy and resources and they’re the first thing to avoid interacting with.
My exposure to and understanding of the manual was “here are some things to avoid in your own life” not “here’s how to throw a wrench into their plans!”
I don’t think the R4L project is for naught or is impeding progress. I see their good faith and their efforts. A split codebase can just be chopped off at the base and business can move on as usual at any point.
If Linux kernel maintainers are against potential improvements being found to the existing C code as a result of parallel development, then perhaps they should require the Rust developers to suggest what the added/changed code could look like in C (if possible) and their reasons for changing the implementation in Rust before they can push their implementation (forcing R4L to shoulder the brunt of the work) - or force R4L to stick to close-approximations and working within the existing system to properly change existing functionality through established processes.
I apologize that I misrepresented his arguments, I of course meant to say that his problem was a split codebase and I understood as much, I just misspoke. Other comments have enlightened me to better understand his arguments and concerns since I posted, as well.
I suppose your earlier statement was just stuck in my head, and I was wondering to what extent they have “infected” the codebase with Rust.
And I learned about the manual when a creator I was linked was talking about how there are parallels between the manual and the decline/failure of the U.S. education system, but I similarly disagreed with them that the issues of the U.S. education system are due to internal or external sabotage (through any methods described in the manual, whether intentional sabotage or not) or anything close to it. This was before Trump.
I don’t think that rust in the kernel is for naught or impeding progress. I think the patterns of expanding the scope of conversation to the absolutely philosophical level that some rust mailing list exchanges have done and kicking decisions up the chain or requesting a set of accommodations be made to the existing processes and methods fall broadly into the tactics outlined in the simple field sabotage manual.
I think it’s that behavior that isn’t going to get anywhere or solve problems.
I don’t think that the kernel codebase has been infected with rust. I think that especially after Linus said “sure, see what happens” to the suggestion of taking in rust work rust devs have been making tons of commits and sometimes it’s accepted, sometimes it’s rejected and often a border is created and there’s friction along it like this example.