Intel has already had so many flaws and vulnerabilities that I think nothing will change. People would prefer to ignore the problem and do nothing because they don't want their businesses to implode.

I wish the updates for Spectre/Meltdown were optional on my Windows machine. They posed no real risk to my single-user gaming machine and the fixes had an unacceptable performance burden IMHO.

They are, you can disable them in the registry.

> They posed no real risk to my single-user gaming machine and the fixes had an unacceptable performance burden IMHO.

Where are you seeing a performance burden? The spectre/meltdown patches had no impact to game performance: https://www.tomshardware.com/reviews/gaming-performance-melt...

Are you sure they are not optional? I remember disabling various security updates at the time, but unfortunately I wasn't testing whether performance in games was affected positively after removing them. I can only say that it felt as it had been faster, but I hadn't measured FPS.

My understanding is that newer Windows version contain microcode updates for the processors, and once they are applied, they are in there for good.

Microcode doesn't flash the CPU, it's loaded at boot time, you can remove it and disable the software mitigation.

Same on my Chromebook Pixel LS too. They were optional but now they added all kinds of additional mitigations and are also adding linux throttling and in the last 6 months or so I probably have gained ~60% compile time.

There's a performance mode that Google has a support article for. Google exactly "Change your Chromebook’s performance setting", and you should see it.

If lscpu still shows some offline cpus (let's say cpu 1 and 3 are offline), echo 1 >> /sys/devices/system/cpu/cpu<1 or 3>/online. Run lscpu again, and you should see all CPUs online and 2 threads per core.

Do you not browse the web on that machine?

You can toggle/check mitigations with a program called InSpectre.

the closest I can think of was the famous floating point error that caused Intel to recall lots of parts[1]. Even that didn't render the CPUs useless for most users, only some scientific and business use cases really had problems.

[1] https://en.wikipedia.org/wiki/Pentium_FDIV_bug

>Thomas Nicely, a professor of mathematics at Lynchburg College, had written code to enumerate primes, twin primes, prime triplets, and prime quadruplets. Nicely noticed some inconsistencies in the calculations on June 13, 1994, shortly after adding a Pentium system to his group of computers, but was unable to eliminate other factors (such as programming errors, motherboard chipsets, etc.) until October 19, 1994. On October 24, 1994, he reported the issue to Intel.

Can you imagine debugging this for that many months only to find out there was nothing on your end to fix.

I spent an entire summer as an intern, constantly on the phone with IBM support trying to get DB2 Connect to work in a Windows cluster only to be told "this is not a supported configuration" despite it being clearly supported in the documentation. Gave up. Years later, ran into my former boss randomly (at a liquor store of all places) and he mentioned they were finally able to get it to work.

Another confounding one was where I was trying to bulk copy some data to Sybase using Python. Started getting some really strange DB errors. Couldn't figure it out for a while. Turns out, it was a bug in the DB module and it was using uninitialized memory in certain conditions. Was a 1-line fix, but took about 6 weeks to find.

Yet another one was when I was working on porting my C++ services from 32 to 64-bit. Sockets were timing out immediately sometimes. Couldn't reproduce in the debugger. Was a bug in a 3rd party framework. It was improperly using the rtdsc instruction in some inline ASM. Worked fine on 32-bit, but the register layout was different on 64-bit. So, it was effectively reading a garbage upper 32-bits for the high-res timer. Only found that one because I noticed in my logs that my timers were reporting that some operations had taken >200 years. I forget how long it took to track that one down, but it was months of off and on hunting.

I've also hit internal compiler errors. The one I remember was that an anonymous namespace at global scope would cause an ICE. I was about to file a bug report once I'd a minimal reproduction, but it'd already been reported and fixed.

I had a similar experience when doing my first serious work in a compiled language. I found and reported a compiler bug in double-precision division (in a commercial C compiler). It took me years to stop blaming the compiler for my bugs.

I had the same, an embedded system with GCC 3.something. Managed to get a toolchain together with 4.something and suddenly our uptime and random corruption issues disappeared.

My memory is hazy but I'm sure I recall the problem during summer 94, but I stand corrected. Was there any normal way for the information to reach us? That was the year intel took down Vlsd Pentkovskis profile page.. I loved to tease everyone that Pentium was named tribute to him...

Edit:typo fixed for pentium

"Render useless" makes me think of something more like the F00F bug - hard lockup until a reboot.

https://en.wikipedia.org/wiki/Pentium_F00F_bug

OS vendors worked around it in software.

And as I recall Linux had a kernel patch that would bypass the affected hardware and run all floating point operations in software (splitting floats into two integers, etc), so you could bypass the flaw at the cost of performance.

I remember Linux having floating-point emulation for 486 processors without a floating point unit. But at least according to this early message from Torvalds, Linux didn't implement this for FDIV:

> It wouldn't be impossible, but it's not something I will do: this isn't a problem to be solved by the OS, but by Intel or the user. The fdiv bug isn't a problem for most people, and for those that it is, it's more efficient to make the compiler do the bug work-around instead.

> Note that doing it in the kernel would mean trapping for every fp operation, and that's not good for a fp-intensive program: and the main programs which /would/ care about the fdiv bug are the fp-intensive ones.

https://groups.google.com/d/msg/comp.os.linux.development/4o...

Googling around it seems the typical solution, other than just doing nothing, was to recompile, as GCC had a patch to detect the FDIV bug and emulate division much more efficiently.

I only had a 486SX (no FPU) at the time so it was never really on my radar. Non-scientific software didn't really do floating-point arithmetic precisely because FPUs weren't very common on consumer hardware. Most of the people burnt by the FDIV bug were already well positioned to either recompile their software or receive patches from their vendors.

not OP but i always assume Linux had a workaround. But you are right, it just prints you got the bug and that's that

https://github.com/torvalds/linux/search?q=X86_BUG_FDIV&unsc...

People patch, or seriously consider patching, their compilers -- unfortunately. See for example: https://bugzilla.mozilla.org/show_bug.cgi?id=1596565

Maybe it doesn't quite fit your criteria completely, since there is also a microcode workaround. Still...

The driver for recalls is demand from the largest customers. In Intel's case, mostly big cloud operators.

They have a strong vested interest in pretending that sharing compute resources across customers is a safe thing to do, so they're unlikely to rock the boat.

Seriously this isn't humor, we're running a "abandoned " processor for authentication and a operating system decidedly unattractive unless you want to win capture the flag at deacon. We abandoned the secure operating system version very reluctantly so it was formerly B book.

I’m having difficulty understanding this comment, would you mind explaining it a bit more?