That's actually the funniest damn thing I've read in a while. Totally unprofessional and inappropriate for the context, but hilarious.

Maybe he needs a creative writing hobby of some sort as an outlet to help keep such glorious color out of his professional emails. (I'm totally serious and would email him the suggestion if I didn't think it a waste of time because I don't know the man, he doesn't know me, yadda.)

It would be great in a satire or fifty shades of grey: programming edition spinoff

Honestly it's a well-crafted insult, I give him that

If this werea Shakespeare play, it would be.

But in real life, we have to worry about being honest. And it's honestly not true that anyone who reads a byte at a time is too dumb to operate a nipple. All it means is that whoever did it doesn't know much about syscalls.

It will be remembered as well as Shakespeare play.

> should be retroactively aborted

> well-crafted insult

This is unnecessary vitriol directed at the person themselves as opposed to their code. It achieves nothing. He could get the same message across with far less words if he stuck to outlining the problem as opposed to attacking the creator of the problem.

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.

While I think reading in data one byte at a time is a stupid, I wouldn’t quite say that what he said is what I was thinking.

No but you know what I mean. We’ve all been there, looking at some effedup code and cursing the goon who dared check it in. Usually just end up sighing and getting on with it.

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.

I am also a stupid programmer. However, the difference is that I try not to submit pull requests if I have no idea what I am doing. However, from what I am reading, these are not naive programmers who don't know what they're doing. From what I understand, most of the people that Linus rants about are employees of corporate sponsors of the Linux Foundation.

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.

From what I’ve read about some of these rants corporate sponsorship != competence and there’s one or two things in my recollection that were astoundingly stupid. Schoolboy errors, in code that’s supposed to run in kernel space. I get that he kind of feels that he shouldn’t be in a position of having to spoonfeed people.

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 ...

> We’ve all been there, looking at some effedup code and cursing the goon who dared check it in.

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.

I completely agree up to the point scour ”everybody on the same team”

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.

> Often he's saying what we're thinking

This line of thinking is a fantastic way to create a non-inclusive group.

So what? Isn’t that what kernel development is all about? The careful detailed stuff goes in kernel space so that if you want to make a mess of things in your application you can do so without bringing down the whole system. It’s not like that to hurt your feelings or make you feel “excluded”. It’s for the greater good.

> careful detailed stuff

> 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.

None of the techniques you’ve described is either proven or applicable to this domain. Being an asshole while unpleasant is not incompatible with “getting things done” as has been shown again and again and again.

I know a fellow who did that. He had never written a program before, read the manual, and wrote the code. He explained it in terms of the manual never said that system calls were slow.

This is somewhat ironic considering Linux is written in C, which is the most stubbornly "one thing at a time" language in widespread use today.

It's not ironic at all. C doesn't not do anything promoting a syscall per byte. Even if you think that's what you are doing, libc is probably buffering for you behind the scenes.

If you're using fopen(3) "stdio" (buffered I/O), then yeah, fread(3) and friends will buffer. But if you're using open(2) and read(2), libc's not going to buffer that.

For example?

- C-style strings are null-terminated, with no information about their length - no equivalent of "for item in items" or "map" because no native data type has any concept of its length - array-to-pointer decay

Modern assembly languages - for processors that have SIMD or AVX instructions - are more natively able to deal with several things at one time than C is.