dfrage

> This is clearly what Intel did.

And ARM, and IBM, both the POWER and mainframe/Z teams.

Although this design decision of Intel's was in the early 1990s, shipping in their first Pentium Pro in 1995. When AMD's competition was a souped up 486 targeting Intel's superscaler Pentium, although I assume they were also working on their first out-of-order K5 at the time, it first shipping in 1996.

> Because implementing it increased performance which made the numbers which captured market share.

More than the following big things, in both directions?

- A consistent fabrication advantage until very recently? That's said to have wiped out a generation of clever hardware architects, when Intel beat their best efforts with their next process node.

- Falling behind AMD with the Netburst "marchitecture", the front side bus memory bottleneck, and only supporting Itanium as a 64 bit architecture?

- Reversing the above by licencing AMD64, reverting to the same Pentium Pro style design AMD was using, and copying their ccNUMA multi-chip layout (each is directly attached to memory, with fast connections between them).

- AMD losing the plot after the K8 microarchitecture, including putting a huge amount of capital into buying ATI instead of pushing their CPU advantage? And then having to sell off their fabs, putting them at a permanent disadvantage until Intel's "10nm" failed? (And what happened to the K9??)

- Anticompetitive marketing and sales?

> Execution-time attacks and other sidechannel leakage have been well-known for years, and I can't imagine that at a place like Intel, nobody had heard of that.

The strange thing is that security researchers assumed for years that Intel was accounting for this, when it turned out not a single one of AMD, ARM, IBM POWER and mainframe/Z, Intel, MIPS, or SPARC did?

And for Intel these bugs go back to the first Pentium Pro in 1995, their first out-of-order speculative execution design. Very cunning of them, along with IBM two years earlier, the SPARC bunch starting that year, MIPS and AMD a year later, and recently ARM as it targeted higher performance to follow the same exactly "strategy".

Or maybe it was an industry blind spot, now a very big deal because so many of these CPUs run other people's random code, JavaScript in browsers, and anything and everything in shared cloud hosts.

Expanding on your points, only AMD, SPARC and MIPS avoided Meltdown bugs, they were also found in ARM, and IBM POWER and mainframe/Z designs. All of these vendors have out-of-order speculative execution designs that are vulnerable to Spectre.

> If anything, the "capture 90% of the market." by Intel as you put it only ensures that these problems will usually be discovered on their processor's first.

Precisely. I haven't looked at the MDS set of flaws yet, but to take the first version of Foreshadow/L1TF, it targets the Intel SGX enclave, by definition the designs of other companies that don't have SGX won't be vulnerable. But as you note this doesn't mean they don't have their own design or implementation specific bugs.

I remember reading that Intel was having TSMC run off the lowest end Altera FPGAs because Intel's fabs were just too expensive.

Other possibilities off the top of my head might be Cadence being able to do stuff that's now required for these smaller and using EUV lithography nodes, and/or a backup in case their "10nm" never makes it, and their "7nm" having problems or also failing. Embarrassment should be preferable to the worst case alternatives, and we have no reason to believe Intel will be able to regain its ability to move to smaller nodes.

They used to charge serious money for it, that would have allowed them the budget to fix enough of the bugs that SMS is now pretty damned good.

Culture is also a large part of it, it's embedded in telcos to such a degree that I and my parents use rather expensive and fairly slow AT&T DSL because its rock solid, every one of my friends and family who use cablecos for Internet have a tremendously higher rate of problems. Cablecos come from a culture where a customer or neighborhood losing connectivity for hours or a day or two wasn't the "end of the world".

The OP is an Android developer, eating the $70 dollars was part of the cost of continuing to do that business.

But it's not going to help their brand or encourage others who are too tied to Google to sign on to services like Fi, and if not with this guy, in general it'll encourage people to find other lines of work.

I suspect so many people are sufficiently tied more or less to Google that the pool able to do chargebacks is small enough it won't prompt Visa/Mastercard on down to take action.

Too many people have too much of Google as part of their lives to do more than the OP did and eat the $70 instead of dropping out of Android development.

And that's got to be how Google can, intentionally or not, get away with such blatant fraud, the pool of people able to escalate is kept very small.

Even in Texas you aren't going to get away with "defending" yourself in this situation without a real physical threat. And gun owners know that, there are very few unjustified shootings of bill collectors or the like, and the really bad cases show clear mens rea.

But I was thinking somewhat along those lines, take a picture of the perp while keeping one hand close to my concealed gun. And you could well be generally right, I'm pretty sure from some of the snail mail I get or that shows up in USPS Informed Delivery that some of the past residents of my current location are dodging bills, but no one's every showed up to my house, nor have I ever heard of it happening around here.

For lots of people, because that would cost them all their other Google accounts and services. The OP would have to give up on Android development.

