SNAP Computing and the X Window System

James GettysHewlett-Packard Company

jim.gettys@hp.com

Abstract

Today’s computing mantra is “One keyboard,one mouse, one display, one computer, oneuser, one role, one administration”; in short,one of everything. However, if several peopletry to use the same computer today, or crossadminstrative boundaries, or change roles fromwork to home life, chaos generally ensues.

Several hardware technologies will soon pushthis limited model of computing beyond thebreaking point. Projectors and physically largeflat panel displays have become affordable andare about to take a leap in resolution[12]. Cellphone size devices can now store many giga-bytes of information, take high resolution pho-tographs, have significant computation capabil-ity, and are small enough toalwaysbe with you.

Ask yourself “Why can’t we sit with friends,family or coworkers in front of large displaywith audio system, and all use it at once?”

You should be able change roles or move lo-cations, and reassociate with the local comput-ing environment. The new mantra must become‘many’ and ‘mobile’ everywhere ‘one’ has suf-ficed in the past.

Change will be required in many areas frombase system, through the window system andtoolkits, and in applications to fully capitalizeon this vision.

1 Introduction

As much as three quarters of the cost of com-puting in enterprise environments now goes tosystem management and support; the hardwareand software purchase cost is well under halfof the total expense. In the some parts of thedeveloping world, expertise may be in shortersupply than computers. Personally, I now man-age three systems at home, in addition to threefor work. Clearly something needs to be done.

Project Athena[13], a joint project of Digital,MIT and IBM in the mid 1980’s, had the vi-sion of centrally administrated, personal com-puting, in which mobile students and facultycould use which ever computer was most con-venient or appropriate for their work. Out ofthis project was born a number of technolo-gies that we take for granted today, includingKerberos[24], the X Window System[31], cen-tral administration of configuration informationusing Hesiod[18] (now mostly supplanted byLDAP) and Zephyr[17], the first instant mes-sage system.

Due to the lack of a critical mass of applica-tions, UNIX divisions, and UNIX workstationscosting more than PC’s, the Athena environ-ment did not reach critical mass in the marketplace, despite demonstrating much lower costof ownership, due to much easier system man-agement. The Wintel environment has causedalmost everyone to become poor system man-

1

agers of an ever-increasing number of comput-ers, and it is now clear that Athena had moreright than wrong about it. The “solution” ofhaving to carry laptops everywhere is poor, atbest. Some of Athena’s technologies escapedand became significant parts of our computingenvironment as individual components, but theoverall vision was lost.

Athena’s vision was right on many points:

� People are mobile, the computing infras-tructure is not.

� People should be able to use any comput-ing system in the environment so long asthey are authorized.

� There is a mixture of personally ownedand organizationally owned equipmentand facilities.

� Authentication enables an organization’sto control its resources.

� Collaborative tools, either real time, ornon-realtime are central to everyone’slives.

� Your information should be available toyou wherever you go.

The Fedora Stateless Project[11] is resurrectingmost aspects of the Athena environment andextending it to the often connected laptop; andthe LTSP project[6] uses X terminal technol-ogy for low system management overhead, thinclient computing. These technologies reducecost of ownership due to system managementto something much closer to proportional to thenumber of people served rather than the numberof computers. Deployment of systems basedon these technologies, the continuing decliningcost of hardware, and open source systems zerosoftware cost, will enable computers to be lo-cated wherever may be convenient. We need to

go beyond the Athena vision, however, good asit is for centralized system management.

History also shows Athena’s presumptions in-correct or insufficient:

� We presumed display technology limitedto one individual at a time, possibly withsomeone looking over the shoulder.

� That users play a single role, where inthe adult world we play many roles, job,home life, church, schools, clubs, and of-ten more. Computer systems must enablepeople to play multiple roles simultane-ously.

