Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Mark, I agree. The X client-server architecture is what allows us to simply set up an application (eg. X client) to run on one machine and display on another. In contrast, on Windows one needed to buy an application such as Carbon Copy to have the same effect. On 11/05/2010 05:38 PM, MBR wrote: > On 11/5/2010 1:01 PM, Mark J Dulcey wrote: > =20 >> On 11/5/2010 12:40 PM, Gordon Marx wrote: >> >> =20 >>> My guess is that there'll be some really cool things coming out of Ub= untu, >>> and the fact that they're not just throwing out X means that they're >>> interested in actually advancing the state of the art in open-source >>> graphical display environments...which is cool. And about which we sh= ould >>> all be excited. >>> =20 >> I suspect that a big driver here is lightweight computing environments= >> where the overhead and memory consumption of X is an issue. An >> environment with a GUI built natively in OpenGL could provide a better= >> experience on netbooks and tablets (and perhaps other mobile devices -= - >> might Ubuntu Phone be in our future?) where the existing display >> solutions tend to be sluggish. >> =20 > Is the technology of existing display solutions at the limit of Moore's= =20 > law? If not, then the display solutions in existence by the time this = > is implemented could well have supported X11's overhead. > =20 >> I expect X to continue to be supported for a long time, and it will be= >> the environment of choice for servers (where, just as now, you'll >> typically only install the "client" part, i.e. the server in the >> backwards terminology that X uses) >> =20 > The terminology is not backwards. It makes perfect sense if you=20 > understand what's meant by a server, and calling the X server the=20 > "client" makes things confusing as hell. > > A server is a process that provides clients access to a resource. =20 > Sometimes the resource is a physical device, sometimes the resource is = > an algorithm implemented in the server. But whatever the resource, the= =20 > server is the process that calls the listen()function of the Berkeley=20 > sockets API to wait for incoming connections and accept() to handle eac= h=20 > incoming connection request. The client is the process that calls=20 > connect() to initiate a request to a server. > > For most of the physical resources we're used to (disks, printers,=20 > etc.), the client is running on our local machine, and the server is=20 > attached to the disk or printer which is far away. But resources like = > your screen, keyboard, or mouse are physically nearby, so the server=20 > controlling them runs on the host to which those resources are=20 > physically attached. The client will often run on that same machine,=20 > but it could equally well run on a computer halfway around the world. > > Back in the late 1980s, early 1990s timeframe, I read a white paper=20 > released by Microsoft whose sole purpose was to denigrate the X Window = > System -- part of the endless stream of Microsoft FUD. One of the bits= =20 > of nonsense they spread was that the X people got the definition of=20 > "server" backwards. > > The definition of "server" as a piece of software that controls a=20 > resource is useful. It tells you what that software does, and which=20 > socket calls it's going to need to use. Defining "server" to mean a=20 > piece of software running physically far away from you tells you nothin= g=20 > at all about what the software does. And using Microsoft's definition = > means that the display "server" would call connect() and make requests = > of the "client" that controls the display resource. So, unlike a clien= t=20 > of a print server, where the application logic (i.e. what does this=20 > application want to display on the printer) resides in the client, usin= g=20 > Microsoft's near vs. far definition would mean that the client of the=20 > display server calls accept() and listen() and the display server would= =20 > contain the application logic (i.e. what does this application want to = > draw on the screen). > > X is unique among window systems in providing the ability to run a=20 > client anywhere on the net and have its output display on your screen. = =20 > The advent of the world-wide web changed things. X's ability to displa= y=20 > data generated by remote machines became somewhat less important when=20 > that capability was moved inside a particular client (the web browser).= =20 > But for any GUI application that doesn't run in a browser, X's network = > architecture is still necessary for remote display. > =20 --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |