[digi_owl]

Too bad my laptop can't use those crimson drivers, as AMD no longer support the APU part of the setup that make things like external displays work (and will you please stop trying to be helpful and silently "upgrading" my drivers, Microsoft!).

[pixelcloud]

You can disable driver updates through group policy.

https://technet.microsoft.com/en-us/library/cc730606(v=ws.10...

[digi_owl]

Could have sworn that MS had disabled GP access on "consumer" grade installs.

[graycat]

> and will you please stop trying to be helpful and silently "upgrading" my drivers, Microsoft!

Or, I finally got it to appear to work. Details on how it really works, the documentation didn't really say. Why it works now, I don't really know. I never understood it well and, instead, just threw it against the wall in various ways until it appeared to stick.

Another point is, after such a remote Microsoft change, I no longer really know what went into my system or relevant boot partition or how to rebuild it starting with what I already have. That is, when I built the system, I took careful notes on just what I did so that I could retrace if necessary; with remote changes from Microsoft, my notes are now inaccurate. My system is no longer reproducible. So, if next week I make a change that ruins my boot partition, then I can't rebuild to just before the change -- unless I have backed up that boot partition with, say, NTBACKUP which I do use. Indeed, with the system I am building now, I'm planning a boot drive with several bootable partitions and a second drive with backups via NTBACKUP (if that is still the best approach on Windows) of various increments of the boot partitions.

That is, in general I very much want to know just what, and quite generally and in as much detail as possible, (A) the heck is on my system and (B) how to get back to some earlier state.

All this skeptical caution is a special case of rules:

(1) If it ain't broke, don't fix it.

(2) If anything can go wrong, then it will.

(3) There is no independence; if you change one thing, then no telling what else may be affected.

(4) The fundamental perversity of material objects.

etc.

I very well remember, from when I was at IBM's Watson lab and we visited some high end customers, how when IBM came out with a fix, update, change, or new version, the site would run the change for months just on a test system before they permitted it on-line for production work. Part of this was, if the system crashed for an hour, then the CIO could lose his bonus. Two such in one year, and he could lose his job. They very much did not want systems that crashed. They were very clear about that.

Once, out of IBM, I visited the main NASDAQ site in Trumbull, CT: They were doing their core work on Non-Stop systems. IIRC, their attitude was that their Non-Stop systems didn't stop and didn't need updates.

Here is some irony: First the vendor sells their system as the greatest. Second, the vendor says they have an update.

Hmm .... If their greatest needs an update, then how about the update?

To borrow from the movie The Treasure of the Sierra Madre, "Updates? What updates? We don't need no stink'n updates."