� That universal authentication was possi-ble. This is probably a chimera despite ef-forts of Microsoft and Sun Microsystems -it implies universal trust, unlikely betweenorganizations. At best, you may have asingle USB fob or wireless device withmany keys that authenticate you for yourmany roles in life, at worst, many such de-vices, attached to your physical keyring.

� That there would be very small wearabledevices, with significant storage and com-puting power (soon sufficient for mostuser’s entire computing environment).

� That wireless networking would becomevery cheap and commonplace.

� That the computing environment is andPC, file, compute and print services: to-day’s environments include projectors andlarge format displays, (spatial) audio sys-tems, display walls, and so on.

So long as large displays are few and far be-tween, and limited in resolution, the pseudo-solution of the laptop VGA connector attachedto a projector has been a poor but adequate

2

solution. Projectors are now cheap and com-monplace, but with the imminent advent of1080i and 1080p large screen HDTV displaysand projectors (1080p is 1920x1080 resolu-tion in computer-speak), we face a near fu-ture in which we will finally have displays withenough pixels that sharing of the display makessense. We will soon be asking: ‘Why can’t Iuse the environment easily? Why can’t I com-bine my 100 gig cell phone with the surround-ing environment to always be able to have mycomputing environment with me? Why can’t Ieasily shift from work, to home, to school, tochurch, to hobby?’

Computing systems should enable the reasso-ciation of people, any computing devices theyhave with them, and the computing infrastruc-ture available wherever they meet, work, andplay. While many devices can be used by onlyone person at a time (e.g. keyboards, mice,etc.), others, such as large screens and audiosystems can and should be usable by multiplepeople simultaneously. It is time we make thispossible.

2 User Scenarios

My great thanks to my colleagues AndrewChristian et. al. for exploring wider insightsinto SNAP Computing[15]. Some of the sce-narios below are excerpted from that paper.This paper will provide a concrete proposal forwork on the X Window System, but withoutproviding background material explaining theSNAP vision, it would be impossible to under-stand the rationale of the design changes pro-posed.

2.1 Office

You are sitting in your office. Your incomingfrantic call is from your spouse, who is having

problems with a complicated formatting prob-lem in the word processor of a document thatmust be sent before you get home that evening.You ask that the window be cloned to your dis-play, so you can help solve the problem to-gether. When finished, you close the clonedwindow and the document is finished by thedeadline.

2.2 Home

In this example Nikki and her friend Chris aresitting in Nikki’s living room watching tele-vision on a big, high-resolution video screen,but also doing a little work and web browsing(see below). The living room’s personal videorecorder (PVR) is playing a movie on the videoscreen and sending audio to the living room au-dio system. Nikki has pulled out a portablekeyboard, connected to the home office CPU,and pulled up her e-mail on a corner of the liv-ing room video screen. As she browses her re-mote mail store, audio attachments are routedand mixed in the local audio system and playedthrough the living room speakers so that theyappear on her side of the room (spatially lo-cated so as to not distract Chris).

3

Meanwhile, Chris has pulled out a wirelesshandheld computer. Nikki has previouslygranted Chris some access rights for using thehome’s broadband connection and living roomequipment, so Chris grabs a section of thebig video screen and displays output from aweb browser running on the handheld com-puter. Audio output from Chris’s web browseris spatially located to help disambiguate it fromNikki’s e-mail. Without a keyboard Chrismust use the handheld computer for handwrit-ing recognition and cursor control. To speedthings up, Chris borrows a wireless keyboardfrom Nikki’s home office. The keyboard de-tects it is in the living room and bonds automat-ically to the big screen. Through the handheldcomputer, Chris assigns the keyboard to workwith the web browser and goes back to surfing.

Most of the time Chris and Nikki are workingwithin the confines of the big video screen. Forexample, both may be driving their own privatepointing cursor on the screen. Security poli-cies prevent them from controlling each others’applications; Nikki typing at her e-mail is keptseparate from Chris’s web browsing. However,the big screen also provides high level servicesthat both can request and access. For example,a screen window manager service positions theindividual windows and a screen cut-and-pasteservice allows data to be shared across users.Should Chris or Nikki wish to change chan-nels or control audio volume in the room, ei-ther can ask for video screen control and usethe shared, built-in video browser to access theaudio volume control or bind it to their localdevice (Chris’ handheld or Nikki’s keyboard).

