All of the resources spent mitigating and monitoring these bugs could have been spent on other things, like bombing more nations or throwing more pot smokers into cages.
Or employing CPU designers that know how to do their job.
As someone who has actually been responsible for debugging pipelining fuckups in cpus, I say you are either an idiot or a shill.
If you make a living selling really complex stuff, then saying "aw shucks, we did not understand the technology we are producing" is not the way to enhance your sales. Meltdown and Spectre are the result a pile of very basic design errors all joined up.
Sure it can take a team of people with expensive, specialised equipment to debug a CPU, but have a look at Intel's turnover before you come out with this twaddle. If someone says "it looks like there is a problem" then they should be in line for bug bounties, like from software people.
It is our job as/. contributors, geeks and nerds to make the market heap this on Intel till it really hurts, or it will go on happening. Its not like Joe Sixpack call tell fake news when he laps it up.
I seriously doubt that the characteristics of the CPU TLB can be changed with a simple microcode update.
probably not, but the ability to read the pipeline contents that was speculative and not used when not in kernel mode probably could be. That would be a significant improvement (like putting passwords on your baby monitor when having sex). Of course with the IoT's track record, that may not be possible either.
OTOH if the "lock" won't remain closed if you "look at it from the wrong angle", then its not a lock, its a scam.
This design error contains at least three features worthy of "www.wtf.com":
The branch prediction trains on other people's threads: that is like your satnav giving you directions based on other cars movements.
The speculative execution can access data it is not supposed to: that is like you can imagine your are in a different person's house, and nick their things. Even in the 1970's the data returned by other 16 bit machines in this situation would have been "0xf001" and by 24 bit ones "FOOL" as 6-bit baudot code. Its not like this is not a well documented situation.
You can read the pipeline cache for speculative stuff that was abandoned when not in kernel AND debug mode that on its own is a completely unacceptable design defect. Worse, since it was known to contain other threads' data (at least by Intel).
That is the three no-nos we know about. There must be at least one more we don't know being held back because it is even worse.
Whoever designed this stuff MUST have known it would behave like that, same way the Volkswagen engineers knew what was going on. Someone signed the designs into production. Presumably the first time round it was "let's chance it" and subsequently "well, we got away with it last time".
I am guessing quite a few people knew about some of it - like people debugging the compilers for example.
If you want to know why NDAs should not be permitted this is it! Use an Open Source architecture if you want accountability.
It looks like the Intel guys were going to cripple performance for everyone until the patch from AMD removed the unnecessary crippling from AMD processors.
This sounds like racketeering to me. Where is RICO when you need him?
1) Javascript
2) C++
3) PHP
4) Javascript-based fameworks
5) Anything used to write an Excel or Word macro by the HR department
This is an unfair comparison: PHP specifically targets producing buggy products, and in the unlikely event that an HR compartment gets anything to work, it is even more unlikely to involve a computer.
Truth is I've seen very few projects where using C++ actually resulted in decent code in the end and quite a few where it wasn't at all helpful.
Probably because a huge amount of C++ code is in massive embedded systems which are closed source and you can't see the code. I can't either in the general case, but in the cases I have seen, the quality of code is roughly what you would expect from the quality of the team. (In all probability, larger teams will need one or more specialists to do the more complex debugging).
Are there any large Open Source projects in Cobol? No. That is mostly because Cobol is not fashionable with the OSS crowd. My point is fashion is the biggest factor in language selection for OSS. Not so much for closed source (where the prejudice of the CTO is the biggest factor). I doubt actual performance of the language is relevant to language selection in more than 1% of projects - and those are mostly academic experiments, rather than commercial work.
Which is hardly surprising, since C is just PDP11 assembler tidied up a bit.
Which is interesting considering the PDP11 was "a hardware Fortran machine", and the i386 architecture is a close copy of the PDP11 - the 286 even copied the early (variable page size) PDP11 memory management scheme that was the fashion before people figured out it was not really good for virtual memory, and then the 386 copied the later (fixed page size) PDP11 MM which is needed for virtual page based memory. The PDP11 was designed on the assumption that memory bandwidth was the bottleneck in throughput.
The fact that C has been successfully ported to almost all more recent processors is largely because the concepts of what a CPU is and does have been developed by people who grew up on the PDP11 architecture. RISC architecture may be different, but, in reality, the RISC architecture is mostly just used to simulate CISC anyway. RISC was designed on the assumption that instruction decode was the bottleneck - which has not really been the case since the 1980's - hence the failure of RISC to displace CISC.
I am writing this on a Sparc64 (RISC) machine - the story is more complex that I describe here.
The Dutch have been building "wind farms" all round the north sea (eg South and East England) for about 300 YEARS, and there have been DC cables carrying megawatts between UK and France since the 1950's.
Plus anything that makes the Dogger Bank more visible to sailors will save a lot of lives in the long run - there are massive numbers of shipwrecks there because of the shallow water. (Nothing to do with Vodka at all, honest).
Because there is about half the world between us and them, and the people in the middle have a lot of guns and little sense of humour - especially the Americans and Russians (who have the biggest lumps of land between us and NK).
KJU probably is not a major threat to us - he is more of a laughing stock. Sure he is a major threat to his own people - but as we all should know by now, interfering in other country's affairs does not generally improve the situation. Its not impossible that his own people will decide they might as well kill him - they are going to die anyway - why not take him with them.
If we do in the "American way" (go in with all guns blazing) it will end the way it always does - masses of "collateral damage" and no significant change in the big picture. This is not traditionally our preferred approach.
Slashdot Mirror
Or employing CPU designers that know how to do their job.
How do we know that code is a valid exploit test? Why would it not produce '0' as a result?
If you make a living selling really complex stuff, then saying "aw shucks, we did not understand the technology we are producing" is not the way to enhance your sales. Meltdown and Spectre are the result a pile of very basic design errors all joined up.
Sure it can take a team of people with expensive, specialised equipment to debug a CPU, but have a look at Intel's turnover before you come out with this twaddle. If someone says "it looks like there is a problem" then they should be in line for bug bounties, like from software people.
It is our job as /. contributors, geeks and nerds to make the market heap this on Intel till it really hurts, or it will go on happening. Its not like Joe Sixpack call tell fake news when he laps it up.
probably not, but the ability to read the pipeline contents that was speculative and not used when not in kernel mode probably could be. That would be a significant improvement (like putting passwords on your baby monitor when having sex). Of course with the IoT's track record, that may not be possible either.
If they DON'T fix it, then they may be seriously short of future customers. Now THAT would be a serious financial hit!
But you use Oracle Sparc64 for all your database work, don't you?
Have you read a description of the hardware defects? It is exactly like it is insecure by bungling ineptitude and corner cutting
If they advertised these defects, no one would have bought a single chip from them, ever.
Its like selling buckets with hole in and saying "its OK if you carry them real fast".
This design error contains at least three features worthy of "www.wtf.com":
That is the three no-nos we know about. There must be at least one more we don't know being held back because it is even worse.
Whoever designed this stuff MUST have known it would behave like that, same way the Volkswagen engineers knew what was going on. Someone signed the designs into production. Presumably the first time round it was "let's chance it" and subsequently "well, we got away with it last time".
I am guessing quite a few people knew about some of it - like people debugging the compilers for example.
If you want to know why NDAs should not be permitted this is it! Use an Open Source architecture if you want accountability.
Provided by the crows!
Depends on what your workload is.
And people wonder why sales of laptops are bad? Its obvious the old ones are better if you ever manage to actually get hold of the specs from anyone.
Typical use case for the Laptops in PC world appears to be "getting in the way".
This sounds like racketeering to me. Where is RICO when you need him?
Because then they would grow up to be plastic fish, and they would not taste very good.
2) C++
3) PHP
4) Javascript-based fameworks
5) Anything used to write an Excel or Word macro by the HR department
This is an unfair comparison: PHP specifically targets producing buggy products, and in the unlikely event that an HR compartment gets anything to work, it is even more unlikely to involve a computer.
Probably because a huge amount of C++ code is in massive embedded systems which are closed source and you can't see the code. I can't either in the general case, but in the cases I have seen, the quality of code is roughly what you would expect from the quality of the team. (In all probability, larger teams will need one or more specialists to do the more complex debugging).
Are there any large Open Source projects in Cobol? No. That is mostly because Cobol is not fashionable with the OSS crowd. My point is fashion is the biggest factor in language selection for OSS. Not so much for closed source (where the prejudice of the CTO is the biggest factor). I doubt actual performance of the language is relevant to language selection in more than 1% of projects - and those are mostly academic experiments, rather than commercial work.
Which is hardly surprising, since C is just PDP11 assembler tidied up a bit.
Which is interesting considering the PDP11 was "a hardware Fortran machine", and the i386 architecture is a close copy of the PDP11 - the 286 even copied the early (variable page size) PDP11 memory management scheme that was the fashion before people figured out it was not really good for virtual memory, and then the 386 copied the later (fixed page size) PDP11 MM which is needed for virtual page based memory. The PDP11 was designed on the assumption that memory bandwidth was the bottleneck in throughput.
The fact that C has been successfully ported to almost all more recent processors is largely because the concepts of what a CPU is and does have been developed by people who grew up on the PDP11 architecture. RISC architecture may be different, but, in reality, the RISC architecture is mostly just used to simulate CISC anyway. RISC was designed on the assumption that instruction decode was the bottleneck - which has not really been the case since the 1980's - hence the failure of RISC to displace CISC.
I am writing this on a Sparc64 (RISC) machine - the story is more complex that I describe here.
If that is why he was shot in the head, the cop was an even dumber fuck that we first thought!
I think you will find it is closer to every other year
(Unless your information comes from #TheTotallyFakeMcDonald.)
FTFY
They may have guns, but probably no ammo. They can't afford it, and the gummint won't trust them with it anyway.
The murder rate per 1,000 in Africa is about 10th of what it is in the USA.
The Dutch have been building "wind farms" all round the north sea (eg South and East England) for about 300 YEARS, and there have been DC cables carrying megawatts between UK and France since the 1950's.
Plus anything that makes the Dogger Bank more visible to sailors will save a lot of lives in the long run - there are massive numbers of shipwrecks there because of the shallow water. (Nothing to do with Vodka at all, honest).
Trump would abolish that in an instant
Because there is about half the world between us and them, and the people in the middle have a lot of guns and little sense of humour - especially the Americans and Russians (who have the biggest lumps of land between us and NK).
KJU probably is not a major threat to us - he is more of a laughing stock. Sure he is a major threat to his own people - but as we all should know by now, interfering in other country's affairs does not generally improve the situation. Its not impossible that his own people will decide they might as well kill him - they are going to die anyway - why not take him with them.
If we do in the "American way" (go in with all guns blazing) it will end the way it always does - masses of "collateral damage" and no significant change in the big picture. This is not traditionally our preferred approach.
When it performs something that most people agree is intelligent.
(Doing one very stupid thing, or even a lot of stupid things at once, does not count)
What if the clowns have RFID tags?