when Ritsuko times out

It’s been nagging away at my mind now, but just recently I’ve found the final piece of the puzzle – why I really don’t trust Intel… or should I say, I trust Intel less than AMD.

Back when Intel released the first generation X-25, people were ecstatic. Then after using it, they found that, like all solid state drives, the performance decreased over time, the reasons for which are out of the scope of this blogpost but can be found on Anandtech. The industry’s solution was a little command called TRIM. Practically everybody scrambled to support it, because it, in conjunction with an OS that supports TRIM, mitigates the performance decrease over time in solid state drives.

Except for Intel, which released a new X-25 G2 drive that supported TRIM. The owners of the first generation X-25 were left without TRIM, even though it was simply a trivial update to the firmware that would solve the problem.

This is just like the Intel which omitted VT-x extensions from every CPU except for the C2D E8xxx and Q9xxx series, until Windows 7’s Classic Mode required virtualization, only then did Intel slowly start releasing models with VT-x support. AMD had virtualization extensions from its cheapest Athlons up to its highest end models.

This is, of course, the Intel that left Socket 423 users dead in the water when they suddenly moved on to Socket 478 for the Pentium 4 CPUs. Or the Intel that released Celerons without L2 cache… except that didn’t work, because AMD CPUs outright killed those in performance.

This is also the Intel that’s currently making HyperThreading a high end option, one that’s clearly only for Core i7 8xx and 9xx CPUs. When in fact HyperThreading, as Intel boasts, only requires a small part of the die space.

And this is also the Intel that, for a more recent example, is abandoning support for the GMA500 chipset in Linux. There are open source drivers for Poulsbo, of course, but they are broken.

To add insult to injury, we get this kind of a response from Intel.

If some of the device drivers are closed, what does it matter? The system is “embedded” — it’s tied closely to the actual hardware present on the platform — and the user is never expected to change anything about the core system, neither hardware nor software. Even the manufacturer might not ever expect to upgrade the firmware on the device, once it’s shipped. Closed drivers? Who cares!

Not only is there no significant penalty for closed drivers in the device world, sometimes, they work out better. There’s a business advantage, in terms of vendor lock-in. If I’m a chip maker, my customer has to come back to me for a new driver or source-level license (with non-disclosure agreement) when they begin working on a new product model, or a firmware upgrade. In the thin-margin world of device parts, that kind of ongoing revenue stream might make the difference between getting by or having to lay off engineers.

nVidia would make the same argument. But nVidia at least has had regular updates for later kernels. No, “the user is never expected to change anything” is NOT a valid argument, because people can and will change things, inevitably. Hell, I wish they’d just all switch to AMD en masse already. R200/RV250 support in Linux is alive and well, and in Mac OS X too.

By now it should be painfully obvious that Intel doesn’t care about its customers… except, perhaps, for the HPC crowd. After all, there’s quite a few Nehalems in the Supercomputing Top 100 list. Which brings me to the sad part of this: Intel doesn’t have to be an asshole. If it wants to, it can surely get the job done.

Which is why I’m going AMD for my next build. And heaven forbid that I ever buy anything with Intel integrated graphics in it ever again. One GMA950 is bad enough, don’t get me started on its horrible 3D drivers.