2.3 Conference Room

Functionally, a conference room is not greatlydissimilar from Nikki’s living room. The con-ference room provides shared video screens

that multiple users can access from their lap-top/handheld computers, or via broadband con-nections back to their desktop machines.

The conference room provides severalbusiness-specific services. First, the roomitself can provide scheduling and journalingfunctions. Because the conference room dis-play screens are intelligent - rather than simpleprojectors - it is easy to allow them to recordand store information about what was done inthe room. Each user provides authenticationbefore accessing services, so a clean record ofusers and activities can be journalled and madeavailable to participants later.

Adding video conferencing introduces a secondinteresting feature: virtual proximity. A videoconference establishes a virtual location rela-tionship between people and devices. For ex-ample, the remote user may wish to print a filein the conference room, display and control apresentation on the video screen, and play au-dio through the local speakers.

To make this more concrete, imagine you areat a meeting of a industry working group withrepresentatives from competitors, to work ona standards document. Several of you put updrafts on the conference room display screensto work on from the laptops you brought withyou. One of your working group memberscomputer has failed entirely, but he has the in-formation cached in his cellphone, so using aspare keyboard in the conference room, he isable to find the needed information using a cor-ner of the screen for the group.

Such conference rooms were described byIsaac Asimov in his Foundation series, in whichhis first foundation mathematicians work to-gether in rooms whose wallsaredisplays. Suchconference rooms are no longer science fic-tion; display wall systems are already beingbuilt[9][2], and their cost will continue to fall.

4

3 Design Requirements of theSNAP Vision

If we are to disassemble, or unsnap, the com-ponents of the classic computer and allow theflexible reassociation (or snapping together) ofcomponents, while enabling people to reasso-ciate with the computing environment as theymove, we require some networking connectorsto snap the components back together. I ar-gue that the networking connectors now exist,and if we disassemble our systems and combinethe pieces using these connectors, we can theneasily snap them back together dynamically atwill. I will touch on some of the resulting top-ics in this section, before diving into X WindowSystem specific issues.

These software components include:

� distributed caching file systems (e.g.Coda[23])

� encryption of all network communication

� roaming between networks

� software which can easily roam amongmultiple differing authentication systems

� discovery of network services

� network connectors replacing hard wiresto snap the computing components backtogether

� network audio, so that you can easily useaudio facilities in the environment

� the window system that supports multiplepeople collaborating, and helps protectsyou from other malicious people

3.1 Service Discovery

People need to be able to discover that fa-cilities are available and take advantage ofthem. Open source implementations of theIETF Zeroconf[10] protocols are now availablesuch as Howl[4]); zeroconf is also used to goodeffect as Apple’s Bonjour[1] in OSX. We canleverage such protocols to discover file sys-tems, X Window System servers for large dis-plays, scanners, printers, and other services thatmay be interesting to mobile users in the envi-ronment, and zeroconf support is beginning toappear in open source desktop projects.

3.2 Localization

For ease of use, you need to know what de-vices are in a given physical location. Present-ing a user with a long list of devices present inmany work environments, even just a local sub-net, would result in confusion. Research showsthat it may be feasible to localize 802.11[abg]to roughly the granularity of an office or a con-ference room, but such systems are not gener-ally available at this date. Given these resultsit is clear that location tracking systems willbecome available in the near term future, andthere are startup companies working actively tobring them to market.

Bluetooth was intended as a cable replacement,but experience with it has not been very favor-able in a SNAP system application. Introduc-ing a new bluetooth device to its controller isinvolved, and time consuming, not somethingthat is done casually, at least as cumbersome asdragging a cable across a room and plugging itin.

