Michael

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.

laymen who are not involved in the process in any way (on either side) acting like armchair experts and passing harsh judgement.

It doesn’t matter what laymen say, so how can they be the problem?

This is why people like Martin feel justified going on social media to publicly complain, because they know they’ll get a bunch of yesmen with no credible arguments to mindlessly harrass the developers they disagree with.

Did Hector call people to action to harass the developers that “they disagree with”? Or did they try to promote awareness on the issue that is clearly causing them frustration? They certainly questioned whether or not there was another way besides shaming people on social media and it shows potential growth from my perspective.

If the project fails, it will be because of this behavior, not because of the “old guys” being stubborn.

Social media is another medium to express yourself and communicate ideas - it is neither good nor bad. If a project that is already developed pretty openly cannot address the criticism by social media/the public of their statements and behaviors, then perhaps they should privatize their communications. Or perhaps just address the criticisms in good faith and explain themselves in the spirit of open source.

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, I am aware of the manual. I was recently exposed to it, as well, so it’s very fresh in my mind. I understand why you mentioned it and understand what you are saying, but I disagree, I don’t see the parallels.

I think Linus just wants the drama to stop and the progress to flow, but I’ll let him speak for his emotions towards the R4L project and avoid speculating about him.

I’m just openly speculating that there are vulnerabilities in the C code, and that the R4L project will uncover those as a natural product of its evolution. I don’t think a CIA sabotage manual is apt to describe the R4L project, largely because I see it as progress. From my perspective, maintaining old C code is not something they are sabotaging.

As opposed to the R4L members, there are those who are openly admitting to sabotaging the progress of the R4L project. If you’ve seen the past public clashes between the R4L project and the Linux kernel community, you’d also be able to garner that from those interactions as well.

trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.

I am aware of the manual, but I fail to see how adding to a codebase is “sabotage” if it’s all generally seen as fine by the project lead - it’s far from a hostile takeover.

Would a CIA saboteur even want memory safety as a rule? Just speculating, but I’d say that’s unlikely.

Edit: I changed the order of the sentences, as it was not intentionally ordered, and slightly clarified my second thought.