From owner-freebsd-chat Fri Nov 30 6:52:52 2001 Delivered-To: freebsd-chat@freebsd.org Received: from guru.mired.org (okc-65-31-203-60.mmcable.com [65.31.203.60]) by hub.freebsd.org (Postfix) with SMTP id B49A237B41C for ; Fri, 30 Nov 2001 06:52:47 -0800 (PST) Received: (qmail 42859 invoked by uid 100); 30 Nov 2001 14:52:46 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15367.40254.191788.665077@guru.mired.org> Date: Fri, 30 Nov 2001 08:52:46 -0600 To: "Anthony Atkielski" Cc: Subject: Re: As usual, I disagree. In-Reply-To: <03fa01c179ac$e85cdba0$0a00000a@atkielski.com> References: <15366.58396.746782.116282@guru.mired.org> <036901c17949$335163b0$0a00000a@atkielski.com> <15367.35596.70893.123850@guru.mired.org> <03fa01c179ac$e85cdba0$0a00000a@atkielski.com> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Anthony Atkielski types: > Mike writes: > Keep in mind that the early versions of Windows had no preemptive multitasking; > an application held control of the processor until it decided to voluntarily > relinquish it with a call to the OS. There wasn't much reason for filtering, > since there was no significant parallelism of execution, anyway. Windows 9x > started to do a bit of preemption, but it still stalls when applications are > hogging the system. Windows NT is immune to this, but instead it tends to > thrash when there are many applications in the system, because of (IMO) the need > to fill and service message queues for all open applications with windows. I'm fully aware of the origins of windows, and even pointed out why those origins took it out of the category of "systems designed from scratch for windowing UIs". That NT has to provide the same functionality to be compatible with W9x is a sad thing. > > So far, you haven't demonstrated that the > > Windows way is any more flexible or functional > > than the X way. > The 100,000 applications provide the flexibility and functionality. That may make the desktop more flexible and functional, but not the underlying windowing system which we were discussing. Unless you can demonstrate an application which can't be done on X, the sheer number don't matter. > > I don't know that I would call it a covert > > channel. > You can learn or transmit information about other processes about which you > should know nothing by determining or influencing their states. This provides a > low-bandwidth covert channel, and is thus a (small) security risk. Unfortunately, that channel *has* to exist because the window manager couldn't function without it. As I stated before, you eliminate that small risk by not allowing untrusted clients to connect to the server. Just out of curiosity, if I'm using one of the remote access methods for NT, is there anything that prevents me from running a program that opens a window on the screen and thus get access to the same information? > > As far as I can tell from your description, > > the only difference between Windows and X is > > that in Windows passes every event to every > > client to let the client choose, resulting in > > a boatload of context switches ... > Yes. > > > ... whereas in X the clients have specified > > which events they want, and X does the determination > > internally, so you don't get context switches > > for clients that don't care about an event, which is > > a major savings as most clients don't care > > about events in other windows. > Yes. In other words, the Windows approach is no more flexible or functional than the X approach, just a lot more expensive. That that's because of it's roots as a single-tasking program loader actually gives some credibility to your argument that Unix is bad on the desktop because of it's roots as a multiuser server. But I think I already agreed that having capabilities you don't use is an expense you could avoid. Just not nearly as bad as having to provide backwards compatability for systems that didn't have capabilities that you need. http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message