The 801.15.4 ZigBee local wireless technology,just becoming available, does not suffer fromthese limitations that make Bluetooth so cum-bersome. Additionally, IR is ubiquitous can

5

be used for local line of sight localization, andhandheld devices often have consumer IR (in-tended for remote control use), which has muchlonger range than that found in laptops.

There are multiple efforts in the research com-munity to provide location based lookup of re-sources, and this work and expertise should beleveraged.

3.3 Audio

There is a long history of inadequate audioservers on UNIX and Linux.

ESD and NAS are inadequate even for localmultimedia use (lacking any provision for tighttime synchronization), much less low latencyapplications like teleconferencing.

There are a number of possible paths:

� the Media Application Server (MAS)[7]may be adequate

� we can build a network layer for theJack[5] audio system

These possibilities are not mutually exclusive(Jack and MAS could be used in concert), andwe can start from scratch, if they will not serve.

Detailed discussion of the need/requirementsfor network audio, needed to complement ournetwork transparent window system are beyondthe overall scope of this paper. The AF audioserver[25] on UNIX of the early 1990’s showedthat both very low latency and tight synchro-nization is in fact possible in a network trans-parent audio server.

3.4 Network Roaming

There is much work to be done to take whatis possible and reduce it to practice. Real-timeroaming between networks can be as short asfractions of a second; we should not accept thecurrent delays or manual nature we find todayas we DHCP and manually suspend/resume aswe transition between networks. Handoff be-tween networks can and should be similar induration to the cellphone network, so short asto be effectively unnoticed.

4 X Window System

The ‘One’ mantra is most clearly ingrained inall of today’s window systems, where one key-board, one mouse, one user is the norm. Ourbase operating system, however, was designedas a multi-user system, with the operating sys-tem providing protection between users. TheX Window System has at least been, since itsinception, network transparent, allowing appli-cations to run on multiple displays, potentiallyincluding displays in our environment.

4.1 Multiple People Systems

X’s current design presumes a single person us-ing the window system server, and thereforeonly provided access control. To allow multi-ple people, particularly in open environmentswhere people cannot trust each other, to use acommon screen means that privacy and securityproblems must be solved.

The core X protocol allows applications tospy on input. Furthermore, cut-and-paste canquickly transfer megabytes of data between ap-plications. Multiple simultaneous users there-fore pose a serious security challenge. X needs

6

better access control to input events, pixmapdata, X properties, and other X resources mustbe enforced.

During the mid 1990’s, there was work to ex-tend X for the requirements posed by militarymulti-level ‘orange book’ security. The result-ing extension provided no policy flexibility, andstill presumed a single user. The resulting X Se-curity extension[35] has remained entirely un-used, as far as can be determined.

Recently, Eamon Walsh, an intern at the NSA,implemented a SELinux style X extension [34]with the explicit goal of enabling multiple pos-sible security policies, that might provide thekinds of policy flexibility. Differing environ-ments, in which different levels of trust be-tween users exist and different sensitivities ofinformation displayed on the screen simultane-ously, will clearly need different policies. Onepolicy can clearly not fit all needs. Eamon’swork was updated this spring by Bryan Eric-son, Chad Hanson and others at Trusted Com-puting Solutions, Inc., and provides a generalframework that may be sufficient to explore thepolicies required for this use of the window sys-tem.

X has internally noexplicit concept of a ‘user,’without which it is impossible to devise any se-curity policy for systems being used by multi-ple people. Given good security policies andenforcement, in many environments even un-known people should have unprivileged accessto a display. An explicit concept of a user, andthe window resources they are using, is clearlyneeded in X, and once present, policy develop-ment using this framework should become fea-sible. X also lack explicit knowledge of a peo-ple’s sessions, and since several sessions maybe going on simultaneously, I also expect X willrequire this concept as well.

On Linux and some UNIX systems you can de-termine the person’s identity on the other end

