Timeline for Patching Mechanism and security holes
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21, 2011 at 8:26 | vote | accept | Yasser Sobhdel | ||
| Apr 19, 2011 at 9:29 | comment | added | Rory Alsop♦ | @Yasser - just to add to @Graham's point. 1 and 2 are often incompatible: the vendor wants to test as much as possible to avoid disrupting systems, but unless a critical patch is deployed rapidly, attackers could cause major disruption. The result - a trade-off. My advice to everyone is to maintain a test version of their production environment and fully test all critical patches there as soon as they become available - then rollout to your live environment once you have confirmed the patching will work successfully for you. | |
| Apr 19, 2011 at 8:45 | comment | added | user185 | @Yasser that comes down to my point 2: the amount of testing. Patches occasionally interfere with third-party applications too, but it's usually the change in behaviour of the system after the patch is applied that causes issues rather than the mechanics of applying the patch. | |
| Apr 19, 2011 at 8:23 | comment | added | Yasser Sobhdel | In a small order, this could be right but assume an operating system as vast and user-friendly as windows or others, could this update affect other sides of operating system (i.e., unwanted side effects)? | |
| Apr 19, 2011 at 8:10 | history | answered | user185 | CC BY-SA 3.0 |