[GRLUG] Thinking of app servers

Ben DeMott ben.demott at gmail.com
Wed Mar 3 17:38:31 EST 2010


To drive home my point about the Mess that is X.
On the Todo list for the development roadmap is:
"Rewrite the bottom of the rendering layer" -> yeah.

On Wed, Mar 3, 2010 at 5:01 PM, Ben DeMott <ben.demott at gmail.com> wrote:

> Nice explanation Michael on X by the way.
>
> The amount of time it would take me to concisely re-enact a conversation I
> had at Fosdem a year ago is just not worth it.
>
> Several Large projects have attempted to replace the dependency on X for
> cases where it's not needed, the abstraction is not needed or wanted.
> And they have all failed... Mostly because of a lack of portability, or
> backwards computability.
> X isn't even sure about what portions of the user experience standard they
> are implementing as well as loosely implementing some ISO standards.
>
> X is a mess...
> Not only from a "They don't know what they are supporting standpoint"
> But from a general Rendering standpoint.
>
> Basically lots of people in the industry want to bring a Good OpenGL based
> rendering platform that is tightly integrated to *GTK and the KERNEL
> For lot's of various reasons... argue with them if you want but right now
> an Open Source equivalent of DirectX will never make it to *nix because of
> rendering problems to overcome, specifically with X as the source of input
> and output.
> There are huge challenges with X's Frame Buffer and implementation as well
> as support for legacy software rendering.
>
> In the framebuffer source code there are entire portions commented out...
> and at one point there were comments in the source like "What does this do"
> I'm told that things have improved since then.
>
> The original INTENT of X is not workable, or accessible to users today...
> its hard to get running, and working.
> If you are reading this you represent the top 10% of the most Technical
> *Nix users (At least) so it may not seem that way to YOU.
> And in general desktop sessions are not realistically portable.
>
> The thing (being the collection of programs that form the end-user
> experience) from a non-technical standpoint is a ... "MESS".
> And the dependency on X is the fuel to the flame.
>
> In my hurry to write my previous post I switched the verbage of X-Server
> and X-Client, my apologies for the Typo.
>
> And I commonly throw around the word "Gnome" to mean "The collection of
> programs that connect to an X-Server and eventually get rendered to the
> framebuffer", seeing as most people have no idea what the individual
> components are.
>
>
> Well I apologize this has turned into an X-bashing rant...
>
> On Wed, Mar 3, 2010 at 4:33 PM, Adam Tauno Williams <
> awilliam at whitemice.org> wrote:
>
>> On Wed, 2010-03-03 at 15:11 -0500, Ben DeMott wrote:
>> > X was designed, so applications could run on remote servers, and be
>> > interacted with graphically on a local client.
>> > The whole thing is a huge mess...
>>
>> I disagree.  I see a mess nowhere.  There are clear lines of delineation
>> between components.
>>
>> > You should be able to attach and run programs on a remote X Server.
>>
>> That makes no sense.  There is no "remote X server".  The server is
>> local;  that is the design of X.  The service provided by the server is
>> display.
>>
>> > Have the X information piped to an X client and then have Gnome
>> > attached to the local X client.
>> > This doesn't however work in my limited experience.
>> > This is the closest you can get:
>> > http://mohanjith.net/blog/2008/01/using-gnome-remotely-via-ssh.html
>>
>> I'm not sure what his issue is (and the post is a year old).  But....
>>
>> awilliam at linux-yu4c:~> ssh -X adam at workhorse.cis.mormail.com
>> Last login: Fri Oct  9 11:54:33 2009 from
>> fdb5:60da:9b8a:1:219:d2ff:fe42:66b6
>> Have a lot of fun...
>> adam at workhorse:~> evolution
>>
>> Boom!  There is evolution.  I'm not sure what you are saying doesn't
>> work.  Automatically started are:  dbus, gconfd,
>> bonobo-activation-framework, evolution-data-server, gvfs-fuse-daemon,
>> gnome-keyring-daemon, etc...
>>
>>
>> adam at workhorse:~> ps -u adam
>>  PID TTY          TIME CMD
>> 11455 ?        00:00:00 sshd
>> 11456 pts/2    00:00:00 bash
>> 11499 pts/2    00:00:58 evolution.bin
>> 11503 pts/2    00:00:00 dbus-launch
>> 11504 ?        00:00:00 dbus-daemon
>> 11506 ?        00:00:00 gconfd-2
>> 11508 ?        00:00:00 gnome-keyring-d
>> 11512 ?        00:00:00 bonobo-activati
>> 11518 ?        00:00:00 evolution-data-
>> 11540 ?        00:00:00 evolution-alarm
>> 11601 ?        00:00:00 notification-da
>> 11604 ?        00:00:00 gvfsd
>> 11610 ?        00:00:00 gvfs-fuse-daemo
>> 11623 pts/2    00:00:00 ps
>>
>>
>> _______________________________________________
>> grlug mailing list
>> grlug at grlug.org
>> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shinobu.grlug.org/pipermail/grlug/attachments/20100303/ff08269b/attachment.htm 


More information about the grlug mailing list