of a local socket. We also need the identity ofthe person’s application on the far end of a net-work connection. In a corporate environment,this might best be served by the person’s Ker-beros credentials. In other environments, sshkeys or certificate based authentication systemsmay be more appropriate. Fortunately, it ap-pears that Cyrus SASL[19] may fill the authen-tication bill, as it supports multiple authentica-tion families.

Even with this work, there is work remaining todo to define usable security profiles, and workthat should take place in toolkits rather than re-lying solely in the window system. For exam-ple, a person cutting from their application andpasting into another person’s application doesnot have the same security consequence as theopposite situation, of others being able to cutfrom your application into their application: inthis case, the person is giving away informationexplicity that they already control. It is easier totrust the implementation of the toolkit you areusing, than the implementation of a remote Xserver that you may have much less reason totrust.

More subtle questions arise for which there arenot yet obvious answers: How do you knowwhat security profile is currently in force inthe X server you are using? Why should youtrust that that profile is actually being enforced?These class of problems are not unique to X, ofcourse.

Distinguishing different pointing devices ac-cording to the people using them will requirean extension to X to support multiple mousecursors, that can be visually distinguished fromeach other. Since hardware supports a singlecursor at most, X already commonly uses soft-ware cursors, and by compositing another im-age with the cursor shape, we can easily indi-cate whose cursor it is.

7

4.2 Securing the wire and the SSH trap

At the time of X11’s design (1987), and untiljust a few years ago, the U.S. government ac-tively discouraged the use of encryption; thebest we could do was to leave minimal hooksin the wire protocol to enable a later retrofit.Even pluggable architectures allowing the easyaddition of encryption were actively opposedand might cause the U.S. Government to forbidexport of software. Export of encryption with-out export control only became feasible in opensource projects in the last several years.

In the era of little or no security problems ofthe 1980’s and early 1990’s, X was for a timeroutinely used unencrypted over the network.With network sniffers on insecure systems ev-erywhere today, this usage today is clearly in-sane.

The Swiss army knife of encryption and au-thentication, “ssh”[14], appeared as a solution,which provides authentication, encryption andcompression by allowing tunneling of arbitrarystreams (including X traffic). While it has beena wonderful crutch for which we are very grate-ful, a crutch it is, for the following reasons:

� SSH requires you to have an account on amachine before tunneling is possible. Thisprevents the casual use of remote displays,even those we might intend for such use.

� SSH requires extra context switches be-tween the ssh daemon, costing perfor-mance, memory, latency, and latency vari-ation, likely an issue on LTSP servers.

� A remote person’s identity cannot be de-termined; only the identity of their localaccount.

IPSEC might seem to be the easiest solution,and may be necessary to implement as a ‘check

off’ marketing item: however, it does not en-sure end-to-end encryption of traffic, and evenworse, does not provide user authentication. InIPSEC’s use in VPN software, the data is of-ten unencrypted at corporate firewalls and de-livered unencrypted, unacceptable for use thatinvolves user keyboard input. It is therefore ata minimum insufficient for SNAP computing,and in some uses, in fact completely insecure.

Therefore authentication, encryption, and com-pression must be integrated into the X Win-dow System transport to allow for a wider rangeof authentication and encryption options, to beproxyable to enable secure traversal of admin-istrative boundaries, and to enable use of dis-play resources on displays where you cannotbe authenticated. Compression can provide ahuge performance benefit over low bandwidthlinks[27].

4.3 Remote Devices

It has always been trivial for an X application touse a remote display, but when the applicationis running to a remote X server, there has beena presumption that the input devices are also at-tached to the remote machine. Having to drapeinput device cables across the room to plug intothe computer driving the display, is clearly lu-dicrous. We therefore need network transparentinput devices.

People may want to use either spare keyboards,a laptop they brought with them, their PDA, orother input devices available in the room to in-teract with that application. In any case, inputevents must be routed from the input device tothe appropriate X server, whether connected viawires or wireless.

