Unfortunate typo: the article says "Having placed the fresnel lens, we're not able to get an usable image on the whole 40x30cm sensor." but I think the "not" should be "now". Having "not" reverse the meaning of the critical sentence!
It's easy to make these 800V systems totally safe. You just have to combine this idea with the extremely sensible plan to put data centers in space and then there will be no worry about when "someone pulls out a rackmount unit" because there not be someone within hundreds of kilometers.
The concern isn't keeping people out of the facility altogether. It's keeping people safe when they are hot swapping dead or outdated rack units.
You could consider a robotized approach, but for now robots aren't very good at this type of task. Whether the robotized system is in space is irrelevant. It's not a "next five years" type of solution.
It did not help that the performance of the Xbox 360 CPU (and Cell) was terrible. In-order execution without the crazy-high frequencies the CPU was designed for was a failure.
Author here: This is not a common problem. I think I was told that Alpha had basically the same bug but it is a bug, for sure. Speculative execution causing problematic side effects is a deal killer.
Speculative execution, however, can cause less problematic side effects. For instance, a speculatively executed load or prefetch will usually actually prefetch which will pollute the cache, TLB, etc., and reveal side-band information, but that is a performance problem and perhaps a subtle security flaw, not a correctness bug like this was.
I remember reading this many years ago, it was great.
In the last week Raymond Chen on his The Old New Thing mentioned the concept of delay slots on some CPUs.
It sounds like a similar thing, just formalized so it’s not a bug. Knowing that the instruction after a branch always executes, regardless of if the branch is taken.
I think that is correct, but yes, a delay-slot instruction that is always executed is easy to reason about. Speculative execution that gets real? shudder
A week later, when the GetCpuUsage function was added to process.cc, the CloseHandle call at the end of GetProcessMemoryUsage was deleted/pushed into GetCpuUsage.
The unified diff for that change doesn't point out that code was deleted from GetProcessMemoryUsage (the CloseHandle() call is now in GetCpuUsage).
Someone ok'd those changes...
Also MS's PREfast/PREfix static code analysis tools missed that bug as well. I'd update my static analysis perl script to check for that case, but one of the comments to TFA said chatgpt will catch the problem, so I'll punt.
Minor nit: The ProcessInfo struct declares fields in an awkward fashion if you're debugging, esp. if you're viewing memory of the struct. One should put small size fields at the start of the struct, large size fields at the end. As is, the large name character array will occupy a large amount of space and if you want to see the values of the small fields, one would probably have to scroll to locate these small fields after the large character array.
Minor nit: What's with the magic number 1024? At least in recent versions of the process.cc file, they've gone from a fixed 1024 element array (each element == MAX_PATH * TCHAR + sizeof(DWORD)*3 bytes) to a dynamic array.
I was surprised also when this happened, but pleased. The trust was nice. The fact that they needed to give me the symbols in order to understand the issue was surprising. Why couldn't they find the calls in their source? Or analyze the trace themselves? Curious.
That is a problem they haven't tried to solve. Driving directions could be for tax/ride-share or a person in their own car. If Google Maps doesn't even ask you which it is then it can't possibly reliably give you correct directions. I'd love to see that fixed.
reply