If you are wondering why many people hate updating working systems, no matter what the security implications, look no further than this.

Time and again it is an innocent security update that would end up in a reinstall, finding a bunch of bloat ware on a system, losing critical functionality, data loss and time lost.

Updates should be restricted to the absolute minimum and tested to the point that deploying them does not put customer data at risk.

Notably, this is the second time in a few months that this happens. The previous one was a microcode update, though that one was Intel's fault (according to Intel, it happened only when the microcode was loaded by the kernel; they probably had tested only loading it from the firmware).

> according to Intel, it happened only when the microcode was loaded by the kernel; they probably had tested only loading it from the firmware

I followed the Spectre situation quite closely, and never heard anything along those lines. Do you have a source?

Many system vendors pulled the faulty firmware from their own sites, and Dell went so far as to recommend rolling back if you had installed it, so the partner ecosystem didn't want people running the firmware at all.

> I followed the Spectre situation quite closely, and never heard anything along those lines. Do you have a source?

Sure, it was this one: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

"Intel identified an issue when OS loading microcode update revision 0xDC for cpuid 406E3 and 506E3. The microcode update has been reverted to revision 0xD6. This issue does not affect the microcode update when loaded from BIOS."