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 |
On 11/5/2010 1:01 PM, Mark J Dulcey wrote: > On 11/5/2010 12:40 PM, Gordon Marx wrote: > >> My guess is that there'll be some really cool things coming out of Ubuntu, >> 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 should >> all be excited. > 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. Is the technology of existing display solutions at the limit of Moore's law? If not, then the display solutions in existence by the time this is implemented could well have supported X11's overhead. > 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) The terminology is not backwards. It makes perfect sense if you understand what's meant by a server, and calling the X server the "client" makes things confusing as hell. A server is a process that provides clients access to a resource. Sometimes the resource is a physical device, sometimes the resource is an algorithm implemented in the server. But whatever the resource, the server is the process that calls the listen()function of the Berkeley sockets API to wait for incoming connections and accept() to handle each incoming connection request. The client is the process that calls connect() to initiate a request to a server. For most of the physical resources we're used to (disks, printers, etc.), the client is running on our local machine, and the server is attached to the disk or printer which is far away. But resources like your screen, keyboard, or mouse are physically nearby, so the server controlling them runs on the host to which those resources are physically attached. The client will often run on that same machine, 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 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 of nonsense they spread was that the X people got the definition of "server" backwards. The definition of "server" as a piece of software that controls a resource is useful. It tells you what that software does, and which socket calls it's going to need to use. Defining "server" to mean a piece of software running physically far away from you tells you nothing 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 client of a print server, where the application logic (i.e. what does this application want to display on the printer) resides in the client, using Microsoft's near vs. far definition would mean that the client of the display server calls accept() and listen() and the display server would 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 client anywhere on the net and have its output display on your screen. The advent of the world-wide web changed things. X's ability to display data generated by remote machines became somewhat less important when that capability was moved inside a particular client (the web browser). But for any GUI application that doesn't run in a browser, X's network architecture is still necessary for remote display. Mark Rosenthal mbr-rRLCkWC8vypBDgjK7y7TUQ at public.gmane.org <mailto:mbr-rRLCkWC8vypBDgjK7y7TUQ at public.gmane.org> > and power desktop users because of > its remote capabilities. But the ability to separate the client and > server aren't so important for everyone, and cutting the display > overhead is.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |