Project Athena - X Window System Users and Developers Conference, Day 2 [1/6]

[MUSIC PLAYING]

PROFESSOR: I'm not going to say anything very lengthy. You're basically in very good hands with your conference organizers. I'd just like to welcome you here on the behalf of MIT and the laboratory for computer science, which Bob represents, and project Athena, which I represent.

And actually, I really only have one thing to tell you. This conference will deal with the technical side of X, where X is headed, what sorts of things people are working on to augment X. From project Athena's perspective there is another side. It's somewhat less interesting from a technical perspective.

But for us, it's very important that X not only be an interesting technical and important technical development. It must also be something that the industry itself adopts so that universities can write applications, third party software companies can write applications, and that those applications will have a large hardware based to run against. With that in mind, I'm pleased to announce that concurrent with this conference there will be a press conference, which will be held.

It is a non-technical conference. And it is a small conference. It's not expected that anyone here will go over there. In fact, if you do you will overwhelm the room. Its for the press only.

But at that conference, a fairly unique announcement will be made by what will probably be 10 or 11 different computer manufacturers. Each of them will simultaneously announce support for the X window system in their product line. I know of no other event quite like it. Its, I think, a tribute to the people who developed X that so many manufacturers are seeking to support it concurrently as a product.

I think it is the first step in seeing a workstation environment that is less and less machine dependent and more and more machine independent. I think its an exciting development. Let me just tell you the companies that were coming to this thing as of yesterday.

And let me be very clear. This thing is changing in very real time. For example, if I had made the statement four weeks ago the number would have been two. But as of yesterday, the number who are putting their name on the press release that actually went out yesterday over the wires was Adobe Systems, Apollo Computer, APLEX Incorporated, a software company, Dana Computers, Data General Corporation, Digital Equipment Corporation, Hewlett-Packard Company, Mass Comp, Siemens, Sony Corporation, and Stellar Computers.

In addition, IBM has announced support in the form of the academic information systems 4.2. That was something they announced at EduCon that they would be providing support within that part of their operating system line at IBM. They are not coming to his press announcement, but they have asked me to announce that to the press.

So what we have basically is 12 different companies with very distinct economic interests combining on a common windows system. I think you'll hear words emerging like defacto standard when X is described in the press. Not because that's something we're necessarily encouraging, although I find it encouraging, but simply because when that many companies sign up with such a large fraction of the workstation market something very important has happened. And I certainly am quite excited about it.

With that, I wish you all have a good two day session. This should be an interesting technical conference. I'm going to be back as soon as I possibly can for what is fundamentally a public relations event. And thank you all for coming.

[APPLAUSE]

You want that, right?

I don't think it's working.

MODERATOR: You don't? OK, some quick administrivia. I want each of the speakers basically to introduce themselves. We're not going to waste time with introductions.

We didn't get into the agendas, email addresses, or phone numbers. If the speakers want to put that information up or just recite that information as part of their opening that would be good. We're going to be under a very tight schedule today given the number of speakers we have, so please observe the coffee break times and the lunch schedule.

Apropo of lunch you've been given a map. The important thing to note is the places that will handle the biggest crowds are the student cafeteria and Walker cafeteria. These two places. They're set up to handle large numbers of students. Those are the places you should tend to head for. Places like legal seafood will be long waits typically for lunch, although legal in fact, does have take out if you're interested in that.

The birds of a feather sessions tomorrow are going to start at 9:30, except for the imaging one, which is going to be at two. I would like to get a brief show of hands of interest in the individual boss, so can I get a show of hands of how many people think they're going to attend the 3D. Okay.

How about the tool kits? Okay. The protocol? Okay.

Window managers? Wow. Anybody want to volunteer to chair the Window Manager session?

[LAUGHTER]

Everybody we asked said, no, I won't do it or I'm not coming. If somebody wants to volunteer, please see me. The images? Okay.

We have one or two extra rooms that we reserved on the side. If someone wants to suggest boss, please write it down and at a break or at lunch give it to me or leave it at the registration desk.

