> This error occurs because new processor generations require the latest Windows version for support.
Can someone explain this better? It feels like the direction of 'support' has been inverted. I thought all these new CPU's were supersets of the instruction set of previous gen i386/amd64 processors?
IMHO, it feels like just another hamfisted way to get the adoption of Windows 10 to increase. The whole point of Windows used to be that it would run on nearly every system, with most overhead being reactivating the license, now you'll actually find yourself re-installing an OS that refuses to work on a newer processor.
They're closing the gates to their pseudo-walled garden. Windows 7/8 don't have permanent revenue streams, WIndows 10 does (or will).
For all the song and dance of Windows 10 being superior, Linux seems to not care at all about what processor it runs on.
Linux seems to not care at all about what processor it runs on
That's not true, there definitely are unsupported (Intel/x64) CPUs for Linux. It even prints a lovely warning on boot to not file any bug reports because you're using an unsupported CPU.
But, what Linux does (often) do is make it possible to get a kernel patch or upgrade to add the missing support.
Outside of an all-volunteer ecosystem, like Linux or the BSDs, supporting and validating software on a particular processor family costs time, money, and ties up engineering resources, you know.
It's not just Windows that has this issue. I recently had issues trying to add new Intel servers to an existing cluster. The new servers had a CPU that was too new to be supported by the older (CentOS 6 based) Linux OS that the cluster was running. Now, this particular problem was fixed in the kernel and pushed in the next point release by Red Hat. Unfortunately for us, it never made it to the upstream cluster OS vendor, and we weren't able to patch the supported kernel, so we were stuck for those machines.
Intel's Skylake processors caused kernel panics on earlier Linux versions, but that never affected Windows, and Microsoft still supports Skylake on 7/8.
And Kaby Lake is just a rebranded Skylake with higher clocks, with no hardware differences. So this is just Microsoft fucking over users.
You do not buy a perpetual support license with those OSes.
The cost of those operating systems was for a given list of compatible hardware. Windows 7 support ended, Windows 8 support ended, and Windows 8.1 is no longer sold, but still supported (so security patches still arrive).
Like it or not, I understand MS, as backporting and re-valdating anything is a huge cost. Been there, done that, although for embedded systems.
1) this is almost certainly a partially arbitrary limitation, since Kaby Lake is architecturally identical to Skylake, yet one is supposedly supported and the other not, and
2) AMD Ryzen hardware has already been sold with the explicit promise by the vendor that it will have Windows 7 support; Microsoft is now breaking that promise.
Also, you may be misinformed regarding how Microsoft's support lifecycles work. MAINSTREAM support has ended for Windows 7 -- which means no new features -- but it still receives security patches until 2020. So does Windows 8 and 8.1. In fact, even Windows Vista still receives security patches until April 11th.
It seems like what's happening here is that they pushed out a patch that maliciously UN-supports certain hardware. I was running Windows 7 on Kaby Lake fine yesterday and receiving security updates, and now they're telling me I can't. Why? All the chipset drivers are third party and have nothing to do with Windows Update.
> You do not buy a perpetual support license with those OSes.
Well, when it come to Windows 10, I would say that yes, we are effectively paying for a perpetual support license. If Microsoft is comfortable throwing ads at me as a part of normal OS operation (and they are, and keep putting them in new locations I have to disable individually), I'm comfortable saying that I'm paying them perpetually.
Most people are paying them money for a version of windows that works with the hardware they are buying. You won't be able to find an OEM selling win 7 on a ryzen box, for example.
If you buy a separate license, you should be aware of compatibility as well.
and still they contain bugs sometimes, which need software workarounds. If interested in the topic you can surely find several examples in the Linux source codes as well.
Contemporary commodity CPU's have all sorts of features that important customers want [1]. You probably are not an important customer if you don't own multiple large data centers of the sort located next to hydro-electric dams and who causes price drops on used high end Xeons when you upgrade the data center hardware.
The CPU inside a CPU is vulnerable and it changes with every tic and toc. Windows 7 is pushing 8 years old and was designed around older and almost certainly early generation Management Engine designs (and perhaps a few down the road iterations of it). But it wasn't designed with data from the field about attacks and exploits. Windows 8 is largely a reskinning of Windows 7 and probably has similar vulnerabilities in regard to accessing the CPU in the CPU if such vulnerabilities exist.
Windows 10 has a somewhat different architecture and almost certainly has been designed considering ME and AMD's spin on it from the ground up and reflects all those years of experience from field deployments and the CPU vendors current roadmaps. Importantly, Windows 10 is designed with the idea that future experience will require changing the code.
Anyway, my suspicion is that the internal security model of at least some contemporary chips are considered to have probable or actual vulnerabilities exposed by Windows 7/8 and the business decision is that the most effective way of mitigating those vulnerabilities is simply to not support the consumer use case of buying new hardware and then running old versions of Windows on it.
The business case I am imagining runs along the lines of how much damage would Microsoft suffer if there was a problem versus how much damage it suffers from pissing off a handful of edge case users (considering that the majority of the noise will come from people who don't use Windows).
ME relies on security by obscurity (and hence the motivation of some for open source code). Of course that's not proof.
But I wouldn't rely on a Skylake ME's integrity for a public IP'd computer if it was running Windows 98 because it can be pwnd in ways that a Pentium Pro can not: replacing the disk drive won't get ownership back.
> I thought all these new CPU's were supersets of the instruction set of previous gen i386/amd64 processors?
Yes and no. People seem to forget that CPUs are not magical and can have bugs. On top of that, each processor family and processor stepping[0] have their own distinct bugs. (An example list can be found at [1], starting on page 8.) Well known incidents include the Pentium FDIV bug[0] and the more recent TSX bug[1] but there are a whole host of lesser ones that never reach the public consciousness because the OS works around them, e.g [2]. Needless to say, creating these workarounds takes time and effort and re-testing and that translates to money. And anything that costs money, well, ...
Can someone explain this better? It feels like the direction of 'support' has been inverted. I thought all these new CPU's were supersets of the instruction set of previous gen i386/amd64 processors?