← Back to context

Comment by KennyBlanken

10 months ago

> Assuming everyone is acting in good faith

Why would we assume that Ted repeatedly using strawman fallacies, bleating appeals to emotion and acting like a victim...all the while shouting people down...evidence of "acting in good faith"?

When you shout over someone like that you're nothing but a bully.

> he fails to address the concern that a change they introduce would error downstream and someone else had to clean up afterwards.

Because that "concern" was a strawman. It demonstrated that Ted either did not understand what the presenters were asking for, or simply didn't like others asking him to do something, because he's very important and nobody tells him what to do.

As has been exhaustively explained by others in previous HN threads and elsewhere: the Rust developers were asking to be informed of changes so that Rust developers could update their code to accommodate the change.

Ted loses his shit and starts shouting nonsense about others forcing people to learn Rust, and so on.

> but most of all the moderator unable to prevent the situation from exploding

When someone is being abusive to others, the issue is never "the people on the receiving end are not handling it as best they can."

Further: did it occur to you that Ted's infamous short temper, and his "status" as a senior kernel developer, might be why the moderator was hesitating to respond?

Imagine how Ted would have reacted if he was told to speak respectfully, lower his voice, and stop talking over others. Imagine how the army of nerds who think Ted's behavior was acceptable or understandable.

I don't understand how abusive bullies like Ted are allowed the privilege of being a senior kernel developer. This feels, in the end, like the fault of Linus, for allowing abusive maintainers to maintain their grip.

  • Linus was the original abusive bully maintainer, that's how. He's improved his personal use of language, but the culture that he initiated continues unabated. Linux's existing success as a project is used as evidence that it doesn't need any changes to the kernel maintainers' culture.

  • Up until recently (assuming you believe he's genuinely reformed), Torvalds was also one of those abusive bullies, remember.

I'm not a rust or c developer.

> As has been exhaustively explained by others in previous HN threads and elsewhere: the Rust developers were asking to be informed of changes so that Rust developers could update their code to accommodate the change.

I don't understand why you don't see this as "a really big deal". The C developers make a breaking change. They fix all the C code, then they write an email to the Rust devs explaining the changes.

Then the process of making the change stops, and the C devs have to wait for a Rust dev to read the email, review the C changes, fix and test the resulting rust, and check in the update. (including any review process there is on the rust side.)

Is it hours, days, or weeks? Are there 2 people that know and can fix the code, or are there 100's. Do the C devs have visibility into the Rust org to know its being well run and risks are mitigated?

This is adding a hard dependency on a third party organization.

I would never dream of introducing this kind of dependency in my company or code.

  • This is kernel development we're talking about. It progresses carefully, not a the breakneck pace of a continuous integration SaaS platform that is single-minded about pushing features out as quickly as possible.

    A better analogy would be like an API inside of a monolithic app that has multiple consumers on different teams. One team consumes the API and wants to be notified of breaking changes. The other team says "Nah, too much work" and wants to be able to break the API without worrying about consequences.

    If having multiple consumers of an API or interface is a goal, you make communication a priority.

> Why would we assume that Ted […] acting in good faith?

Because he has done more for Linux than you ever will. Therefore, he gets all the benefit of the doubt, and you are assumed wrong