Okay. I'd like a brief show of hands that may help the speakers, and I'm sort of curious myself, how many people are here from universities? Okay. How many people are here marketing?

[LAUGHTER]

How many people here are management? Okay. How many here are programmers?

[LAUGHTER]

Will all of the people who claim to have helped in the success of X past, present and future stand up.

AUDIENCE: Come on people.

MODERATOR: Be honest. Come on. That's it? Come on. Not public domain. Vendors, everybody come on, stand up. Okay

[APPLAUSE]

I want to make it clear, we've started getting questions already. If you're expecting to say, oh, I'd like to get a distribution v10r4. Can you please make me a tape today? Forget it.

Okay. Don't even ask. If you're here and you say, I'd really like five minutes for a demo somewhere. Forget it.

But I will point out Ralph Swick. Ralph Swick. Will Ralph Swick stand up? If you're crazy enough you can go try and talk to him.

Okay, fine. Good idea. So without further ado Jim Gettys is going to give you some status report.

JIM GETTYS: Okay. They'll be a lot of people who probably want to take notes. As is who I am, I'm in a transitional state from here at MIT to the Systems Research Center of Digital in Palo Alto.

I've been a digital employee here in Project Athean since the beginning. Okay. Where are we today?

Basically, for version 10, which is released four out of here, the comments are release four has been out since December 2nd electronically, though there was an update in late December with a pile of new stuff as well that couldn't make the December one. The December one was driven by academic schedules. There's this embarrassing thing about academia. The calendar year doesn't shift.

And there's a lot more device dependent code on there, really nice addictive game, yet another read redone version of the terminal emulator, bug fixes, and so on. I'm sure we guarantee some new bugs to boot. There are three different tool kits on there. There's one done by Ram Rao and Smokey Wallace at All Digital. And then Hewlett-Packard Company has contributed a toolkit called X-ray. And John Ousterhout of Berkeley has done a toolkit called SX.

For version 11 we hope to get back to one common structure taking the best ideas out of these three different tool kits. Each of them have their different advantages or disadvantages. What you do with them is your problem, okay?

But with version 11 we expect and intend to have one common toolkit structure to work from. In your notes is also the same basic ordering information. The tapes cost $100. They're half inch industry standard 1600 BPI tapes only in tar format only.

We do not generate floppies for anything. And currently, I'm told that the micro-computer center has a three week backlog from the beginning of the year. Okay.

So that's where version 10 is. Release four is the last release based out of MIT based on version 10. So we go on to version 11, which we went out asking for comments on some time last summer. And there are a couple of specific recommendations I want to make to two vendors, which make a very large difference.

Please, bother to do the work for the input mechanism. The difference is dramatic. Both VAX and on RT/PC under 4.2A do the input side right, so you'll be embarrassed if you don't.

And a single device for keyboard and mouse, please. We want to keep time sequence order between mouse events and keyboard events. So implementing separate devices for keyboard and mouse is a long term bad idea.

Then another thing which came back to bite us, 4.3 beta, that's 4.3 Berkeley distribution beta, has a change in the TCP transmission strategy, which for example, winded its way into Ultrix 1.2 and made wind it's way into other people's systems. In for the final 4.3 Berkeley distribution there is a socket option to be able to control the TCP transmission strategy and that turns out to be very important for good mouse tracking and rubber banding across the net. So I want to point those two particular implementation details out as bugs to avoid.

1.2 has it wrong, okay? We realized it too late to get it fixed except on the local machine. So just to know that this is an issue and it does affect the way rubber banding works and so on. So, sigh, such is life.

What can I say, except fix the next release. Or so I hope. I don't speak for UNIX engineering group, but you know.

Okay. Let's go on to-- we are very close to releasing bits for Alpha Tester version 11. So what will be on such a distribution? And I'll get to precisely when very shortly.

