Re: Installing patch KB837001 via Windows Update

["Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <[EMAIL PROTECTED]>]

The reality is my friend, down in my space, 'Nix will not work on my 
desktops and the costs vs benefits of migration/wine emulation.... it's 
just not there yet.

For the record, all patched via Shavlik, no issues.  See you all next month.

Susan



George Capehart wrote:

> 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
>  

--
http://www.sbslinks.com/really.htm



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