*BSD News Article 66105


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!gatech!news01.aud.alcatel.com!news.sesqui.net!oitnews.harvard.edu!news.dfci.harvard.edu!camelot.ccs.neu.edu!camelot.ccs.neu.edu!albert
From: albert@krakatoa.ccs.neu.edu (Albert Cahalan)
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc,comp.os.linux.advocacy
Subject: Re: Historic Opportunity facing Free Unix (was Re: The Lai/Baker paper, benchmarks, and the world of free UNIX)
Date: 17 Apr 1996 21:22:26 GMT
Organization: Northeastern University, College of Computer Science
Lines: 57
Message-ID: <ALBERT.96Apr17172227@krakatoa.ccs.neu.edu>
References: <4ki055$60l@Radon.Stanford.EDU> <yfgd959fo96.fsf@time.cdrom.com>
	<199604161719.SAA02142@kythera.demon.co.uk>
	<31740061.389946B0@lambert.org> <4l19gb$sn8@zeus.achilles.net>
NNTP-Posting-Host: krakatoa.ccs.neu.edu
In-reply-to: pjlahaie@zeus.achilles.net's message of 16 Apr 1996 19:12:11 -0400
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:21515 comp.unix.bsd.386bsd.misc:623 comp.unix.bsd.bsdi.misc:3242 comp.unix.bsd.netbsd.misc:3060 comp.unix.bsd.freebsd.misc:17463 comp.os.linux.advocacy:45812

>>>>> "P" == Paul JY Lahaie <pjlahaie@zeus.achilles.net> writes:
P> In article <31740061.389946B0@lambert.org>, Terry Lambert
P> <terry@lambert.org> wrote:

>> I've often thought that X should provide an object interface,
>> and that look-and-feel should be implemented in X server -- like 
>> the window manager should be.

> I hope that after you have such thoughts you wake up from that
> horrible nightmare :-) The X server should not enforce policy.
> It should do what it needs to do, which is windows, and nothing else.
> The entire flexibility of X is lost if you force a policy on the user.

Exactly.  That would be a Good Thing - no, an Excellent Thing!
Wake up, people hate X.  Part of "windows" is the boarder, icons,
menus, whatever.  X needs 16 MB of ram to do what both Windows
and OS/2 can do in 8 MB.  The curses library should send text
directly to the window system without all the xterm baggage.
The X window system is absurd.  Think about what happens when
I run an editor in an xterm: the editor loads some crap from
terminfo (or the vile /etc/termcap even!) that tells it how to
pretend that I am using a terminal over a serial line.  It even
"optimizes" to reduce data transmission and cursor movement to
the xterm (which pretends to run on a 38400 baud serial line).
This gets fed through a twisted pty-tty system in the kernel
instead of a direct connection between processes.  The xterm
then interprets all the control codes to do an extremely complex
protocol translation.  It sends the new mess over a notwork
connection to a big program we call X.  After passing data through
the kernel twice and once through an unrelated program, the
X server bangs on the hardware.  Hmmm, user code banging on the
hardware - we are no better than MS-DOS!  What is _really_
absurd is that the data goes through the kernel twice, yet in
the end the X server just hits the hardware directly.


Here is a picture of the problem.
Existing: program---kernel---xterm---X---hardware
Better:   program---WindowSystem---kernel---hardware

Note that the existing situation is even worse than it looks
because of the silly ncurses and X protocol fooling around.
If you want networked windows, you run a _separate_ network
server that connects to the window system directly.  If you
want terminal independence, you have the library perform that
function _only_ when it is needed.  The curses library should
be able to use a tty, window system, and mmaped video device.

This situation reminds me of all the other great ideas that
just don't work.  Would you like to have your kernel written
in SmallTalk, or an ugly language like C?  X and curses are
nice and abstract, but they are very wasteful.  It takes a
powerful machine to get real work done.
--

Albert Cahalan
albert@ccs.neu.edu