Input devices present security challenges, alongwith a further issue: we need some way to asso-ciate an input device with a particular user. As-sociation setup needs to be both secure and easy

8

to use, which may present the largest single re-search challenge; most of the other tasks de-scribed in this paper are simple engineering ef-forts, applying existing technology in obviousways. One might have hoped that USB’s HIDserial numbers on devices would help; how-ever, due to the very low cost of many inputdevices, most manufacturers do not provide ac-tual serial numbers in their hardware.

4.4 Who is in Control?

The X server implementation has presumedthat it is in control of all of its input devices,and worse yet, that these do not change duringan X session. It uses a static configuration file,only read during server reset (which only oc-curs when a user logs out). This static model ofconfiguration is clearly wrong, and hotplug is anecessary. The X server needs (as in all goodserver processes) to react to changes in the en-vironment.

Over the last two years, open source systemshave developed extensive infrastructure to sup-port hotplug, with kernel facilities, and the D-BUS[29] and HAL[36] facilities. These shouldgreatly simplify the problem, and allow the pol-icy decisions of whether an input device (localor remote) is connected to a particular X server.

D-BUS can inform the X server of the changesin configuration of input devices. This itselfposes a further challenge, as the X server mustbe able to become a client of the D-BUS dae-mon. To avoid possible dead-lock situations be-tween X and the D-BUS daemon, some of theinternal X infrastructure needs updating.

With only slight care, an interface can be de-signed that will allow input devices to either uselocal or remote input devices. Input device as-sociation policy should be kept outside of the Xserver.

4.5 X Input Extension

The X Input Extension[28] provides supportfor additional input devices beyond the ‘core’pointing device (typically mouse) and key-board. It has a competent design, though itshows its age. XInput lacks:

� Hotplug notification of devices being con-nected or disconnected.

� The valuator axes should have abstractnames (e.g. you would like to know thatvaluator 0 is the X coordinate, valuator 1is the Y coordinate, valuator 2 is pressure,and so on).

� Support for multiple users and devices thatall users might share.

� A modern reimplementation exploiting thestandardization of USB HID (and the/dev/input abstraction on Linux); most ofthe current implementation is supportingold serial devices with many strange pro-prietary protocols.

� A limit on 255 input devices in the wireencoding (which might become an issue inan auditorium setting); however, if inputevents are augmented by a identity infor-mation, this should be sufficient.

Whether a upward compatible wire protocolversion is possible or a new major version of theX Input extension is not yet completely clear,though an upward compatible API looks verylikely.

4.6 Toolkits

Replication and migration of running applica-tions has in fact been possible from X’s incep-tion: GNU emacs has had the capability to both

9

share buffers on different X servers, allowingfor shared editing of text, and therefore migra-tion of emacs from X server to X server formore than 15 years.

In practice, due to the level of abstraction ofthe most commonly used toolkit of X’s first era(Xt/Motif[22]), migration and/or replication ofwindows has been very difficult, as such appli-cations initially adjust themselves to the visualtypes available on the X server and then drawfor the rest of their execution with the samepixel values.

Modern toolkits (e.g. GTK[21] and Qt[16])operate at a higher level of abstraction, wherepixel values are typically hidden from appli-cations, and migration of most applications isfeasible[20]: a prototype of migration capabil-ity first appeared in GTK+ 2.2.

One to one replication of information is thewrong level of abstraction, since not only is theresolution of different screens extremely wide,but different users on different displays shouldbe able to control the allocation of the screenreal-estate. A multi-view approach is clearlycorrect and to be preferred over the existingserver based pixel sharing solutions such asxmove[32], useful though such tools are, par-ticularly for migration of old X applicationsthat are unlikely to be updated to modern toolk-its. Work to ease replication of windows for ap-plication developers awaits suitably motivatedcontributors.

Since the resolution between a handheld deviceand a display wall is over an order of mag-nitude, applications often need to be able toreload their UI layout on the fly for migrationto work really well; again, using the Glade userinterface builder[3], libglade and GTK+, thiscapability is already demonstrable for a few ap-plications.

