dfrage

ARM is actually a good target with a number of their newest designs using out-of-order speculative execution with Spectre vulnerabilities and their owning mobile space outside of notebooks, one of the newest even being vulnerable to Meltdown, but the significant headline worthy instances tend to come in much more locked down devices. Speed is also an issue, everything else being equal, the faster the chip, the faster data exfiltration proofs of concept will work.

So the cloud vendors are 97% minimum Intel, they're exquisitely vulnerable both technically and reputationally to these bugs, the stakes are existential for them and they have a lot of money they can throw at the problem, whereas the users of notebooks and desktops are a much more diffuse interest.

As I've mentioned many times in these discussions today, everyone had Spectre issues, and everyone but AMD has Meltdown ones. The more recent vulnerabilities are Intel only because they're using what was learned from those first two to attack Intel specific features like the SGX enclave.

All depends on your threat model; to take one extreme, if you're crunching numbers with your own optimized numeric code, the issue of untrusted code of "random JavaScript off the net" is not an issue. And I doubt many mainframes are used to casually browse the net ... I certainly hope not at the same time they run the night's financial transactions!

Per Wikpedia, "The Pentium has two datapaths (pipelines) that allow it to complete two instructions per clock cycle in many cases. The main pipe (U) can handle any instruction, while the other (V) can handle the most common simple instructions." (https://en.wikipedia.org/wiki/P5_(microarchitecture) )

HT uses two instruction decoders to keep more busy a set of execution engines, suppose you had the above set of 2 execution datapaths (that may be improved on these Atoms), and couldn't do two operations at a time from one instruction stream, but the other could use the unused datapath.

To the extent I've looked at it, without reading original documents, the original OoO design that current systems are based on, the IBM System 360/Models 91 and 95's floating point unit using Tomasulo's algorithm https://en.wikipedia.org/wiki/Tomasulo_algorithm didn't extend to speculative execution.

No doubt because gates were dear, implemented with discrete transistors, and that processor was a vanity project of Tom Watson Jr's. And memory was slow, core except for NASA's two 95's with 2 MiB of thin film memory at the bottom, and cache was still a couple of years out, introduced with the 360/Model 85. OoO becomes compelling when you have a fast and unpredictable memory hierarchy, as we started to have in a big way in the 1990s when we returned to this technique.

For example, the first version of Foreshadow went after the SGX enclave. Given how widespread Meltdown and Spectre bugs are, there's absolutely no reason to believe that the other vendors don't have similar unique problems.

Hitting diminishing returns on caches with an ever increasing gate budget is I believe prompted this second generation starting in the 1990s which adds speculative execution, which the algorithm with all those extra hidden registers really invites you to do.

Time sharing was very big in the 1970s, and non-OS/VM methods of sharing mainframes for batch processing were also big at times I'm less sure of.

Inviting complete randoms to routinely run untrusted code in your own security domain, as we do with browsers, that's "new". And thus the popularity of NoScript and uMatrix.

Serious weasel wording, outside of x86 space every other high end architecture also had Meltdown issues, ARM, and IBM's POWER and mainframe designs.

I personally wouldn't say the design aesthetic for either is "attractive", but they're pretty clean and functional, and that is worth a lot. Walmart.com transactions are now a bit easier than Amazon, before you factor in the tremendous amount of effort the latter requires to avoid counterfeits. Walmart.com search is a lot better once you get the right terms, and turn off 3rd parties which they make trivial.

Except due to commingling you might get something from a 3rd party Fulfilled by Amazon instead of Amazon's supply chain.

> And with first hand experience with Amazon's Vendor program they go further than a lot of other retailers in pushing costs onto their vendors such as making them eat returns etc.

I know Walmart is very severe with their vendors, do you believe Amazon is worse?

The latter detail was the last straw for me and my Prime membership due to Amazon switching to pro forma padding by just throwing in a few air pillows. Between that and all the last mile delivery issues others are reporting, its clear Amazon is seriously pinching pennies in fulfillment without caring how much business and extra expense that costs them. Add in the counterfeit problem and it's hard to imagine how much damage the brand is suffering.

While its not always possible, it's a good idea to use at least two completely different backup methods, avoiding single points of failure like in this case. For example, use a logical volume manager to make frozen copies of your filesystems, and back those up using something low level.

The cost is basically infinite as Google is internally structured, maintenance on anything but a monster service is a career dead end. It would likely be worse for an acquired service like Nest, the experience gained wouldn't transfer over to Google's back end.

Maybe the conversion of Nest's infrastructure was internally viewed as more maintenance than new project, so it didn't get much in the way of resources? Google palpably doesn't care about brand damage so that's not a consideration.