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.
I don’t think the ends are those of the cia, and I didn’t say that the means were either, only that they were similar to those in a famous mid century guide for those trying to halt or hijack organizations.
I don’t think the rust devs are a cia opp, before you ask. I think some rust devs and even proponents of rust who only cheer from the sidelines are sometimes behaving in ways that raise red flags. I think it’s natural and laudable that the existing devs and maintainers are alarmed by that same behavior. It’s their job.
I also think Linus position on rust has been stretched to the point of breaking and I personally find it hard to take positions seriously that distill the complex process of integrating new languages into a very old very large codebase with many full time developers into “Linus said I could”.
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 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.
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.
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.
I don’t think the ends are those of the cia, and I didn’t say that the means were either, only that they were similar to those in a famous mid century guide for those trying to halt or hijack organizations.
I don’t think the rust devs are a cia opp, before you ask. I think some rust devs and even proponents of rust who only cheer from the sidelines are sometimes behaving in ways that raise red flags. I think it’s natural and laudable that the existing devs and maintainers are alarmed by that same behavior. It’s their job.
I also think Linus position on rust has been stretched to the point of breaking and I personally find it hard to take positions seriously that distill the complex process of integrating new languages into a very old very large codebase with many full time developers into “Linus said I could”.
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 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.
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.
“Follow rules to a letter” kind of sabotage manual.