Torvalds: Standards need to be questioned(lkml.org)
lkml.org
Torvalds: Standards need to be questioned
https://lkml.org/lkml/2018/6/5/769
182 comments
What makes you think Linus would be more effective if he used a different tone? That seems like a tough argument to win given how tremendously effective he is. It doesn't seem like an exaggeration to me to say that Linux is the most successful opensource project of all time and among the best managed of all time in terms of the number of use cases it's managed to address over time and the number of people who have contributed. Not, I will grant, in terms of number of people whose feelings have been hurt. But I fail to see the evidence that Linux would actually be better off if Linus behaved differently. If we had good Linus and bad Linus we could A/B test, but sadly, we don't. We just have the one Linus, and he's been more effective than anyone in opensource over the last 20+ years. So it seems a lot more likely to me that his behavior is part of that effectiveness, not in opposition to it.
You have it reversed. The only thing that makes his behaviour slightly bearable to others is his effectiveness. Otherwise the community would've dumped him right away. Not like there's any reason not to, except for his technical knowledge.
This is kind-of a survivorship bias example.
This is kind-of a survivorship bias example.
Cripes. He's not the first opinionated, yet strangely effective Engineer the world has ever seen and will not be the last either.
I personally happen to like his approach in general but as I'm sure you are aware: "You can please some of the people most of the time and most of the people some of the time but this aphorism sounds a bit tired these days"
I personally happen to like his approach in general but as I'm sure you are aware: "You can please some of the people most of the time and most of the people some of the time but this aphorism sounds a bit tired these days"
I don't really think this is about pleasing people or not. More about self respect. I for one would have to be way too drunk to pun on a shitshow like this in public, also when there's no apparent reason.
But well that problem belongs to those who work with him, so I don't care. All I wanted to say is that because he gets away with it, it does not mean that us the halflings will too, so that's not a good advice to somebody thinking of participating in the general open source sphere.
But well that problem belongs to those who work with him, so I don't care. All I wanted to say is that because he gets away with it, it does not mean that us the halflings will too, so that's not a good advice to somebody thinking of participating in the general open source sphere.
Dunno, whenever I dig into one of the "shitshows" I find I mostly agree with it. I'd say a decent fraction of the ones that make hacker news are some form of "Don't break userspace". He obviously feels it's quite important, and there's been several cases of failed perception (like the gnome folks breaking userspace "like linux does").
Sometimes it's worth being a bit over the top so that the entire community you are working with gets the message loud and clear. Seems like other communities (like bsd, gnome, debian, etc), often have extensive documentation, policies, and best practices... which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
I suspect a big part of why user space is broken so rarely in Linux is exactly because Linus has made such a big deal about it in the past.
Sometimes it's worth being a bit over the top so that the entire community you are working with gets the message loud and clear. Seems like other communities (like bsd, gnome, debian, etc), often have extensive documentation, policies, and best practices... which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
I suspect a big part of why user space is broken so rarely in Linux is exactly because Linus has made such a big deal about it in the past.
I was referring to the delivery more than the content. Frankly I don't know much about his side of computing, so I cannot agree or disagree anyways. My message in this thread is to the random guy getting into FOSS: don't make an annoying freaky nerd out of yourself becaue one particular annoying freaky nerd has been very successful. That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
> That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
I do not know him personally, but people who do know him comment that he is a nice, considerate, thoughtful person.
Linus has actually chimed into this metadiscussion in the past, basically saying something along the lines of "the audience is too big and too varied to be subtle. If I am not very explicit, someone will misunderstand this, usually as an invitation to keep wasting my time" (IIRC) -- which, having managed much much smaller projects, I tend to agree with and can only imagine how much more true this is an the Linux Kernel scale.
The Finns I know are all very direct "straight shooters" - I guess that's part of it.
> That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
From three decades in the industry, I would say it's likely contributing to his success (though, it is independent of the cause/origin of his success, which is being smart, diligent, persistent and lucky). The ability to cut down and through bullshit is IMO fundamental, and it seems impossible to do without occasionally being rude.
I do not know him personally, but people who do know him comment that he is a nice, considerate, thoughtful person.
Linus has actually chimed into this metadiscussion in the past, basically saying something along the lines of "the audience is too big and too varied to be subtle. If I am not very explicit, someone will misunderstand this, usually as an invitation to keep wasting my time" (IIRC) -- which, having managed much much smaller projects, I tend to agree with and can only imagine how much more true this is an the Linux Kernel scale.
The Finns I know are all very direct "straight shooters" - I guess that's part of it.
> That he is so is not necessarily the cause of his success, and might even be invisibly detrimental to it.
From three decades in the industry, I would say it's likely contributing to his success (though, it is independent of the cause/origin of his success, which is being smart, diligent, persistent and lucky). The ability to cut down and through bullshit is IMO fundamental, and it seems impossible to do without occasionally being rude.
You can still be direct without having to act out or treat people like they're idiots.
It is not impossible to narrow down the complaints without being rude. Most people do that just fine, with way larger projects than his kernel.
His behaviour is just unnecessary and distracting. It's almost as if he does it for publicity or shock value. Maybe that contributes to his success, but it shouldn't.
I find it weird that people try to defend him rather than acknowledge it is just one of his character flaws. People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
It is not impossible to narrow down the complaints without being rude. Most people do that just fine, with way larger projects than his kernel.
His behaviour is just unnecessary and distracting. It's almost as if he does it for publicity or shock value. Maybe that contributes to his success, but it shouldn't.
I find it weird that people try to defend him rather than acknowledge it is just one of his character flaws. People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
> Most people do that just fine, with way larger projects than his kernel.
What are your examples? Please qualify project size by number of contributors and their organizational and cultural diversity.
According to [0], in 2015-2016 there were over 5,000 contributors sending patches, representing over 500 organizations (and likely, something like 50 countries/cultures/languages). Linus, through the LKML, corresponds with many of them, and has a small number of deputies. He is not paying any of these contributors, so he can't actually fire them, unlike e.g. Zuck, Jobs or Gates which, according to rumour, are/were all much less polite than Linus to their subordinates.
> It's almost as if he does it for publicity or shock value
He most definitely does, and uses it effectively. When he does, he mostly attacks ideas, not people. I've been following the LKML very intermittently, but my impression is that he is mostly kind and thoughtful in his answers while being direct. Those times that get to HN/Slashdot/Reddit/common-knowledge are few and far between, and mostly the 3rd or so response to the same thing (though, it has happened before on a "first offence").
> People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
No one said he was perfect. Some of us believe that it is effective; call it "necesary evil", but it's one of the very few management tools that he has - basically, refusing a merge, and voicing an opinion.
I eagerly await your examples, as my experience is that people with much more management tools at their disposal are not better in this respect than Linus. Especially those examples (of "most people") that coordinate submission from 5,000 people mostly interacting directly with them.
[0] https://www.linuxfoundation.org/blog/the-top-10-developers-a...
What are your examples? Please qualify project size by number of contributors and their organizational and cultural diversity.
According to [0], in 2015-2016 there were over 5,000 contributors sending patches, representing over 500 organizations (and likely, something like 50 countries/cultures/languages). Linus, through the LKML, corresponds with many of them, and has a small number of deputies. He is not paying any of these contributors, so he can't actually fire them, unlike e.g. Zuck, Jobs or Gates which, according to rumour, are/were all much less polite than Linus to their subordinates.
> It's almost as if he does it for publicity or shock value
He most definitely does, and uses it effectively. When he does, he mostly attacks ideas, not people. I've been following the LKML very intermittently, but my impression is that he is mostly kind and thoughtful in his answers while being direct. Those times that get to HN/Slashdot/Reddit/common-knowledge are few and far between, and mostly the 3rd or so response to the same thing (though, it has happened before on a "first offence").
> People aren't perfect, and neither is he. Doesn't take from his achievements but acting like he's in the right to behave this way is just enabling him. If people want to emulate him, they should look at the good and leave the asshole behaviour behind.
No one said he was perfect. Some of us believe that it is effective; call it "necesary evil", but it's one of the very few management tools that he has - basically, refusing a merge, and voicing an opinion.
I eagerly await your examples, as my experience is that people with much more management tools at their disposal are not better in this respect than Linus. Especially those examples (of "most people") that coordinate submission from 5,000 people mostly interacting directly with them.
[0] https://www.linuxfoundation.org/blog/the-top-10-developers-a...
Well, look up what companies like IBM, Google, Amazon, etc. are doing with thousands of workers and all the organizational and cultural diversity you want.
I don't get what is "necessary" with his insults. Would delivering the message calmly not be understood?
There's nothing to make anyone believe it's an "effective" strategy. Some people are deterred from contributing because this guy can't act professionally. The only reason people still want to contribute is because of the importance of the project (aka thousands of projects depend on a good linux kernel).
He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned. It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Maybe he is not that bad of a person to work with. Hopefully lower than how bad Gates and Jobs were. But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
I don't get what is "necessary" with his insults. Would delivering the message calmly not be understood?
There's nothing to make anyone believe it's an "effective" strategy. Some people are deterred from contributing because this guy can't act professionally. The only reason people still want to contribute is because of the importance of the project (aka thousands of projects depend on a good linux kernel).
He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned. It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Maybe he is not that bad of a person to work with. Hopefully lower than how bad Gates and Jobs were. But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
> Well, look up what companies like IBM, Google, Amazon,
Does any of these companies run a team with 5,000 people contributing to the same codebase?
Do you have it on good authority that most of the people in IBM, Google, and Amazon that manage those 5,000 people teams are nice and polite? Because I've heard a lot about Amazon to the contrary. Do consider your selection bias: You know everything Linus tells the world, you only hear about Ballmer's chair throwing, but not any other profanities,
> Would delivering the message calmly not be understood?
Yes, he tries/tried occasionally. The wikipedia entry for LKML has more info.
> He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned
That goes counter to Linus' experience, and a few other people's.
> It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Are you on the LKML? He almost never does it. You hear about it when he does. He is not shy with criticism, and he never sugarcoats anything, sure, but he goes ballistic very rarely.
> But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
You admit that you have no idea what happens between the times you hear of him. You implicitly say your model is "IBM, Amazon and Google", in which you hear nothing of how disagreements are handled, and none of which have the scale and diversity of the LKML in a single team.
It is my impression that your beliefs are not grounded in data or even anecdata. It does not make them wrong, and I'm not saying you are wrong. I'm saying you have not made any convincing argument to say you are right.
Does any of these companies run a team with 5,000 people contributing to the same codebase?
Do you have it on good authority that most of the people in IBM, Google, and Amazon that manage those 5,000 people teams are nice and polite? Because I've heard a lot about Amazon to the contrary. Do consider your selection bias: You know everything Linus tells the world, you only hear about Ballmer's chair throwing, but not any other profanities,
> Would delivering the message calmly not be understood?
Yes, he tries/tried occasionally. The wikipedia entry for LKML has more info.
> He can accomplish the same things, without going ballistic, in shorter time and with the respect of others earned
That goes counter to Linus' experience, and a few other people's.
> It's still using the same few management tools and he can retain his bad temper for when a situation actually calls for it (which is almost never). Blowing everything out of proportion is crying wolf.
Are you on the LKML? He almost never does it. You hear about it when he does. He is not shy with criticism, and he never sugarcoats anything, sure, but he goes ballistic very rarely.
> But he sure seems to hide it well since that's all I ever hear about him. But I guess bad publicity is still publicity.
You admit that you have no idea what happens between the times you hear of him. You implicitly say your model is "IBM, Amazon and Google", in which you hear nothing of how disagreements are handled, and none of which have the scale and diversity of the LKML in a single team.
It is my impression that your beliefs are not grounded in data or even anecdata. It does not make them wrong, and I'm not saying you are wrong. I'm saying you have not made any convincing argument to say you are right.
> Especially those examples (of "most people") that coordinate submission from 5,000 people mostly interacting directly with them.
This is wrong. He has said himself on video multiple times that his correspondents are the subsytem maintainers, which are way fewer in number (a handful of people).
This is wrong. He has said himself on video multiple times that his correspondents are the subsytem maintainers, which are way fewer in number (a handful of people).
He is on the LKML[0], and does respond to many people, not just the handful of maintainers. I'm sure he doesn't read the entirety of the LKML (hundreds of messages per day), and for sure he has a private channel (mailing list or otherwise) with subsystem maintainers, but he DOES correspond with a lot more than that handful, and when I was reading the LKML, he would even occasionally respond to first-time posters.
[0] https://en.wikipedia.org/wiki/Linux_kernel_mailing_list
[0] https://en.wikipedia.org/wiki/Linux_kernel_mailing_list
It is very rare to see him treat people like they're idiots.
There's a very fine but very clear line in a lot of his rants between very harsh language used against solutions he doesn't like, but without making it personal, like in this case where he's attacking the rationale, and attacking the C standard, but is very explicitly avoiding attacking the people (even taking pains to point out he's not suggesting people on standard bodies in general are incompetent). The closest he comes to attacking people directly here is when he calls people who use -fstrict-aliasing "fcking morons" when* they use -fstrict-aliasing, so even that is conditional on behaviour rather than assigning a trait to the person in general. You'll sometimes see him making wide-ranging accusations about general categories of people (e.g. I remember a rant about people who think it's a good idea to do reads a byte at a time), but rarely about specific people.
On the rare occasions when he attacks people directly, I have yet to seen an example which doesn't fall in the category of either attacking persistent repeat offenders who has refused to listen to more polite rebukes (his attack on Kai Sivers being the most obvious example [1] - notably while very direct and personal, that rant was also comparatively civil in terms of actual language), or attacks that fall in the "I know you know so much better, or you wouldn't be in the trusted position you're in" category (his attack on Mauro Carvalho Chehab for a change that broke userspace [2] falls in that category; Mauro has contributed to the kernel since 2005, and have worked on it as his job for years - in this case Mauro took it on his chin, apologised for the breakage and the discussion remained strictly on topic on the technical issues afterwards).
Frankly if I'd gotten a dressing down by Linus in that category, I'd print it out and frame it, because harsh as they may be, I don't know of any case of people having gotten those without having demonstrated time and time again that they should know better first. You don't see him ranting like that at beginners. You see him ranting like that when he's disappointed because he has high expectations of you. Doesn't mean people can't get upset by them, of course, but it changes the nature of it quite a bit.
Note that I'm not saying that it's a good thing- I'm sure there'd be more civil ways to express that too -, just that I think the importance of these rants is exaggerated.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
[2] https://lkml.org/lkml/2012/12/23/75
There's a very fine but very clear line in a lot of his rants between very harsh language used against solutions he doesn't like, but without making it personal, like in this case where he's attacking the rationale, and attacking the C standard, but is very explicitly avoiding attacking the people (even taking pains to point out he's not suggesting people on standard bodies in general are incompetent). The closest he comes to attacking people directly here is when he calls people who use -fstrict-aliasing "fcking morons" when* they use -fstrict-aliasing, so even that is conditional on behaviour rather than assigning a trait to the person in general. You'll sometimes see him making wide-ranging accusations about general categories of people (e.g. I remember a rant about people who think it's a good idea to do reads a byte at a time), but rarely about specific people.
On the rare occasions when he attacks people directly, I have yet to seen an example which doesn't fall in the category of either attacking persistent repeat offenders who has refused to listen to more polite rebukes (his attack on Kai Sivers being the most obvious example [1] - notably while very direct and personal, that rant was also comparatively civil in terms of actual language), or attacks that fall in the "I know you know so much better, or you wouldn't be in the trusted position you're in" category (his attack on Mauro Carvalho Chehab for a change that broke userspace [2] falls in that category; Mauro has contributed to the kernel since 2005, and have worked on it as his job for years - in this case Mauro took it on his chin, apologised for the breakage and the discussion remained strictly on topic on the technical issues afterwards).
Frankly if I'd gotten a dressing down by Linus in that category, I'd print it out and frame it, because harsh as they may be, I don't know of any case of people having gotten those without having demonstrated time and time again that they should know better first. You don't see him ranting like that at beginners. You see him ranting like that when he's disappointed because he has high expectations of you. Doesn't mean people can't get upset by them, of course, but it changes the nature of it quite a bit.
Note that I'm not saying that it's a good thing- I'm sure there'd be more civil ways to express that too -, just that I think the importance of these rants is exaggerated.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html
[2] https://lkml.org/lkml/2012/12/23/75
I suspect a big part of why user space is broken so rarely in Linux is exactly because Linus has made such a big deal about it in the past.
Its almost as though he identified a weak point and ameliorated it! That's what an Engineer does.
which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
There is no such thing as best practice - that is a nonsensical phrase that I think someone involved with MS created many moons ago and caught on in IT and I absolutely despise. There is good and bad practice but you had better be very, very good at something to tell me that you know best about that something.
Its almost as though he identified a weak point and ameliorated it! That's what an Engineer does.
which are often ignored because every developer doesn't keep 100% of the best practices in mind at all times.
There is no such thing as best practice - that is a nonsensical phrase that I think someone involved with MS created many moons ago and caught on in IT and I absolutely despise. There is good and bad practice but you had better be very, very good at something to tell me that you know best about that something.
He may be a bastard, but he's our bastard!
I know you're being lighthearted here but that kind of thinking is actually another form of "appeal to authority".
FWIW, having not looked at any of his LKML rants for years, he seems to have mellowed out a bit in this one.
FWIW, having not looked at any of his LKML rants for years, he seems to have mellowed out a bit in this one.
This assumes consistency of tone over time. It'd be interesting to get some data on how his approach has varied over those 20 years. It'd also be difficult, since this is a somewhat subjective measurement, but perhaps a PPP (profanity per paragraph) metric.
Linus used to be much more polite... until some developer attempted suicide after discovering, too late, that their patches were not going to be merged.
Since then he's much more direct, and his SPP (suicide per paragraph) metric is much better.
I don't understand why people feel the need to go Kremlinologist on his tone.
He swears a lot. Who the fuck cares? His audience isn't HN or The Register or anyone else not doing kernel development.
The apparent desire for bland, well-scrubbed and boring is not universal. I haven't heard of a sudden increase in demand for talk therapy for kernel devs. Lots of engineers swear a lot, and that's unlikely to change anytime soon.
Now, if you'd like to discuss actual abusive managerial behavior, we could have something to talk about.
He swears a lot. Who the fuck cares? His audience isn't HN or The Register or anyone else not doing kernel development.
The apparent desire for bland, well-scrubbed and boring is not universal. I haven't heard of a sudden increase in demand for talk therapy for kernel devs. Lots of engineers swear a lot, and that's unlikely to change anytime soon.
Now, if you'd like to discuss actual abusive managerial behavior, we could have something to talk about.
I think James Mickens expresses it correctly;
"""
When you debug a distributed system or an OS kernel, you do it Texas-style. You gather some mean, stoic people, people who have seen things die, and you get some primitive tools, like a compass and a rucksack and a stick that’s pointed on one end, and you walk into the wilderness and you look for trouble, possibly while using chewing tobacco.
"""
Kernel developers tend to, in my experience, be a specific type of person. They are writing software that will possibly save someone's life today. Billions of dollars changing hands using their code every second.
The average programmer on HN does not write code that will see more than a couple thousand users at once. Even people at google usually don't write code as important as the linux kernel (they write on top of the kernel, usually).
---
There is also some narrativ that Linus is being abusive and I kinda disagree. Linus doesn't take a dump on people who don't know better, he takes a dump on people who should definitely know better and who are long time kernel contributors in important positions. Because these people count. (Plus, he's finnish)
"""
When you debug a distributed system or an OS kernel, you do it Texas-style. You gather some mean, stoic people, people who have seen things die, and you get some primitive tools, like a compass and a rucksack and a stick that’s pointed on one end, and you walk into the wilderness and you look for trouble, possibly while using chewing tobacco.
"""
Kernel developers tend to, in my experience, be a specific type of person. They are writing software that will possibly save someone's life today. Billions of dollars changing hands using their code every second.
The average programmer on HN does not write code that will see more than a couple thousand users at once. Even people at google usually don't write code as important as the linux kernel (they write on top of the kernel, usually).
---
There is also some narrativ that Linus is being abusive and I kinda disagree. Linus doesn't take a dump on people who don't know better, he takes a dump on people who should definitely know better and who are long time kernel contributors in important positions. Because these people count. (Plus, he's finnish)
Link for those interested in reading the rest:
https://www.usenix.org/system/files/1311_05-08_mickens.pdf
> "I don't understand why people feel the need to go Kremlinologist on his tone."
It's easier to discuss his profanity than it is to discuss a technical topic. (I'm not unaware of the irony inherent in this very comment.)
It's easier to discuss his profanity than it is to discuss a technical topic. (I'm not unaware of the irony inherent in this very comment.)
I haven't spent much (any) time listening to him, just heard that he behaves badly sometimes. This swearing of him, is it because he is finnish? They are known to be quite dirty in the mouth-department when they are upset.
https://satwcomic.com/bear-whisperer
https://youtu.be/dIfZKdZEJNQ
https://www.youtube.com/watch?v=z7_pVrIshxA
https://satwcomic.com/bear-whisperer
https://youtu.be/dIfZKdZEJNQ
https://www.youtube.com/watch?v=z7_pVrIshxA
It's a meme that a certain camp spreads so that when the inevitable time comes to replace Linus, they can get "their guy/gal" in.
Kernel commits should be to a much higher standard and his way of reminding people is necessary to steer the ship.
Kernel commits should be to a much higher standard and his way of reminding people is necessary to steer the ship.
[deleted]
Good point that his style and profanity is intentional. But perhaps he uses the non-civil tone to drive home the point which he makes it clearer in the follow up mail [1]. Especially because the original commit message [2] he is complaining about goes overboard in appealing to the C standards and I think Linus is concerned that other people might think that is the recommended approach when the opposite is true as far as the Linux kernel code is concerned.
[1]https://lkml.org/lkml/2018/6/5/774 [2]https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux...
[1]https://lkml.org/lkml/2018/6/5/774 [2]https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux...
No, he's wrong. Aliasing between union members has never been defined behavior. It just happened to work.
Now that optimizers are getting better, these long-standing issues are starting to surface in the real world. This is no different from when programmers do something dumb like
Code around it and move on -- as in the patch mentioned.
[1] https://en.cppreference.com/w/cpp/language/eval_order
Now that optimizers are getting better, these long-standing issues are starting to surface in the real world. This is no different from when programmers do something dumb like
j = i++ * i++;
Code around it and move on -- as in the patch mentioned.
[1] https://en.cppreference.com/w/cpp/language/eval_order
Did you actually read what he wrote? He agrees that's what the standard says, thus the standard is not workable in reality, so he goes with GCC's (defined in documentation) implementation. It doesn't "just happen to work" in GCC, it deliberately works, and GCC is the only compiler the core kernel devs care about (see ASM goto).
Sure. And that's a terrible reason.
First, he's binding Linux to gcc forever. I've made that mistake and let me tell you, it's a mistake with surprisingly few benefits. A couple of asms and gccisms? Easily replaced.
Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic.
Third, "the standard is not workable in reality" is simply wrong. I work on low-level systems. I somehow manage to work with devices and networks on a day-to-day basis without relying on this.
Ultimately it comes down to this: Linus put his faith in something which was explicitly removed from C 30 years ago. The writing has been on the wall for about 10 years now[1]: Good optimizers are going to do away with this mis-feature. Time to start adapting to reality.
[1] http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al...
First, he's binding Linux to gcc forever. I've made that mistake and let me tell you, it's a mistake with surprisingly few benefits. A couple of asms and gccisms? Easily replaced.
Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic.
Third, "the standard is not workable in reality" is simply wrong. I work on low-level systems. I somehow manage to work with devices and networks on a day-to-day basis without relying on this.
Ultimately it comes down to this: Linus put his faith in something which was explicitly removed from C 30 years ago. The writing has been on the wall for about 10 years now[1]: Good optimizers are going to do away with this mis-feature. Time to start adapting to reality.
[1] http://blog.qt.io/blog/2011/06/10/type-punning-and-strict-al...
> Second, it is an error to call gcc's behavior "defined in documentation" as if that means it's okay to use. It's just a flag to support obsolete code. Long-term, the assumption that gcc will retain flags to support antique code is optimistic.
Type punning through a union works on GCC without -fno-strict-aliasing, and is documented in multiple places. Among others, it's suggested as an alternative to fix code broken under strict aliasing here: https://gcc.gnu.org/bugs/#nonbugs.
It's also relatively safe to assume that GCC will continue to be able to compile the Linux kernel for the indefinite future, since it would be very high profile, cause a ton of drama, and result in many people to moving away from GCC (including contributors). It seems very unlikely to be a smart decision.
(That's not to say lower profile projects than the linux kernel should rely on this. Using memcpy/memmove is just as fast and that much more difficult).
Type punning through a union works on GCC without -fno-strict-aliasing, and is documented in multiple places. Among others, it's suggested as an alternative to fix code broken under strict aliasing here: https://gcc.gnu.org/bugs/#nonbugs.
It's also relatively safe to assume that GCC will continue to be able to compile the Linux kernel for the indefinite future, since it would be very high profile, cause a ton of drama, and result in many people to moving away from GCC (including contributors). It seems very unlikely to be a smart decision.
(That's not to say lower profile projects than the linux kernel should rely on this. Using memcpy/memmove is just as fast and that much more difficult).
The difference is that the code you wrote actually is dumb, but relying on union aliasing is not. :) A behavior doesn't need to be defined by the spec as long as it is defined by the implementation (gcc) you are targeting.
The code I wrote was dumb... and yet Stroustroup repeatedly made a variant of the mistake in the "C++ Programming Language." Turns out that the use of operator<< in iostreams is problematic.
It's gcc defined behavior. Not the BS (his words) C standard behavior.
I don't think a "civil tone" is necessary; directed anger can be good and helpful. The problem with Linus is that he just smears it around aimlessly, adding lots of boring noise to what may have been an interesting technical argument.
It's not real anger, is my point. It's just shit-stirring. Unless he's got far less self-awareness than I credit a functioning adult of his industry stature, he has to know that people reading his "idiot fucking brain-damage" spiel sort of roll their eyes and think "there goes Linus again"; nobody stops, catches a breath, and thinks "damn, he's really upset this time".
When I hear open source maintainers talk about their woes, it tends to be that they are a single person and their are many people who try to contribute who think they are offering great things, but who are in fact just giving them shit that they must then maintain for the rest of their lives.
In a world in which there are only two people communicating with each other, you're definitely right that the point he is making can be made better. But consider that he just made his point to thousands upon thousands of potential contributors, because the message was shared. This directly addresses two of the things I hear open source maintainers complain about: it discourages the giving of shitty things and it moves away from the poorly scaling one on one communication.
In a world in which there are only two people communicating with each other, you're definitely right that the point he is making can be made better. But consider that he just made his point to thousands upon thousands of potential contributors, because the message was shared. This directly addresses two of the things I hear open source maintainers complain about: it discourages the giving of shitty things and it moves away from the poorly scaling one on one communication.
> roll their eyes and think "there goes Linus again"
You both seem to be unaware, that emotional responses are not universal. A swear word in a second language and a different less sensitive culture doesn't feel like much to cause anyone to care enough to roll their eyes.
You both seem to be unaware, that emotional responses are not universal. A swear word in a second language and a different less sensitive culture doesn't feel like much to cause anyone to care enough to roll their eyes.
"there goes tptacek moralizing to everyone again"
(I am merely trying to illustrate that we are all creatures of habit)
(I am merely trying to illustrate that we are all creatures of habit)
But is it effective? That's really the point.
I also feel like we see every single abrasive Linus email hauled out of context to make this point that he's an over-dramatic asshat, and not the mountain of mundane ones where he isn't torching somebody to make a point.
I also feel like we see every single abrasive Linus email hauled out of context to make this point that he's an over-dramatic asshat, and not the mountain of mundane ones where he isn't torching somebody to make a point.
> The problem with Linus is that he just smears it around aimlessly
I take it you don't really read a lot of Linus' mail? I find it hard to believe that somebody would think that, unless they only got to see a highly biased selection of his emails.
Also, consider that we would never have had this thread in which several people are learning about gcc's documented behavior on unions if it hadn't been for the somewhat strong language. It serves a genuine purpose.
I take it you don't really read a lot of Linus' mail? I find it hard to believe that somebody would think that, unless they only got to see a highly biased selection of his emails.
Also, consider that we would never have had this thread in which several people are learning about gcc's documented behavior on unions if it hadn't been for the somewhat strong language. It serves a genuine purpose.
I consider his post fully appropriate, as I share his view of the quality of that aspect of the standard. The standard, for this specific issue, is so obviously unbelievably wrong, so much that it deserves the worst words to describe it, just to give the clearer view of wrongness to the readers.
At this point, if that's true, he should have written his condemnation very carefully and subtly. People would flip their shit; Linus must really be mad now!
What I read in your comments here is just "I know Linus uses strong language, and therefore I can't figure out if he's right or not."
Which is wrong approach to your figuring out that. Instead, you can have only two approaches:
- learn enough about the topic discussed to have your own opinion
or
- consider how often Linus was wrong in his "expert" opinions (From my point of view, he's almost always right, but you are free to give the example of the opposite if you have them) and use that as a starting point.
Note: both approaches are completely independent of the speech figures of Linus' post, which is how it should be.
I personally, for myself, came to conclusion that most of the time, specifically for the issues I know more than enough to have my own opinion, I can trust that Linus' opinion will match my. And if it doesn't happen, that he will probably still be right and I have to reevaluate my initial opinion.
In this specific case, I would be very glad that people here try to even give some reasonable arguments why he would be wrong. Because "it's in standard" is not a valid argument, as soon as you accept that the standards definitely aren't guaranteed to be without even big errors.
The most problematic attitude I see is exactly like 'ramshorns (parallel post) asking "How can the standard be wrong" (the right question would be "where is the standard wrong"). The answer to the former:
A standard is just a document produced by a group of people trying to specify something. There's nothing that guarantees in any way that the product of any group of people doesn't contain errors.
The answer to the later: In this case, the standard "resolution" of the real need is obviously wrong, because the "resolution" is pretending that the need doesn't exist. And the need not only exists but is fundamentally necessary for the use cases where C is being used: being "low level" enough not to incur unnecessary penalties to implement something that is "natural" on the hardware level. Unions were used for decades to fulfill exactly that specific need that the standard body somehow managed to "ignore" and the compiler implementers looking for a "loophole" to produce unusable code sadly want to use. Such attitudes, both by standard bodies and by such implementers are also wrong.
edit: re tedunangst's "Linus is yelling. Do I care? Should I care? Is there any meaningful signal from the yelling" please read this my post again. I assumed I'm answering exactly this. And my opinion is really: you can assume Linus is right. He was so often right for such technical issues that it's a good start. Then, yes, care. Yes, you should, if the technical topics discussed have connection with what your work is. And if you don't program in C, and don't influence those who do, you can of course ignore the whole thing, but then the question is why are you involved now in the topic's discussion or consideration.
And for those that believe that there is really no correlation between Linus using strong language and him being rightly against some "practice," they should provide some proof that such correlation is negative or doesn't exist, as much as I know, it exists and is actually positive, exactly for some big issues I care about.
Which is wrong approach to your figuring out that. Instead, you can have only two approaches:
- learn enough about the topic discussed to have your own opinion
or
- consider how often Linus was wrong in his "expert" opinions (From my point of view, he's almost always right, but you are free to give the example of the opposite if you have them) and use that as a starting point.
Note: both approaches are completely independent of the speech figures of Linus' post, which is how it should be.
I personally, for myself, came to conclusion that most of the time, specifically for the issues I know more than enough to have my own opinion, I can trust that Linus' opinion will match my. And if it doesn't happen, that he will probably still be right and I have to reevaluate my initial opinion.
In this specific case, I would be very glad that people here try to even give some reasonable arguments why he would be wrong. Because "it's in standard" is not a valid argument, as soon as you accept that the standards definitely aren't guaranteed to be without even big errors.
The most problematic attitude I see is exactly like 'ramshorns (parallel post) asking "How can the standard be wrong" (the right question would be "where is the standard wrong"). The answer to the former:
A standard is just a document produced by a group of people trying to specify something. There's nothing that guarantees in any way that the product of any group of people doesn't contain errors.
The answer to the later: In this case, the standard "resolution" of the real need is obviously wrong, because the "resolution" is pretending that the need doesn't exist. And the need not only exists but is fundamentally necessary for the use cases where C is being used: being "low level" enough not to incur unnecessary penalties to implement something that is "natural" on the hardware level. Unions were used for decades to fulfill exactly that specific need that the standard body somehow managed to "ignore" and the compiler implementers looking for a "loophole" to produce unusable code sadly want to use. Such attitudes, both by standard bodies and by such implementers are also wrong.
edit: re tedunangst's "Linus is yelling. Do I care? Should I care? Is there any meaningful signal from the yelling" please read this my post again. I assumed I'm answering exactly this. And my opinion is really: you can assume Linus is right. He was so often right for such technical issues that it's a good start. Then, yes, care. Yes, you should, if the technical topics discussed have connection with what your work is. And if you don't program in C, and don't influence those who do, you can of course ignore the whole thing, but then the question is why are you involved now in the topic's discussion or consideration.
And for those that believe that there is really no correlation between Linus using strong language and him being rightly against some "practice," they should provide some proof that such correlation is negative or doesn't exist, as much as I know, it exists and is actually positive, exactly for some big issues I care about.
Linus is yelling. Do I care? Should I care? Is there any meaningful signal from the yelling to suggest that this is more important than, say, people who misspell commit messages?
How can the standard be wrong? Is what it says about aliasing unclear, impossible to implement, or what?
The standard massively conflicts with the practices used in existing C programs by existing C programmers. Yes, it's perfectly possible to write code that doesn't violate any of the (largely implicit, it's worth noting) strict-aliasing rules. But was it a good idea for the standard to allow optimizing compilers to silently break massive amounts of existing code that has worked for years? Even if that were acceptable, was it a good idea for the standard to disallow one of the more ergonomic and explicit ways (using a union) of reinterpreting an object as an object of a different type?
Some good reads on this topic:
https://blog.regehr.org/archives/1307
http://www.yodaiken.com/2018/05/20/depressing-and-faintly-te...
https://blog.regehr.org/archives/903 (See the end of Xavier Leroy's comment)
Some good reads on this topic:
https://blog.regehr.org/archives/1307
http://www.yodaiken.com/2018/05/20/depressing-and-faintly-te...
https://blog.regehr.org/archives/903 (See the end of Xavier Leroy's comment)
Linus has spoken about why he speaks/writes this way before - https://youtu.be/MShbP3OpASA?t=2190
"On the internet nobody can hear you being subtle."
https://en.wikiquote.org/wiki/Linus_Torvalds
https://en.wikiquote.org/wiki/Linus_Torvalds
It is ironic that his own arguments about the standards can be applied to his own attempts to convey ideas, persuade other people, and collaborate effectively with other human beings.
It's not really ironic, computers and programs are different from ideas and minds. His complaint is about computation and maintaining uniformity in computational philosophy, which is meant to allow development to flow with the least performance issues possible.
Ideas can be impassioned, wrong, clever, ridiculous, circular, etc. Computation shouldn't be, but often is, because, preference.
It's hard to hold all that stuff in one's head alone, and consistently feel like every time a problem is solved, a new one magically gets created, without having anyone to talk to, that really 'gets it', without that person pushing every single button you have about preference in computation.
Ideas can be impassioned, wrong, clever, ridiculous, circular, etc. Computation shouldn't be, but often is, because, preference.
It's hard to hold all that stuff in one's head alone, and consistently feel like every time a problem is solved, a new one magically gets created, without having anyone to talk to, that really 'gets it', without that person pushing every single button you have about preference in computation.
You missed the point. He is haranguing about ignoring reality, all the while ignoring the reality of how to effectively work in groups. His method of interacting with people is an idiotic way of doing that and he damn well knows that and just doesn't give a fuck and yet he wants to hold others to that standard in other areas.
Your point is weakened by the fact that Linus has managed an enormous project for decades with incredible success. That scores some reality and effectiveness points, surely.
That's great and it's a credit to him!
Have you factored in the opportunity cost of being an ass for decades?
Have you factored in the opportunity cost of being an ass for decades?
I have not. I choose not to grumble in public that the enormous contribution to the world of a master craftsman could have been even more enormous if he'd done things the way I prefer instead of whatever way works for him.
And then I get back to work using his software which I paid close to zero dollars for.
Is there another gift horse whose mouth is so frequently inspected as Linus?
And then I get back to work using his software which I paid close to zero dollars for.
Is there another gift horse whose mouth is so frequently inspected as Linus?
Oh excuse me, I should bend over for him then! Because his achievements are so great, he must be immune to criticism!!!
> the enormous contribution to the world of a master craftsman could have been even more enormous
Hardly, it's about the contributions that don't exist from other people because of the insufferable shit-headedness of working with him. But that doesn't matter to you because we can't criticize him now can we? No, we must bend over because he is so much better than us!
> the enormous contribution to the world of a master craftsman could have been even more enormous
Hardly, it's about the contributions that don't exist from other people because of the insufferable shit-headedness of working with him. But that doesn't matter to you because we can't criticize him now can we? No, we must bend over because he is so much better than us!
Your complaint is that Linus is an ass, and this is how you choose to express yourself in public. Huh.
Your inability to realize that the the context of my criticism is on his ability to collaborate and that that doesn't apply to how I express myself in public is laudable.
Where are Matthew Garrett and Sarah Sharp's Linux kernel forks? Anyone else I forgot?
I mean at least when the NetBSD group ego-tripped and removed Theo, he had the decency to work on OpenBSD.
People who really want to contribute will find a way to, always. Unless something else is more important to them than contributing.
I mean at least when the NetBSD group ego-tripped and removed Theo, he had the decency to work on OpenBSD.
People who really want to contribute will find a way to, always. Unless something else is more important to them than contributing.
He's talking about computation, getting the computations to be correct. If you read the end of his message he's well aware that the reality of thinking in groups and transmitting ideas through non-computational language are flawed.
It's an idiot way to you because you are too sensitive to it.
I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots, but honestly I'd rather just laugh at the insanity computation tends to bring out in all those that have to work on computers with other people.
It's an idiot way to you because you are too sensitive to it.
I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots, but honestly I'd rather just laugh at the insanity computation tends to bring out in all those that have to work on computers with other people.
> He's talking about computation, getting the computations to be correct.
Irrelevant to my point.
> If you read the end of his message he's well aware that the reality of minds and ideas are flawed.
And he still doesn't work with in the confines of human social behavior.
> It's an idiot way to you because you are too sensitive to it.
And when it hinders his ability to get things done because other people think he's an asshole, I'm sure you'll still be here saying "hurrrrr durrrrr stop being so sensitive".
> I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots,
If you want to think calling someone an idiot for idiotic behavior is idiotic, then you're pretty sensitive. However since I don't need you to do anything for me, it doesn't hurt me in any way to treat you like an ass.
Irrelevant to my point.
> If you read the end of his message he's well aware that the reality of minds and ideas are flawed.
And he still doesn't work with in the confines of human social behavior.
> It's an idiot way to you because you are too sensitive to it.
And when it hinders his ability to get things done because other people think he's an asshole, I'm sure you'll still be here saying "hurrrrr durrrrr stop being so sensitive".
> I could very well point out how idiotic it is to say a person is an idiot for calling other people idiots,
If you want to think calling someone an idiot for idiotic behavior is idiotic, then you're pretty sensitive. However since I don't need you to do anything for me, it doesn't hurt me in any way to treat you like an ass.
Maybe it's a cultural thing? I don't find the language as being particularly abrasive, only as having personality, and quite expressive. But then swearing and cursing seems to be much more accepted in most of Scandinavia than it is in much of the English speaking world.
If the Swedish speaking minority of Finland is speaking anything like the good people of Åland, well, then it could be interpreted as trying to be quite polite. Never met any people who could get more obscenities into the most casual and every-day conversations then they can. It's really quite impressive.
If the Swedish speaking minority of Finland is speaking anything like the good people of Åland, well, then it could be interpreted as trying to be quite polite. Never met any people who could get more obscenities into the most casual and every-day conversations then they can. It's really quite impressive.
Negative experiences create far stronger memories. That's just how the brain works. You can walk great distances and barely remember the places you passed through, but if you step on a nail at some point you'll never forget that event. That memory is simply much stronger than the others.
How many email messages does Linus send in a year? How many of those messages contain rants so epic they get posted here? I bet it's less 1% of all messages. Yet everyone remembers those messages and what they say. He might not be polite, but he gets his point across.
How many email messages does Linus send in a year? How many of those messages contain rants so epic they get posted here? I bet it's less 1% of all messages. Yet everyone remembers those messages and what they say. He might not be polite, but he gets his point across.
I think all the polite/diplomatic arguments would be 1% effective vs his "fuck you NVIDIA"
qofcourse(2)
Before anyone flips out, he actually merged the code:
https://lkml.org/lkml/2018/6/5/774
Side note: I've merged it, and it's going through my build tests,
so it's really not that I hate the code.
But I really find that kind of one-sided rationale that ignores reality unacceptable.
And I find it dangerous, because it *sounds* so "obviously correct" to people who don't know any better.
If you don't know that gcc explicitly says that you should use unions to do type punning to avoid aliasing issues,
you might believe that union type punning is a bad thing from that commit message.
So it's dangerously misleading, because lots of people have a dangerous reverence for paper over reality.
In programming, "Appeal to Standards" should be considered a potential logical fallacy.
Standards have their place, but they definitely have their caveats too.> And I find it dangerous, because it sounds so "obviously correct" to people who don't know any better.
> So it's dangerously misleading, because lots of people have a dangerous reverence for paper over reality.
It's the same thing everywhere. You see it as "famous person said X" or "the standard is X" or "the industry does X" or "X is popular". Then you talk shit about X, because you actually know it's not right, and people dump on you because you're a heretic, or not famous, or not an authority, or don't have "a piece of paper" to quote from.
Everybody just goes with what sounds right rather than what is proven right.
> So it's dangerously misleading, because lots of people have a dangerous reverence for paper over reality.
It's the same thing everywhere. You see it as "famous person said X" or "the standard is X" or "the industry does X" or "X is popular". Then you talk shit about X, because you actually know it's not right, and people dump on you because you're a heretic, or not famous, or not an authority, or don't have "a piece of paper" to quote from.
Everybody just goes with what sounds right rather than what is proven right.
Which is why it nice to have famous but intemperate people like Torvalds to keep things in balance.
What do you mean!? Everyone knows Rails doesn't scale and jQuery is garbage!
Trying to appeal emotionally is just cheap and easy for our brains. Explaining things in depth and coming up with rationales is hard work.
>Everybody just goes with what sounds right rather than what is proven right.
I'll just throw out the corner case that sometimes that's just what you... do to get through the day. I might not give others advice on it because I don't know, but often I don't know enough and someone better says "naw that will give you trouble down the line" and stuff has to get done so I do the thing the way I was told.
Maybe I look it up later .... maybe.
I'll just throw out the corner case that sometimes that's just what you... do to get through the day. I might not give others advice on it because I don't know, but often I don't know enough and someone better says "naw that will give you trouble down the line" and stuff has to get done so I do the thing the way I was told.
Maybe I look it up later .... maybe.
There is not much in life that can be proven correct, and even less so in ancient past, which explains why humans are naturally this way.
[deleted]
I find it ironic in that C++ has the correct solution to this problem. If you need type-pruning, use reinterpret_cast<foo>(bar). Done and done. Ironic, because Linus's weapon of choice (C... or more specifically, GCC's particular implementation of C) would require far more expertise to use correctly.
Lets break it down.
In C, type-punning is NOT part of the language. Its technically "undefined behavior". There's an expectation that when you do:
When an optimizer can assume, and when it can't assume, "aliasing" is very much an undefined behavior within the C language.
-------------
In effect, Linus knows GCC inside and out. GCC guarantees that unions will ALWAYS work for this aliasing problem. But this requires knowledge above and beyond the C Standard.
Linus may be "hating" and "criticizing" the standard in this case. And I guess there's certainly a gap. But the general expectation that everyone knows the intricacies of GCC to properly understand the kernel code is misplaced IMO, and goes back to "Angry Linus yells at random dev unnecessarily" territory for me.
And instead of simply explaining this VERY simple fact (although super-obscure) that GCC makes unions safe against aliasing issues at the compiler level... Linus yells at the dev. Not fair IMO.
Lets break it down.
In C, type-punning is NOT part of the language. Its technically "undefined behavior". There's an expectation that when you do:
short foo[2] = {1, 2} ;
*(int*)foo = 0x12345678;
assert(foo[0] == 0x5678 && foo[1] == 0x1234);
When an optimizer can assume, and when it can't assume, "aliasing" is very much an undefined behavior within the C language.
-------------
In effect, Linus knows GCC inside and out. GCC guarantees that unions will ALWAYS work for this aliasing problem. But this requires knowledge above and beyond the C Standard.
Linus may be "hating" and "criticizing" the standard in this case. And I guess there's certainly a gap. But the general expectation that everyone knows the intricacies of GCC to properly understand the kernel code is misplaced IMO, and goes back to "Angry Linus yells at random dev unnecessarily" territory for me.
And instead of simply explaining this VERY simple fact (although super-obscure) that GCC makes unions safe against aliasing issues at the compiler level... Linus yells at the dev. Not fair IMO.
Stop spreading complete bullshit and go read https://en.cppreference.com/w/cpp/language/reinterpret_cast already. C++ has strict aliasing rules (probably even stricter than C) and reinterpret_cast can do absolutely nothing to workaround them. It is of no help because it certainly not allow you to access objects with a wrong type. It merely reinterpret the type of values, or values as far as the implementation is concerned (C++ reference, which are only pointers with syntactic sugar plus a few extra restrictions). In the C++ community, the current thinking is that memcpy allows to type pun, but IIRC the C++ standard is actually not even clear as for why this is the case, and in its current writing it might be that there is actually no way. Short of memcpy you need at least a placement new on a trivial type. And sometimes even other cases of insanity, like std::launder. Hell, sometimes you even need std::launder for the same type.
Short of converting void* (or sufficiently large ints) to T* because of legacy API, I'm not sure reinterpret_cast has any portable use. But I'm sure you can NOT type pun with it if that would break the aliasing rules.
Short of converting void* (or sufficiently large ints) to T* because of legacy API, I'm not sure reinterpret_cast has any portable use. But I'm sure you can NOT type pun with it if that would break the aliasing rules.
Note: When converting void* to T* you can use use static_cast, which is well-defined. For example
int* x = static_cast<int*>(malloc(sizeof(int)));BTW, I find this useful when programming in a C dialect that compiles as C:
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif
You just re-invented MFC macros for the C++ features that were being discussed for ISO C++89.
https://docs.microsoft.com/en-us/cpp/mfc/reference/mfc-macro...
https://docs.microsoft.com/en-us/cpp/mfc/reference/mfc-macro...
What you're missing is that
C++ has just divided the behavior of the (TYPE) cast notation in terms of more specific kinds of casts which are mutually exclusive. If a qualifier is being removed, you must use const_cast, which will not change type. The C-style-cast notation automatically chooses the right combination of C++-style casts to do the job. So for instance a C style cast from "const char " to "void ":
E.g. reinterpret_cast is not so powerful that it will strip away qualifiers:
*(int *)foo = 0x12345678
*reinterpret_cast<int *>(foo) = 0x12345678
C++ has just divided the behavior of the (TYPE) cast notation in terms of more specific kinds of casts which are mutually exclusive. If a qualifier is being removed, you must use const_cast, which will not change type. The C-style-cast notation automatically chooses the right combination of C++-style casts to do the job. So for instance a C style cast from "const char " to "void ":
void foo(const void *arg)
{
static_cast<char *>(const_cast<void *>(arg));
}
void foo(const void *arg)
{
(char *) arg;
}
E.g. reinterpret_cast is not so powerful that it will strip away qualifiers:
void foo(const void *arg)
{
reinterpret_cast<char *>(arg); // error: stripped qualifier
}> the general expectation that everyone knows the intricacies of GCC to properly understand the kernel code is misplaced IMO
But this isn't just a person trying to properly understand the kernel code. It's someone who's trying to merge a change that's motivated by following a standard. If you're making a change to code based on a standard then yeah, you should know the intricacies of how the compiler implements that standard. Because, as Linus keeps coming back to, that's reality, that's what's actually going to impact users and other devs: the intricacies.
But this isn't just a person trying to properly understand the kernel code. It's someone who's trying to merge a change that's motivated by following a standard. If you're making a change to code based on a standard then yeah, you should know the intricacies of how the compiler implements that standard. Because, as Linus keeps coming back to, that's reality, that's what's actually going to impact users and other devs: the intricacies.
Here's the change: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux...
This change strictly makes the Linux kernel more in line with the C Standard, so it may compile better in CLang.
There's literally nothing wrong here. The code is more correct and more conformant with the C-Standard. So why is Linus against it?
Hint: he really isn't. Linus accepted the code anyway.
I dunno, the more and more I look into this, the more I feel like its just another example of Linus unnecessarily flaming someone on the developer communication channels.
This change strictly makes the Linux kernel more in line with the C Standard, so it may compile better in CLang.
There's literally nothing wrong here. The code is more correct and more conformant with the C-Standard. So why is Linus against it?
Hint: he really isn't. Linus accepted the code anyway.
I dunno, the more and more I look into this, the more I feel like its just another example of Linus unnecessarily flaming someone on the developer communication channels.
Well Linus says that he's not against the code but the reasoning in the original post and I think his whole point is that neither of those arguments are good reasons to make a change. He doesn't specifically mention CLang, so I'm not sure how much he values compiling on that, but he clearly doesn't value conformation to the C Standard. Saying "This change strictly makes the Linux kernel more in line with the C Standard" and concluding there's literally nothing wrong here and that it's strictly more correct this way seems to be the opposite of Linus' opinion, and mine. It's fine to disagree with that, but don't act as if this is just unnecessary flaming by Linus without a purpose.
> He doesn't specifically mention CLang
This is from the overall discussion going on in this thread. Others have shown how union-aliasing fails to work in CLang throughout this thread:
https://news.ycombinator.com/item?id=17242457
By removing the non-standard GCC-specific union{} methodology from the code, the contributor necessarily improved portability to CLang. That's just the facts.
This is from the overall discussion going on in this thread. Others have shown how union-aliasing fails to work in CLang throughout this thread:
https://news.ycombinator.com/item?id=17242457
By removing the non-standard GCC-specific union{} methodology from the code, the contributor necessarily improved portability to CLang. That's just the facts.
Clang now follows GCC's behavior with regard to that specific example, which makes sense, as Clang more or less explicitly aims to correctly compile the GNU dialect of C.
I think it's reasonable (and even important) for Linus to emphasize that the kernel is coded in GNU C, not strictly standards-compliant C.
I think it's reasonable (and even important) for Linus to emphasize that the kernel is coded in GNU C, not strictly standards-compliant C.
> Clang more or less explicitly aims to correctly compile the GNU dialect of C
That was super important as the compiler was first starting out, because (A) Apple's existing code was built with GCC, so it relied on GCC flags & extensions, and (B) for it to be a viable open source compiler, it needed to build large existing codebases which were already using GCC.
However, that doesn't mean that Clang will always continue to support every thing GCC does. Whether they by design or by accident, incompatibilities will arise. Of course, projects as tightly coupled to GCC as the Linux kernel might not care.
That was super important as the compiler was first starting out, because (A) Apple's existing code was built with GCC, so it relied on GCC flags & extensions, and (B) for it to be a viable open source compiler, it needed to build large existing codebases which were already using GCC.
However, that doesn't mean that Clang will always continue to support every thing GCC does. Whether they by design or by accident, incompatibilities will arise. Of course, projects as tightly coupled to GCC as the Linux kernel might not care.
[deleted]
Don't use reinterpret_cast for type-punning in c++, you'll end up with UB. You should instead use memcpy.
Nonsense. Aliasing unlike-typed objects via memcpy is equivalent to pointer aliasing. memcpy has void pointer arguments. You're relying on the addresses of the source and destination objects being converted to void pointer.
All type punning is in the hands of the implementation. The language definition provides the syntax for it, which has the virtuel that all code which attempts to do type punning expresses it in the same manner. However, the language leaves it up to implementations to define whether type punning works, and with what caveats and restrictions.
All type punning is in the hands of the implementation. The language definition provides the syntax for it, which has the virtuel that all code which attempts to do type punning expresses it in the same manner. However, the language leaves it up to implementations to define whether type punning works, and with what caveats and restrictions.
Except using memcpy specifically does not violate aliasing rules, while aliases do.
It absolutely does. E.g. you can't memcpy a uint64 to a double and expect well-defined behavior.
There is some hand-waving in the definition of memcpy so that copying compatible objects is well-defined.
There is some hand-waving in the definition of memcpy so that copying compatible objects is well-defined.
> E.g. you can't memcpy a uint64 to a double and expect well-defined behavior.
Yes, you can. The behavior is implementation-defined but not undefined. (Well, it can trigger undefined behavior if the value corresponds to a signaling NaN, or if the implementation uses a nonstandard, non-IEEE format for doubles that has other "trap representations". But it's not otherwise undefined.)
The basis for this is that the aliasing rule has an explicit exception for reading or writing to objects using char pointers, i.e. byte-by-byte, regardless of the object's type. This exception is in both the C standard:
https://port70.net/~nsz/c/c11/n1570.html#6.5p7
and the C++ standard:
http://eel.is/c++draft/expr.prop#basic.lval-11.8
The memcpy function is defined as copying characters, so the exception applies to it too.
Both standards also explicitly define that objects (at least of POD types) have byte representations and those representations are implementation-defined (as opposed to triggering undefined behavior if you depend on them). For C:
> Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined.
https://port70.net/~nsz/c/c11/n1570.html#6.2.6.1
C++:
http://eel.is/c++draft/basic.types
Yes, you can. The behavior is implementation-defined but not undefined. (Well, it can trigger undefined behavior if the value corresponds to a signaling NaN, or if the implementation uses a nonstandard, non-IEEE format for doubles that has other "trap representations". But it's not otherwise undefined.)
The basis for this is that the aliasing rule has an explicit exception for reading or writing to objects using char pointers, i.e. byte-by-byte, regardless of the object's type. This exception is in both the C standard:
https://port70.net/~nsz/c/c11/n1570.html#6.5p7
and the C++ standard:
http://eel.is/c++draft/expr.prop#basic.lval-11.8
The memcpy function is defined as copying characters, so the exception applies to it too.
Both standards also explicitly define that objects (at least of POD types) have byte representations and those representations are implementation-defined (as opposed to triggering undefined behavior if you depend on them). For C:
> Except for bit-fields, objects are composed of contiguous sequences of one or more bytes, the number, order, and encoding of which are either explicitly specified or implementation-defined.
https://port70.net/~nsz/c/c11/n1570.html#6.2.6.1
C++:
http://eel.is/c++draft/basic.types
"access" refers to reading there. Not reading or writing. Objects may be treated as arrays of character type to the extent that their value may be examined that way.
If you memcpy a uint64_t to a double, the implementation is not required to notice that the double variable's value has changed; a subsequent access to that variable can continue to refer to a register. It's not a matter of what bit pattern was stored there.
If you memcpy a uint64_t to a double, the implementation is not required to notice that the double variable's value has changed; a subsequent access to that variable can continue to refer to a register. It's not a matter of what bit pattern was stored there.
No, "access" is defined as reading or writing:
> 3.1 > 1 access >〈execution-time action〉 to read or modify the value of an object
Thus, the requirement is symmetrical. The compiler must consider any char write as potentially aliasing a subsequent read (or write) of any type, unless it can prove non-aliasing without depending on type. And similarly, it must consider a write of any type as potentially aliasing a subsequent char read/write.
> 3.1 > 1 access >〈execution-time action〉 to read or modify the value of an object
Thus, the requirement is symmetrical. The compiler must consider any char write as potentially aliasing a subsequent read (or write) of any type, unless it can prove non-aliasing without depending on type. And similarly, it must consider a write of any type as potentially aliasing a subsequent char read/write.
What is reinterpret_cast for, if not type punning?
Unadjusted conversion between pointer types that have matching cv qualifiers.
Pointers are converted in order that they be used. Though the uses may be undefined, there is value in the conversion having a well-defined syntax. In effect, C and C++ allow certain intents to be expressed in a common way, without requiring implementations to make those intents work. This is better than having compiler-specific syntax for that sort of thing.
You can't cast a short ptr to an int ptr safely even ignoring aliasing rules. What bites you is that ints have different alignment than shorts (2 vs 4), so while this works on e.g. x86 almost always [1], your code won't always work on machines that can't do unaligned int reads.
There are a lot of sharp edges to C/++ and the community really is hurting for a good static analyzer that can at least save you from most of them.
[1] almost always, because while a simple unaligned mov is safe, if the compiler unrolls and vectorises your loop, it is free to then use aligned sse read instructions, assuming that your int ptr is aligned, because pointers must be aligned according to their type. Then your program crashes, but only in optimised builds.
There are a lot of sharp edges to C/++ and the community really is hurting for a good static analyzer that can at least save you from most of them.
[1] almost always, because while a simple unaligned mov is safe, if the compiler unrolls and vectorises your loop, it is free to then use aligned sse read instructions, assuming that your int ptr is aligned, because pointers must be aligned according to their type. Then your program crashes, but only in optimised builds.
> I find it ironic in that C++ has the correct solution to this problem. If you need type-pruning, use reinterpret_cast<foo>(bar). Done and done.
If you need type-punning, use a union. Done and done.
You're just making an appeal to authority here and deciding that The C++ Standards Committee (who give us one official way to do this) is a better authority than The GCC Authors (who give us another).
And that's shortsighted and silly, because GCC (being working software) is if anything a more reliable and more accessible authority than any spec-writer will ever be. That's exactly the point Linus was making, albeit with more profanity.
If you need type-punning, use a union. Done and done.
You're just making an appeal to authority here and deciding that The C++ Standards Committee (who give us one official way to do this) is a better authority than The GCC Authors (who give us another).
And that's shortsighted and silly, because GCC (being working software) is if anything a more reliable and more accessible authority than any spec-writer will ever be. That's exactly the point Linus was making, albeit with more profanity.
> And that's shortsighted and silly, because GCC (being working software) is if anything a more reliable and more accessible authority than any spec-writer will ever be.
Well, until you decide to use CLang, ICC, or Visual Studio or something out there. The reason why people follow the standards is because they want their code to correctly work on more than just one compiler.
Well, until you decide to use CLang, ICC, or Visual Studio or something out there. The reason why people follow the standards is because they want their code to correctly work on more than just one compiler.
No, that's exactly backwards. In fact ICC and Clang (I have no idea about VS) both follow GCC on this particular feature, largely because important software like Linux relies on GCC's useful and practical feature set. See also support for GCC's struct initializer syntax, statement expressions, inline assembly constraint system, etc... GCC invented all this stuff, and software developers everywhere (Hi!) love them and use them, and the industry follows suit.
Fundamentally you're still missing the point. Standards are important. Features are more important. The best standards are ones driven by features and not paper. GCC has been a far better, more innovative, and more practical driver of "standards" than any committee.
Fundamentally you're still missing the point. Standards are important. Features are more important. The best standards are ones driven by features and not paper. GCC has been a far better, more innovative, and more practical driver of "standards" than any committee.
Or even better in this particular case, using std::variant to provide type-safe unions.
Linus has long railed against the aspects of the C standard, and how they're been interpreted by compiler writers [0].
I'm not much of a C programmer, but the C aliasing rules are incredibly confusing, and seem to be interpreted differently by GCC and Clang. e.g. GCC allows type punning via unions[1], but Clang does not [2].
[0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...
[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Typ...
[2] https://bugs.llvm.org/show_bug.cgi?id=31928
I'm not much of a C programmer, but the C aliasing rules are incredibly confusing, and seem to be interpreted differently by GCC and Clang. e.g. GCC allows type punning via unions[1], but Clang does not [2].
[0] https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-p...
[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Typ...
[2] https://bugs.llvm.org/show_bug.cgi?id=31928
That was just a clang bug, and as I read the comments they fixed it quietly without exactly admitting as much. That kind of local bitsmithery on floating point values is a pervasive idiom, clearly explained by the syntax of the language, and the compiler had no business getting smart with it.
union and memcpy are known ways to do type-punning. Caveat to these is that they require at least one memory copy operation. Last I heard, clang and llvm's TBAA is still buggy.
So much swearing to make three points:
1. What's in practice conflicts with what the standard prescribes
2. The reason it conflicts is because the standard is misguided and everyone knows that; for reliable code-generation you have to take the approach in the kernel
3. He disagrees with the rationale for the change, and wants a better reason for it
1. What's in practice conflicts with what the standard prescribes
2. The reason it conflicts is because the standard is misguided and everyone knows that; for reliable code-generation you have to take the approach in the kernel
3. He disagrees with the rationale for the change, and wants a better reason for it
I would add
4. As a general rule, appealing to a standard isn't a sufficient rationale for making a change.
(I think most of the swearing was about that)
(I think most of the swearing was about that)
I guess you're right that Linus was saying that -- after all, he considers the standard to be less important than toilet paper.
Regardless, if standards should be questioned, then surely Linus also should be questioned. I think a better rule would be: Appealing to the standard is sufficient reason for a change, unless a good argument can be made that the standard is BS.
Regardless, if standards should be questioned, then surely Linus also should be questioned. I think a better rule would be: Appealing to the standard is sufficient reason for a change, unless a good argument can be made that the standard is BS.
yeah but strict type aliasing bro...
> So much swearing to make three points:
By my count there is one f*cking, one bullshit, one shit and one arse, hardly "so much swearing". I think anyone complaining about that is way to sensitive.
By my count there is one f*cking, one bullshit, one shit and one arse, hardly "so much swearing". I think anyone complaining about that is way to sensitive.
"So much swearing..."
Yes, yes, that's Linus. Most of us have learned to get past that.
Yes, yes, that's Linus. Most of us have learned to get past that.
Some of us find it reassuring someone cares enough to go on hyperbolic comedic rants from time to time. I know I enjoy seeing the moon pretty much every day, it's reassuring, even if it's made of cheese.
I think people misunderstood my comment. I'm very pro-Linus swearing, inasmuch as he just is who he is and people shaming him for swearing are yelling at clouds.
> Most of us have learned to get past that.
Have we really? The post is over 100+ points right now. People seem to LIKE this swearing thing Linus does.
I don't think its healthy for the general programming community. The tone that was written here is certainly not acceptable behavior on YCombinator in general. But we put up with Linus because... well... Linus is an elevated programmer and we all respect him. For better or for worse.
Have we really? The post is over 100+ points right now. People seem to LIKE this swearing thing Linus does.
I don't think its healthy for the general programming community. The tone that was written here is certainly not acceptable behavior on YCombinator in general. But we put up with Linus because... well... Linus is an elevated programmer and we all respect him. For better or for worse.
I think it gets points because Linus' Rants are usually good breeding ground for some discussion on various things.
Also don't forget to contrast the occasional (about ~1/month) rant with the thousands of emails where he's level headed and polite.
Also don't forget to contrast the occasional (about ~1/month) rant with the thousands of emails where he's level headed and polite.
Pretty much. You don't get one without the other. So it is what it is.
I would consider Linus one of those people who knows what the fuck he's talking about. Respect.
Nobody doubts he knows what he is talking about. The question is whether he’s making his points effectively (no).
Can you prove swearing is ineffective? (Fuck no.)
[deleted]
Strict aliasing shouldn't have been set as the default [1]. It was a huge mistake that instantly broke maybe all C programs everywhere. The standard also provided no guidance on how to work around the problem. `memcpy` is insufficient because it's a copy and that's a huge performance issue. Swapping through unions is UB. Casting about through `void * ` and `char * ` is gross, dangerous, and often runs afoul of alignment problems. It's a mess, and it has been for 20 years. Linus is right to be pissed.
[1]: https://blog.regehr.org/archives/1307
[1]: https://blog.regehr.org/archives/1307
> `memcpy` is insufficient because it's a copy and that's a huge performance issue.
Compilers (at least clang and gcc) are smart enough to see through those memcpy's. For example:
https://godbolt.org/g/5L5PT5
Compilers (at least clang and gcc) are smart enough to see through those memcpy's. For example:
https://godbolt.org/g/5L5PT5
Maybe, but wouldn't you rather be explicit so you know the compiler will do what you want instead of crossing your fingers and hoping it does?
> Compilers (at least clang and gcc) are smart enough to see through those memcpy's
That's worse though because compiler optimization are wholly unreliable. Maybe today, maybe not tomorrow. And you have utterly no control over that.
That's worse though because compiler optimization are wholly unreliable. Maybe today, maybe not tomorrow. And you have utterly no control over that.
For stack allocated scalars sure. What about stuff on the heap or arrays and structs?
Generally speaking, if a memcpy's size argument is a constant expression equal to the size of a native integer type, it will be transformed to a native load from the source pointer followed by a store to the destination pointer. After that, the load or store operation (or both) may itself be optimized away if the pointer points to a local variable. Thus, for example, given something like:
void write32(int *ptr, int val) {
memcpy(ptr, &val, 4);
}
write32:
mov DWORD PTR [rdi], esi
ret
> Casting about through `void ` and `char * ` is gross, dangerous, and often runs afoul of alignment problems.*
This just highlights why strict aliasing rules exists. Because the exact same alignment problems is what you get when you type pun. Looking at the raw data as a char* or memcpy'ing it just makes it more visible that what you are doing is wrong.
The only valid reason to do type punning is to serialize data and then deserialize it back to exactly the same type. And since type puning with char* is defined as ok so there is no problem. I am having a really hard time seeing other valid reasons to do type punning and have never ever had to use it myself.
Seriously, why are people upset over strict aliasing? What is the valid use case for type punning that people are missing?
This just highlights why strict aliasing rules exists. Because the exact same alignment problems is what you get when you type pun. Looking at the raw data as a char* or memcpy'ing it just makes it more visible that what you are doing is wrong.
The only valid reason to do type punning is to serialize data and then deserialize it back to exactly the same type. And since type puning with char* is defined as ok so there is no problem. I am having a really hard time seeing other valid reasons to do type punning and have never ever had to use it myself.
Seriously, why are people upset over strict aliasing? What is the valid use case for type punning that people are missing?
Mostly you run into problems either using the "inheritance" pattern, or with discriminated unions. These are pretty common in C. There really is no alternative to inheritance because if you don't type pun you end up needing to copy a lot (or you can pass around pointers to internal members but it's really easy to lose track of memory that way). And there's also not really an alternative for discriminated unions; the functionality is pretty unique. You can pull the polymorphism out of the type up to the top of your control flow, but that severely degrades your locality. In other words, at some point you have different batches of functions for each "type", but you don't realize that's what they are until you trace the call graph all the way up. Of course, sometimes that's preferable to avoid branching, but at least w/ discriminated unions you get the option.
1. Discriminated unions don't have any issues with strict aliasing, you are allowed to read a union member as long as it was the last union member being written to, and the tag-member helps you identify that.
2. If you are trying to retrofit polymorphism in C maybe you are using the wrong tool for the job.
3. If you really want polymorphism you can create baseclass-struct with a void* this pointer and a bunch of function pointers as instance-functions. To "override" the struct you just instantiate it with different function pointers. If you want to inherit an existing struct you add a void* super-member into your this-data and instantiate it explicitly. For any function you don't want to override you use just call the existing function function and pass in you super-data as this.
This is also safe as each subclass implementation only casts the void* this into itself which is a known struct of the same type as was last written to. You do have to split the data and keep super-class data in another struct one pointer-hop away but that shouldn't be a big issue.
2. If you are trying to retrofit polymorphism in C maybe you are using the wrong tool for the job.
3. If you really want polymorphism you can create baseclass-struct with a void* this pointer and a bunch of function pointers as instance-functions. To "override" the struct you just instantiate it with different function pointers. If you want to inherit an existing struct you add a void* super-member into your this-data and instantiate it explicitly. For any function you don't want to override you use just call the existing function function and pass in you super-data as this.
This is also safe as each subclass implementation only casts the void* this into itself which is a known struct of the same type as was last written to. You do have to split the data and keep super-class data in another struct one pointer-hop away but that shouldn't be a big issue.
> Swapping through unions is UB
Writing to union member and reading back as another member should be okay. But it does incur copy.
Writing to union member and reading back as another member should be okay. But it does incur copy.
Reading from a union field other than the one last written to is explicitly UB. I wish this worked too, but it doesn't (compiler-specific guarantees aside).
It's actually well-defined in the C standard (although the format of the byte representation is implementation-defined), but undefined behavior in the C++ standard:
https://stackoverflow.com/a/11996970
Since Linux is C, not C++, it should be fine; the author of the patch is just mistaken.
(Note that in practice, this will work in C++ too, since most compilers support both C and C++ and don't change their optimization behavior based on which mode the code was compiled in; but of course there's no guarantee this won't change in the future.)
https://stackoverflow.com/a/11996970
Since Linux is C, not C++, it should be fine; the author of the patch is just mistaken.
(Note that in practice, this will work in C++ too, since most compilers support both C and C++ and don't change their optimization behavior based on which mode the code was compiled in; but of course there's no guarantee this won't change in the future.)
Not all compilers handle it like you'd expect, and it looks like that's because it's actually unspecified in the standard [1].
But furthermore, this will really only work for scalars. Plus you have to go and declare a whole new type to cast things safely. It's extremely awkward.
[1]: https://blog.regehr.org/archives/959
But furthermore, this will really only work for scalars. Plus you have to go and declare a whole new type to cast things safely. It's extremely awkward.
[1]: https://blog.regehr.org/archives/959
memcpy(&int, &float) probably turns into the same register move as a cast. Check with your compiler.
Yeah that's ok, but I don't know about arrays, or the "inheritance" pattern:
(also hey Ted I'm a huge fan of your work, thanks in particular for threading, holy shit)
struct Person {
char *name;
unsigned char age;
}
struct Teacher {
struct Person person;
char *subject;
}
(also hey Ted I'm a huge fan of your work, thanks in particular for threading, holy shit)
I read the comments here before I read the post and was honestly expecting a full out swear fest. Instead, I read linus being passionately expressive about something he clearly has strong opinions about... With a few swear words and over exaggerated metaphors thrown in.
I'm not saying that the language is not not-nice but it's not like he was being a bully or arsehole to someone in particular nor was he being over the top abusive. The delivery shouldn't be the take away here.
I'm not saying that the language is not not-nice but it's not like he was being a bully or arsehole to someone in particular nor was he being over the top abusive. The delivery shouldn't be the take away here.
Reading it fully and it seems to line up with Torvalds attitudes towards things like userspace facing API stability.
Standards are standards, reality is reality, and when the two conflict the only way to maintain long term sanity is for the standard to be amended to fit reality.
The alternative is seen up and down userspace, where we have piles upon piles of workarounds, and whatsnot, to deal with APIs that change and break between releases because someone suddenly decided to re-read a standard spec like the devil reads the bible.
Standards are standards, reality is reality, and when the two conflict the only way to maintain long term sanity is for the standard to be amended to fit reality.
The alternative is seen up and down userspace, where we have piles upon piles of workarounds, and whatsnot, to deal with APIs that change and break between releases because someone suddenly decided to re-read a standard spec like the devil reads the bible.
And he committed the patch anyway...
https://lkml.org/lkml/2018/6/5/774
https://lkml.org/lkml/2018/6/5/774
It's a reasonable response, imho. The community wants to go in a given direction based on directed guidance, a standard. The community that follows the standard blindly lacks the intellectual tools to question the standard. The community needs the standard at the present moment but also needs directed guidance to be able to learn how to question the standard. It doesn't seem like hypocrisy to me, it just seems like he's annoyed at the general problem, aware that an individual mind does not have the capacity to solve the problem alone, aware that a collaborative effort is needed, and otherwise, venting, because problems like these are honestly, incredibly frustrating, especially when computers basically have to all be able to 'think' in ways that are more or less, equivalent, yet, humans don't think perfectly identically.
> The community that follows the standard blindly lacks the intellectual tools to question the standard.
Yeah Linus is the sole person who has some "intellectual tools" in a community of thousands of people.
Yeah Linus is the sole person who has some "intellectual tools" in a community of thousands of people.
That's not what I said.
This is actually something I like about Linus, and one of the reasons I think the Linux kernel has been so successful: he merges stuff even when he doesn't personally agree with it or see the value in it. He has rejected plenty of stuff that would introduce problems, but despite the outwardly harsh attitude he works to try and make things acceptable so they can be merged.
Every time I've gotten sucked into these <cough> notable LKML messages from Linus I'm not taken aback in the least.
To my ear, his language comes across as that of a drill sergeant: intentionally loud, pejorative, and foul for reasons of effectiveness, in addition to reinforcing the hierarchy he sits atop (as do the tirades of any prototypical drill sergeant).
My 0,02$.
NB: my parent cussed like a sailor, certainly influencing my PoV.
To my ear, his language comes across as that of a drill sergeant: intentionally loud, pejorative, and foul for reasons of effectiveness, in addition to reinforcing the hierarchy he sits atop (as do the tirades of any prototypical drill sergeant).
My 0,02$.
NB: my parent cussed like a sailor, certainly influencing my PoV.
Commit in question: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux...
Is there any part of the standards process that is geared to the needs of the users of the compiler? Or is it all determined by the compiler writers themselves? I'm wondering why this kind of push back is necessary.
The people on the standards committee, at least for C++, tend to be heavy users of the language.
My theory is there ware two kinds of programs.
Type one: where all the side effects are hidden behind an OS call.
Type two: Where side effects are primary and unavoidable.
People on the standards committee universally write type one code (compilers and the like). Where the Linux kernel is type two.
Type one: where all the side effects are hidden behind an OS call.
Type two: Where side effects are primary and unavoidable.
People on the standards committee universally write type one code (compilers and the like). Where the Linux kernel is type two.
I can't imagine what it's like to be in Linus' position. After all these years he still hasn't found Linux's own Junio Hamano to turn over maintainer-ship to.
I wonder if there's a way to put all this engineering thought into reducing/simplifying standards and optimizing compilers so that individuals don't need a Linus-level knowledge.
In my opinion, the knowledge-cost of a system is a major downside that is often ignored (probably the biggest downside of unix, vi, git).
In my opinion, the knowledge-cost of a system is a major downside that is often ignored (probably the biggest downside of unix, vi, git).
[deleted]
Honestly, I read a few sentences, began stumbling over the expletives, then decided I didn't care what the issue was or what his opinion is. Though he acts like everything that isn't done precisely as he would have done it in hindsight is "utter garbage", there are probably all kinds of historical
and logistical reasons that things were done a certain way and that doesn't make the people involved "f*cking morons." And, to save everyone the trouble, the usual refrain of "he's actually right" is meaningless to me.
Well the guy is just full of himself, and the community around him continues on to fill him up with himself every day. On other news *BSDs are mature, nice OSes with nicer communities around them (even De Raadt is better than Linus). Unfortunately I don't have time to try FreeBSD again to see if I can get suspend/resume working. But if I used a desktop I wouldn't think one bit and go with it.
>Unfortunately I don't have time to try FreeBSD again to see if I can get suspend/resume working. But if I used a desktop I wouldn't think one bit and go with it.
Suspend and Resume mostly work for me with the new drm-next-kmod drivers on an XPS-13 running FreeBSD current, it's just a little slow sometimes[1].
[1]: https://www.freshports.org/graphics/drm-next-kmod
Suspend and Resume mostly work for me with the new drm-next-kmod drivers on an XPS-13 running FreeBSD current, it's just a little slow sometimes[1].
[1]: https://www.freshports.org/graphics/drm-next-kmod
Thanks, made note of this!
Give him a break, megacorps are making billions on top of his software, and he's not.
I'd be swearing all day as well! ;-)
I'd be swearing all day as well! ;-)
Roasting other developers for getting it wrong is so much worse than just saying "the standard doesn't apply here. Try this instead"
He is so full of it. It wouldn't hurt to say it nicely in 3 sentences.
I would rather that he made a standard wherein he specifies how he thinks the language should behave, and then followed that standard slavishly. One must follow _some_ standard slavishly!
there is nothing new here.
At this point, his flailing supposed anger is really just schtick. He deploys it so casually you just assume it isn't serious. Ironically, he could convey his contempt for standards, or for people who adhere to them slavishly, far more effectively if he simply wrote in a civil tone, rather than continuing to try to affect his Andrew Dice Clay of Programming persona.