"Here's a patch" - "Here's a patch to disable that other patch" - ...
What's next? Repeat? Sounds like this could turn into a maintainance nightmare quickly. Also because I've introduced things like that myself in the past, and that was for normal applications and not a kernel or OS. Somewhere, someday, there's usually this one exception for which none of your rules hold true and the thing blows up in your face.
Anyway, I'd love to see the actual code for this. Not a chance probably?
Im really wanding they had more than 6months to do these patches and they did not bother testing on a good number of systems. Its not like MS + Intel dont have enough money to buy a few 1000 testing machines and get some testers on it.
Have you released a bugfix to a large application? I've had one line fixes break some use case I hadn't even heard of before, and it doesn't always show up right away, either. Intel's fix has to work on every application in every version of Windows, macOS, Linux, for multiple versions of processors with multiple different chipsets. And it has to be done yesterday. That's a nightmare scenario.
I think Spectre may have appeared later, after Meltdown? Remember the investigations into what's possible were proceeding in parallel with the attempted fixes.
Also, CPU design changes take a long time. 6 months may seem a long time from the perspective of HackerNews node.js type hackers, but it's a bit harder to patch decades worth of CPU microcode than a website.
I get it may take a long time (that is fine even if the patches took a few more days), what I don't get is that they released it to production (server) envs seemingly without testing. Surely even rudimentary testing (deploying on a few 1000 different server platforms for a few hours at least should be something that Intel does for all microcode updates, after all they are rather more important than js Node packages as you point out)
I haven't heard of microcode updates that hurt stability before. Presumably the collapse of the embargo caused them to do an accelerated release, skipping their usual long testing cycle.
Currently, they are not patching a decade worth of CPU microcodes since we have 0 working microcode. And, previously, released microcodes were only down to Ivy Bridge EP (~2014).
What's next? Repeat? Sounds like this could turn into a maintainance nightmare quickly. Also because I've introduced things like that myself in the past, and that was for normal applications and not a kernel or OS. Somewhere, someday, there's usually this one exception for which none of your rules hold true and the thing blows up in your face. Anyway, I'd love to see the actual code for this. Not a chance probably?