The server will be almost entirely complete, at least in terms of the protocol. There are some things that we hope to do having to do with things like Bitmap unders and the like, which hopefully will make the beta test version of it. But the server is essentially complete at this point. There is a full set of generic monochrome bitmap graphics code.

It's for a straight memory frame buffer. It's written to be highly portable. It's written to be highly modular so that you can plug and unplug pieces. They'll be people talking this afternoon about the details of that.

We do not expect the device dependent interface to change significantly between alpha and beta module O. You know, bugs that we find as more and more implementations are done. There should be the native piece of the X library, at least the protocol native part.

Those are some of the additional stuff like region code that's in my current spec. Won't make it right then. Some demo program's a clock, a not a window manager window manager-- the person wants to disclaim any responsibility for it being a window manager. despite the fact that that's what it is for the time being-- and some manuals and porting documents.

The beta test stuff is more or less the same sort of thing, but the major missing pieces in the alpha will be things like a terminal emulator, which conversion of the terminal emulator only started like 10 days ago or something, and the miscellaneous tools that exist, and completion of the documentation, and all that sort of good stuff. So it's same sort of thing again. The intent of the alpha test is to-- a lot of people to start doing ports to their devices and give us feedback as to whether this thing is was really portable and whether the new facilities work properly.

Okay. What you've got to do to be an alpha test site. The deadline for this is February 2nd. We will be asking for a single technical contact person, okay? That is we want all information to go through one person at a company rather than get random questions from 5 or 10 places in somebody's company.

Not a problem with small companies, but in big companies we see flurries of the same question asked from five different directions in the company, so we want a single contact point. An electronic email address, that is we really can't deal with the turnaround time for paper mail and the overhead of making it as is way too high. So we really want to be able to talk to alpha test site people via electronic mail.

We want to deal with people who are doing useful and interesting work by some definition. Basically that's things like porting to hardware and/or testing particular new features of version 11. For example, people who might want to build a piling window manager, which may use lots of the new facilities that version 11 provides.

There's no good way we can deal with non-disclosure. I mean, many of the people working on the public server are digital employees. And we can't sign your non-disclosure agreements to talk about your funny hardware. And that would be also true of MIT employees too, so it's very hard for us to deal with somebody who can't talk at all about their hardware to us at some level. Because how can we track down bugs if the guy can't tell us what kind of hardware they're talking about.

We don't want to see the code be redistributed beyond your organization. And there has to be an alpha test site. You send mail to that address. I don't have very many minutes.

Also, this is a real deadline by the way.

AUDIENCE: [INAUDIBLE]

JIM GETTYS: What?

AUDIENCE: How do you know?

JIM GETTYS: No. You'll be informed whether you'll be an alpha test site, but you must have your request in by-- it must be received here by the second. We have to deal with logistics like getting tapes made and stuff like that, so it gets hard.

Also, there has to be a turnaround of mail, because we're going to ask people to sign a letter saying that they're not going to redistribute the code basically at that point. Okay. For a beta test it's a similar deadline, April 1st.

We'll be willing to deal with more people with less justification required and the same sort of caveats having to do with a single person. And we still can really deal with people electronically. Are And the address for this is XBETA.

Why? No. Beta test time it would be possible to redistribute.

We hope and believe things will be stable enough that the protocol won't be changing period at that point though we will still reserve the right that it may have to change if something comes up. For example, release one of X was on protocol version 9, which is a very slight difference from 10. And it made a tremendous difference in portability to things like the RTPC and various risk architectures. Okay. I've been using modifications of the slide with time.

We aren't doing too badly. Some people will see that the dates aren't quite what we started off with last summer, but we aren't too far off. I guess we've claimed in December or January to be able to start giving out bytes and the real date is the 9th of February.

So the interesting dates are the deadline for alpha test applications. February 9th is when we will be cutting tapes. You can expect to see tapes by the end of that week. I believe that that's a Monday. Then, by that Friday. April

