Almost all of the microarchitecture changes and die shrinks come out of Haifa, Israel. Not Hillsboro. The Itanium came out of Santa Clara, California. Willamette came out of Hillsboro (the Pentium 4, which was arguably a pretty big failure, with 35%-50% of the 115W power consumption lost to leakage power). There was also the well-know SMT issue, where the dispatch ordering was (effectively) random, meaning the IPC between SMT cores never really scaled very well. Prescott never really scale above about a max of 3.8GHz, when it was (in theory) designed to allow derivatives of the microarchitecture to run at speeds of up to 10GHz.

Generally, most of the machine-building companies I've worked for (Apple, Google) tend to skip the Hillsboro designs for anything but prototypes, and they wait for the every other year die shrink out of Haifa for the actual shipping product.

You mean the "shirked responsibilities" that would be being paid to the lowest bidder in Topeka or Wichita Kansas, rather than in Oregon, were it not for the tax breaks?

The people who build data centers don't care where they are located physically; they care about taxes, land costs, and power costs. If power were more reliable in Kabul Afghanistan, and the local government a bit more stable, they'd be located there, instead.

Because everyone wants to live next door to a data center because of all the jobs there, or why? Why would it be more expensive to live near a data center, than not, if there were no economic benefit to doing so?

If only there were some way to make Oregon economically desirable to businesses...

So you can give the tax breaks, and have the data center built locally, and employ construction workers, ongoing site maintenance workers, etc., which you don't count as employees because they are contractors, yet they have jobs.

Or you can *not* give the tax break, and have a vacant lot, as the data center is built in Kansas or wherever instead.

Pick one.

Sure it can.

It *does*, therefore it can. Proof by example.

Where are the big arrows coming into California from Mexico, China, and Russia, among other countries? That map seems incomplete.

Exactly. That was my take-away as well.

(1) Get a huge government contract

(2) Ignore robots.txt

(3) Profit!

There are commercial emulation chips available, used for testing everything up to the flat panel. You could build your own FPGA if you wanted to, I suppose.

Well, then, very clearly, we need to start giving government contracts to your brother in law's company which manufactures deep oceanic temperature sensors. You know, "just to be sure"...

Think "anomalously long backscatter times"/"anamalous diffusion of backscatter" for energetic cosmic rays. You can refine the specificity for the location utilizing synthetic aperture techniques, but you end up with very thin stripes for each pass over the scanned region. I *did* say "long term observation"...

Note that the Fukushima detectors are a pretty long ways away from the reactor itself, as well as the containment vessel, compared to straight tomographic techniques used to examine cargo containers, say in Oakland.

NB: These days, it's pretty obsolete as a technique, and we use neutrino tomography instead, but there are enough "dark spots" that it's not possible to cover everywhere with the technique. Interestingly, Vernor Vinge "outed" the neutrino tomography technique in his novel "The Peace War", although his details are a bit hand-wavy and wrong.

Generally we don't have to worry about being shot down when we fly a constellation of high altitude aircraft over North Korea without their permissions in order to create a synthetic aperture large enough to be meaningful, so it's OK for filling in the dark spots there. You wouldn't want to run the same flights over Russia, even at 90,000 feet these days.

PS: In case you missed it, there was a story the other day bemoaning the lack of noble gas detectors to detect by-products of fission plant operation, but they also wanted some better generalized climatological models (read: give us lots of money for supercomputer hardware to play with) in order to determine the origin, should noble gasses be detected with their new detectors.

This article is specifically about Silicon Valley Day Care.

Which I think is probably code to "The day care next door to Marisa Mayer's office", but even if it's not, in the companies I've worked in in SV, they were a substitute for a babysitter to get mothers and fathers back to work as quickly as possible following a birth, without paying them enough to be able to afford a nanny. They took kids from a few weeks old up to age 4.

You can have stuff *like that*, but it's not going to be the same stuff, it's going to be *new stuff* written in VB.Net or C#.Net.

