Ubuntu moving away from X

[MBR]

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.