Re: sick of Linux bias
From: Hairy One Kenobi (abuse_at_[127.0.0.1)
Date: Tue, 6 Jan 2004 12:05:28 -0000
"Rowdy Yates" <email@example.com> wrote in message
> "Hairy One Kenobi" <firstname.lastname@example.org> wrote in
> > "Rowdy Yates" <email@example.com> wrote in message
> > news:Xns9467E6CA0D249rowdyyatesnospamlyco@220.127.116.11...
> >> Leythos <firstname.lastname@example.org> wrote in
> >> news:MPG.1a63ec3f52a4f22f98a048@news- server.columbus.rr.com:
> >> > In article <email@example.com>, "@micro$oft.com"
> >> > <""billyboi\"@micro$oft.com"> says...
> > <snip>
> >> > Interesting response - so, I can assume that you've never used a
> >> Windows
> >> > box since you don't really know anything about Windows other than
> >> > the over-blown hype spread by the uninformed.
> >> >
> >> > I've not seen an exception error in more than a year, and only
> >> > because of bad hardware the year before that.
> >> >
> >> we deployed Win updates via much hyped SUS deplyement services onto
> >> WinXP boxes. 10% of users got impatient and rebooted machines in the
> >> middle of the updates, upon bootup, the machines blue screened and
> >> were not recoverable implementing any of the official ms emergency
> >> recovery procedures posted on ms web site, rendered the OS and
> >> staions useless, had to deploy staff to individually re-image
> >> workstations.
> >> you were saying about OE errors?
> > You deployed updates that required a boot, in the middle of a working
> > day..?!?
> > And were then surprised that users would rather do their jobs and sit
> > and watch someone play?!?
> > And you feel qualified to talk about computer security? Where one of
> > the basic tenets is continuity-of-service?
> > Hmm.
> the updates get deployed first thing in the morning when users logon -
> not middle of the day.
> how do you do it? wake on lan @ 3am?
03:00? Not necessarily; usually a weekend (for a major upgrade) But most
definitely out-of-hours unless there's a damned good reason.
And *never* at the peak hour of the day, excepting a very damned fine reason
(think: you even get to keep your job if you can manage to explain to your
CFO why you've just brought his business to its knees)
Going back to the days before the multitude of deployment servers and
auto-update services, the most common method was to do the login approach,
followed by a second person to test the integrity of the system (on the
basis that screwing-up an entire trading floor would be best described as a
"Career Limiting Move")
Relying on end-users to verify an upgrade without any IT oversight is..
well.. let's put it this way - do you have your car brakes serviced by a
mechanic or your postman? And is there a reason for that..?
I'd also be interested to know - assuming that everything was tested in
advance, the users informed well in advance, and additional helldesk staff
available - what was your acceptable failure rate for this deployment? 10%
of all users locked-out? 50%? Were the figures signed-off in advance, and
After all, you're taking a rather obvious risk, presumably to save cash by