This would be fine, if anyone had liked some of the intermediate Windows releases, and gone forward on those platforms, instead of running more XP systems because they freaking *HATED* "ME", "Vista", which is why they never achieved sufficient market share to displace XP. This should have been obvious when everyone avoided "200" and instead went for XP when it came out.

Instead, the vertical market code is still living on the old VB platform on XP.

While VB6.0 apps *can* run on Server 2008, Windows 7, and Windows 8 platforms, most *don't*.

First of all, the Server 2008 platform is irrelevant for vertical market apps, since they run client side, not server-side.

Second, you can't use Office 2000 as an installed application on the new platforms, you have to use Office 2011 and 2013, and the DLL components that make up the components you'd use in the vertical market app are sufficiently different from one another that you'd have to pic running one or the other anyway. Which would be fine, except Office 2013 requires Windows 7 or above to install. So basically, if I want new Office, I have to tke new Windows, and vice versa.

This means that you have to do a re-buy, or you have to have two versions of your vertical market application.

To add insult to injury, it's practically impossible to force the newer versions of Office to use the older file formats at the DLL level, without reselecting the settings every time you save a document. So if your vertical market app has to communicate data between an older and a newer workstation instance, even if you invest in rewriting you vertical market app from scratch to move off VB 6.0, it's most non-interoperable without a bunch of "Can you re-save that document in the old office format so I can use it? Thanks.".

At a minimum, if I'm a small business with 20 employees, and I want to add 3 more, I am pretty much screwed, unless I've done one of two things:

(1) Pre-bought a bunch of XP systems and stuck them in a closet in case I wanted to hire someone, or someone's computer dies

(2) Paid to move everyone forward onto at *least* Windows 7 and Office 2003, and paid to have my middleware rewritten.

Even so, there are a lot of third party DLL components that simple *are not available* as 64 bit versions. So I m either SOL, or paying to duplicate their functionality, as well, in order to get my dentists office / collections agency / non-profit call center / POS systems / whatever vertical market app, back online.

---

So like I've said: they've missed the boat for about 70% of their market, which simply can not afford to redo everything all at once.

They *REALLY* needed to deprecate the OS and the applications components - Office - and the applications platform - VB 6.0 - *separately* so that SMBs could do overlapping buy-forward, which is more in line with the fact that they are constrained in their instantaneous purchasing power by being in a cash flow business model, but relatively unconstrained in their over time purchasing power, for the same reason.

Frankly, they *could* have maintained component binary binary compatibility, while deploying a new office.

The actual order should have been:

(1) New windows with VB 6.0 and Office binary backward compatibility
(2) Deprecate XP and force people OS-forward with (relatively) little pain

(3) New Office with component binary backward compatibility, requiring new OS

(4) New VB.Net capable of running VB 6.0
(5) *GOOD* source translation tools that warned about coming incompatibilities. Include translation to C# instead of VB.Net for extra good will

(6) Deprecate VB 6.0 in favor of VB.Net / C#
(7) Deprecate old Office DLL APIs that were warned about in #5; force migration to new DLLs for new installs of Office used as components

This would have allowed layered buy-forward into the new ecosystem without crapping on anyone's business that they've been running on a vertical market since 1991.

Microsoft sold everyone a bill of goods with their component architecture, and then failed to carry through on component reuse going forward.

And I would say that that is about 70% of their installed base.

Me too. I electrically emulated a LVDS flat panel and reconstructed the high resolution image from the LVDS.

Works great for BluRay encryption, and for projectionist monitor screens in movie theaters, too, since the flat panels themselves are *after* the content decryption.

We've been using muon detectors for over 40 years to detect nuclear-related activities in various countries, including reactor installation, stockpiling, bomb-building, and so on. One of the reasons for the ability to move MX missiles around underground was so that long term muon detector observation by the Soviets could not pinpoint the location of the missiles.