1st is the beta test application deadline. I put a line here, because after this clearly, if there are unexpected problems in alpha test, then these dates get more fuzzy. So the statement here has to do with a subject which people who've have looked at the version 11 protocol carefully may understand and will be discussed technically later in the day, which is in version 10 there was a whole pile of different little mechanisms for things like resize hints, names of Windows, all those sorts of things. We subsumed that into a single mechanism.

We expect that there will be a long list of predefined atoms. All an atom is as a nickname for a string. So for example, we can have a resize hint associated with a window, or a name associated with a window, or so on. And so there clearly can be a whole pile of things in like primary selection, secondary selection, a whole pile of names like that, so the ones that get built in we need to know by around then what they ought to be for various kinds of user interfaces and various other things. I believe that at alpha test time we expect they'll be like 50 or so predefined atoms for various things.

Everybody got any dates they need off this list?

AUDIENCE: [INAUDIBLE]

JIM GETTYS: George Ampine claims that there'll be a way of getting copies of these slides. So if enough people bother him immediately maybe he'll try to solve the problem sooner rather than later.

And there's some other information we need out of people. There are lots of infinite different keyboards in the world. They don't all happen to look like the digital LK201 or the new IBM keyboard, which looks very similar.

In version 10 there were lots of spare key codes, but none of them were in the standard translation tables. So you can say that this particular funny key with whatever label could have a new key code, but some other machine in the world might not know what that should translate to. I mean, I've gone around and looked at like 10 different keyboards, and it's clear that if you add 30 or 40 new codes for different labeled keys that you end up starting to have nearly every key that you'll find on any keyboard.

But there may be some funny keys somebody's got somewhere. So we need a list of descriptions of the labels of keys, which glyph is written on the top of the key whether it's in the upper or lower position. And please send that information here. Prevent a lot of grief.

AUDIENCE: [INAUDIBLE]

JIM GETTYS: All that sort of stuff. You end up finding the same kind of label on different keyboards. So by the time you've added 50 or 60 more codes--

AUDIENCE: [INAUDIBLE]

JIM GETTYS: What?

AUDIENCE: [INAUDIBLE]

JIM GETTYS: Well--

[LAUGHTER]

Good point.

AUDIENCE: Call them and send it in.

JIM GETTYS: I don't understand enough to deal with things like Japanese keyboards. I think the statement is US and European flavor keyboards more or less. Send us the information and we'll see whether we can figure out what to do with other funny, special cases I think is the right statement. In other words, feel free not to sign a code if we can't figure out how.

So that's most of what I have to say. And this is mostly administrativia, but we've decided that it would be a good idea to try to answer it sooner rather than later to preempt a whole pile of questions. I'm sure it'll generate a lot of questions. We hope that most of the remaining questions will be answered in one or more of the talks today.

DAN DYCKMAN: Hello, everybody. My name is Dan Dyckman. I'm from the Harvard School of Public Health.

The project I'm working on is a package for displaying statistical data using such rendering techniques as Ray tracing and texture mapping. I've really come here just to describe the user interface I've developed for the program rather than to talk about the program itself. I think that might be of more interest to you.

Here's how the program looks on the screen. Let's see how this works now. Okay, four regions in this window represent four methods of user interface. On the upper right, there's a menu system comprising of three windows here. On the left as a window for text. Oh, kidding.

AUDIENCE: [INAUDIBLE] mic up.

DAN DYCKMAN: Okay. How's this?

AUDIENCE: It's working

DAN DYCKMAN: Is this okay? Better?

AUDIENCE: [INAUDIBLE]

DAN DYCKMAN: Well, the light isn't on.

AUDIENCE: [INAUDIBLE] on the bottom.

DAN DYCKMAN: It's okay? Okay.

AUDIENCE: Talk loud.

DAN DYCKMAN: Okay. [CHUCKLE] On the left over here there's a window for text input and output. On the lower right is a window which can contain panels of buttons. And on the lower left is a window for graphical display.

Let's look at the menu system. Menus are hierarchical. Okay. The menu system is currently not operational.

[LAUGHTER]

