Ubuntu moving away from X

[mbr-rRLCkWC8vypBDgjK7y7TUQ at public.gmane.org (MBR)]

Getting back to the original topic -- that Ubuntu is planning to move to 
an OpenGL-based window system and relegate X to compatibility-mode 
status -- my initial reaction was dismay because that will most likely 
mean that X will wither and die over the next 5-10 years. And since X is 
the only window system that allows you to run applications anywhere on 
the Internet and have them all show up on your display, this decision 
seemed like it would mean that that capability would disappear as X 
disappears.

But then I thought about how typical GUI applications are being written 
today. Many (most?) are no longer native applications. They're 
Javascript applications running in the browser.  And for those 
applications, the functionality we once counted on the window system to 
provide is now being provided by the browser.

I'm not sure what the situation is WRT native apps on mobile phones, but 
web browsers provide the same network capabilities in that environment 
that they do on traditional computers.

So, maybe Ubuntu's decision isn't the disaster I initially feared.

    Mark Rosenthal


On 11/6/2010 8:07 AM, Jerry Feldman wrote:
> 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:
>>
>>> 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.
>>
>
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss