On Thu, Aug 21, 2008 at 8:02 AM, Matthew Miller <mattdm@xxxxxxxxxx> wrote: > And it's part of our responsibility: we're putting powerful software into > their hands and then not providing security updates for it for very long at > all. Turning off network access before they all become part of a gigantic > botnet is the right thing to do. I think there is an argument to be made to encourage our users to choose responsible use of technology. A part of that is adequate education as to what responsibility actually means in context of making a personal choice. I'm not sure all efforts to disseminate best practises are always best achieved by silently active enforcement policies which do not have a timely educational component meant to educate the system admin or user when the enforcement engages. Now I'm not saying we shouldn't consider doing something by default. I would think that something designed as autoannoy instead of autodeath would be more appropriate. For desktop machines..hooking the concept behind autodeath into packagekit to give users a choice to use preupgrade or turn off the network..seems pretty reasonable...and it seems people are already thinking hard about that particular usage case. For machines which aren't meant to be used like a desktop... remotely hosted machines with ssh remote logins or whatnot...would it be reasonable to have autoannoy change the motd or message at login to indicate to remotely logged in users that the machine is no longer able to receive updates and communicate the associated risks of that situation? Thus informing users of such remotely located Fedora systems that they need to take action, or their hosting company needs to take action...but without locking them out of the system entirely by bringing the network down? How many hosting companies out there sell access to Fedora systems to people without adequately informing them as to the EOL policies and are willing to continue to take money to host EOL'd Fedora systems with no due diligence on their part as a hosting company to help their clients handle Fedora release EOL? Can we give users of systems like that enough information to take steps to rectify the EOL related problems their hosting company didn't prepare them for.. without arbitrarily shutting them out of their own systems? -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
