Re: Installing patch KB837001 via Windows Update

[George Capehart <[EMAIL PROTECTED]>]

On Thursday 15 April 2004 10:59 pm, Susan Bradley, CPA aka Ebitz - SBS 
Rocks [MVP] wrote:
> Okay it's the end of the day and I gotta rant.  We keep talking about
> how Microsoft should regression test these patches and yet look what
> we are asking them to do.
>

<snip>

>
> Yes, I want them to build better patches, but I'd rather they'd build
> patches in a way that I can get back to where I was before the patch
> went on as well.

<rant>
OK.  *My* turn to rant.  There are other OSs in which this is not a 
problem.  Matter of fact, MS operating systems are the only ones I've 
used that have this problem, and I've used most of the Unices, DOS 
(both PC and mainframe), MVS, VMS, MPE, RSTS, CP/M, etc., etc. 

> The reality is they cannot patch for all the "junk"
> that I have on my box.

That's not the problem.  The problem is that they have thrown everything 
and the kitchen sink in the OS and it's nigh on impossible to tell 
where the OS stops and the applications begin any more.  This was done 
on purpose.  It is just the opposite strategy of the Unix world in 
which the idea is to build many single-purpose tools that can be used 
in concert to perform complex tasks.  (I am not intending to start yet 
another MS vs. *nix food fight.  I am merely describing differences in 
design philosophy and some of the implications of those differences).  
In the *nix world, there is a clear distinction between the kernel 
which manages system resources and all of the userland applications and 
subsystems that use those resources.  The kernel and all of the 
userland applications and subsystems have their own lifecycles, can be 
managed independently, and can be patched (*and rolled back*) 
independently.  There is lots of "junk" on most production machines.  
It is the phenomenal complexity and multiple levels of interfaces, 
levels of indirection and opaqueness that makes patching *dows such a 
challenge.  Frankly, I'm amazed that they're able to do as well as they 
do.

>  And that's the reality of Patch Managment.  I
> have to take the risk.  I have to make the decision.  In my office
> I'm taking the chance that my ports are pretty nice and tight and
> nothing [while exploit code is out] is in worm mode and I'm coming in
> to the office tomorrow when everyone else is making a nice three day
> weekend out of it and patching my LAN and cleaning my office.  [Do I
> know how to party or what?]
>
> The point is no vendor can patch test for the environments we have.

In almost all non-MS environments, that's not necessary.  There is a 
clear distinction between the OS, OS utilites and applications.  The 
APIs are well known and dependencies among the subsystems are known.  
The OS vendor doesn't have to test everything and the kitchen sink.  
That is not to say that there are not dependencies among subystems and 
applications.  The difference is that the interfaces and their behavior 
is well known.  There are no silent "enhancements" or "bug fixes" that 
change their structure or behavior.  And it is possible for the 
administrators to decide how they want to partition their system, where 
to put the utilties, applications and data.  Configuration data are 
well documented and not buried in a "registry."  If, after an update, 
it is necessary to have an application reread some initializing 
information, it is not necessary to reboot the operating system.  It is 
sufficient to restart the application.  And the operating system can be 
reconfigured on the fly.  Most of the problems with patching MS systems 
are caused by the design of the "operating system," and I use that term 
loosely.  I can think of no reason beyond avarice that would justify 
having a browser be a part of an operating system.
</rant>

Cheers,

George Capehart
-- 
George W. Capehart

Key fingerprint:  3145 104D 9579 26DA DBC7  CDD0 9AE1 8C9C DD70 34EA

"Does getiud(2) halt the spawning of child processes?"
  -- Unknown from a very old fortune cookie file



---
To unsubscribe send a blank email to [EMAIL PROTECTED]