921–930 of 1001 posts
Earlier quoted context omitted.
The difference is between posting "ugh, having a hard time with someone on a project, they're blocking this merge and I don't think it's for a good reason" and literally starting your post with "Behold," linking directly to a mailing list post, and misrepresenting the other person's objections as "sabotage."
I mean when what you're frustrated about is a leader actively sabotaging what you're working on...
Earlier quoted context omitted.
Developer A wants to make a change. Developer B rejects it. Developer A makes a big fuss about it on social media. The creator of the project steps in and chastises Developer A for his behavior. And as additional context, developer A has a history of causing drama on social media. So much that he even has his own page on KiwiFarms.
Incredibly biased summary there
Earlier quoted context omitted.
I mean when what you're frustrated about is a leader actively sabotaging what you're working on...
Go on?
Earlier quoted context omitted.
The short of his rant is that he wants a "Code Of Standards for maintainers" in addition to a CoC, in order to witch hunt people he feels "gets in the way." Yikes, this is EXACTLY what Linus was talking about except an order of magnitude worse!
No. He just wants people to have some decency and standards in communication and not arbitrarily decide that their little kingdom can never be touched.
Earlier quoted context omitted.
People should read it: "... I come at this from the perspective of having worked on Linux since around December of 1991. I first met you and Tove in 1995 at the Free Software Conference at MIT that Stallman sponsored. ... Probably the last technical contribution of my career is leading an initiative to provide the Linux community a generic security modeling architecture. Not to supplant or replace anything currently…
A maintiner's perpsecitive on the above: https://lore.kernel.org/rust-for-linux/20250208204416.GL1130...
Earlier quoted context omitted.
Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems. That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.
> That one bug happened one time does not mean that the promise is broken. It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had th…
Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?
Earlier quoted context omitted.
[flagged]
The dirty laundry of the entire kernel community not immediately knuckling under and implementing a rather long list of technical changes in the preferred way of one specific individual? That's an unreasonable take. It would be disastrous for all of us if the project ever went that way, considering the importance of Linux today. It's not like I disagree with some of the points that Marcan raised, but others have equa…
It was a move of frustration due to having exhausted all other avenues. It wasn't his first action.
Earlier quoted context omitted.
I also agree that Linux should close the door to Rust as a matter of principle, as it has done to any other language other than C. I don't believe in a mixed language kernel, it is just nonsense, specially with such a different language such as Rust which is closer to C++ in philosophy.
I love Linux and have no preference to either C or Rust, but locking Linux in to a programming language that was designed in the relatively early stages of computing will lead to Linux dying in the long term. There will be fewer and fewer new C programmers with people instead taking up newer systems programming languages like Rust or Zig.
Earlier quoted context omitted.
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…
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.
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?
Earlier quoted context omitted.
Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.
Is it impossible to just delete the rust parts and go back to pure C? That ship could come back to port anytime.