Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ubuntu moving away from X



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org