In the face of unreliable wireless connections,

the X library needs minor additions to allowtoolkits to recover from connection failures.This work is on hold pending completion ofa new implementation of Xlib called Xcb[26],which is well underway and now able to run al-most all applications. Testing connection lossrecovery may be more of a challenge than itsimplementation.

Lest you think these facilities are interestingonly to SNAP computing, it also aids migrationof X sessions from one display (say work) toanother (e.g. home). As always, security mustbe kept in mind: it would not be good for some-one to be able to steal one or all of your runningapplications.

4.7 Window Management and Applica-tions

Besides the infrastructure modifications out-lined above, window managers need somemodification to support a collaborative environ-ment.

Certain applications may want to be fully awareof multiple users: a good example is an editorthat keeps changes that each person applies toa document.

Existing applications can run in such a collab-orative environment unchanged. Wallace et.al.[33] recently reported experience in a de-ployed system using somewhat jury rigged sup-port for multiple cursors and using a modifiedX window manager on a large shared display atPrinceton’s Plasma Physics Lab’s control room.They report easier simultaneous use of existingapplications such as GNU Image ManipulationProgram (gimp). They also confim, as hypothe-sized above, multiple people working indepen-dently side by side require sufficient displayreal-estate to be effective; here they may belooking at different views of the same dataset

10

using separate application instances. And fi-nally, they report that even sequential use of thedisplay was improved due to less dragging ofthe mouse back and forth.

5 Summary

Most of the problems SNAP computing posehave obvious solutions; in a few areas, furtherresearch is required, but none of the researchtopics appear intractable.

Network display software systems such as Mi-crosoft’s RDP[8] and Citrix and VNC[30] arepopular, though by operating at a very low levelof abstraction, badly compromise full appli-cation integration (e.g. cut and paste, selec-tions, window management meta information)between applications sharing a display frommany remote systems. They do, however, doa fine job of simple access to remote applica-tions, but arefatally flawedif full collaborationamong multiple users is desired.

Open source systems SNAP systems should beable to exist quickly, not only since our tech-nology starts off close to the desired end-state,is more malleable, but also that it does notthreaten our business model in the same waythat such a shift might to commercial systems.

While this paper has primarily explored X Win-dow System design issues, there is obviouslyplenty of work elsewhere to fully exploit the vi-sion of SNAP Computing.

References

[1] Bonjour. http://developer.apple.com/darwin/projects/bonjour/index.html/ .

[2] Distributed Multihead X Project.http://dmx.sourceforge.net/ .

[3] Glade - a User Interface Builder forGTK+ and GNOME.http://glade.gnome.org/ .

[4] Howl: Man’s new best friend.http://www.porchdogsoft.com/products/howl/ .

[5] Jack audio connection kit.http://jackit.sourceforge.net/ .

[6] Linux Terminal Server Project.http://www.ltsp.org/ .

[7] Media Applications Server.http://www.mediaapplicationserver.net/ .

[8] RDP Protocol Documentation.http://www.rdesktop.org/#docs .

[9] Scalable Display Wall.http://www.cs.princeton.edu/omnimedia/index.html .

[10] Zero Configuration Networking(Zeroconf).http://www.zeroconf.org/ .

[11] Stateless Linux, 2004.http://fedora.redhat.com/projects/stateless/ .

[12] Will Allen and Robert Ulichney.Wobulation: Doubling the addressedresolution of projection displays. InSID2005, volume 47.4. The Society forInformation Display, 2005.http://sid.aip.org/digest .

[13] Edward Balkovich, Steven Lerman, andRichard P. Parmelee. Computing inhigher education: the athena experience.Commun. ACM, 28(11):1214–1224,1985.

11

[14] Daniel J. Barrett and Richard Silverman.SSH, The Secure Shell: The DefinitiveGuide. O’Reilly & Associates, Inc.,2001.

