[GRLUG] Thinking of app servers
Ben DeMott
ben.demott at gmail.com
Wed Mar 3 20:19:10 EST 2010
Really appreciate the detailed response Michael .. I'm leaving work right
now after reverse engineering source code that's undocumented, my brain is
fried, and I will respond when I have a little more time.
I agree with most of what you said... hahaha and yes DirectX (the rendering
bits are a mess too) but it's is a decent overall platform to get everything
out to the screen efficiently and even sound! (thats a long conversation for
another day)
And I mostly think X is 'good' as an architecture.. there just needs to be a
more concise Light-Switch in the application for "Local Super Fast Mode"
essentially.
Sony put like 3 billion into OpenGL 3 -> If x-server wasn't such an obstacle
we would (could) be rendering from an almost pure OpenGL codebase right now.
Eve Online Dropped Support for Linux after they decided the Cedega port had
too many problems...
Now with Cedega releasing version 7 it supposedly works again although its
unsupported.
It's too bad a commercial company is doing this work...
http://www.cedega.com/
In general I wish I understood the complexities of simulating the API calls
to X better and redirecting these to a local rendering engine that was much
*lighter* while simulating the same protocol features.
This in Philosophy is my favorite attempt:
http://www.fresco.org/introduction.html
And related conversations around this project is where much of my bias
towards X comes from.
Suns stab at it ...
http://en.wikipedia.org/wiki/NeWS
Y Windowing System:
http://www.y-windows.org/about.html (author explains is reasons)
http://www.y-windows.org/pipermail/y-devel/2005-January/001870.html (these
series of discussions might be of interest)
Apple replaced it with Quartz (obviously) there is a blog post somewhere by
Mike Plaquette explaining the reasons.
X is a hot, hot mess... it's code a sad mess, it's user experience a hot
mess.
I will respond more fully when I have time... I am actually interested in
starting a summer C project -> I would get involved with a backwards
compatible in-place replacement to X, or a rewrite or reduction in code.
Basically my sick and disturbed dream is that OpenGL would get shipped with
the Scene Graph manager and renderer on linux boxes making games for Linux a
possibility because of the "Standardization" that would exist.
If Nvidia keeps shipping their driver, and the Window Manager and Renderer
became "standardized" it would be a huge step in the right direction.
I don't want to FORCE RPM's down peoples throats but if everyone knew OpenGL
libs were present, accessible, configured properly, and would just "Work"
people might actually write some decent 3d projects.
There's also some good conversations (that I will dig up later) about the
work Blender went through for consideration of the Linux variant.
On Wed, Mar 3, 2010 at 5:42 PM, Michael Mol <mikemol at gmail.com> wrote:
> 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
> _______________________________________________
> 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/2307bdbf/attachment-0001.htm
More information about the grlug
mailing list