Windows NT used to give you a whole bunch of details when it hit a BSoD - NT4 bluescreens were wildly informative, but to the average user, completely useless. It was just a bunch of numbers that had no meaning to them or provide them with any pointer to what the problem was. It didn't help that many drivers adopted the 8.3 naming convention making it even more obscure.

Also completely useless because the screenful of information was there but you couldn't do anything with it - you couldn't print it or anything. Windows 2000 simplified it a lot but was still mostly useless - now instead of a screenful, it just showed the stop code with parameters and the module that triggered it. But again, mostly useless information.

The information was contained in the kernel core dumps = the critical bits in the minidumps that it creates that could be loaded into a debugger, or a full dump file. These were much more useful because you could do a post-mortem examination using a debugger with full symbols. (The data for the dump files was written to the swapfile - since the BSoD meant the kernel could not be trusted you couldn't trust the filesystem or disk block driver stack to be working, so the BSoD code would write the core dump to the known blocks of swapfile using direct disk access - it's why there are "text mode" drivers). The next reboot when the kernel starts and initializes the filesystem, before it starts swapfile it checks the swapfile for the dump and if it's there copies it to a new file.

But there were a lot of stop codes that were completely odd but the cause was hardware. There was one that basically said you had bad RAM, another one that would tell you your CPU was overheating. a third that would happen if your disk was dying, and some of the odder ones caused when your GPU was dying and causing PCI bus errors.

It was straightaway - if you see this error, replace RAM. If you see this error, check the heatsink. This error means your disk is dying. You never saw the errors for anything else.

"A hypochondriac and his money are soon parted."

That is why I run memtest86+ for several days on new RAM. I once had an Infineon module crap out after about 2 days.

ECC on memory is 1-error correction 2-error detecting. On 3 errors it will just correct to the wrong value. I agree that the warning is nice (if your OS gives you one and you pay attention to it), but relying on the correction is pure foolishness.

State funeral for a felon? That would be a first.

But I am looking forward to reading the obituary. Always a good thing and cause for celebration when a fundamentally rotten and evil asshole leaves this world.

In civilized countries, suicide is quite legal. I am not surprised you apparently do not know that. Seriously, dude, think about maybe being less cringe and stupid?

And in Germany, this may be a "covert surveillance device", which is even illegal to own.

I actually had to write a paper check recently. Took me 30 minutes to find my darn checkbook.

No, it would piss off a lot of the other passengers - even though it is legal behavior.

Talk to someone who does street photography about their confrontations sometime.

I only knew two people who wore Google Glasses, and honestly - they tended to frequently be assholes even before they got the glasses. The addition of the Google Glasses just exacerbated their personality issues.

Members of the current administration will certainly talk about anti-competitiveness, along with a copious amount of Trump spewing random unrelated crap when he gets asked about the merger - but then Netflix will funnel money to Trump in some manner and the deal will get done.

Netflix might buy into the ballroom, it might promise to develop "Trump: The Making of a Beloved Modern King", or money will quietly flow directly into the Trump family's pockets. One way or the other, this is going to be allowed to happen.

One major difference, assuming you've got full platform support(should be the case on any server or workstation that isn't an utter joke; but can be a problem with some desktop boards that 'support' ECC in the sense that AMD didn't laser it off the way Intel does; but don't really care); is that ECC RAM can (and should) report even correctable errors; so you get considerably more warning than you do with non-ECC RAM.

If you pay no attention to error reports ECC or non-ECC are both rolling the dice; though ECC has better odds; but 'proper' ECC and Linux-EDAC support will allow you to keep an eye on worrisome events(normally with something like rasdaemon, not sure what other options and preferences there are in terms of aggregating the kernel-provided data) and, unless the RAM fails particularly dramatically and thoroughly, will give you much better odds of knowing that you have a hardware problem while that problem is still at correctable levels; so you can take appropriate action(either replacement, or on the really fancy server systems, some 'chipkill'-like arrangement where the specific piece of DRAM that is failing gets cut out of use when deeemed unreliable without having to bring the system down.

Sometimes you'd get a BSOD that was a fairly clear call to action; when the error called out something recognizable as the name of part of a driver; but that is mostly just a special case of the "did you change any hardware or update any drivers recently?" troubleshooting steps that people have been doing more or less blind since forever; admittedly slightly more helpful in cases where as far as you know the answer to those questions is 'no'; but windows update did slip you a driver update; or a change in OS behavior means that a driver that used to work is now troublesome.

Realistically, as long as the OS provides suitable support for being configured to collect actual crash dump material if you want it; it's hard to object too strongly to the idea that just rebooting fairly quickly is probably the better choice vs. trying to make the BSOD a genuinely useful debugging resource; especially given how rare it is for the person with useful debugging ability to happen to be at the console at the time of crash(rather than just an end user who is ill equipped to make sense of it; or a system that mostly does server stuff, quite likely not on actual physical hardware, where nobody has even touched the physical console in months or years; and it's more or less entirely useless to display a message there; rather than rebooting and hoping that things come up enough that management software can grab the dump files; or giving up and leaving the system in EMS so that someone can attach to that console.

Not that suprising with a software person.

With ECC, memory will go "bad" too, just a bit later. If you buy good quality memory, it will be fine for far longer than the time you are going to use it. Bad memory will overwhelm ECC way before that time.

AGI? Hahaha, no. The fake just gets more complex.