[15] Andrew Christian, Brian Avery, StevenAyer, Frank Bomba, and Jamey Hicks.Snap computing: Shared wireless plugand play. 2005.http://www.hpl.hp.com/techreports/2005/ .

[16] Matthias Kalle Dalheimer.Programmingwith Qt. O’Reilly & Associates, Inc.,second edition, May 2001.

[17] C. Anthony DellaFera, Mark W. Eichin,Robert S. French, David C. Jedlinsky,John T. Kohl, and William E.Sommerfeld. The zephyr notificationservice. InUSENIX Winter, pages213–219, 1988.

[18] S. P. Dyer. The hesiod name server. InProceedings of the USENIX Winter 1988Technical Conference, pages 183–190,Berkeley, CA, 1988. USENIXAssociation.

[19] Rob Earhart, Tim Martin, LarryGreenfield, and Rob Siemborski. SimpleAutentication and Security Layer.http://asg.web.cmu.edu/sasl/ .

[20] James Gettys. The Future is Coming,Where the X Window System ShouldGo. InFREENIX Track, 2002 UsenixAnnual Technical Conference, Monterey,CA, June 2002. USENIX.

[21] Eric Harlow. Developing LinuxApplications with GTK+ and GDK.MacMillan Publishing Company, 1999.

[22] Dan Heller.Motif Programming Manualfor OSF/Motif Version 1.1, volume 6.O’Reilly & Associates, Inc., 981

Chestnut Street, Newton, MA 02164,USA, 1991.

[23] J. J. Kistler and M. Satyanarayanan.Disconnected operation in the coda filesystem. InThirteenth ACM Symposiumon Operating Systems Principles,volume 25, pages 213–225, AsilomarConference Center, Pacific Grove, U.S.,1991. ACM Press.

[24] J. Kohl and B. Neuman. The kerberosnetwork authentication service.Technical report, 1991.

[25] T. Levergood, A. Payne, J. Gettys,G. Treese, and L. Stewart. Audiofile: Anetwork-transparent system fordistributed audio applications, 1993.

[26] Bart Massey and Jamey Sharp. XCB: AnX protocol c binding. InXFree86Technical Conference, Oakland, CA,November 2001. USENIX.

[27] Keith Packard and James Gettys. XWindow System Network Performance.In FREENIX Track, 2003 Usenix AnnualTechnical Conference, San Antonio, TX,June 2003. USENIX.

[28] Mark Patrick and George Sachs. X11Input Extension Protocol Specification,Version 1.0. X consortium standard, XConsortium, Inc., 1991.

[29] Havoc Pennington, Anders Carlsson, andAlexander Larsson. D-BUSSpecification.http://dbus.freedesktop.org/doc/dbus-specification.html .

[30] Tristan Richardson, QuentinStafford-Fraser, Kenneth R. Wood, andAndy Hopper. Virtual networkcomputing.IEEE Internet Computing,2(1):33–38, 1998.

12

[31] Robert W. Scheifler and James Gettys.XWindow System. Digital Press, fourthedition, 1996.

[32] Ethan Solomita, James Kempf, and DanDuchamp. XMOVE: A pseudoserver forX window movement.The X Resource,11(1):143–170, 1994.

[33] Grant Wallace, Peng Bi, Kai Li, and OttoAnshus. A MultiCursor X WindowManager Supporting Control RoomCollaboration. Technical reporttr-707-04, Princeton UniversityComputer Science, July 2004.

[34] Eamon Walsh. Integrating XFree86 WithSecurity-Enhanced Linux. InXDevelopers Conference, Cambridge, MA,April 2004. http://freedesktop.org/Software/XDevConf/x-security-walsh.pdf .

[35] David P. Wiggins. Security ExtensionSpecification, Version 7.0. X consortiumstandard, X Consortium, Inc., 1996.

[36] David Zeuthen. HAL Specification 0.2.http://freedesktop.org/~david/hal-0.2/spec/hal-spec.html .

13