On Sun, 04 Mar 2018 23:50:32 -0500, Ruben Safir said: > Don't pretend to understand what I can and can not afford. Your not > picking security policy for Google. What your failing to address, > because you are so blinded to your own frame of reference, is that your > solution leaves out well over 90% of the devices connected to the > internet, some of those devices connected to things like nuclear power > plants. Others are just VOIP appliances. Give an example of a system - *ANY* system - where you *can't* afford the time down for a reboot, but the downtime for a hardware failure *is* acceptable. If you connect something to a nuclear power plant and can't afford a reboot time, what is your plan if the device fails entirely? If you can't stand your VOIP box being down at 3AM when there's no calls in progress, what do you intend to use for voice service if you're down because a DIMM failed? Don't confuse "the downtime for a reboot pisses me off personally" with "if we take downtime at all, it's A Serious Problem". If it's the former, then you have to learn that reboots are like changing the oil in your car - refusing to do periodic maintenance will bite you eventually. If it's the latter, and you *aren't* already doing things like HA to deal with hardware failures, *you are being negligent*. And yes, we're talking in "court of law" mode here for some things - if you knew that downtime would cause damages (either physical or monetary) and you didn't do anything about it, you better have a *really* hefty insurance policy covering negligence on your part. And if you *are* doing stuff to deal with hardware failures, *then a reboot is a non-issue*. (And by the way - as I've mentioned, managing reboots is the *easy* part of updating an Internet of Pwned Things device. The hard part is getting the vendor to produce an update in the first place...)
Attachment:
pgp53RC1lOSEt.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies