From owner-freebsd-chat@FreeBSD.ORG Wed Oct 27 16:25:19 2004 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9988D16A511 for ; Wed, 27 Oct 2004 16:25:19 +0000 (GMT) Received: from s1.ofdeng.com (adsl-66-137-123-97.dsl.hstntx.swbell.net [66.137.123.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F8643D2F for ; Wed, 27 Oct 2004 16:25:19 +0000 (GMT) (envelope-from kevin_lyons@ofdeng.com) Received: from ofdeng.com ([192.168.254.17]) by s1.ofdeng.com (8.12.11/8.12.11) with ESMTP id i9RGQYK4083503; Wed, 27 Oct 2004 11:26:36 -0500 (CDT) (envelope-from kevin_lyons@ofdeng.com) Message-ID: <417FCBDF.4040102@ofdeng.com> Date: Wed, 27 Oct 2004 11:25:03 -0500 From: Kevin Lyons User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny MacMillan References: <017b01c4bb78$28263a00$4df24243@tsgincorporated.com> <20041027155704.GA861@procyon.nekulturny.org> In-Reply-To: <20041027155704.GA861@procyon.nekulturny.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: TM4525@aol.com cc: stefan@swebase.com cc: Micheal Patterson cc: Ted Mittelstaedt cc: freebsd-chat@freebsd.org Subject: Re: Serious investigations into UNIX and Windows X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2004 16:25:19 -0000 > 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.