[GRLUG] Thinking of app servers

[Michael Mol]

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.

You're going to have to be a lot more specific; I can't debate
generalities very well.

>
> 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.

I'm not arguing with them, I'm debating with you; you presented the
arguments. You can defend them or reference treatises on their
defense.

(Oh, and DirectX is a mess as well. A royal, PITA, POS mess, for
anything real-world that's not specific to single-monitor video game
use cases. Want to talk about backwards compatibility? No DX10 for XP,
so I have to code for DX9. Real World coding means I only just
recently got to drop support for Win2K, so I anticipate coding for XP
and DX9 long after Vista has been EOL'd.)

> There are huge challenges with X's Frame Buffer and implementation as well
> as support for legacy software rendering.

That's why DRI was developed; nobody wanted to shuffle that volume of
data through a socket, where it would have to be marshalled to the
appropriate driver and passed on to the appropriate video device. And,
yes, DRI has a *lot* of problems, notably pointed out by Compiz
conflicting with other OpenGL apps. That's why they're rewriting it.
Nothing stops them from doing it right, this time.

I think the only way to have an effective 3D compositing window
manager with X is to have the window manager execute on the X Server's
physical hardware. If you *want* the remote display capabilities, that
means that your display box must run your window manager, which in
turn suggests you might need a program local to the X server control
the spawning of your window manager.

Which, incidentally, is what your display manager is for. (xdm, gdm, kdm)


>
> 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.

Hardware acceleration considerations aside, and from a technical
standpoint, X is just fine.  What makes "app server" technologies
difficult for that other 90% (and some of the 10% here) is that there
isn't much demand for it outside of large institutions.  Those places
hire one of this 10% to do it for them, and people from this 10% don't
need much in the way of automated tools to get things up and running.

Will this change?  Maybe.  Groups like the LTSP are working on it.
Companies like NoMachine are working on it. There's precedent; look at
Ubuntu. Until a group of developers got together with the specific
intent of building a Linux distribution someone like my grandmother
could use, there wasn't a workable avenue for building a coherent,
you-don't-have-to-write-glue-code-to-use-it system.

Another key point was when Apple switched to using Intel processors.
Now Mac owners could run OS X or Windows. Many do.  They quickly
discovered that they still couldn't really run their Windows programs
under OS X, or their Mac programs under Windows.  Along comes VMWare
with Fusion, and now you have a generation of Mac users who definitely
aren't in that top 10% who appreciate the machine boundary between
their OS X and Windows installs, and have some concept of a bridge.

That same degree of comprehension is probably going to grow more common.

We also have this explosion of Web applications going on; people run
GMail, or they run Facebook.  Well, really they're running a browser
and using those websites, but there's no substantive difference from
their perspective. I could see Facebook building a client for running
under XULrunner. I've been pondering doing the same thing for
Mediawiki sites like Rosetta Code or Wikipedia.

>
> 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.

The X *architecture* isn't (that much of) a mess. Perhaps the codebase
is, but the protocol is open, and nothing stops anyone from
cleanrooming it. Wait a sec...there are several closed-source
implementations out there already.  XFree86 is only really a reference
implementation. Xorg forked because the XFree86 folks weren't adapting
to newer technologies fast enough.

>
> 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.

Which is fine, because that's how most people *should* see X. They
don't need to comprehend how the components are bound together any
more than they need to understand TCP or the dependency order of
services in their operating system.

You've got me pondering, though...How difficult (technically; I assume
the software doesn't exist yet) would it be to have a Linux machine
advertise X11 apps via mdns, so that machines running X sessions could
see those applications and pull them up? That'd kick ass, IMO. (Sure,
there's a matter of auth checking and such, but I can see how that
could be worked around.)


>
>
> 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
>
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug
>



-- 
:wq