Serious investigations into UNIX and Windows

[Kevin Lyons]

> I don't disdain the Microsoft pointy-clicky approach.  It is
> easier to use because it provides psychological tools to help
> manage complexity.  However, when things don't work you still
> have to do the learning you were able to defer at the beginning.

In pointing out the advantage of pointy clicky, I think you may overlook 
a signifigant deleterious side effect.  In fact there is plenty of 
reason to disdain the point-click approach.  Mainly because it adds 
complexity to the software which tends to make the software unstable. 
How often have you performed a gui command on a windoze "system" (pick 
your flavor) and found that 1 time out of 10 it did not work, even 
though the same procedure was repeated?   How many times has that 
happened on a Unix box with command line?

That is why the windows user/admin approach of reboot and try again is 
now so common (they even have a nicer name than reboot- they use the 
term "bounce" as in "bounce the server".  And a clean install is now 
more nicely called a "reimage".)

Yes in theory a gui should not have anything to do with these problems, 
but the fact remains that in the real world the code bloat and state 
management problems of the windows gui do lead to instability.

Another rather trivial issue is resource utilization on a server that 
must run gui which then takes away memory and cpu time from pure server 
applications.  We have all heard of the all too typical case of the 
windows network server admin running the opengl 3d pipes screen saver on 
his network server using 90% cpu while users wonder why the damn thing 
is so slow and keeps crashing.

Or how about the Navy ship that was rendered immobile for 3 days because 
the windows screen harware that ran the ship's controls cause a blue 
screen of death.  Laughable if it wasn't so pathetic.