I seem to have lost all slides. Okay, yeah. The menu system is hierarchical and each menu level is placed in one window. As the user moves the mouse, menu items under the mouse are highlighted.

A new menu is selected by clicking with any one of the mouse buttons. My menu manager will report the selection to the host application, which might respond by running a subroutine or the application might open a new level of menu options in the next menu window. Here, the user asks to load something, so the application responds by opening a new menu of load options.

And the original item, load-- well it actually doesn't show up too well-- which spawned the second menu list is highlighted in red, so the user can see where he's coming from. On the screen that's a little easier to see. If the user were to select another item from that first menu, then the second menu would close up and disappear.

Okay, let's suppose that the user has decided to load some data. The program wants to know the name of the data file. This brings us to the second type of window for text input and output. This is relatively straightforward. I've just written a number of functions for reading keyboard events from the user and writing text and numbers to the window formatted in various ways.

For instance, the programmer can activate a syntax checker so that if he wants the user to input a number, then the text manager will do all the checking for him character by character. Illegal characters will just be ignored, won't appear on the screen. If the program wants he can light up the border to this window in a bright color just to alert the user that there's something to look at.

Why don't I move onto the third type of window, which implements buttons. The programmer defines individual buttons, which collectively form a panel of buttons. You see one here.

You can define any number of panels, and then activate one panel in a window. When the mouse moves over each button it's highlighted with a red border. You'll be able to see that on future slides.

A mouse click selects the button, and the button manager notifies the host program of the selection. If the programmer wishes, he can group together two or more buttons and make them alternative options. The button manager will keep one and only one of these alternative options highlighted with a dark border around it.

You can see an example here in the lowest row. This is useful if the programmer wants the user to select from a finite set of options. Here, I've implemented a color picker just to show you an example of what can be done with this. The user selects one of these eight locations.

The other buttons in the panel can alter the color of the selected location by changing the red, green, and blue component of the color or the hue, lightness, and saturation of the color. You can change each component up or down quickly or slowly. The buttons on the right provide more functions, such as moving and blending. To demonstrate, a user might increase the red component of the color. These slides aren't as bright as they might be.

And then he can copy that red to another location. He might then change its hue gradually or its color gradually to a yellow keeping the same saturation and lightness. He might then darken that yellow a bit.

Okay, it does look a little darker when you see it on the screen. And then he might want to blend the two colors together. If the user then wants the red, green, blue numerical values for any color he's created, they can be printed in the text window.

Note that for some buttons a function is performed once and only once when the mouse goes down. For example, the copying function just copied once. For other buttons a function might be performed repeatedly as long as the mouse is held down. This was used, for example, when gradually adjusting the hue from red to yellow. The user clicks down, watches the button change color, and he can release the mouse when the value suits him.

The fourth type of Windows is for images. A programmer might use this window to select objects or polygons, drag them, rotate them. And the manager for this window is extremely simple. And basically just reports mouse events that it gets from x.

Unlike the other types of windows I've described, output to this window is the responsibility of the programmer. With the other windows the managers I've written take care of all the output. There you have a description of my user interface package.

So far I found it to be a very quick programming tool. And I've been able to easily make a few utilities as separate programs. For example, I've pulled out this color picker as a standalone application.

I've also included a panel in it, which displays the color lookup table for the machine. Here the user has selected one of these cells in the color look up table, and you see the numerical values for the red, green, and blue printed out in the text window. Another program I wrote will just continually monitor and report on the mouse's xy coordinates on the screen and the coordinates of mouse drags. And if you click on a button a display window opens up to magnify whatever portion of the screen is under the mouse.

Here, you see a clock magnified. And again, using buttons you can select magnification level, etc. As you can see, applications produced with this package, besides being very quick to program, are quite clear and easy to use.

The interface is a pretty obvious one. If you want to reach me about this, you can reach me at Dyckman, that's spelled D-Y-C-K-M-A-N @havard.harvard.edu. Are there any questions? Mhm?

AUDIENCE: Do you have any comments about [INAUDIBLE] on the screens?

