Linus Torvalds on aliasing
yodaiken.com
yodaiken.com
He also does no service to his own arguments by peppering them with childish swearing because things like "So standards are not some kind of holy book that has to be revered. Standards too need to be questioned." can't be said enough to some people in the industry.
If his reply were written with more tact and less swearing it would be a lot more powerful. We as an industry should demand this of each other, but also of our 'celebrity' colleagues.
As a northern European I find it not only comfortable that Linus runs Linux, but I would be less comfortable if it was another American smile in face pretend to be your friend but be shady as fuck attitude that you guys seem to confuse for 'professionalism'.
So let's chalk this to cultural differences. We wouldn't hire someone like you and you wouldn't hire someone like him.
I never said that Linus should be fake friendly. I am saying that swearing does damage to moral and the power of his arguments.
Also, Steve Jobs was a notorious asshole and he is revered in the US despite this. There are countless other examples of CEOs and managers who are more than unfriendly in the US who are looked at as examples of how one should behave to be 'professional'.
Your being 'northern European' has nothing to do with any of what we are talking about. Maybe you can chalk your reaction to your apparent false sense of superiority over friendliness and, it seems, Americans.
Tact can be very usefull in small teams where trust and coordination is important.
For large projects, with thousands of stake holders the bar to participate in a conversation should be high.
As we both say in Holland: we are not made of sugar. But go read Linus rant now and ask yourself: would this really classify as an inappropriate rant in Holland? Or are you just, parroting the default (mostly from the US) critique on Linus?
Because this whole 'Linus isn't tactfull' is a false comparision. He is more approachable than any other person in that sort of position. Since there isn't a big filter at the door based on who somebody is but there is a verbal filter at the table. Very egalitarian if you ask me. Very Dutch like.
And our directness is often referred to as rude. It would look better on you to not blindly follow in that judgement when it concerns others.
For example: >Maybe you can chalk your reaction to your apparent false sense of superiority over friendliness and, it seems, Americans
If out of the mouth of Linus would be one of those 'look at how insensitive Linus is' posts. Something with the pot and the kettle.
In fact, here's an edit which gets his point over in less words, and more clearly:
"Honestly, this looks questionable to me. [U]sing a union to do type punning is the traditional AND STANDARD way to do type punning in gcc. In fact, it is the documented way to do it for gcc. The fact is that gcc documents type punning through unions as the "right way". You may disagree with that, but using the [C] standard to push it - the same standard that came up with the completely mis-guided aliasing rules - is not a valid argument. his is why we use -fwrapv, -fno-strict-aliasing etc. The standard simply is not important, when it is in direct conflict with reality and reliable code generation.
So what's the _real_ reason for avoiding union aliasing?"
No swearing, no abuse, all points covered, less typing required. No talk of splinters.
The chances that you get to hear things from the source and never hear things in a way you don't like is almost zero. You have to make a decision.
"...when you are a f*cking moron" "Andy, what is the background for trying to push this idiocy?"
Note that I only called the other swearing in his text childish and not damaging to morale. Also note that in verbal discussions I wouldn't myself shy away from swearing or graphic metaphors. I just think that when replying to pull-requests there should be some emotional self-control... something which children have less of.
> Something with the pot and the kettle.
As I said, confronting people isn't on some list of don'ts that I keep and replying to comments filled with false assumptions and accusations is not the same as replying to a pull-request.
>would this really classify as an inappropriate rant in Holland?
If I were to call my colleagues fucking morons and call their contributions idiocies I would probably at least receive some negative feedback from my boss. So yes. I find it hard to believe that calling people 'fucking morons' is an accepted practice at your job.
> And our directness is often referred to as rude. It would look better on you to not blindly follow in that judgement when it concerns others.
But blindly following some judgement of Americans being two-faced liars does look good on you? Something with pots and kettles?
When I play games like Rocket League, a game where you depend on your teammates, I rarely say anything if people play badly. Others will say things to me if I play badly and that sometimes makes me play even worse depending on my mood. Sometimes I play worse because they actually made me care less and sometimes I play worse on purpose because they were a real asshole and they deserve a loss.
It's pretty obvious that antagonizing and disparaging your teammates is generally a bad plan anywhere.
My feeling is that people who need to be abusive of others are compensating some of their feelings about themselves. I think everybody does this though, I am no angel myself either. I just thought that people who are highly visible and in some way represent our industry, like Linus, should not be praised for being 'bad ass' when they are needlessly rude to people who are contributing. On a whole though, anyone can do what they want, and I can form an opinion based on what people do of course ;)
Yes, haha, Rocket League teammates sometimes don't excel at being good sports.
This is a false dichotomy.
Most of what Linus says would run foul of HN's guidelines - which I'll paraphrase here as "don't call someone an asshole before making your real point", but that doesn't mean that everyone on HN is a 'smile in face pretend to be your friend but be shady as fuck'.
Keep in mind that you're much more likely to see it when he explodes at someone, because that's more entertaining to read. Most of what he writes in the ordinary work of building a kernel is unobjectionable.
I doubt there is difference between about how often people resent other people around the world. But I do consider it more humane if resentment isn't hidden under the surface. It's easier to trust Linus than a tactfull politician. That should make us all think.
I can kinda see where you're going with this, ie. the idea that knowing what someone is thinking means you can trust them... but I disagree.
To my mind verbal abuse doesn't mean they're speaking their mind, it means they've lost control.
Based on these blow-ups I'd certainly question trusting Torvalds in any high stakes situation that required tact under pressure... which I would expect to happen frequently when running a country.
Huh? When are kernel developers in high stakes situations that require tact? He doesn't host peace talks for a living. He manages Linux. He needs to be trusted for high stakes situations requiring technical clarity and technical decision making. And between our phones, our internet services and our banking infrastructure, basically everybody in modern society depends on the linux kernel working correctly.
> To my mind verbal abuse doesn't mean they're speaking their mind, it means they've lost control.
What? I just don't see it that way at all. If he'd lost control the criticism would be less technically grounded, and he wouldn't have merged the patch anyway. To me, Torvald's temper clearly expresses the value of "make the kernel good, don't make it be bad". Blowing up like this is an expensive social signal - it shows that to him the kernel being good is so important that he's willing to risk losing face and support to do so. I agree with other commenters that there are probably better ways he could get his point across; but how he expresses himself is completely authentic and aligned with his value of technical competence.
And that buys a lot of trust in my eyes.
And I don't think its just me. Trump does the same thing, and I suspect the "I can trust him because he gets angry" vibe helped him get elected. (For better or worse.)
Parent commenter made a comparison between Torvalds and politicians. I was exploring that comparison.
> If he'd lost control the criticism would be less technically grounded, and he wouldn't have merged the patch anyway.
Losing control in one way doesn't mean losing control in all ways. Saying someone has "lost control" doesn't automatically mean that they've shat themselves, for example.
I mention this here because kristianic made the valid point that you have set up a false dichotomy, and you replied with a statement that keeps it going. Is the habit of not paying attention to the actual issues also part of your superior Northern European culture, and, in fact, is it perhaps a reason why insults are apparently such an important part of it?
That being said, I feel that if I were in a managerial position here in the Bay Area I would probably adopt a smile and softer language because that's what people are used to. The challenge is being genuine while putting people at ease so that they can do their best work.
"Why did you cook this? Are you fucking stupid?"
I'm in the military, and if you can't control what you say, you shouldn't be respected.
In the military with all the hierarchy this wouldn't happen because no small private would be arrogant enough to throw their opinion in the top generals and president face without being asked.
The whole point of the rudeness is that it does give space for people to voice their opinion irregardless of their rank. Only at the risk of being somewhat insulted.
I don't care that Linus swears, he hasn't invaded anyone or harmed anyone as far as I know. I don't care that Trump swears, I care about the stupid stuff he actually does.
Linus may swear, but he also protects us from bad code and I value that, because in the end, words don't do anything, actions do.
Rather, I'm saying that EVEN in the military, with some of the most insensitive people around, swearing indicates lack of self-control and situational awareness.
I once saw a doc about the alarming levels of rape in the U.S. military. Some of these guys were pretty high rank, so I guess they fooled everyone that they possessed self-control, (perhaps they didn't swear), but in reality they clearly lacked self-control. I only bring up this example to explain my point, I know there are many officers who don't swear and don't lack self-control, but my point is that the lack of swearing doesn't really prove anything, nor does the presence of swearing.
Obviously swearing is a big thing, but not when leading. You'll have exceptions with some of the line units of course, but that's a culture that won't change.
If I saw one of my squad leaders cursing at someone for doing something dumb, then I'd know that supposed leader just failed that Soldier. At ease those emotions, get your point across, and hold them accountable. If you can't do that without throwing a hissy fit, take off those stripes.
Yes, there are cultural differences between the US and Europe.
No, that doesn't mean that Europe agrees with your opinion on what constitutes acceptable behaviour in the software community. You do not speak for us.
It's quite refreshing, even.
I'm sure the difference is due to lattitude. A little bit of getting heated is ill advised in the scorching sun.
I'm just asking this to see if this culture is one way or goes both ways...
The honest reaction to any post like this is to just report it because the only entertainment factor is the drama.
That won't tell you anything about LKML culture, either.
If you want a better sense of lkml than social media hot takes can deliver, go lurk it for a month.
He never needed any protection; Linus always wrote like this. Back in the argument with Tanenbaum in '92, when he was a nobody, he already wrote stuff like "your job is being a professor and researcher: That's one hell of a good excuse for some of the brain-damages of minix. I can only hope (and assume) that Amoeba doesn't suck like minix does."
https://mobile.linuxtoday.com/security/minix-the-most-popula...
His idea is that he wants to make his feelings as clear as possible. He mentioned a case where some guy attempted suicide after working months on a kernel patch that he rejected. He blames himself for not being clear enough about what he felt about the idea before work has started.
When you say "People put time and energy in making software better, at least in their own eyes, for others and then they get textually abused". That's actually the whole point. Linus doesn't want you to put time and energy in what he perceives as a lost cause.
Not saying that what he does is good or bad, just saying what I think his rationale for using harsh language is.
I don't know if that's good or not, but it's not just in software that harsh words are used. And their stridency makes clear that this is an exceptionally significant point. I imagine that Linus's many more blandly worded emails don't result in this level of attention, so you wouldn't even be aware of his points there.
In this case, Torvalds is swearing at someone who agrees with him (see Andy Shevchenko's response) because he hasn't bothered to seek clarification before calling it "pure and utter garbage".
Yeah, there were few reasons why I decide to make that patch (OK, it seems I staked on not the best reason).I don't want to assume too much about your wife's job or personality, but I'd also assume she would swear in a way that was reciprocal with those under therapy, based on a communication style they had established together... as opposed to her swearing at them while they were being perfectly polite.
It'd certainly make a good sitcom.
"we're fucked" <-- feared consequence
"You are fucking us up!" <-- your actions are harming the group.
Not "you are a fuck" and no shunning from the group.
I don't care for the tone, and all the dark patterns could be there too in the meeting, but your single quote on its own is not evidence of dysfunction.
You shouldn't sell yourself short. Changing the way you communicate is a huge but worthwhile challenge.
In a different time, I would have been mean to you over your comment instead of offering supportive words. It took as much effort to be nice as it used to take to be mean.
'Hey, great that you took the time to contribute, here are a few suggestions though.'
I am talking about things like: 'If you think xyz, then you are a fucking moron'.
The constructive part, not destructive, is in the alternatives proposed. So, plus minus zero in my mind, the emotional aspect is just a grab for attention, and ...
Sometimes people forget that C was created for writing operating systems. They get in their mind that C is all about high-performance, and that making it competitive with FORTRAN is the way to go. I understand that, but it's not what C was created for. If the world's most famous C programmer and OS guru wants to have strong opinions on the direction of the language, I say allow it.
That doesn't properly justify C's minefield around aliasing and type punning in general. It's UB galore. Thing is, whenever you're writing low level code that's tied to hardware in my experience you very often end up having to pun your types to match hardware constraints, and at this point the C standard basically says "lol good luck with that bro".
I'm not a programming language expert but IMO at the very least C should make reading from a different union member than was last written to "implementation defined" instead of UB (with suitable constraints if the sizes of the members differ I suppose). In effect that's mostly how compilers deal with that anyway.
So I agree with Linus that the C standard is really unhelpful in these situation, although his childish anger is unnecessary and counter-productive.
"If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning")."
The whole world needs betrization soonest ( https://en.wikipedia.org/wiki/Return_from_the_Stars )
That's how it is :) The standard even describes union behavior as "type punning".
I don't know if C++ allows it though.
union { int i; float f; } u;
You can't safely call a function with pointers to the members like func(&u.i, &u.f), because when func was compiled, the compiler couldn't know that the arguments are pointers to union members.
This sort of thing scares me, because what the compiler can "see" isn't well defined. Is it ok if func is in the same file? Probably not. How about if I don't send the pointers to an other function and just use them locally? Probably ok, but I wouldn't trust it. If you want to type pun with a union, make sure to always access the members through the union, not with direct pointers.
The only method of type punning I 100% trust is memcpy, and if you get lucky the compiler might optimize away the overhead for you.
If your func(&u.i &u.f) example fails it may be because the standard is picky about pointers of different types to the same memory. I have no idea whether it is, because I've never had to do anything like your example.
float func(int *i, float *f) {
*i = 42;
return *f;
}
float func(int *i, float *f) {
float result = *f;
*i = 42;
return result;
}
If the C standard says: the following construct is undefined, then as a compiler writer you have two options: you try to figure out what is sensible in this context, or you do something crazy that conforms to a literal interpretation.
For operating system code, you want the compiler to something sensible. Life is already hard enough. In just about all cases where the C standard introduces undefined behaviour, there is an obvious interpretation that makes sense to most C programmers.
If you want to get the highest possible score in a benchmark, you write a compiler that drops code left and right if you can prove that the code invoked undefined behaviour.
Unfortunately, compiler writers, in particular the maintainers of gcc, seem to care more about this ratrace than to write a good compiler for compiling operating system code.
Not exactly. Rather, the compiler is not constrained by any particular behavior of the construct which is said to be undefined. So if there is an optimization that changes the meaning of the undefined construct, it's all fair game, because the construct was not defined in the first place.
That's only useful if you only care about the total run time of the program and not about what it is trying to achieve.
I think it'd be helpful to be able to talk about this behaviour without needing to suger-coat it as "opinions".
There are far less damaging ways to say exactly the same things as Tovalds says, and someone with his position in the community should know better.
Punch up if you like, not down.
[1] It's an open secret that most of the optimizations introduced in the last ten years provide no real benefit while making programs harder to reason about and trust. While at the same time the gcc backend is a trashfire. Hint, Microsoft's VC compiler produces better assembly code without any of these 'optimizations'
I don't see why it would need to be negative emotion sourced from another area of his life that is leaking out here.
You presumably have to be pretty emotionally invested in something to work on it that long as a hobby and only later as a job.
There's nothing wrong with this - it's an important enough project to be able to make those kinds of demands.
[1] https://lkml.org/lkml/2018/2/14/724 [2] https://lkml.org/lkml/2018/2/14/157
Nested functions is exactly how you would write it in assembly.
Does anyone know why clang won't support them? "Blocks" are fucking stupid.
http://lists.llvm.org/pipermail/cfe-dev/2015-September/04503...
GCC doesn't use a trampoline for the following code:
long f1 (void) { long i = 0; void f2(void) { i++; } f2(); return i; }
int main() { return f1(); }
But to edify on my "Blocks" are fucking stupid throwaway, in clang you can do this:
long f1 (void) { __block long i = 0; void (^f2)(void) = ^{ i++; }; f2(); return i; }
int main() { return f1(); }
Surely clang could simply disallow passing the address of the nested function, if it's trying to protect people from themselves?
If Linus would habitually curse in the kernel list, it would have no emphasis effect and it would be a really bad style. Linus using cursing in a rant equals [for wider distribution] and it works perfectly. I can't remember a single discussion linked to HN that didn't start from cursing. It provided the opportunity for people to be offended. For technical people it's a challenge (like a glove slap).
Example:
* his opinion about hardening: https://lkml.org/lkml/2017/11/21/356
* previous message that collected the attention: "Those security people are f*cking morons." https://lkml.org/lkml/2017/11/17/767
this was the whole point of the rant.
He already writes that he's OK with the code ("can live with it") -- he's against the reasoning that accompanies it.
This is for history. If someone, later, say: "We should use union aliasing to fix this", someone would argue "No, we shouldn't because we already states _there_ that union aliasing is bad".
You can't consider a such amount of code like the kernel one without its commit history.
Here Linus explain why union aliasing is not "bad" per see, but considered "bad" because the C standard say so and he clearly explain standards are not holy book and compiler implementation is as important (something he always states).
Several, but no one that mattered enough with respect to Linux for his opinion to matter in return.
His OS, his rules. Others can always fork it if they have an issue with that.
It seems to have worked fine as a gatekeeping technique for the last 25+ years, even if it hurts some feelings. Linus goes for an in-the-trenches, rough camaraderie, approach, rather than a "professional soft spoken cubicle workers" approach.
He's an outright toxic and abusive person. Characterizing a lack of toxic, abusive behavior as "professional soft spoken cubicle workers approach" is disingenuous.
So what people mean with that is not that he actually has a toxic effect, but that they dislike his tone.
Having a 'toxic' personality does not mean he will produce bad code. Two completely different things.
I said that the claim of those saying he's language is toxic is that his language poisons the Linux kernel community development.
And yet, I counter-argue, I see it doing just fine, and going from strength to strength, over the last 25 years. If there's any toxicity effect, I wont see it affecting much, if anything.
I could accept that it might have led some people who could have otherwise contributed away. But I don't see this having any substantial effect on Linux's development.
Perhaps it's even beneficial (since the outcome and results from Linux's development team is better than from any other Unix-like OSS OS, with their supposedly not toxic leaders).
If that freedom of language is all it takes to keep Linus happy, and stewarding the project as well as he has done all these decades, then so be it...
Yes.
Back in 2014 several DebConf attendees publicly confronted Torvalds, quoting some of the outrageous things he's written to/at people and making him explain himself. It makes for some rather cringy moments and there is no evidence it had any meaningful impact on him. You may watch it all here:
See excerpt here: https://twitter.com/nntaleb/status/892370148476190720
Linus Torvals adds some insults into the above or simple does not even attempts to keep control over his emotional side - half people jump up and down happy like a fourteen years old. Wow, look, he used insult! The other half suddenly turns into prude "I never swear nor insult anyone" Victorian aristocrats - despite having tweet feeds full of, and I am quoting here, "fucks".
> In fact, I'll take real toilet paper over standards any day, because at least that way I won't have splinters and ink up my arse.
An Englishman saying "that's interesting" can be more rude than someone else saying "get lost"
never disappoints.
double d = 3.14;
int64_t *p = (int64_t *) &d; // !!!
int64_t n = *p;
typedef union {
double d;
int64_t n;
} int_or_double;
int_or_double u;
u.d = 3.14
int64_t n = u.n
---------
The standard team decided to forbid type punning to allow compilers to implement more optimizations. They still allow union aliasing because they felt there should still be a way to do low-level type casts if for those that absolutely want to.
The standard only allows reading a value as the type it was written with or as char, and an access as char is only good for copying. If a char access used different bit order, that would be OK according to the standard because you couldn't tell unless you violated the standard.
It seems every compiler will tolerate a memcpy for type punning, even though this isn't required.
Having said that, it is possible to implement memcopy in standard C: char pointers have an explicit special exemption to the aliasing rule so you are allowed to inspect objects as array of chars.
double d = 3.14;
uint64_t i;
memcpy(&i, &d, sizeof(d));
Aren't exact-bitwidth integer types optional even with C99 (let alone preceding versions of standard)?
If an implementation can't represent uint64_t exactly, it can still have a uint_least64_t type of whatever width works.
a) I believe sizeof (double) * 8 == 64 is not enforced by the standard either. One could argue that it is hard to find anything else these days, but (for a contrived example) I believe nothing prevents you from making your own port of GCC for some purpose, and make 'double' be 'float'. (From my memories, it is even far enough from rocket science.)
b) It already happened to me personally, to work with code where people have implemented their own uintXX types (because of the lack of the standard ones), and then over time these became narrower/vider.
So if we would like to have it portable, I think, nothing beats:
union { double d; char cc [sizeof (double)]; };
and there we are, back to what is in the standard.
sizeof (double) can be guaranteed to be 8 if __STDC_IEC_559__ is defined, so checking that is an additional hurdle if you want to use memcpy for punning. That said, I think it can be assumed that you're writing non-portable code for a specific set of platforms already if you are punning floats to integers, because the representation is implementation dependent in the first place. Probably you also know the environments in which it will be compiled as well, so the example is a bit contrived.
Very much agree that unions are the easiest and standard way to do type punning. There's so many misconceptions about this somehow being unclear in the standard. Sure, it does reflect poorly on the quality of the standard that Linux contributors don't understand it and that Linus Torvalds actively ignores it, but if you know what you're looking for it's often not that hard to find a definite answer.
That's why Linus writes:
"So the commit message that talks about how horrible union aliasing is is pushing a story that is simply wrong."
The commit message with which he disagreed obviously explicitly wrote something like (paraphrasing) "using union is undefined behavior by standard, so we are changing the code to not use it" etc.
Linus also wrote: "I'm not talking about the changes themselves - I can live with them. But the _rationale_ is pure and utter garbage, and dangerously so."
The rationale was (note, I don't have exact quote, I'm paraphrasing, if somebody has the original please give a link) that using unions for that is bad as per standard. Which is what the standard says but which is for practical purposes simply wrong. The standard is wrong an should not be followed, that was main Linus' argument.
IMO there are 4 highly relevant paragraphs in C99:
6.2.6.1: When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values.
6.2.6.1: When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values
6.5.2.3 DR283) If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning").
6.7.2.1: A pointer to a union object, suitably converted, points to each of its members (or if a member is a bit-field, then to the unit in which it resides), and vice versa.
None of this implies that unions can't be used for type punning. What it does imply is that reading from a larger member of the union than you last wrote to will leave you with an unspecified value.
gcc 4.9.2 for sure does not (-O3 -fstrict-aliasing). Not sure what clang does, but I'd be surprised if it ignores the standard. The standard makes it pretty clear what meaning it will have. Sure, gcc and clang maintainers may seem to read the standards like a lawyer looking to void a contract, but in this case it is actually very clear what they should do.
> what is not said that it “must work” in spite of other “must work” and “undefined” standard statements.
The standard makes it clear how to deal with the semantics: "In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object)." Only constraints directly use "shall"/"shall not" type language, but the expressions should still be evaluated as specified by the semantics.
“GNU extensions to standard C++ (and to C90) do explicitly allow type-punning with unions. Other compilers that don't support GNU extensions may also support union type-punning, but it's not part of the base language standard.”
Also, apparently in C99 one relevant statement was:
“The value of a union member other than the last one stored into [is unspecified]”
https://stackoverflow.com/questions/25664848/unions-and-type...
Note: In case it's not obvious, I, personally, believe that, at least, using unions for type-punning has to exist and should be explicitly supported in the standards too. And that the compiler contributors should not produce practically unusable results even when some standard is wrong (for common use) or unclear. But the quotes like the above give a hint on which basis some try to cling to bad approaches in this special case. In other cases it's probably even harder to avoid unwanted results.
void wat(uint16_t *x, uint16_t *y) {
*x = *y;
}
uint64_t a[100] = { 0 };
wat((uint16_t *)&a[0], (uint16_t *)(((char *)&a[0]) + 1));
uint16_t heh = 0xFFFF;
extern uint16_t doesAnything(uint16_t *, uint16_t *);
void wat(uint16_t *x, uint16_t *y) {
*x = *y + doesAnything(&heh, y);
}
uint64_t a[2] = { 0 };
wat((uint16_t *)&a[0], (uint16_t *)(((char *)&a[0]) + 1));Linus is obviously being harsh, his words are also preserved publicly as a part of the contribution. He's arguing against the logical fallacy. Had he not swore: would we discuss this?
These outbursts seem to happen every few weeks, and have long seized to surprise. IF anything actually bad ever comes up, he has no further escalation available to raise awareness.
It also reminds me of these choleric bosses screaming at someone every day: it's almost always a sign that they're insecure, sociopaths, or can't handle their responsibilities.
But I work in customer support of highly technical products, and I visit various companies very often. By now, I can figure this type of persons from the first communication -- not the ones who does it the way Linus does it (see above), but the real a&^%$%^$les -- owning some inner knowledge unavailable to others, just because they happened to be here from the bigbang and haven't evolved since. Boy, is this "rough but just and truthful" attitude counter-productive to projects! I haven't seen any exception to that yet.
Fork it and make your own.
Even Google couldn't pull that off with Android.
well, if you can keep pace with it, why not ?
"Spoiled little princesses" are those that can't take some strong words and need hugs and smiles...
#define BASE_FIELDS int a; int b; int c;
struct Base {
BASE_FIELDS
};
struct Derived1 {
BASE_FIELDS
int d; int e;
};
struct Derived2 {
BASE_FIELDS
int f; int g;
};
Is this against the standard C aliasing rules? If so, how would this need to be rewritten to conform to the standard?
edit: If you want to keep the existing syntax and can use GCC extensions, it should be legal to use an unnamed union:
struct Derived1 {
union {
struct Base base;
struct {
int a; int b; int c;
};
};
int d; int e;
};
struct Derived1 {
struct Base;
int d; int e;
};"One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members."
Looks like we are in the clear! :)
So Linus, made my day!
You can print the Standard on the real toilet paper and have the best of both worlds. Read before wipe!
Linux only took off thanks to SGI, IBM, HP, Cray seeing value reducing costs from their own in-house systems to something else.
> Linux only took off thanks to SGI, IBM, HP, Cray seeing value reducing costs from their own in-house systems to something else.
This seems unfair, Linux took off because it constantly kept getting improved and has more and more developers contributing to it. It didn't only take off because it was cheap, but it kept on improving. Also, the Elitist mindsets of some BSD devs and community go back to harm it. Try contributing to OpenBSD or FreeBSD and compare it with how approachable and relatively easy it is to contribute to Linux is.
Also, it's the fault of BSD's to not adopt or change to a better License at getting contributions back to its mainstream.
I also have major objections to calling anything more secure. No software is secure, each one of them has bugs. Some are discovered because more and more people use it. It's not like BSDs never had any CVEs ever.
It would be just another BSD or Minix if it would be only university students and weekend coders working on it, and we would all keep using Solaris, Aix, HP-UX, Tru64, Ultrix....
As for security issues, it helps that Linus is against disclosing security bugs as such.
This is overwhelmingly true now, but it wasn't always.
I still remember how it was when I was getting distributions via Walnut Creek CDROMs.
As per Wikipedia, IBM, Compaq and Oracle started contributing in some form around 1998.
I guess we could look at commits history to see when IBM and friends actually started to provide features.
How much code do you think they got back from Sony, Apple, companies selling routers with BSD on them?
Even Google prefers to build their own OS from scratch with MIT license (Fuchsia) than keep on using Linux for that effort. They already reduced GPL use to the bare minimum on Android by removing gcc.
Then there was the whole suit which made most companies loose interest to be involved with BSD.
They even appear as MIT/BSD in many projects.
https://opensource.stackexchange.com/questions/217/what-are-...
Relevant part:
"o what both the 2-clause BSD license and the MIT license have in common are:
Permits use
Permits redistribution
Permits redistribution with modification
Provision to retain the copyright notice and warranty disclaimer
merging
publishing
sublicensing
selling
The practical differences between the 2-clause BSD license and the MIT license are marginal. Which one to pick is mostly up to personal taste. Especially considering that both licenses are considered compatible, so you can take code under one license and use it in a project under the other, as long as you keep the license text around."
Yocto has files with such dual license.
https://git.congatec.com/yocto/meta-openembedded/blob/fido/m...
Unless you're heavily invested in the Linux kernel and Linux-only tech, I'd advise to keep your software running on the BSDs as well as Linux to avoid monocultures in your own best interest. The strength of F/OSS is in giving you choice, eg. by providing two (or more) interchangeable, excellent O/S's and compiler suites.
Also, essentials things like graphics drivers etc, work properly so that the devs like us start using it as a daily driver and contribute to it's usage.
"When documented gcc behavior says one thing, and the standard might be unclear, we really don't care one whit about the lack of clarity in some standard."
I think the union thing was at least initially implemented as not functioning at all in clang, where developers "followed the standard."
For modern compiler, just use memcpy and compiler can optimize away the memcpy and produce the exactly same code.
But the kernel developers has some issues on trusting compiler generated code.
If you have a better argument to counter his logic, please post that, it would be more useful for everyone involved. Posting pretty useless comments here is pretty lame.
I think most people couldn't care less who's right or wrong in this discussion. They are simply reacting to the discourse.
Personally, I'm far from convinced that there even is an objective right or wrong in this question. It's probably just a matter of taste and/or perspective.
I find Linus behavior rude because in discussions like this he seems to have little to no understanding of other perspectives than his own.
Either that or he is deliberately provoking this other fellow to get him off his high horses.
In either case, it's not exactly accepted public discourse.
He has said himself that he needs to do this to drive his point across, and given the medium and audience I can agree that the political challenge of running the project must be huge.
But surely there must be a more diplomatic way to the same end?
> Personally, I'm far from convinced that there even is an objective right or wrong in this question. It's probably just a matter of taste and/or perspective.
This is not always true. Sometimes there is only one correct/pragmatic way of doing something. And if someone asserts that it's nothing wrong.
> I find Linus behavior rude because in discussions like this he seems to have little to no understanding of other perspectives than his own.
You can't say this is the case always. I have read a lot of the discussions like these. A lot of times, he writes a pragmatic and valid explanation of his dislike about a certain topic.
> In either case, it's not exactly accepted public discourse.
Again, you are assuming all cultures and societies are alike, they are not. There is a vast wide world with different thinking and a culture other than the Silicon Valley bubble. It's time people stop generalizing everything under the sun.
Speech is a topic of discussion just like anything else under the sun.
(And also: People here have no authority or power to police anything.)
You can take as many steps as you want to get to the mailbox too. And you'll be taking more steps if you detour to go sniff dog shit. Going in a straight line solves two problems - it's faster and it smells better.
Reading on a shitty 96dpi 100nits screen from 2004 in a bright room, the lkml link is the more readable one.
Another situation of the eternal issue of "we need a web standard for specifying relative contrast", not "make everything blinding #000 on #fff".
With CSS4, you can choose other colour-spaces instead.
The web standard is there, but so long as 99% of users have setups which emit 300+cd/m^2 and say they're emitting 80, you can't do much with it.
The push toward HDR displays gives us another chance to 'get it right' wrt calibration, but a quick google search of 'HDR washed out' demonstrates why it's an uphill battle to get consumer displays to be honest.
Hell most displays nowadays don't even do sRGB, which was defined as the colorspace and contrast of an average 1990 CRT.
Oh wait, you know you can switch CSS to default layout? Perhaps the browser could use an option to still apply layout but ignore formatting and colours.
I really wish browsers' default formatting could be trusted to be as readable as possible, but alas.
it’s an embarrassment for the field.
a) useless- doesn't change anything b) the publicity is affecting the other side more
So basically Linus is Trump
I'm neither an expert in security nor in licensing, most of the things I've heard him say about either sounds pretty reasonable. Could you link to an example where he talks out of his ass, and explain why what he's saying is stupid? Both licensing and security strikes me as the kind of thing the author of the world's most used FOSS kernel has thought a lot about.
In this sub-thread, you're the first one to bring up swearing.
Solutions to those mistakes are rarely found by publicly demonising those who made the mistake.
But that isn't what is happening here at all. This code was merged. In fact Linus wasn't even yelling at the guy, rather the standards committee.
Just because you don't read 'atta boy, good job' doesn't mean it wasn't good. There was no mistake here.
In fact I'd be on your side if that is what he was doing.