But the other side of that is that from a developer perspective, the #1 thing in security is about fixing bugs. Yes, you want to be conservative so that bugs you haven't fixed yet don't cause problems, but that "be conservative" absolutely *has* to be priority #2. Because no amount of conservatism is going to help you unless you actively fix the bugs. And the thing is, a locked-up machine is really really hard to debug. I can tell you from experience just what the bug reports will look like, but I think you can guess. So locking up is one of the worst things you can do. You are pretty much always much better off making forward progress and try to report the issue. Including for security reasons. Because you'd rather have a security issue today that you can debug, and fix for tomorrow. A dead machine with a bug you can't debug is not actually suddenly a really secure machine. Because somebody will just figure out a way to take advantage of *that* bug too indirectly. Being able to kill machines at your leisure is a great way to stress other parts of your network, and suddenly that dead machine might be a big security hazard when somebody figures out a weakness elsewhere ("Oh, look, there's a bug in the fail-over that allows me to do X"). Linus