DAN DYCKMAN: Well, my feeling about pop up menus is it kind of depends on the application you want to use. The hierarchical menu system I've used is, for starters, it's just easier to see. When you have the windows in front of you it's a lot clearer to understand what's happening.

If you have menus that just pop out of anywhere as is supported by Xlib, sometimes user can be very confused. Which mouse button do I use to get which menu? Where do I have to click to get this pop up menu?

So just for simplicity of user interface I've kind of avoided making pop up menus. Sorry, that might offend people. Any other questions? No, okay.

[APPLAUSE]

CHRIS BURDORF: My name is Chris Burdorf. And I'm from Rand Corporation. And I'm going to talk about the use of X Windows in a concurrent processing environment. We've got some papers over here if anyone wants more information.

Over the years at Rand a lot of work's been done in the area of simulation. And in the last five years or so a lot of work's been done in object-oriented simulation also incorporating rules into the object orient simulations. One of the problems we've had though with these big simulations is that they're too slow. It takes forever to load them onto one machine. It takes forever to run.

So we're working to speed it up through having more than one processor. And that's what the goal of CPAS system is, which stands for concurrent processing for advanced simulation. We're using X in this system to build a user interface at the programming level and at the analyst level who's running a simulation and examining what's going on.

The interface begins at the lowest level. At a wrappers level it interfaces directly with X into LISP. We're using a subset Com LISP.

And then at the high level we've got two tools and application programs. Starting at the lowest level up to the highest level the wrappers layer is a direct interface between the X routines and LISP in a one to one mapping without the use of pipes. What we do is we convert C data structures into a LISP data structures and back again.

On top of the wrappers layer we have an abbreviation layer, which contains functions that make calls to X to manipulate X objects. For example, in the case of creating a cursor we have an X cursor function that you call that does everything required to build a cursor for you and associate it with a window. On top of the abbreviation layer lies the LISP window manager layer. And this window manager is similar to UWM, except that it works only with windows created from LISP.

And it allows a user to connect tools or gauges into LISP. And then, LISP will manage the events directly. We have an add event function that indicates to LISP window manager, I want this window created, and I want certain events recognized, and upon finding those events perform certain actions. And then we have a remove event, which allows you to take out a tool from the window manager.

On top of the list window manager we have the window level layer, which contains higher level X utilities built on top of X primitives including, scroll windows, panes, color menus, and pick and stuff for LISP windows. The panes are merely sub windows that can go on a tool that accept mouse input. An example of a little simulation, we ran a five processor simulation using X. This is it right here.

Each one of these windows here pop up corresponding to the remote processors in the network. And then each one of these icons correspond to points that are calculated concurrently. On top of the window level layer we've got tool layer, which contains some more facilities to support a multiprocessor programming environment, including a gauges package, which is separate from the Window Manager. It allows you to connect a gauge into this package.

And then it's automatically updated and refreshed. And some examples here of the gauges, some example gauges that we use. Up in the corner here we've got a cons activity gauge, a heap utilization gauge, and a binary program space utilization gauge.

We've also got an inner processor profiler that allows you to profile functions and messages across machines. It indicates how many times each function or message was called and on what machine it was called from. This is a profile right here.

At the top, the longest bar up there, the green bar, corresponds to the function called the most during your profiling and all the other functions listed have a bar relative to the one most used. Right here we've got a side pane that you can't really read it is blurred, but it allows you to scroll up or down lines, half pages, or full pages. We've got a color menu right here. And as you scroll through the profiler it's always renormalizing, so the top listed function is all the way. Everything else is relative to it.

We also plan to have a data structure browsing facility that will be an object browser inspector that will display objects attributes and that objects relationship to other objects in a window that comes up once the users or the programmer specifies to monitor that object. And we also plan to have some menu control of the parameters to that object from the window. And we've also got a fancy little pixmap editor that generates LISP output. And it's mouse controlled. And it shows a corresponding pixmap on the screen the actual size of what it will look like.

