system autodeath
Horst H. von Brand
vonbrand at inf.utfsm.cl
Mon Sep 15 05:09:55 UTC 2008
Glen Turner <gdt at gdt.id.au> wrote:
> I am the author of the Wiki page with the suggestion. A friend showed
> me this discussion and I'd like to add a few points.
I was in charge of computer labs around here, and have known my measure of
users... even ones you'd think should be /very/ sophisticated.
- What makes you think that when the machine gets disabled, a Google search
won't suggest that the "easiest solution" is just disabling autodeath?
- Nagging the user at the screen of the machine is of no use, they mostly
don't care about upgrading (and if they do, can't do anything about
it). The lab administrator is probably running something else in any
case.
- Many times around here upgrades were held back because something or other
didn't work (old servers + new clients: No autofs and thus no accounts;
GCC update: Examples/asignments don't compile anymore; random package
upgrade: Some propietary extension or program doesn't work). Yes,
sometimes it /is/ rational not to upgrade. And sadly, many times those
can't be bugzilla'd decently.
- Yes, a /long/ time ago we had a Windows machine just for our students
working on their theses... and it started behaving weird. One of the
users had disabled the antivirus, as it didn't let them run a program
from diskette, while loudly warning that it was infected...
- In the Red Hat 7.3 timeframe (our machines were kept rigurously up to
date) a user tried an exploit targeted at _unpatched_ Red Hat 6, that had
an /explicit/ warning that it wouldn't work on anything newer, and that
it generated a very noticeable overload on the target, during lab rush
hour against the machine of the neighboring user... we didn't know if we
should punish him for attempted cracking or sheer stupidity.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
More information about the fedora-devel-list
mailing list