I forget the page number now, I posted it in a Slashdot comment ages ago. There is a band, basically it depends where the fuel comes from and varies a lot from country to country. When I get home I'll see if I can dig it out for you.
"You seem to have bought into the cool-aid. Please add a healthy dose of critical thinking. Because this isn't the kind of cool-aid that makes for a fun trip with pretty pictures. This is the kind that melts your brain."
"And that's actually ignoring the much _worse_ issue, namely that the whole hardware interface is literally mis-designed by morons."
Most of it is fine, it's just really a few lines where he could have avoided the pointless insults that add nothing to the technical argument.
I kind of wonder how it played out at Intel. Their employee could have complained about having to work with someone who says that about them publicly and it would have been hard for them to force them to keep doing it.
Assuming they somehow figured out how to do a pull request yet still have no idea how to code, you could try:
"I'm sorry, but we can't accept this pull request. The Linux kernel has really high standards and you might try working on some other projects and building up to it first. You are clearly enthusiastic and I'd encourage you to keep learning and improving. If you want some tips then you could try asking for a code review on Stack Exchange, for example."
That completely meets the requirements of the CoC. I'm sure you could try to twist it into a complaint but I'm sure the Technical Advisory Board wouldn't be interested.
Here's my edited version of Linus's email, which I suggest conveys the same serious message but in a less brutal way. Most of it is actually fine.
> Certainly it's a nasty hack, but hey â€" the world was on fire and in the > end we didn't have to just turn the datacentres off and go back to goat > farming, so it's not all bad.
It's not that it's a nasty hack. It's much worse than that.
> As a hack for existing CPUs, it's just about tolerable â€" as long as it > can die entirely by the next generation.
That's part of the big problem here. The speculation control cpuid stuff shows that Intel actually seems to plan on doing the right thing for meltdown (the main question being _when_). Which is not a huge surprise, since it should be easy to fix, and it's a really honking big hole to drive through. Not doing the right thing for meltdown would be completely unacceptable.
So the IBRS stuff implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation.
Honestly, that's completely unacceptable too.
> So the part is I think is odd is the IBRS_ALL feature, where a future > CPU will advertise "I am able to be not broken" and then you have to > set the IBRS bit once at boot time to *ask* it not to be broken. That > part is weird, because it ought to have been treated like the RDCL_NO > bit â€" just "you don't have to worry any more, it got better".
This is not a good solution.
The whole IBRS_ALL feature suggest that Intel is not serious about doing a proper fix, just an expensive hack that won't be enabled by default because the performance hit would be unacceptable.
It's not even a good solution from a technical standpoint.
I'm sure there is some lawyer there who says "we'll have to go through motions to protect against a lawsuit". But legal reasons do not make for good technology, or good patches that I should apply.
> We do need the IBPB feature to complete the protection that retpoline > gives us â€" it's that or rebuild all of userspace with retpoline.
That doesn't seem to be right.
The patches do things like add the MSR writes to the kernel entry/exit points. That doesn't make sense. That says "we're trying to protect the kernel". We already have retpoline there, with less overhead.
If this was about flushing the BTB at actual context switches between different users, it would make sense. But that's not at all what the patches do.
So are you sure about this? For now we can't accept these patches.
And that's actually ignoring the much _worse_ issue, namely that the whole hardware interface is literally mis-designed.
It's mis-designed for two major reasons:
- the "the interface implies Intel will never fix it" reason.
See the difference between IBRS_ALL and RDCL_NO. One implies Intel will fix something. The other does not.
- the "there is no performance indicator".
The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions.
But since we already know that the IBRS overhead is/huge/ on existing hardware, all those hardware capability bits are useless. Nobody will use them, since the cost is too high. So you end up having to look at "which CPU stepping is this" anyway.
I think we need something better than this I'm afraid. Can you propose something else? Maybe discuss the fixes before submitting further patches.
Note that the old CoC warned contributors that most contributed code would need revising before being accepted. In other words, hardly anyone is good enough to produce high enough quality for Linux and it takes community effort to get to that level.
So if you think people who "can't keep up" should "get out of the way" you are rejecting most Linux contributors.
I also don't see how being open and welcoming would prevent feedback being given and code improve before being accepted. If anything it should help the process along. Perhaps you can give us a real world example of how you think this could be a problem.
Speaking of the GPL, Linux is licenced under it but doesn't follow the philosophy or politics of the author, or the stuff on the web site/organization from which it originates.
Also, please read the Code of Conduct's "scope" section carefully again. It doesn't apply to things done outside the project. It is actually very narrow, limiting itself to when people are representing the project officially, such as via an official email address or as an organiser/representative at a conference.
It doesn't even apply to most of the people contributing to Linux.
I'm hoping that now they have internet functionality they release a new Mario Maker for Switch... But also hoping they don't because the Wii U version is pretty good but will die off if a new one comes out and the Switch is not cheap.
You know it's really easy, all you need is an email address and git. You can do it through Github or not.
Having said that I don't think that one sentence is the issue you really want to address here. The bit you liked says "examples of", i.e. it's not an exclusive list. So it already includes anything else that might be deemed official, with the determination ultimately being made by the Technical Advisory Board.
That's probably the only realistic option, since as any D&D player will tell you there is always some situation they missed in the rule book that the DM will have to make the final decision on... But by all means, feel free to try and enumerate every possible way someone can represent a project in some capacity.
This claim that mere accusations of being looked at "wrong" are enough for sexual harassment complaints is bogus. There needs to be a documented pattern of behaviour or a single well documented overt incident like groping in public.
Complaining about looks with no evidence will just get you on HR's shit list and passed over for promotion.
You won't get a straight answer to this. Someone will claim that there is no discrimination or find some excuse, but they won't tell you why they really want to allow this kind of discrimination.
"We don't care what you are, what you do, or what your opinions are. Just show us the code. If it's good, we'll take it. If it's not, we'll see what we can salvage"
Linux isn't a monolithic block like that, where you anonymously submit patches and get an accept/reject response.
Linux is a community of developers who cooperate to plan and develop features and ensure that they all integrate and operate well together. Many of the contributors are doing it for work. Most use their real names, and many attend conferences where they meet other members of the community in person.
There have always been some rules about behaviour, just not well codified or enforced. Individual conferences and events often had their own. So it's not even new.
A quick diff suggests that the only adaptation they made was to change the phrase "project maintainers" to "maintainers", and fill in their contact details.
You could submit a pull request to fix it, you know.
But it really seems like they have gone out of their way to limit the scope of the CoC and allow maximum diversity of political views, something that is extremely difficult to do in practice.
To be clear though the Code of Conduct doesn't say any of that, or even hint at it. And the text from the Contributor Covenant that you quoted isn't actually from the Covenant itself, it's from the preamble on the web page that introduces it.
So I think your "context" here is just fear-mongering. Can you point to anything you find problematic in the actual Code of Conduct?
When you say "market it for me", exactly what work are you expecting them to carry out? If it's modelling then okay, they need the right type of hair, and the law allows you to select people based on that genuine need. But if it's just counter sales or something then you have a harder time arguing that the blond won't be able to sell it, because that really depends on her sales skills and not her ability to use the product on herself.
Interesting that they are complaining about gender discrimination now. Previously it was race and efforts to get Facebook to fix it didn't work out so well, as it's still going on. Historically white women have often been the first to benefit from greater equality so when there is a stubborn problem like this it makes sense to target gender first. Just a shame it has to happen at all.
The markets in China are up right now because they anticipate the retaliatory actions to be beneficial. Some with be tariffs on US goods, some will be non-tariff stuff like domestic stimulus packages and increased bureaucracy for US companies.
Because the US is doing the same to Europe and east Asia too this is seen as an opportunity to displace US exports to those countries as well.
- Mostly paper only designs, very few prototypes have been built.
- Economies of scale only kick in at 70+ units because the factory needs to be built, and economists think 70 orders is unlikely.
- Licencing is still in the early stages, needs to be sorted out with governments first.
- Most are still water cooled anyway.
- Many of the designs only realize a small reduction in staff numbers, the idea of sealed self managing unit is pie in the sky even for the concept designs.
A lot of investors still seem to think they can get in "early" and grab a slice of the patent pie with high end vehicles that will develop and prove the technology that will eventually end up in affordable cars.
Unfortunately for them Kia, Hyundai, Nissan/Renault and a bunch of Chinese manufacturers have already done that and are selling those affordable cars today. But I suppose this is pocket change for the Saudis so maybe they are willing to take a punt.
Slashdot Mirror
In practice, if a white male criticizes someone who isn't, the content of the criticism is irrelevant, and he's automatically a bigot.
I'd love to see a real world example of that, preferably using this CoC which has been adopted by many different projects.
I forget the page number now, I posted it in a Slashdot comment ages ago. There is a band, basically it depends where the fuel comes from and varies a lot from country to country. When I get home I'll see if I can dig it out for you.
He never trashes the human being
I'm not so sure about that.
"You seem to have bought into the cool-aid. Please add a healthy dose of critical thinking. Because this isn't the kind of cool-aid that makes for a fun trip with pretty pictures. This is the kind that melts your brain."
"And that's actually ignoring the much _worse_ issue, namely that the whole hardware interface is literally mis-designed by morons."
Most of it is fine, it's just really a few lines where he could have avoided the pointless insults that add nothing to the technical argument.
I kind of wonder how it played out at Intel. Their employee could have complained about having to work with someone who says that about them publicly and it would have been hard for them to force them to keep doing it.
Assuming they somehow figured out how to do a pull request yet still have no idea how to code, you could try:
"I'm sorry, but we can't accept this pull request. The Linux kernel has really high standards and you might try working on some other projects and building up to it first. You are clearly enthusiastic and I'd encourage you to keep learning and improving. If you want some tips then you could try asking for a code review on Stack Exchange, for example."
That completely meets the requirements of the CoC. I'm sure you could try to twist it into a complaint but I'm sure the Technical Advisory Board wouldn't be interested.
Here's my edited version of Linus's email, which I suggest conveys the same serious message but in a less brutal way. Most of it is actually fine.
/huge/ on existing hardware, all those hardware capability bits are useless. Nobody will use them, since the cost is too high. So you end up having to look at "which CPU stepping is this" anyway.
> Certainly it's a nasty hack, but hey â€" the world was on fire and in the > end we didn't have to just turn the datacentres off and go back to goat > farming, so it's not all bad.
It's not that it's a nasty hack. It's much worse than that.
> As a hack for existing CPUs, it's just about tolerable â€" as long as it
> can die entirely by the next generation.
That's part of the big problem here. The speculation control cpuid stuff shows that Intel actually seems to plan on doing the right thing for meltdown (the main question being _when_). Which is not a huge surprise, since it should be easy to fix, and it's a really honking big hole to drive through. Not doing the right thing for meltdown would be completely unacceptable.
So the IBRS stuff implies that Intel is _not_ planning on doing the right thing for the indirect branch speculation.
Honestly, that's completely unacceptable too.
> So the part is I think is odd is the IBRS_ALL feature, where a future
> CPU will advertise "I am able to be not broken" and then you have to
> set the IBRS bit once at boot time to *ask* it not to be broken. That
> part is weird, because it ought to have been treated like the RDCL_NO
> bit â€" just "you don't have to worry any more, it got better".
This is not a good solution.
The whole IBRS_ALL feature suggest that Intel is not serious about doing a proper fix, just an expensive hack that won't be enabled by default because the performance hit would be unacceptable.
It's not even a good solution from a technical standpoint.
I'm sure there is some lawyer there who says "we'll have to go through motions to protect against a lawsuit". But legal reasons do not make for good technology, or good patches that I should apply.
> We do need the IBPB feature to complete the protection that retpoline
> gives us â€" it's that or rebuild all of userspace with retpoline.
That doesn't seem to be right.
The patches do things like add the MSR writes to the kernel entry/exit points. That doesn't make sense. That says "we're trying to protect the kernel". We already have retpoline there, with less overhead.
If this was about flushing the BTB at actual context switches between different users, it would make sense. But that's not at all what the patches do.
So are you sure about this? For now we can't accept these patches.
And that's actually ignoring the much _worse_ issue, namely that the whole hardware interface is literally mis-designed.
It's mis-designed for two major reasons:
- the "the interface implies Intel will never fix it" reason.
See the difference between IBRS_ALL and RDCL_NO. One implies Intel will fix something. The other does not.
- the "there is no performance indicator".
The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions.
But since we already know that the IBRS overhead is
I think we need something better than this I'm afraid. Can you propose something else? Maybe discuss the fixes before submitting further patches.
Give us a specific example of a flaw that can't be addressed in a way that is compatible with "using welcoming and inclusive language".
I'll see if I can address it in a way that meets those requirements if you give me an example.
Note that the old CoC warned contributors that most contributed code would need revising before being accepted. In other words, hardly anyone is good enough to produce high enough quality for Linux and it takes community effort to get to that level.
So if you think people who "can't keep up" should "get out of the way" you are rejecting most Linux contributors.
I also don't see how being open and welcoming would prevent feedback being given and code improve before being accepted. If anything it should help the process along. Perhaps you can give us a real world example of how you think this could be a problem.
Speaking of the GPL, Linux is licenced under it but doesn't follow the philosophy or politics of the author, or the stuff on the web site/organization from which it originates.
Also, please read the Code of Conduct's "scope" section carefully again. It doesn't apply to things done outside the project. It is actually very narrow, limiting itself to when people are representing the project officially, such as via an official email address or as an organiser/representative at a conference.
It doesn't even apply to most of the people contributing to Linux.
I'm hoping that now they have internet functionality they release a new Mario Maker for Switch... But also hoping they don't because the Wii U version is pretty good but will die off if a new one comes out and the Switch is not cheap.
You know it's really easy, all you need is an email address and git. You can do it through Github or not.
Having said that I don't think that one sentence is the issue you really want to address here. The bit you liked says "examples of", i.e. it's not an exclusive list. So it already includes anything else that might be deemed official, with the determination ultimately being made by the Technical Advisory Board.
That's probably the only realistic option, since as any D&D player will tell you there is always some situation they missed in the rule book that the DM will have to make the final decision on... But by all means, feel free to try and enumerate every possible way someone can represent a project in some capacity.
This claim that mere accusations of being looked at "wrong" are enough for sexual harassment complaints is bogus. There needs to be a documented pattern of behaviour or a single well documented overt incident like groping in public.
Complaining about looks with no evidence will just get you on HR's shit list and passed over for promotion.
You won't get a straight answer to this. Someone will claim that there is no discrimination or find some excuse, but they won't tell you why they really want to allow this kind of discrimination.
"We don't care what you are, what you do, or what your opinions are. Just show us the code. If it's good, we'll take it. If it's not, we'll see what we can salvage"
Linux isn't a monolithic block like that, where you anonymously submit patches and get an accept/reject response.
Linux is a community of developers who cooperate to plan and develop features and ensure that they all integrate and operate well together. Many of the contributors are doing it for work. Most use their real names, and many attend conferences where they meet other members of the community in person.
There have always been some rules about behaviour, just not well codified or enforced. Individual conferences and events often had their own. So it's not even new.
A quick diff suggests that the only adaptation they made was to change the phrase "project maintainers" to "maintainers", and fill in their contact details.
You could submit a pull request to fix it, you know.
But it really seems like they have gone out of their way to limit the scope of the CoC and allow maximum diversity of political views, something that is extremely difficult to do in practice.
What words specifically are you worried about?
To be clear though the Code of Conduct doesn't say any of that, or even hint at it. And the text from the Contributor Covenant that you quoted isn't actually from the Covenant itself, it's from the preamble on the web page that introduces it.
So I think your "context" here is just fear-mongering. Can you point to anything you find problematic in the actual Code of Conduct?
When you say "market it for me", exactly what work are you expecting them to carry out? If it's modelling then okay, they need the right type of hair, and the law allows you to select people based on that genuine need. But if it's just counter sales or something then you have a harder time arguing that the blond won't be able to sell it, because that really depends on her sales skills and not her ability to use the product on herself.
Interesting that they are complaining about gender discrimination now. Previously it was race and efforts to get Facebook to fix it didn't work out so well, as it's still going on. Historically white women have often been the first to benefit from greater equality so when there is a stubborn problem like this it makes sense to target gender first. Just a shame it has to happen at all.
Do you have a citation for your numbers? The only GAO info I could find with numbers was this: https://www.gao.gov/products/G...
And that doesn't say $40bn or >$1T.
But in any case, on-shore wind is already profitable without subsidy. Solar is cheaper than nuclear with both subsidised in the UK.
Plant construction, mining, plant operation, decommissioning, waste storage. Lifetime is around 100g/kWh.
The markets in China are up right now because they anticipate the retaliatory actions to be beneficial. Some with be tariffs on US goods, some will be non-tariff stuff like domestic stimulus packages and increased bureaucracy for US companies.
Because the US is doing the same to Europe and east Asia too this is seen as an opportunity to displace US exports to those countries as well.
https://www.ipcc.ch/pdf/assess...
Lifetime emissions of a nuclear plant are around 100g/kWh. Better than coal but considerably worse than wind/solar+battery.
The Wikipedia page is enlightening: https://en.wikipedia.org/wiki/...
- Mostly paper only designs, very few prototypes have been built.
- Economies of scale only kick in at 70+ units because the factory needs to be built, and economists think 70 orders is unlikely.
- Licencing is still in the early stages, needs to be sorted out with governments first.
- Most are still water cooled anyway.
- Many of the designs only realize a small reduction in staff numbers, the idea of sealed self managing unit is pie in the sky even for the concept designs.
A lot of investors still seem to think they can get in "early" and grab a slice of the patent pie with high end vehicles that will develop and prove the technology that will eventually end up in affordable cars.
Unfortunately for them Kia, Hyundai, Nissan/Renault and a bunch of Chinese manufacturers have already done that and are selling those affordable cars today. But I suppose this is pocket change for the Saudis so maybe they are willing to take a punt.