Yes, I agree with all.
Except the conventional wisdom of applying updates without fully testing them in test systems exhaustively and letting them “age”.
But on that practice I am pretty much contrarian to all admins.
Admins, I get it, have the job of applying system updates.
But they don’t have the authority to order exhaustive system tests... which would be whole projects in and of themselves that would involve business users and other IT folks, significantly... with no perceived benefit for the business user community and use of tons of their time and effort.
So, in lieu of comprehensive system testing... sys adms simply have to apply system updates on their own schedule.
The “conventional wisdom” that has been pushed on everyone is to continuously apply every update as fast as possible, i.e., keep up.
Skip no updates, apply them all as they come out as soon as possible.
Unfortunately, every update is not secure.
Therefore, the apply all as fast as you can practice actually guarantees that every insecure update will get applied at some point in time.
So the admin does not avoid any vulnerabilities, he installs every one, followed by its fix at some point, along with succeeding new vulnerabilities.
The best strategy for security, of course, would be to search for, test for, and build configurations that had a combination of updates that was secure, as much as can possibly be determined by researching the vulernabilities of each piece of software and its updates. Every server configuration deemed ready for production would have a combination of updates applied such that the system either had no vulnerabilities or had workarounds that were properly implemented for those that were known.
But alas, this is too much work.
... for little perceived benifit by the business owners. It is really hard to prove a negative, i.e., if you force the BU to fully test patches (and other updates), you won't have as many errors.
Sometimes you can, but folks who aren't serious nerds don't generally understand how computers do their various magics in the first place, so explanations are lost on them.
Many moons ago, I worked for MCI. We had a really awesome lab facility that had copies of every bit of hardware installed on the network, so we could do full integration testing of all patches, updates and upgrades. It was freaking excellent. The "as-built" docs were astoundingly detailed.
So, MCI was bought by a criminal organization known as "Worldcom" so as to keep a ponzi scheme by the mastermind of the criminal organization afloat.
I recall an email conversation that followed a rather large outage that occurred on the Worldcom side of the house. The WC guy asked, why the MCI side hadn't expedienced the particular outage when patch "X" was applied to their switches. The MCI guy replied, well, when we loaded it in the test systems in the lab it broke stuff, so we sent it back to the vendor and held off deploying it. The WC guy response was essentially "you tested it first?" Uh, yeah bud. this is a multi-billion dollar corporation, we test our stuff.
Personally, I really like the idea of not having to reboot for kernel updates. There will always be exceptions. From what I read, there is some stuff that just can't safely be hot-patched because of dependencies. However, for routine stuff, it's a Godsend IMO. Computers should almost never have to be rebooted. The concept of monthly reboots is an artifact of the shoddy code produced by Microsoft. Real computers don't need monthly reboots, and IMO, anyone who recommends them is not someone I'm inclined to listen closely to.