Entertaining though in fairness. Often he’s saying what we’re thinking. That doesn’t make it right though and it’s ultimately self-defeating.
I suppose Linuses appeal in this regard is similar to Simon Cowell or Anne Robinson off the weakest link. Sometimes you just like to see stupid called out.
This is entirely my conjecture and I have no way of proving it but I suspect Linus taking a break is Intel flexing its muscles on the Linux Foundation.
Not condoning his rants, like I say it’s ultimately upon himself these reflect badly, and they probably do little to stem the flow of incompetence ...
Until you realize it was you who checked it in. If you write enough code, you will eventually not write the best code for some situation. It could be because you were tired or you simply didn't understand that part of the code well enough. Instead of attacking someone with insults, it's better to understand why the code got written and work to not have similar mistakes made in the future. Remember, everyone here is on the same team trying to make the best piece of software possible. Berating teammates (which is really what is happening here) does not make them better teammates or make the team as a whole better.
The most egregious errors made in my experience and often Linuses, are by people who don’t see themselves, or have no interest in being “part of the team”. Who dont abide by the code quality guidelines, who have been told time and again, or who are trying to make weasel changes to subvert the organisation of the code to their own ends.
Linuses way, however isn’t really the most productive approach, Aine these kinds of individuals don’t care anyway. It sounds as though this new “code of conduct” might be an attempt to move things forward.
This line of thinking is a fantastic way to create a non-inclusive group.
> if you want to make a mess of things in your application you can do so without bringing down the whole system
You don't need an exclusive community to make that work. We as an industry have tools: fuzzers, testing frameworks, better programming languages and type systems, and proof assistants, all of which will do a better, more consistent job of ensuring quality than project leads being assholes.