The application layer contains a message transit mission monitor that indicates the number of messages passed between objects and machines during simulation. We think this would help a lot with load balancing to indicate if say there's two machines that are doing all the communication, we might want to spread the simulation out and move some objects over to another machine so that there's a balance of communication between the machines not to tie things up. And also in debugging the system.

And we're also working on a data flow analysis browser that will allow programmers who walk a graphic representation of the control flow graph generated by the data flow analyzer. We've got a data flow analyzer and it generates read and write sets of a program and the control flow graph, but that the output is really tough to read. It's real cumbersome.

So using X we're going to have a window come up and it will show a graphic representation. And using this browser the user can determine how to restructure a program to find more concurrency. And it also will help debug a program and get rid of parts of the program that say never get called or never get used because it's not written correctly.

Okay, so in conclusion, currently X is being used for early development of the system. It is going to be a production system probably just use inside RAND. Maybe some other places will use it, but it's mostly just for our own use.

It is a heterogeneous network of workstations. Right now we've got SUN workstations and HP Bobcats over in ethernet. Right now the most processors we have are five, but we're planning on going up to 24.

Some of the disadvantages we have with x are as follows, the HP and SUN implementations are not the same. We have trouble running some of our Xcode that works on the SUN on the HP and vise versa. So it's a hassle for us, and we'd really like to see a standard come out if we could see it, because it'd be a lot nicer for us.

AUDIENCE: [INAUDIBLE]

CHRIS BURDORF: I think it's more like the pixmap level, that kind of stuff. Graphical output is different. That's another problem we have is our black and white pixmaps don't show up on color monitors. They show up on black and white monitors, but they don't show up on color monitors.

So if we switch to another machine that's got a color monitor we have to change that. And that's even within SUN workstations, so it would be nice if that would work for us. It would also be nice in the documentation, we think, to have some sort of chart that shows how to map from colors to pixels to pixmaps to tiles and back again, because it took us a while to figure it out. And because of this and some other difficulties we had with the documentation we went through and started from scratch and rewrote the entire documentation ourselves for our own use.

[LAUGHTER]

AUDIENCE: Are you willing give us your nice explanation?

CHRIS BURDORF: If you want.

AUDIENCE: Yes. Oh

CHRIS BURDORF: Okay. Another problem we had with X is that since we have multiple machines that we're using we want to use the network to hook up those machines, but each one of the net buffers used by X is one less that we can use for our machines. So down the line this is going to pose a problem for us. And we figure we're going to have to rewrite the remote log in facility in order to do that, which is going to be a lot of work. Hmm?

AUDIENCE: [INAUDIBLE]

CHRIS BURDORF: X uses the net buffers, right? For Windows X uses the network?

AUDIENCE: [INAUDIBLE]

CHRIS BURDORF: Yeah, okay. But we want to use as many as we can. We want to have as many as possible and X is going to use that, so we need to put in more.

AUDIENCE: [INAUDIBLE]

CHRIS BURDORF: You don't see what-- my boss does.

AUDIENCE: [INAUDIBLE]

CHRIS BURDORF: Let's see. 8 megs on most-- [INAUDIBLE]

Overall though our experience with X has been very positive. It's been easy for us to interfere with LISP. It allows mouth control with LISP, which is something that we could not easily do from SUN or from HP window.

It runs on different hardware. It has industry support. It allows a remote process to create a window on another machine. And somewhere down the line, we're going to work on getting X so a remote job can communicate with X.

Some things we'd like to see in the future is a standard across machines. And also something we'd like would be if we could have the mouse input to EMAX where you can move around the cursor within EMAX using the mouse. But all in all, we had a very good experience with X. And we're very excited about using it more in the future. Huh?

AUDIENCE: [INAUDIBLE]

CHRIS BURDORF: Oh, Burdorf dash rand unix. Oh, wait, at rand units. Huh?

No, it can be lowercase. Oh, yeah. [? Dot author. ?] Any question? Are there any other questions? Okay. Thank you.

[APPLAUSE]