Linus Rants About C Programming Semantics (iu.edu)
jones_supa writes: "Christ people. This is just sh*t," begins Linus Torvalds in his message on the Linux Kernel Mailing List. Torvalds is grumpy because some new code added to the IPv6 subsystem has created conflicts. "The conflict I get is due to stupid new gcc header file crap," he writes. "But what makes me upset is that the crap is for completely bogus reasons." The new improved code uses fancy stuff that wants magical built-in compiler support and has silly wrapper functions for when it doesn't exist. Linus provides an alternative that contains a single and understandable conditional, which looks cleaner and generates better code.
Film at eleven
SJW's don't eliminate discrimination. They just expropriate it for themselves.
.
Such code is the result of coders who rely on the compiler too much, and their brains too little.
.
"You and I learned C when it was programmers, not compilers, which had to be intelligent."
- - - Terry Lambert
It's literally just a few rants out of thousands of friendly messages per year - and Linus only rants if crappy code comes from someone who is trusted by Linus (such as the networking maintainer here) and who should really know better.
Linus Rants.
Pretending this is my office full of bitter coworkers..
Having read his rant (I know, I know) and agreeing with the points he is making, what struck me is that many programmers on the receiving side of that would have tried to imply that Linus isn't smart enough to understand their work of art.
Obviously, that doesn't work directed at Linus.
They tend to write unreadable code.
Linus is doing his job, making sure that the Linux kernel code continues to maintain quality and supportability. I read the thread, the code is shit, and Linus called it out. I don't care about his language or the tone of his message. He's right. Linus could stomp kittens flat and I wouldn't care, as long as that kitten-stomping was in the pursuit of making the Linux kernel better. Enough of this fake controversy about Linus and his communication style, already.
So he rants and raves and bitches and moans... It shows that he is passionate and serious about what he does.
Now, if only Bill Gates would learn to rant and rave passionately about the quality of his product - instead of counting his coins and pretending to be a philanthropist.
Political correctness is really just herd psychology pushed by insecure people who desperately seek social conformity.
... all the other people over there could use such a language, even for "legitimate" reasons, and get away with it.
You turn into Steve Jobs when you are hungry.
It's horrible, horrible code.
I'm not a C developer, but I know C and have been developing for 20+ years in various other C like languages. The thing Linus is ranting against is absolutely true. The first example is very clear what it does. Assign a variable. The second (new) code is fucked up, and completely unclear what's going on. Check some kind of boundary condition, then some weird shit going on that I don't understand?
The 3rd example is back to clarity. Check some boundary conditions, then assign the variable. I'd have never guessed the 2nd example does that without reading the 3rd.
I also happen to agree with Linus about not "toning it down". There's other ways to manage the kind of stupid bullshit that goes on in software development, but one effective way is going apeshit over shit like this. Linus's way isn't the ONLY way, but it does work. Developers tend to be filled with prima-donnas that think everything they produce is gods gift to coding. Sometimes the only way to get through is just yelling at the top of your lungs about shitty fucking code.
We live in an increasingly hyper-sensitive society where some people want to control speech in a fascist way. I'm so tired of all this bullshit about how it's "disrespectful to women", or other such crap. That seems to be the garbage dump reason for everything someone doesn't like that doesn't fit somewhere else. Just claim rascism, sexism, etc, even when it totally doesn't fit.
Oh, and please stop with the "The LEFT is trying to silence us.. blah blah blah" nonsense. This isn't "The Left" any more than the westboro babtist church are christians, or the nutjobs that open carry guns into Starbucks is "The Right". All of those are just radical elements of the political divide that have inserted themseves where they get the least criticism for their crazy ideas.
Not that this will surprise much of anyone, but the headline is wrong. Linus did not rant about C programming semantics. He ranted about a specific C function and the style used to perform a sanity check.
on the planet you have, criticize Linus can you.
"He took a duck in the face at 250 knots." -- William Gibson, Pattern Recognition
I have NO IDEA who this Linus guy is, but his microaggressive behavior will not be tolerated in the Open Source community. I doubt he was much of a contributor to Open Source, but we need to ban him as he is creating a toxic environment in my safe space. No big loss.
Seems that overflow_usub() will always be less readable than a condition then a subtraction. It's a pretty obscure function - searching for it reveals most of the discussion is about this specific patch. It will save an instruction or two with appropriate compilers, by using the JC instruction rather than a CMP/JZ and in really performance critical code this will matter, but most code benefits more from readability than that extra instruction.
apt-get moo /\---/\
(__)
(oo)
/------\/
/ | ||
*
~~ ~~
..."Have you mooed today?"...
Just curious what it looks like in context.
I love Jesus, except for his foreign policy.
I bet assembly gives you an aneurysm.
Oooh, good! That joke was getting old. Nice way to milk it.
There's nothing like $HOME
And next thing, someone who doesn't know about short circuit evaluation in C will swap the two conditionals.
It's not ugly if it's used in this context (usually involving breaking out of several levels of loops/conditionals, and/or go to one specific error handling code snippet from several points in the function).
This is someone you wouldn't want to work for.
Actually, I don't mind working with people who rant often, as long as they have good reason to do so.
In fact I'd rather work with people yelling at me about how shitty my code is and telling me why than a whole pasture of cows mooing about how good I am no matter what I do.
Two points:
a) I agree with him on the code, but I am not a competent coder myself.
b) I disagree with the form of communication and that is an area where I am competent.
As Linus expects others to write proper code, I expect people to conduct proper communication.
Same rules apply: If it does not improve the flow of information, it does not belong in the email. Some swearwords don't bring any points across that could not be covered by "professional english" subset ;-). I think "sh*t" and "crap" may be considered validly applied here. But beyond that, it generates an unnecessary conflict at rc7 time. ï
The new improved code uses fancy stuff that wants magical built-in compiler support
Imagine that. Someone thinking, "Ohhh, shiny! Let's try this because it's new and cool."
Instead of, "I need something to get the job done in the simplest fashion."
There's a reason analog light switches are still around. They just work. No bullshit about having to talk to a computer to decide what to do. Clean and simple. Just like code should be.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
Unlike you, Linus is not a drooling moron. He knows when goto is the best tool for the job. He doesn't have irrational fears like fucked-up retards such as yourself.
but yet he allowed the crap that is systemd in the house
Linus doesn't have control over places that systemd are 'in the house'. The biggest notable chunk that would be even remotely perceived as letting systemd into the kernel is kdbus, and that hasn't been merged. Even then, I have heard arguments that it isn't particularly systemd specific. Knowing about dbus, makes me shudder about the concept of kdbus, but folks assure me I don't understand kdbus, which I confess could be true.
Linus basically doesn't have much to say about systemd today, it's beyond the scope of his attention. He has mentioned he is at least not horribly opposed to it, but neither has he gave it a huge endorsement either. He has ranted about code that came to the kernel from at least one of systemd's notable contributors, but not about the concept/project as a whole.
But all that aside, no one should treat Linus' word as the one true word of the whole ecosystem. If he loves it, hates it, or does not care, either way the larger community has to decide.
XML is like violence. If it doesn't solve the problem, use more.
At least without context, the tone seems a bit severe for the rejection, and could bolster the case of those that argue that a violent shaming is a risk of submitting code, even if it would be your first 'mistake'.
I personally prefer this over some other projects that would merge functional, but ugly code for the sake of not scaring folks away from contributing and not having 'it doesn't work' argument to respond with, but there could be a happy medium.
XML is like violence. If it doesn't solve the problem, use more.
but geez he rants and rants.
This is someone you wouldn't want to work for.
Why? Because you're a delicate little flower with easily offended sensibilities?
I've worked for all types, and with all types. A little bit of "colorful" language doesn't bother me, and in many cases I'd prefer someone who can come to me and say "Hey, you fucked up, this is a pile of shit" than someone who smiles, gives me calm reassurances about my efforts, and then drives a knife into my back.
Yes, sometimes he goes a bit over the top. But in many cases, it's more a matter of the receiving party needing to grow a thicker skin.
Goto is a perfectly valid instruction providing you know when to use it. The typical use would be to jump into some teardown code at the bottom of a function or to escape out of some nested loop. Either way provdes more succinct and involves less code than the alternative. I assume every single kernel developer is capable of knowing when best to use it and they wouldn't have to worry about issues with c++ constructors either.
To each his own, but all in all I'd rather not work for a douchebag. Even if he's a really talented douchebag, he's still a douchebag. Real managers supervise without being an asshole.
Yes you do. He points out why it's crap and why it should happen. Considering this is kernel level stuff, you want that.
get by without public shaming rants
If you fuck up publicly, then the public criticism is appropriate and well deserved.
if your boss came in to the office and started ranting about a couple of admittedly bad lines in your code in front of everyone now and then, he would be fired pretty quickly
That's just flat out not true. I've worked for bosses who have done, and continue to do, far worse than anything I've seen Linus do. And guess what? They not only still have jobs, they get promoted.
Goto is good in this case since it avoids nasty 'if's in many places. You complain because you're a noob.
Then you haven't worked long.
"A shiny function that we have never ever needed anywhere else, and that is just compiler-masturbation."
GCC developers are some of the worst language lawyers you'll ever find. Code that used to work correctly will break (optimizations, yo) if they decide it's undefined or implementation defined behavior. Like overflow. They have to add those shitty builtin "safe" overflow math functions because MAX_INT + 1 is undefined. GCC will never generate code for an architecture where that is undefined, but when give the chance to "do the right thing" or "save a couple cycles and break code", GCC will fuck you over.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Yes, but where is the source code?
CLI paste? paste.pr0.tips!
Why? Because you're a delicate little flower with easily offended sensibilities?
I've worked for all types, and with all types. A little bit of "colorful" language doesn't bother me, and in many cases I'd prefer someone who can come to me and say "Hey, you fucked up, this is a pile of shit" than someone who smiles, gives me calm reassurances about my efforts, and then drives a knife into my back.
Yes, sometimes he goes a bit over the top. But in many cases, it's more a matter of the receiving party needing to grow a thicker skin.
A-fucking-men.
In my career, my skills in direct proportion to the speed at which I was criticized multiplied by directness and the skill of the other party.
As a lead, I really struggle with the special little snowflakes that need to be told how great of a job they're doing and how much they are appreciated and ... makes me want to vomit. I make sure that they either don't last long or learn to break their emotional attachment to "their" code.
Price, Quality, Time. Pick none. What, you thought you had a choice?
Knowing about dbus, makes me shudder about the concept of kdbus, but folks assure me I don't understand kdbus, which I confess could be true.
Interprocess communication has been an area of research for a long, long time. I don't understand why the kdbus people want to re-invent the wheel, instead of using a method that's been tried and tested.
"First they came for the slanderers and i said nothing."
Then you haven't worked long.
I never said I haven't worked for assholes. I said I'd rather not work for assholes, and I have left jobs for a lower paying one to get away from abusive assholes. Life's too short. And Linux coding is an unpaid job, is it not? Even less reason to put up with assholes.
This is someone you wouldn't want to work for.
Good boss: rants when he has a good point, is 100% correct, and you screwed up.
Bad boss: rants when he's wrong.
And yours to keep your mouth shut when you don't know what you're talking about?
mazevedo
he GP is right, if your boss came in to the office and started ranting about a couple of admittedly bad lines in your code in front of everyone now and then, he would be fired pretty quickly.
Why should our standards be what goes on in polite office culture? (This is a quite serious question). Cultures vary and change. In the 60s it was OK to be openly sexist and racist in offices. Your argument seems to be simply that we should look at Corporate America, and that should just be our standard with no further thought.
People say Linus needs to be like that when controlling a large open source project like the Linux kernel, but plenty of other large open source projects get by without public shaming rants. Major sub-systems in Linux, for example.
Yup, and there's nothing wrong with that. Why is it you feel the need to impose YOUR standards on the world? Nobody is saying everyone else should be pricks to control open source projects if what they're doing works.
Linus isn't rascist, sexist, or anything else that's personal. He is kind of a prick when it comes to shitty code, So what?
Hannes seems to have a valid point that boundary checking should be standardized in some way. Rasmus backs him up and mentions the result of the rant is they'll end up discarding his more comprehensive work on the issue: http://lkml.iu.edu/hypermail/l...
Linus seems to be saying all boundary checks should be ad-hoc because the new syntax is to hard to GET OFF OF HIS LAWN. Because it is dog poop.
open source world is getting overrun by high IQ morons, that put in bloat, hyped fads, and needless complexity. they indulge in mental masturbation rather than good design
This is someone you wouldn't want to work for.
Good boss: rants when he has a good point, is 100% correct, and you screwed up. Bad boss: rants when he's wrong.
Excellent boss treats you like an adult when he has a point, and communicates the problem clearly, and without resorting to childish abuse.
Nothing new, just walk on. He rants because that's his natural state. Can not wait for the fool to disappear.
Good boss: politely points out flaws in your code in public, and suggests improvements, or privately rants at you when you've really screwed up.
Bad boss: doesn't point out shortcomings, or rants in public about them.
Worse boss: needs to swear in order to get their point across.
We shouldn't be too afraid to hurt "delicate little flowers" and censor our language all the time, but such swearing is just as unprofessional as it is unnecessary.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Like Linus, I also write the simpler form of this kind of code when writing in C/C++.
Unlike Linus, I feel bad about it! My colleagues point out places where arithmetic overflows might lead to crashes. Honestly I find it really difficult to think through the overflow issues for *every single* plus, minus and multiply operator in my code. I think it's like cryptography in that sense -- most regular programmers, including good programmers, don't look at arithmetic operators from the perspective of attackers.
In this case, does Linus' code have the exact same behavior on all possible inputs including overflow-causing inputs? If not, which of the two behaviors is the desired one?
Are there places (maybe including this one) where the kernel code doesn't guard properly against arithmetic overflow? Will the newfound attention bring hackers scrutinizing it for overflow flaws?
I just get links about unclogging drains.
Have gnu, will travel.
Excellent boss...
Good luck finding one of those anywhere.
That's like asking for countries to have governments that are not corrupt at all, are run efficiently and effectively, and work for the good of all their citizens.
Sometimes you just have to take what you can get.
Both in the technical sense and in the human sense.
Technical: People at Linus' caliber understand exactly the rules for signed/unsigned integer promotion and where underflow is defined (as wrap) and where it's undefined[1]. Consequently he wrote perfectly-correct code for detecting the underflow and bailing out safely. Programmers at mere mortal levels of skill, however, routinely mess this up, often causing exploitable security bugs (believe me, I do code security audits as part of a real honest living). My advice for everyone (contra Linus!) is always always always use the compiler intrinsics for integer math. Feel free to decline this advice if you are a Linus level wizard (if you were, of course, you would already feel free to decline it) but if you have to wonder if you are, you probably aren't.
Linus seems to think that the kernel should only be written by folks that don't need that kind of help -- and for that I won't argue with him. It's his baby and he can chose whether to have a small number of über-developers or a larger number of mortals. Which goes straight to the second point:
Human: People at Linus' caliber thrive on negative feedback. At their level, positive feedback means nothing because there's nothing he can learn from someone praising his work. He wrote a kernel, he knows he's good. Meanwhile negative feedback is useful (unless trivially discountable): if the complaint is right, he'll correct something he was doing wrong; if the complaint is wrong, he'll be forced to think through why. In any event, he could never imagine why someone would sugar-coat their opinion on any matter.
So it seems like his mode of communication is meant to answer that question for the former: he wants people of his caliber that don't write ugly code using arithmetic crutches and don't care about strongly worded criticism. There's nothing invalid about that either -- maybe it's true that the best model is that Linuses work in the kernel and the rest of us go up into userland where we use crutches like memory protection and higher-level constructs :-)
[1] And when behavior is undefined, a smarter compiler can remove the code-path entirely -- the kernel itself was hit by such a bug where GCC legally removed a NULL check because the pointer was dereferenced before the check. See also this reference. Then there's the sad fact that people still argue against the clear language rules that say that assert( 100 + some_int > some_int ); can always be optimized away.
Not to mention that sizeof forces hlen+sizeof(struct frag_hdr) into size_t, which very probably is not unsigned int (it is not, on any of the systems I've owned for the last decade at least). Therefore overflow_usub is seriously bogus in and of itself.
"My opinions are my own, and I've got *lots* of them!"
Linux development is done on public mailing lists. Everyone knows this going in. If Linus rants about "your" code in public, he's sending a clear message.
He has passion. Snowflakes don't understand passion.
Price, Quality, Time. Pick none. What, you thought you had a choice?
To each his own, but all in all I'd rather not work for a douchebag. Even if he's a really talented douchebag, he's still a douchebag. Real managers supervise without being an asshole.
I don't mind working for a professional who holds to high standards and doesn't mind telling me when my code is crap, but I'm not going to work for a douchebag that reprimands me in front of everybody.
Professional and effective managers always reprimand in private, and praise in public. DON'T work for someone who doesn't follow that rule, life is too short.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
But does he have to be such a dick about it?
Apparently he does. I don't know why, but he does this from time to time, launching into some tirade laced with explicatives.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
In my career, my skills in direct proportion to the speed at which I was criticized multiplied by directness and the skill of the other party.
Your English in this sentence is unintelligible. You might want to work on it.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
the start of a thread IS the subject line.
No. The subject is a summary, or 'subject' if you will, of the post/email/missive.
That way, you can dismiss a thread based on it's subject, and not have to descend into a thread to see what it's actually about.
Get a clue before ranting, low-id.
Yes, but the question is whether this has been a pattern or a first offence. If this was the first time the person did something like this, it's arguably even worse. Usually if you are a maintainer in good standing, a single questionable design choice in a pull request wouldn't be met with that much vitriol. You have proven yourself to put out generally good work, but you mucked up once. A rejection with a counter-proposal saying 'this is not readable, I counter propose' would be enough to get the picture...
Knowing that no matter my reputation, I do one thing that Linus doesn't like and it could result in insta-rant I could see as discouraging for those used to more level headed discourse.
However, I restate that if I had to choose between passionate, rant-ready maintainer enforcing a consistent design versus all-welcoming maintainer that allows things to point of chaos, I'd pick the rants.
XML is like violence. If it doesn't solve the problem, use more.
No no. You have to do it like Linus to be effective. These gentle criticisms aren't going to cut it. Let me demonstrate
What the f$&@ is this sentence even supposed to mean? This is clearly written by a total idiot. What kind of total sh!&head would ever submit a sentence like this. Get your sh!& together and f$&@ing learn to write you worthless piece of crap.
See. That's the only way anyone learns
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Shame that the function used in the patch is NOT C, but instead a compiler-supplied and thus compiler-dependent feature that was put into the code in the kernel without any kind of fallback for those who don't have that compiler (e.g. an equivalent header that defines it if it's not already defined).
And Linus' equivalent alternative is valid C99 that works on all compilers, and does EXACTLY THE SAME while being slightly more readable.
Otherwise you might indeed have had a point to make.
Yep, you are right. I accidentally the word "grows".
I have a phantom word problem where, if I think the word in my head as I write, then as I read it back, the word "appears" there, even when it isn't.
But I'm not ashamed to admit I fucked it up :P
Price, Quality, Time. Pick none. What, you thought you had a choice?
If they used it like a headline, it would be fine. But they don't. They use it as the location for the beginning of their first sentence.
Subject: Anonymous Cowards don't know how to
Body: use the Internet.
Newspapers don't write their articles that way......they write them like this --
Subject: Anonymous Cowards don't know how to do this....
Body: Anonymous Cowards are apparently clueless Trolls because they don't know how to use the Internet. They think that Subjects are where you start the first sentence of your article and then you just continue the sentence in the body as if that is just an inconvenience to spewing their diatribe.
See.....a real Subject (akin to a headline) that conveys an idea of what the body will discuss but it's followed by a full concept that can also stand alone if the subject is hard to read (for instance on a site like Slashdot where it gets lost in the green bar).
The only way to change anything, Oh Jaded One, is to not put up with the assholes. Let those managers constantly have to replace their staff until only the truly desperate and un-hireable elsewhere will work for them. Or you can just kick the dog everyday when you get home - it's your choice.
Wish I had some mod points for you today.
Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
If I end up belittling a member of my team's efforts publicly, whether they deserve it or not, then I've failed as a supervisor. Unless you're working in a shark tank, that shit just drives down morale. Even *if* you're working in a shark tank, it's unnecessary.
If there is an issue that needs to be addressed publicly, you tell the team to not do that thing directly, but calmly. If they haven't been heeding your instructions purposely, or they are failing to measure up for some other reason, you pull them in and explain to them what is wrong and what needs to be done about it. If they continue to fail, you fire them after explaining that the team needs to work in a certain way.
Being professional doesn't mean being a pussy. It just means understanding the big picture. Drama doesn't help teams. If one person is causing it with their shitty code, then you spend the time with them to see what is happening. If they don't catch up, then perhaps they need to work somewhere else.
Honestly, Linus has blow ups because he *can*, not because it is good a idea. People will continue to contribute to Linux in spite of that, not because of that.
Even shit code like this only requires a private talking-to about it to the maintainer, and a public email about how it should be done. If the maintainer doesn't meet standards, he gets replaced. None of that requires a public fit.
I've only rarely had a boss who does have to rant. And most of those bosses who do rant were CEOs, and it really didn't help much even then.
I do know that bosses like that exist. I have had the good fortune of not having to work in a field where I have to tolerate that shit.
Mind you, I've been chewed out before, but it was always done privately and based directly on what it was perceived that I did wrong. I didn't always agree, but I never felt like I had a bad boss of the sort that would pull a Linus. If I had, I'd be looking for a new job.
I save it for voice comms.
Emails are polite, constructively worded and easily forwarded to very senior managers if escalation is needed.
Phone calls involving swear words as a follow-up usually avoid escalation being needed.
No - Linus doesn't say a *person* is an idiot, but that a person's *behavior* in a particular instance or their snippet of *code* is idiotic. There's a world of difference.
The language's inability to check for overflow is a problem. Putting that sort of obtuse and unreadable compiler-specific code everywhere you want to do arithmetic is a a cure worse than the disease.
"It's literally one punch in the balls out of thousands of friendly hand-shakes per year."
Yeah, I wouldn't submit patches to him either. The GP is right, if your boss came in to the office and started ranting about a couple of admittedly bad lines in your code in front of everyone now and then, he would be fired pretty quickly. People say Linus needs to be like that when controlling a large open source project like the Linux kernel, but plenty of other large open source projects get by without public shaming rants. Major sub-systems in Linux, for example.
So the complaint is that the kernel development does everything in the open, including airing dirty laundry, while other projects keep disagreements quiet behind the scenes (at least until something is forked). Personally, I don't like to be yelled at any more than the next person, but I would prefer open and transparent.
There's zero technical reason why an "undo" function can't be added to almost any software system
I can think of a couple. It's harder to remove elements from some kinds of full-text index, especially a probabilistic index, than it is to add them. And each comment would then need revision history so that moderators can tell to what text each comment was actually replying. Do we want individual revisions to be searchable?
I'm, not defending the code, but you're missing the point:
The compiler fallback had been added:
http://git.kernel.org/cgit/lin...
The problem was the inherent unreadability of the code. Using little known compiler-specific functions makes the code much harder to read.
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
I've debated programming language syntax many times, and have come to the following conclusions:
1. The C-style switch/break syntax is archaic and error prone, and should be replaced by a modern version based on sets rather than "break". We even devised a way to support both the old and new forms for backward compatibility. I'd roughly estimate less than 15% of the debaters agreed to keep (only) the existing style.
2. There's no free lunch. Syntax design creates trade-offs, and not all the trade-offs are immediately recognizable. All languages will probably have warts somewhere under certain conditions or usage patterns. If any language eventually gets it all right, it'll probably be a lucky accident, not pre-planning.
3. Personal preference varies widely. What bothers me may not bother others. Our brains each process syntax very differently. Consensuses are hard to reach.
Table-ized A.I.
Correction,
I should have said "language design", and not (just) "syntax". We generally considered semantics also. What we excluded was compiler design and machine efficiency, unless it became a clear bottleneck.
(A secondary debate then broke out on whether such "chip" bottlenecks are merely a reflection of current chip technology and whether a new language should cater to current chips or "do it right" and not focus on chips. The answer often depended on one's domain perspective, for those who work closer to the hardware, such as embedded, thought tailoring design around common or current chip architecture mattered more.)
Table-ized A.I.
Professional and effective managers always reprimand in private, and praise in public. DON'T work for someone who doesn't follow that rule, life is too short.
First of all, Linus does not do any hiring and does not pay anyone's salaries. So anyone is free to choose whether to work with him or not. Many top developers started to work with him because it's fun, and only later they were able to find a job related to the kernel development.
Second, I do not see anything wrong with public reprimand if the person is clearly wrong, because it is a matter of honesty and trust. This can be a problem only if the person cannot respond to the criticism, because he is afraid to lose his job or something like that. Clearly this is not the case with Linux development. I have never seen Linus harshly criticizing anyone who would be afraid to respond.
The only thing that I do not like is that he uses profanities a bit too much, but if it helps to keep crybabies away then it is not too high price to pay...
The goto is used correctly.
I've worked with people that argued very loudly about technical issues, and as long as they did it in a good-natured way with a smile on their face, it was kind of an enjoyable experience. As far as Linus's complaint, which is essentially "Why use an ultra-secret poorly supported subroutine call when using simple explicit logic is much more clear and readable", I consider that a valid complaint. Sucks to be the person whose code triggered this rant, but it needed to be said. Agreed, it is very easy to misinterpret email or text because the tone of the person "ranting" isn't apparent, but I see no way to personally broadcast this message to the entire developer community.
I've abandoned my search for truth; now I'm just looking for some useful delusions.
There is a difference between doing it in person and doing it as a faceless person on the Internet. Linus has pointed out in the past that if you nicely ask someone to not do something again, they completely ignore you. He solution is to make a BIG stink about it so you don't forget.
You wouldn't want to model everything as an object, nor incur the overhead of dynamic allocation in all cases. If your code involves doing ten things, each of which can fail, and all prior ones need to be undone at the end of it, does it really make sense to have that as 10 objects that each nest the succeeding? That would be all manner of memory grinding as each one is created too. It would also involve header file overhead in most cases, whereas the code with the goto is all in one place, smaller, faster, and more readable. A lot of hardware interface stuff ends up looking like this, and you would not want object oriented code for that.
A very intelligent dude... but at the same time is a pain in the ass son of a bitch
seems like you'd better try doing the first line your latest post again. :o) its catching
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
KICC = Keep it Complicated and Crappy
I recently ran into a similar example in Java, where Java 8 has introduce the class java.util.Optional. This is used by certain other Java 8 classes as a return type.
What does Optional do? It provides an object that contains an object. If that inner object is null, the method isPresent() returns fall. So now, instead of:
if (widget != null) { widget.doSomething()) ... }
You can write
if (optional.isPresent()) { widget = optional.get(); widget.doSomething()) ... }
Of course, if you don't quite trust the class giving you the Optional, you get to write
if (optional != null && optional.isPresent()) { widget = optional.get(); widget.doSomething()) ... }
This serves no useful purpose, except to make code more complex. Stupid, stupid, stupid...
The claim, of course, is that this marvelous class is designed to work with lambdas. The thing is, lambdas themselves are an idiocy in Java. Lambda expressions are inherent in purely functional languages, but they are semantically out of place in a declarative language.
Enjoy life! This is not a dress rehearsal.
Not using doublespeak doesn't mean you have to be an ass about it. You can be perfectly civil, and at the same time, blunt and honest.
Linus' rant is an emotional response. He's human, so he gets to have those happen, just like everyone else does. I'm less concerned about that than I am about the people who I see who seem to thinks that is how developers should operate in general.
Linus gets away with that because he's Linus. Anyone else who hasn't got his level of notoriety needs to think about it and then not do it. Consider the complaints about Linus to be a warning to those who think they get to act like the creator of the Linux kernel and justify it by thinking that they are "un-PC" and avoiding "doublespeak". Not even Linus is doing that, he's simply getting away with it because he can, just like every other celebrity or person with power.
Oh young one.. There is a basic level of human decency and professionalism which we all do well to maintain. Unfortunately this is a rare quality in many organizations these days.
I suspect that if your boss called your efforts crap in full ear shot of your peers, even if he was correct, you'd be a bit miffed at him/her for embarrassing you in public. It may change your behavior, but it also will change your attitude to them due to being rudely treated. Most folks have issues when they "loose face" in public and a wise professional manager avoids creating issues when possible. It only makes sense to go out of your way to avoid offending others, even in circumstances where you don't think you should have to bother. Wise people bend over backwards to avoid creating problems, trust me.
For instance, as a software developer in a large organization, I ALWAYS assume that any software problem I find, or get's reported to me is MY FAULT, even when it's not. I will either *fix* the problem, or if I cannot do that, I will enlist others to "help me" figure out how to fix it. I never say "See, it's your problem to fix." but keep showing them the evidence and asking them how I can fix it. When it is their problem, they will eventually realize this but because I've not been rubbing their nose in it I don't have to fix the relationship the next time something rolls around. The other option is to just shoot your coworkers full of holes, and the first time you are wrong about who's at fault it was, you are the hard nosed worker looking to get out of responsibly.
Do I have to do this? No, but it establishes you as the guy that knows your stuff, who is willing to work with others on stuff that's not his responsibility and exposes you to details from the larger picture. You are the nice hard worker that everybody trusts.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
Sure, if you step up to work on the Linux core, you know what you're in for. For me, it would be a reason not to. I have made myself a promise not to work for asshole bosses, and I'm keeping it. Wouldn't hire the guy either, for the same reason.
I understand passion. I also understand the difference between being passionate and being an abusive asshole. Being passionate doesn't mean losing your inhibitions and social skills. And that has nothing to do with being a snowflake either.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
The biggest problem I see is existence of crap like:
mtu -= hlen + sizeof(struct frag_hdr);
Where such code exists you can expect bugs to not be far behind.
What I especially dislike is Linus's proposal:
if (mtu
Hey lets just do the same exact operation twice... now that provides no opportunity for mistakes and BTW nice magic number.
I've learned the hard way over the years when you write a parser to build or consume packets under no circumstance should code to explicitly count bytes like this be allowed to exist. Write or reuse a higher level function to add or consume structures to centralize constraint checking. MUCH less opportunity to screw something up and less code/easier to read in the long run.
Error, no action moo
Perhaps apt-get install moo?
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
Do you often forget to put "then" in your if then loops?
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
I find it weird that Linus is so against the concept of idiot-proofing code, considering he is apparently surrounded by idiots. In C++ land we can use integer wrapper classes that provide checks against overflows in arithmetic operations. And the code just looks the same. For example:
SafeInt c = a + b;
It's a bit slower, so maybe it doesn't belong in some very nested loop structure. I understand Linus wants the code to be fast, but in places where you are doing that overflow check anyway, it seems like having a class or function do it for you rather than writing your own check is probably better from a consistency standpoint.
kernel development has a different set of values and priorities.
Professional and effective managers always reprimand in private, and praise in public. DON'T work for someone who doesn't follow that rule, life is too short.
A very apt summary of what is wrong with the world today and why mediocrity rules supreme.
He has mentioned he is at least not horribly opposed to it, but neither has he gave it a huge endorsement either.
Not horribly opposed to it and not giving it a huge endorsement is not correct. I'll quote and highlight relevant bits:
"Linus: You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.
I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.
Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.
Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys."
Yep, he's definitely NOT horribly opposed to it, and it sounds like quite an endorsement to me. Hell calling it a shiny turd would be an endorsement in the typical cesspool of hate that systemd gets.
I don't know who "Dave cutler" is, but MSWindows has an EULA that, as far as I am concerned, makes it unusable.
Currently I use Linux, and I've considered various BSDs. Actually, I still consider them every time there's a new update, but I require that I be able to use my current file system, ext4, with them, and so far that's been a deal breaker. If BSD had gotten to me first, I'd be requiring that Linux read the native BSD file system before I considered it. MSWindows got to me first, and I required that Linux have read/write access to the MSWindows file system. Fortunately it was VAT. NT would have taken a few more years...and the MSWind EULA became unusable with MSWindows2000.
I think we've pushed this "anyone can grow up to be president" thing too far.
Really, a goto? That's the best solution to this issue? I can actually read the crap code and while I don't particularly like it since it is assigning the values inside the if statement, that isn't the problem for me. It is the goto. I haven't used a goto in 35 years since I first discovered structured programming and I've been a C programmer for 25 years and while the statement exists in C there's just no need to use it (I never have), especially in this case. The fail_toobig should be a routine that is called rather than a label and there should be an if then else in there too. Linus' code is ugly too. Better than the first one, but still ugly.
"I have the attention span of a strobe lit goldfish, please get to the point quickly!"
It has been reported previously that Linux first asks politely and only if this is ignored does he ask impolitely. This has been said often enough, in enough contexts, that I believe it.
Also, we do not know what private communication has gone on. Why do you assume that he hasn't asked privately? But if there is no private communication, then what is the alternative to asking noisily and publicly?
Whatever, this is an approach that works. It's not the one that Guido uses for Python, but Guido's approach also works. It's not the one that Walter Bright uses for D, but that approach also works. You've got lots of choices for a project to work on, if that's your choice.
I think we've pushed this "anyone can grow up to be president" thing too far.
It's a style that I don't particularly like, but it works. It's one of several that work. If you decide to contribute to a project, pick one that's not only important to you, but whose management style you find acceptable. There are many to choose between. But check and be sure that not only do you like it, but that they style works.
If you're thinking about kernel development, follow the development list for awhile before committing yourself. (You'll probably find that it's a pretty reasonable style, even if it's occasionally newsworthy.)
I think we've pushed this "anyone can grow up to be president" thing too far.
So pick a different project to work on.
When something's not broken, don't try to fix it. You may not want to work there, but there are lots of projects with different management styles. Many of them work...and working is important.
I think we've pushed this "anyone can grow up to be president" thing too far.
If you do not know what usub is, is difficult to determine what is is doing. In that, Linus is right. But look inside the Parenthesis:
" (mtu, hlen + sizeof(struct frag_hdr), &mtu) || mtu = 7) "
Here is a very Clear OR. The guys are checking for the MTU Being to big OR too small...
Linus offers this code:
"if (mtu hlen + sizeof(struct frag_hdr) + 8)"
Which obfuscates the OR comparison...
And Both Call the label "fail_toobig" intead of a more readable "fail_MTU_outofbounds"
Or am I missing Something?
*** Suerte a todos y Feliz dia!
That's why I love programming and computers.. I can't fuck it up in grammar...
It works or it doesn't work... If it's elegant or not... that's where I hope to have criticism... even in basic grammar... you're making my point for me ;)
Price, Quality, Time. Pick none. What, you thought you had a choice?
You're right;
In private companies, Linus would come off as a total asshole...
In my comment, I tried to make a joke where I left off some grammar and... well... people did pounce...
It's the same thing in software... people will pounce...
I've always been scared, and I'm at a very senior level now, that if I didn't deliver then my boss would pounce...
And then I learned that my bosses have always been on my side... and that they *need* me to produce good shit... since that realization, I haven't been afraid, and I want n00bs to understand the same thing... if they need coddling, well... sorry, I've forgotten how to do that.
Price, Quality, Time. Pick none. What, you thought you had a choice?
I think my point is being made for me ;)
Price, Quality, Time. Pick none. What, you thought you had a choice?
That's a selection of quotes, however, and occasionally he's been quite a bit more negative.
Still, the ones I almost remember were about how unresponsive the systemd maintainers were when an error was reported rather than about the basic idea.
I think we've pushed this "anyone can grow up to be president" thing too far.
No - Linus doesn't say a *person* is an idiot, but that a person's *behavior* in a particular instance or their snippet of *code* is idiotic. There's a world of difference.
YES. THANK YOU.
Price, Quality, Time. Pick none. What, you thought you had a choice?
I've got a bit of a memory about the state of C++ when kernel development was started, and it wasn't good. Or standardized. And IIRC it depended upon cfront, when translated the C++ code into C.
Years later C++ code was considerably bulky after being compiled and linked, and not at all suitable for many of the uses of the kernel.
It's my understanding that currently C++ code can be equally good, and the source more compact...but I'm not really certain this is true, and in any case that's not enough to justify a conversion effort.
Yah, Linux was a noob when he started the project, and he started it in C because that was what he knew. But it happened to be the best available choice, and may still be the best choice.
You are, of course, correct about why Linux was successful. But you need to remember that BCD Unix was not the only Unix around, so it's not as if there weren't competitors. But they wanted to charge exorbitant prices, and weren't interested in the microcomputer market anyway. So the lawsuits weren't the only reason, greed played a major role.
I think we've pushed this "anyone can grow up to be president" thing too far.
And Linux coding is an unpaid job, is it not?
It is not! I mean, entry level, casual coder getting his feet week, the home tinkerer, etc. They don't get paid.
But these days there's a lot of corporate investment in Linux, and I think most of the code that does into the Linux kernel (including Linus's) comes from people who are paid for it.
http://systemexplorer.net/file...
I guess we should avoid your crap, it looks like it is marked as malware. Good luck getting that removed.
APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
When it is their problem, they will eventually realize this but because I've not been rubbing their nose in it I don't have to fix the relationship the next time something rolls around. The other option is to just shoot your coworkers full of holes, and the first time you are wrong about who's at fault it was, you are the hard nosed worker looking to get out of responsibly.
And the next time there's a problem:
Gentle approach: Your calls get returned, people don't avoid you, and they're not hostile to you when you approach them. They're willing to help you out when you actually get into a problem yourself.
Nasty approach: Pretty much the opposite of the above.
Everyone makes mistakes. EVERYONE. But when you make people really pay for them, they'll not want to work with you anymore. Maybe they don't cut you any slack. Maybe they just become unhelpful. Maybe they leave to find work in a different division. Maybe they badmouth bad (and you'd deserve it, but hey, if brutal honesty is the best policy, then truthful badmouthing should fit right into that philosophy).
Sometimes I wonder if this is just another "nerd/geek/etc not understanding the importance of social mannerisms, even among other nerds and geeks," or if there's something more complex going on.
Therefore if the subject is contained IN the subject line and spills over into the comment, it's still the subject.
Very true, if one is so incompetent at summarizing that it overflows.
However, the nominal subject of this thread is "When create the most used operating system," which in no way indicates the subject of the comment. It is an introductory clause, after which actual content will appear. "Subjects" of this form are just as useful as a salutation. If every thread is titled "Dear sir," "Hello," or "I was thinking," then there is fuck all reason to provide a subject.
"Subject" is not the first line of your comment.
three
comments
together.
"People at Linus' caliber understand exactly the rules for signed/unsigned integer promotion and where underflow is defined (as wrap) and where it's undefined[1]. "
Well, the specific behavior in this types of cases will/may depend on the hardware. Linux targets lots more systems than just x86-64. And in any case using a gnu version-specific intrinsic is probably not the best thing to do in general.
And what's with the magic number?
A his strong voice is one of the reasons Linux is so popular. I fear for the day a committee makes thedecisions
^ this.
Cheers, AC
no
I would still prefer "sizeof dest" (yes, without parens!) instead of "sizeof(dest's type)", if only because if the declaration of the destination was somehow changed to a different type, the code would be wrong. I prefer to keep as few separate copies as I can of such information, and let the compiler take it from the symbol table, sort of like the new C++ "auto foo = something".
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Yep, "People at Linus' caliber" also understand that gcc is not the only compiler in the world. gcc-centrism is the vaxocentrism of the 21st century.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Errrr... except that I now see that this is validating an IP header, so it's not really the same situation.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
I'm pretty sure that everyone involved in this mix-up is paid quite well. Gone are the days of the major contributers wiling away time in their basement, coding for love and living on Ramen. The good, spare time hackers, are now employed and making good salaries.
That said, I never was one for ranting. I get quiet and speak softly but I tend to enunciate carefully and metered. My kids have a saying about it. "When Daddy gets quiet, you've done something wrong."
"So long and thanks for all the fish."
Look, Torvalds does the final code merge and it's up to him to refuse the update if the developer isn't listening to his direction. He has absolute control over the code base and NOTHING gets in that HE doesn't approve and merge it. Torvalds doesn't need to resort to sending profanity laced E-mail to stop this, he can stop it other ways.
Torvalds doesn't need to be nice I suppose, but to me it smacks of lack of professionalism and perhaps a bit of narcissism when people do this kind of thing to others. But let's face it, it's easy to chew out somebody on the web you don't know, won't ever meet, and have no real relationship with. But IMHO it's a really small world and more than once I've seen where what goes around really does come around sometimes so this is one character trait of Torvalds I would strongly recommend nobody emulate.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
No, there is something going on...
Because this country largely lacked any real serious economic problems for a couple of generations, children have been raised more and more selfishly. It's more "I'm entitled!" than it used to be. We see this on Facebook, Twitter et all, where folks are posting "Look at Me!" and getting "liked" or "followed" by their friends. We have selfie sticks to take pictures of ourselves with our $800 phones and wine when the credit card gets maxed out and we cannot make the payments on our student loans. So this leads to "I don't care about YOU" and we forget the simple truths that made society safe at home as well as work. It's not being a nerd or geek, it's about not being raised to care about others.
The sad part though is we are loosing the skills that smooth out interpersonal relationships, that make cohesive teams and friendly work environments where people are motivated, fulfilled and efficient. Yea it takes effort, but I can assure you it is worth the price to think of others.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
If anything, he was too friendly. People submitting stuff like that should be banned from contributing until they have learned how to write readable code.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Sometimes it is the only sane way out. Even Djikstra did acknowledge that. His "goto considered harmful" was for when goto was used instead of the (newly available) tools of structured programming. It was not for cases where the goto is simpler and clearer. Also note that a "break" or "continue" is basically a disguised "goto".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Looking at some comments here and in similar stories, it seems there are quite a few people that would indeed try this.
Relevant quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan
That one is very, very true.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well, the specific behavior in this types of cases will/may depend on the hardware.
Which is exactly why you should use a compiler intrinsic since it's their job to keep track of machine details.
And in any case using a gnu version-specific intrinsic is probably not the best thing to do in general.
They didn't use the gnu intrinsic, they macro'd it out into to resolve to an intrinsic where available. That's the best way to do it until all compilers get their act together and provide some form of "perform arithmetic and tell me if it overflows".
This is the same way that all extensions are handled. Have AES_NI, you get some intrinsic, otherwise you go down a generic code path.
So people never report problems to you which are not really problems but they didn't take the time to learn how to use the software so they think it is a problem with the software?
Bingo Dictionary - Pragmatist, n. A myopic idealist.
It is a shame that I ran out of mod points yesterday. +1 Insightful.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
The significant difference is that Linus isn't a pointless jerk - he just reacts aggressively to stupidity or arrogance. But you won't find him parking his car on a disabled people's place, or cheating a co-worker/partner out of a fair share of profits.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
The level of rant is important too. It's better to hang out small issues to dry than to wait until you are flooded by them.
The rants are more for everyone else to realize what's bad practice than for the one that made the mistake.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Not to mention that it will also make everyone else also pay attention.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The worst assholes aren't the ranters, it's those that don't care about any quality at all and keep others in the dark for their own purpose.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
That was his respond to a direct question on systemd from the Ask Slashdot crowd. It was also a very recent quote (not selection of quotes), so I'm sticking with it.
Seriously, who cares?
If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
So people never report problems to you which are not really problems but they didn't take the time to learn how to use the software so they think it is a problem with the software?
Of course they do. If my coworker is unaware of how the software is supposed to work and shows up with a "problem" for me to solve, my approach is to enlist them to "help" me fix it. What happens though, is they learn how the software is supposed to work because they get some OJT from ME the author. I get a reputation for being helpful and the company is better off because they then know their jobs better. Plus, understanding the perspectives of the users is ALWAYS a good idea. It helps me build the product in ways they want it to work and makes any UI's I produce more intuitive and user friendly.
If I just told them to get lost and go learn their job, I'd get a reputation for being rude and unhelpful and neither of us would learn anything.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
At our work we have a rule of "don't use goto unless it is for a good reason" (e.g. breaking out of multiple nested loops). Although often times there are still more elegant ways of solving the problem than goto.
That is a good rule. While I agree that most of the time other things are better, sometimes they are not and then you should be allowed to use it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Ok, that is good. But doesn't it happen very frequently that his problem can indeed be solved only making it worse for others? Because others have a whole different way of using that part, reasons of which belong in history, which take hours to explain? And this particular problem finder's ability and willingness to learn about other people's use cases is low in the first place?
And one fake problem finder's opinion is frequently diametrically opposite to another's?
How much time per fake problem finder can you spend, and how many such people do you encounter?
Bingo Dictionary - Pragmatist, n. A myopic idealist.
I actually have an "out" with users in a case where they are insisting on some feature that we've already rejected. If after showing them how they can do their job, they insist it "should not be this way" I have them put in a bug report because "I cannot fix this right now and you have a work around". I just explain to them that the company policy is that if there is a way to work around the issue for the user, we take a bug report so we can schedule the work.
If their bug report doesn't make it past the review process or never gets high enough priority to be worked, so be it. Again, I'm as helpful as I can be, showed them how to do their jobs and by being friendly and helpful have not caused a problem.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
That makes sense, thanks.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
... or even worst: double speak (gniffle)
Personally, I'd love to work for somebody like Linus.
I'd much prefer working for somebody with a severe allergic reaction to stupid shit, even my own, who demands competence and isn't afraid to hurt somebody's feelings, even my own, if they do something completely boneheaded, than somebody who tolerates braindead behavior that yields sloppy results because they're trying to manage with kid gloves.
It may just be that I share some of those traits, and don't get bent out of shape if somebody rips me a new asshole publicly when I do something dumb... And it also may be that I've had far too many bosses that took the opposite approach and turned the entire organization into a barely functioning clusterf*ck because they didn't want to be a "bad guy".
In my experience, the "ideal medium" between the two extremes is so rare anymore as to be up there with winning a lottery or finding an honest politician who is also sane.
I accidentally the word "grows".
Ummmm....
You know, I don't care what folks think about me and I'm willing to accept that MY code is crap at times. I've been publicly reprimanded on a number of occasions by people I really respect, so I understand your position.
However, I've also observed that there is only so much I can do alone and the bulk of people I've worked with DO care about such nonsense. So where you and I might not care, we are in a distinct minority. Part of being effective as a manager is understanding how to best relate to the members of your team, so if you want to be good at this management job, you adjust YOUR behavior. You do this to assemble and keep the best people.
Please understand what I'm saying. If I'm having a problem relating to somebody, I seriously consider how I can change my behavior/approach and restore the relationship. This means I go out of my way to avoid offending others by what I say or do. I understand you cannot win them all, that there just are people who for what ever reason don't like me. I also realize that some may think that bending over backwards for others is not worth it or fair, but I realize that it is to my advantage to be as accommodating to other's faults as possible. I suggest you might consider doing that too.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
The subject of this post pretty much sums it up.
Apparently, you have never managed any software project for many years. Because if you did, you would realize that people are different, and some far more sensitive to criticism than others. Also a lot depends on the overall culture in your organization. So without any specific context, all those generalizations about what "a wise manager" is supposed to do is UTTER nonsense.
Now if we speak about the Linux kernel, the fact is the success of the Linux kernel is largely due to Linus ability to keep many talented people involved, and he works with same people for many years. So whatever words he chooses to express himself, it does not seem to affect his working relationship with those people. Also I do not remember that he has ever criticized newbies, who are still learning, or anyone like that. Practically, all his harsh words were directed at his lieutenants, who were entrusted to keep the source code to a certain standard, but failed to do so.
Finally, I will never trust you (or anyone else) just because you are willing to work on some stuff. I can trust you only if I know that you can deliver the result that meets certain requirements. I had a developer who tried to be nice and willing to work on almost anything, but his code was nearly always crappy, so giving him nearly any task (aside the most trivial stuff) was completely useless. So we had to part with him. So the question is not what you are willing to do, but what you can deliver in practical terms.