Date: Sun, 9 Jan 2005 18:05:49 +0100 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Subject: Re: Freebsd 5.3 Performance Message-ID: <103953715.20050109180549@wanadoo.fr> In-Reply-To: <Pine.NEB.3.96L.1050109162120.64144A-100000@fledge.watson.org> References: <109593615.20050109100927@wanadoo.fr> <Pine.NEB.3.96L.1050109162120.64144A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson writes: RW> The problems I have on the Windows XP platform appear to come from a RW> lack of robustness in the face of nasty application failure. A problem with the Windows environment as a whole is that applications tend to assume that they have the entire machine to themselves, and behave without any consideration for other programs that may be running on the same machine. In addition, Windows programmers (at least those with no experience outside of a PC environment) tend to vastly overused system calls and privileges that can destabilize the entire machine; many relatively mundane applications won't even install unless they can have privileges that they shouldn't really need. The net result is a far less stable platform than might otherwise be possible. It's all a consequence of the old MS-DOS paradigm, in which there is only one user and one program at a time, and any program can (and sometimes must) talk directly to the hardware and occasionally even override the OS. The NT family of operating systems corrected this in large part by introducing tight security concepts. But most Windows applications ignore or override these security features, making them moot. And Microsoft has aggravated the problem by removing or disabling features in NT versions such as Windows XP in order to increase compatibility and user-friendliness. Even NT 4.0 sacrificed security and stability just so that it could have a clone of the "modern" Windows 95 GUI. All of this is in contrast to UNIX, which, like so many other multiuser timesharing systems, has been obligated from the start to pay close attention to keeping users and programs separate. Ordinary UNIX user programs are aware of the fact that they are not alone and are written with security restrictions and the need for coexistence already in mind. In consequence, it's rare for a UNIX user program to do anything that destabilizes an entire system. Another way of looking at it is that, under Windows, practically every user program is the equivalent of a privileged daemon, potentially running roughshod over system stability. Having to support a GUI also destabilizes just about any system, and of course Windows depends on GUIs, although UNIX does not. RW> At work we use Windows with the usual combination of Microsoft RW> office and e-mail products, as well as tools like Acrobat. It seems RW> things go horribly wrong in the interactions between the components RW> (especially Acrobat integration into IE), and this leaves the system RW> in a poor state (often wedged). Lower level OS bits keep responding RW> to pings, but a hard boot is required to get anywhere useful. You're in a state where technically the system is up and running, and the OS is healthy, but the interaction and conflict between all the application programs you wish to run is so complex that any kind of error in one of them effectively stalls or kills them all. The only easy cure is a reboot. This is one argument against using application suites, as they are more likely to try to take over the machine and cause conflicts in consequence than are isolated, standalone applications. So Office or Lotus Notes is a lot more hazardous to run than some individual, free-standing application programs that make no assumptions about what else is on the machine. For this reason I'm very wary of installing anything from Microsoft these days, and only slightly less wary of companies like Adobe. They increasingly try to convert the entire PC to their own chosen environment during installation. RW> NT4 appeared a lot less robust with relatively frequent kernel RW> crashes, whereas with XP my impression has been that the kernel RW> itself is quite robust but the user shell and interface components RW> are so tightly integrated with application behavior that application RW> failure leaves them dead in the water. I didn't find NT to lack robustness, but I agree that XP and indeed all newer versions of Windows have confused the border between OS and applications so thoroughly that the net result is an overall destabilization of the machine. The extreme lack of transparency in Windows is a problem, too. You never really know what's going on behind the scenes. This is far less of a problem with legacy operating systems like UNIX that were designed to be fiddled with directly by administrators. RW> This is not disimilar to related failure modes on Mac OS X and using RW> X11/KDE on BSD, and suggests maybe part of the problem is in the RW> architecture of how we layer "system" applications over windowing RW> mechanisms. I completely agree. It's a general problem with any architecture of this kind (just installing a GUI is already a big step down the path of danger), but it's most obvious in the environments that depend most heavily on GUIs, such as Windows and the Mac. Of course, if you run a GUI on UNIX, you'll see similar problems there as well. To me it's too high a price to pay just for a pretty interface on a server. On a desktop the advantages of the GUI outweigh the reduction in stability, if the system is well implemented. -- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?103953715.20050109180549>