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.<br><br>
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)<br>
<br>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.<br><br>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.<br>
<br>Eve Online Dropped Support for Linux after they decided the Cedega port had too many problems... <br>Now with Cedega releasing version 7 it supposedly works again although its unsupported.<br><br>It's too bad a commercial company is doing this work... <br>
<br><a href="http://www.cedega.com/">http://www.cedega.com/</a><br><br>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.<br>
<br>This in Philosophy is my favorite attempt:<br><a href="http://www.fresco.org/introduction.html">http://www.fresco.org/introduction.html</a><br><br>And related conversations around this project is where much of my bias towards X comes from.<br>
<br>Suns stab at it ...<br><a href="http://en.wikipedia.org/wiki/NeWS">http://en.wikipedia.org/wiki/NeWS</a><br><br>Y Windowing System:<br><a href="http://www.y-windows.org/about.html">http://www.y-windows.org/about.html</a> (author explains is reasons)<br>
<a href="http://www.y-windows.org/pipermail/y-devel/2005-January/001870.html">http://www.y-windows.org/pipermail/y-devel/2005-January/001870.html</a> (these series of discussions might be of interest)<br><br>Apple replaced it with Quartz (obviously) there is a blog post somewhere by Mike Plaquette explaining the reasons.<br>
<br><br>X is a hot, hot mess... it's code a sad mess, it's user experience a hot mess.<br><br>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.<br>
<br>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.<br>
If Nvidia keeps shipping their driver, and the Window Manager and Renderer became "standardized" it would be a huge step in the right direction.<br>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.<br>
<br>There's also some good conversations (that I will dig up later) about the work Blender went through for consideration of the Linux variant.<br><br><br><br><br><div class="gmail_quote">On Wed, Mar 3, 2010 at 5:42 PM, Michael Mol <span dir="ltr"><<a href="mailto:mikemol@gmail.com">mikemol@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Wed, Mar 3, 2010 at 5:01 PM, Ben DeMott <<a href="mailto:ben.demott@gmail.com">ben.demott@gmail.com</a>> wrote:<br>
</div><div class="im">> Nice explanation Michael on X by the way.<br>
><br>
> The amount of time it would take me to concisely re-enact a conversation I<br>
> had at Fosdem a year ago is just not worth it.<br>
><br>
> Several Large projects have attempted to replace the dependency on X for<br>
> cases where it's not needed, the abstraction is not needed or wanted.<br>
> And they have all failed... Mostly because of a lack of portability, or<br>
> backwards computability.<br>
> X isn't even sure about what portions of the user experience standard they<br>
> are implementing as well as loosely implementing some ISO standards.<br>
<br>
</div>You're going to have to be a lot more specific; I can't debate<br>
generalities very well.<br>
<div class="im"><br>
><br>
> X is a mess...<br>
> Not only from a "They don't know what they are supporting standpoint"<br>
> But from a general Rendering standpoint.<br>
><br>
> Basically lots of people in the industry want to bring a Good OpenGL based<br>
> rendering platform that is tightly integrated to *GTK and the KERNEL<br>
> For lot's of various reasons... argue with them if you want but right now an<br>
> Open Source equivalent of DirectX will never make it to *nix because of<br>
> rendering problems to overcome, specifically with X as the source of input<br>
> and output.<br>
<br>
</div>I'm not arguing with them, I'm debating with you; you presented the<br>
arguments. You can defend them or reference treatises on their<br>
defense.<br>
<br>
(Oh, and DirectX is a mess as well. A royal, PITA, POS mess, for<br>
anything real-world that's not specific to single-monitor video game<br>
use cases. Want to talk about backwards compatibility? No DX10 for XP,<br>
so I have to code for DX9. Real World coding means I only just<br>
recently got to drop support for Win2K, so I anticipate coding for XP<br>
and DX9 long after Vista has been EOL'd.)<br>
<div class="im"><br>
> There are huge challenges with X's Frame Buffer and implementation as well<br>
> as support for legacy software rendering.<br>
<br>
</div>That's why DRI was developed; nobody wanted to shuffle that volume of<br>
data through a socket, where it would have to be marshalled to the<br>
appropriate driver and passed on to the appropriate video device. And,<br>
yes, DRI has a *lot* of problems, notably pointed out by Compiz<br>
conflicting with other OpenGL apps. That's why they're rewriting it.<br>
Nothing stops them from doing it right, this time.<br>
<br>
I think the only way to have an effective 3D compositing window<br>
manager with X is to have the window manager execute on the X Server's<br>
physical hardware. If you *want* the remote display capabilities, that<br>
means that your display box must run your window manager, which in<br>
turn suggests you might need a program local to the X server control<br>
the spawning of your window manager.<br>
<br>
Which, incidentally, is what your display manager is for. (xdm, gdm, kdm)<br>
<div class="im"><br>
<br>
><br>
> In the framebuffer source code there are entire portions commented out...<br>
> and at one point there were comments in the source like "What does this do"<br>
> I'm told that things have improved since then.<br>
><br>
> The original INTENT of X is not workable, or accessible to users today...<br>
> its hard to get running, and working.<br>
> If you are reading this you represent the top 10% of the most Technical *Nix<br>
> users (At least) so it may not seem that way to YOU.<br>
> And in general desktop sessions are not realistically portable.<br>
<br>
</div>Hardware acceleration considerations aside, and from a technical<br>
standpoint, X is just fine. What makes "app server" technologies<br>
difficult for that other 90% (and some of the 10% here) is that there<br>
isn't much demand for it outside of large institutions. Those places<br>
hire one of this 10% to do it for them, and people from this 10% don't<br>
need much in the way of automated tools to get things up and running.<br>
<br>
Will this change? Maybe. Groups like the LTSP are working on it.<br>
Companies like NoMachine are working on it. There's precedent; look at<br>
Ubuntu. Until a group of developers got together with the specific<br>
intent of building a Linux distribution someone like my grandmother<br>
could use, there wasn't a workable avenue for building a coherent,<br>
you-don't-have-to-write-glue-code-to-use-it system.<br>
<br>
Another key point was when Apple switched to using Intel processors.<br>
Now Mac owners could run OS X or Windows. Many do. They quickly<br>
discovered that they still couldn't really run their Windows programs<br>
under OS X, or their Mac programs under Windows. Along comes VMWare<br>
with Fusion, and now you have a generation of Mac users who definitely<br>
aren't in that top 10% who appreciate the machine boundary between<br>
their OS X and Windows installs, and have some concept of a bridge.<br>
<br>
That same degree of comprehension is probably going to grow more common.<br>
<br>
We also have this explosion of Web applications going on; people run<br>
GMail, or they run Facebook. Well, really they're running a browser<br>
and using those websites, but there's no substantive difference from<br>
their perspective. I could see Facebook building a client for running<br>
under XULrunner. I've been pondering doing the same thing for<br>
Mediawiki sites like Rosetta Code or Wikipedia.<br>
<div class="im"><br>
><br>
> The thing (being the collection of programs that form the end-user<br>
> experience) from a non-technical standpoint is a ... "MESS".<br>
> And the dependency on X is the fuel to the flame.<br>
<br>
</div>The X *architecture* isn't (that much of) a mess. Perhaps the codebase<br>
is, but the protocol is open, and nothing stops anyone from<br>
cleanrooming it. Wait a sec...there are several closed-source<br>
implementations out there already. XFree86 is only really a reference<br>
implementation. Xorg forked because the XFree86 folks weren't adapting<br>
to newer technologies fast enough.<br>
<div class="im"><br>
><br>
> In my hurry to write my previous post I switched the verbage of X-Server and<br>
> X-Client, my apologies for the Typo.<br>
><br>
> And I commonly throw around the word "Gnome" to mean"The collection of<br>
> programs that connect to an X-Server and eventually get rendered to the<br>
> framebuffer", seeing as most people have no idea what the individual<br>
> components are.<br>
<br>
</div>Which is fine, because that's how most people *should* see X. They<br>
don't need to comprehend how the components are bound together any<br>
more than they need to understand TCP or the dependency order of<br>
services in their operating system.<br>
<br>
You've got me pondering, though...How difficult (technically; I assume<br>
the software doesn't exist yet) would it be to have a Linux machine<br>
advertise X11 apps via mdns, so that machines running X sessions could<br>
see those applications and pull them up? That'd kick ass, IMO. (Sure,<br>
there's a matter of auth checking and such, but I can see how that<br>
could be worked around.)<br>
<div><div></div><div class="h5"><br>
<br>
><br>
><br>
> Well I apologize this has turned into an X-bashing rant...<br>
><br>
> On Wed, Mar 3, 2010 at 4:33 PM, Adam Tauno Williams <<a href="mailto:awilliam@whitemice.org">awilliam@whitemice.org</a>><br>
> wrote:<br>
>><br>
>> On Wed, 2010-03-03 at 15:11 -0500, Ben DeMott wrote:<br>
>> > X was designed, so applications could run on remote servers, and be<br>
>> > interacted with graphically on a local client.<br>
>> > The whole thing is a huge mess...<br>
>><br>
>> I disagree. I see a mess nowhere. There are clear lines of delineation<br>
>> between components.<br>
>><br>
>> > You should be able to attach and run programs on a remote X Server.<br>
>><br>
>> That makes no sense. There is no "remote X server". The server is<br>
>> local; that is the design of X. The service provided by the server is<br>
>> display.<br>
>><br>
>> > Have the X information piped to an X client and then have Gnome<br>
>> > attached to the local X client.<br>
>> > This doesn't however work in my limited experience.<br>
>> > This is the closest you can get:<br>
>> > <a href="http://mohanjith.net/blog/2008/01/using-gnome-remotely-via-ssh.html" target="_blank">http://mohanjith.net/blog/2008/01/using-gnome-remotely-via-ssh.html</a><br>
>><br>
>> I'm not sure what his issue is (and the post is a year old). But....<br>
>><br>
>> awilliam@linux-yu4c:~> ssh -X <a href="mailto:adam@workhorse.cis.mormail.com">adam@workhorse.cis.mormail.com</a><br>
>> Last login: Fri Oct 9 11:54:33 2009 from<br>
>> fdb5:60da:9b8a:1:219:d2ff:fe42:66b6<br>
>> Have a lot of fun...<br>
>> adam@workhorse:~> evolution<br>
>><br>
>> Boom! There is evolution. I'm not sure what you are saying doesn't<br>
>> work. Automatically started are: dbus, gconfd,<br>
>> bonobo-activation-framework, evolution-data-server, gvfs-fuse-daemon,<br>
>> gnome-keyring-daemon, etc...<br>
>><br>
>><br>
>> adam@workhorse:~> ps -u adam<br>
>> PID TTY TIME CMD<br>
>> 11455 ? 00:00:00 sshd<br>
>> 11456 pts/2 00:00:00 bash<br>
>> 11499 pts/2 00:00:58 evolution.bin<br>
>> 11503 pts/2 00:00:00 dbus-launch<br>
>> 11504 ? 00:00:00 dbus-daemon<br>
>> 11506 ? 00:00:00 gconfd-2<br>
>> 11508 ? 00:00:00 gnome-keyring-d<br>
>> 11512 ? 00:00:00 bonobo-activati<br>
>> 11518 ? 00:00:00 evolution-data-<br>
>> 11540 ? 00:00:00 evolution-alarm<br>
>> 11601 ? 00:00:00 notification-da<br>
>> 11604 ? 00:00:00 gvfsd<br>
>> 11610 ? 00:00:00 gvfs-fuse-daemo<br>
>> 11623 pts/2 00:00:00 ps<br>
>><br>
>><br>
>> _______________________________________________<br>
>> grlug mailing list<br>
>> <a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
>> <a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
><br>
><br>
> _______________________________________________<br>
> grlug mailing list<br>
> <a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
> <a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
:wq<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
grlug mailing list<br>
<a href="mailto:grlug@grlug.org">grlug@grlug.org</a><br>
<a href="http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug" target="_blank">http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug</a><br>
</div></div></blockquote></div><br>