I am former Fi user, started back when it was a "Project". My Nexus 5X's battery swelled but was still working and had a full charge, they wanted me to ship it back to them which I morally felt I couldn't do, and replace it with a generally low quality Lenovo Motorola phone that was reported to have serious WiFi problems, negating that major part of their business proposition where it uses any accessible WiFi for data and voice if possible. Felt stupid for having paid them $5/month for device replacement coverage.

The G+ real names debacle prompted me to remove as much exposure to Google as possible, now I'm down to Google Groups which can only be had from them. They're just too risky for individuals to depend on.

Note on the engine math: this is a fully reusable rocket, both stages, so on a Mars missions the 31 in the booster would in theory be recovered for future launches from the Earth. Getting the seven back from the 2nd stage, well, maybe sooner or later?

It's pretty clear it wasn't pervasive for ARM because they're climbing to ever higher performance, while Intel reached a conceptual peak in 1995 with the Pentium Pro, and in turn has used mostly Pentium superscalar based cores in their lower performance Atom line. It's implied by the dates of vulnerabilities cited by Google Project Zero I think that Intel's Meltdown original sin goes all the way back to the first Pentium Pro.

> Other companies didn’t do this.

ARM, and IBM POWER and mainframe/Z also did that (Meltdown): https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili... ARM also has a Rogue System Register Read vulnerable design (https://developer.arm.com/support/arm-security-updates/specu...).

As a friend and coworker liked to say, "speed kills", and Google is right that it's a risk, just one a lot of people are willing to take.

Every company with high performance single thread designs has out-of-order with speculative execution designs, ARM, AMD, IBM POWER and mainframe/Z, Intel, MIPS, and SPARC. RISC-V is working on it, with the Berkeley Out-of-Order Machine (BOOM) and perhaps other cores.

And doing research I should have done a long time ago, SPARC V9 has Spectre vulnerabilities (https://www.zdnet.com/article/meltdown-spectre-oracles-criti...), and MIPS made a statement that a couple of their designs were possibly vulnerable (https://www.mips.com/blog/mips-response-on-speculative-execu... and this followup assumes that: https://www.mips.com/forums/topic/mips-mitigations-for-side-...)

When the penalty for revealing it would likely be execution for high treason?

While I'm entirely satisfied with the simple Oswald explanation, you are correct to emphasis how utterly terrible JFK's defense and foreign policy was.

The severe weakness shown in the Bay of Pigs debacle, an Eisenhower scheme he utterly wrecked by moving the location as well as the last minute denial of air support, directly lead to Khrushchev's nuclear missile adventure in Cuba. Which led to the closest the world has ever gotten to nuclear war, Soviet subs were under orders allowing them to use their nuclear torpedoes if damaged, and one captain decided this was a case but the decision required three officers, one of whom declined. (This ultimately resulted in Khrushchev getting sacked.)

There's lots more, but it's also worth mentioning that just a month before he was assassinated, he went along with his Best and Brightests' scheme to depose and inevitably assassinate the President of South Vietnam and his brother, which ruined that nation's officer corps and any trust they had in us, which led directly to our having to replace them with our own forces, and the nightmare that followed. LBJ's prosecution of the war was downright criminal, but at the highest level moral, he acknowledged the "you broke it, you own it" principle.

But one could see members of the Deep State deciding that JFK's assassination of an ally President made him fair game for assassination in turn. And for all they knew necessary to save the nation, he'd been reckless all his life, succeeding in starting WWIII given another 1-5 years was entirely possible.

Isn't one of the "secrets" to AMD's post-486 success adopting the general approach the Pentium Pro took along with others in the 1990s, which in turn are based on IBM's 1960s Tomasulo out-of-order algorithm adding speculative execution? This general approach made all out-of-order speculative designs, including ARM, POWER and IBM Z vulnerable to Spectre, so I submit they're not "completely different".

Because that logic is the same of the drunk looking for his car keys under the street light, rather than the dark area were he lost them.

AMD's server market share is minuscule and dropped as of 19Q1, 3.2% to 2.9%, although healthier and growing smartly in desktops and notebooks, up to 17.1% and 13.1% as of last quarter (I would guess the two are related if the comments made in this discussion about their being fab capacity limited are correct). That means they're less significant targets for researchers than Intel and ARM. We might also assume AMD has less manpower to devote to finding vulnerabilities than Intel has.

These latest Intel vulnerabilities, Foreshadow/L1TF and this week's? They're all targeting Intel specific details, for example the first Foreshadow version targets the SGX enclave. See also ARM's Cortex-A72 Rogue System Register Read (RSRE), Spectre Variant 3a vunerability: https://developer.arm.com/support/arm-security-updates/specu...

The odds that AMD specific features have vulnerabilities than simply haven't been looked for yet is very high, their Spectre vulnerabilities show that they too generally got caught with their pants down.

Which didn't save AMD from Spectre bugs. And everyone else with high performance speculative execution out-of-order designs also had Meltdown bugs, ARM and IBM, both POWER and mainframe/Z: https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...

ARM is more less examined than less vulnerable. Most of their cores aren't speculative execution out-of-order, that's expensive in power and silicon real estate/cost, but they have 13 vulnerable to Spectre, including 1 known for the 2018 Rogue System Register Read which like this latest set for Intel is design specific. It would be wise to assume there are more vulnerabilities hiding, the name Spectre was chosen because we'll be haunted by it for a long time. Also one of their newest designs is vulnerable to Meltdown, see the whole list here: https://developer.arm.com/support/arm-security-updates/specu...

That any discussion of your potential customers "inside" the office, purely between people in your company, is highly to entirely speculative. You've got to get "out" of the office and sell your product, or not, to know. Hence the emphasis on having a Minimum Viable Product as soon as possible to know if there's real demand for it, and at what price.

> All the standard business knowledge and tech knowledge that is common knowledge today had not yet been figured out.

You're right about that. The lean startup, "there's no truth in the office", Minimum Viable Product concepts just weren't a thing back then, they would have saved one of the companies I worked for if the founders had known and accepted them. Instead they spent way too much time in stealth mode, hired a corporate lawyer to get them a bogus patent, were way too worried about competitors instead of ever getting traction for their idea, spent too much time debating details of the website, and who would pay what for precisely what sort of service, and too much upfront engineering to handle a huge demand which didn't materialize due to sabotage by the last round of investors who were found in desperation half a year before launch.

One thing to focus on is how much of the crash was telecom vs. dot.com companies. An excess of fiber was laid, which was a boon to later companies like Google which bought dark fiber at low prices, competitive local exchange carriers (CLEC https://en.wikipedia.org/wiki/Competitive_local_exchange_car...) rose and fell based on changing law and regulations in the US, equipment manufacturers like Lucent were at the whip end of demand, especially since they financed a lot of the purchases of the equipment they were selling, and some of the biggest Internet service providers blew up in one way or another, see Worldcom for example.

The hype? Largely justified, even if the timing was off, there's no denying this has become a very big thing, note Amazon was founded in 1994. For me getting a job was no different than getting one prior to the Internet really taking off in this first wave.

BjoernKW's comments about the job being not tightly defined, and being responsible for many things including raw hardware matches my experience. And "cloud" alternatives to your own hardware, even if installed at a colo, weren't an option, weren't even for the start of 2nd batch of companies following the crash. And like his experience, one of the companies I worked for in the late 1990s lasted through it and way beyond, was independent until a few years ago when they were bought and folded into another company.

One very big difference is that the IPO exit option largely ended for most companies, the Sarbanes-Oxley Act (SOX) in 2002 seems to have been the tipping point.

> #2 aggregated the bugs rolling in for more than a year to minimize impact.

When the impact is new microcode for every out-of-order CPU going back to Sandy Bridge that's not on its face entirely unreasonable. The date for the new microcode for my Ivy Bridge workstation I'm typing this on is 2019-02-13; if testing followed that.... Could even be they wanted to further delay release until they could do more testing.

> They had enough time to fix and release new silicon!

And properly test it?

There's also Same OS, operating system level virtualization, like Docker, it's the less expensive default for https://www.ramnode.com/vps.php for example. Not at all familiar with this technology, but scanning Wikipedia if you used Docker would the libcontainer library be shared between container instances?

> different trust domain cannot seriously benefit from a common cache: their datasets are by definition disjoint.

Datasets, yes, but what about instructions from shared libraries?

I'll make a wild guess this being seriously beneficial would be limited to uncommon server configurations....

> It's interesting though why cross-process data exfiltration based on speculative execution was not tried with any success in the shared hosting environment of 1990s and early 2000s.

According to several of the researchers who found Meltdown and/or Spectre, they'd always assumed Intel et. al. were too careful to let this happen, at least at useful data rates. But when they looked for reasons I forget, Katie bar the door!

I touch on it here: https://news.ycombinator.com/item?id=19650813 which includes a link to their paper on it.

Good point, I was thinking in the context of owning your own (super)computer or mainframe and having control over what ran on it. In the cloud, which to us implies running in a VM with other tenants vs. for example dedicated machine(s) with other services bundled in, anything goes.

In theory is was going to be a bit better than TSMC 7mm, with only 7+nm equaling or exceeding it.

In practice, it's slower than Intel 14nm, denser (better be!!), and consumes less power. And has pesky yield issues, Semiaccurate is convinced it'll never be a profitable node.