Re: @ZootCadillac
Oh dear, there are so many errors in the above comparison of X, RDP and VNC I don't even know where to begin. Any validity of the actual points is lost among the sheer inaccuracies.
Start with the most primitive protocol first. VNC does not "push the whole server frame buffer to the client". Even VNC onlys sends a region of interest. Not simply the application level - that would be spectacularly dumb - often it is merely a very small portion, around e.g. the mouse pointer or text cursor. Everything else is left unchanged from the last screen update.
Similarly, both X and RDP do not push the server frame buffer to the client - the frame buffer is firmly on the client. Both protocols get much higher performance by sending higher level graphical primitives (draw line, fill rectangle etc) to the client. Not raw pixmap data except of course where it is actually a pixmap being displayed on screen.
As for rendering accuracy that is another completely blind alley. RDP and VNC generally both drop certain on-screen elements by default (e.g. wallpaper, Aero) to speed up the experience. That is a configurable setting - you can easily specify that those elements should be preserved and the result should be bang on perfect. X is if anything more problematic here - between different instances of the same OS it is generally problem free but away from that particular case regular remote X users get used to subtle issues (e.g. the wrong font being used) after a while.
As for performance, yes, on the LAN X11 is exceptional - even video playback can be perfectly acceptable. That doesn't make it profitable to use as a cloudy solution. Compare the basic premise of RDP and X - both send high level primitives to the client but whereas X is implicitly designed for a LAN RDP extends to the WAN as well, with features that are essential to WAN connectivity but which X simply lacks - resuming a dropped session or encryption are two features that come to mind. The second is essential on the wider Internet but obviously comes with a large performance penalty. These feature can be added to X via a number of add-on layers but when you do so you generally find you lose that performance that attracted you to it in the first place.
All told then, they are different protocols for different uses. Pretending that a lightweight protocol designed for one basic use case can suddenly be extended to situations it was never intended for and not gain extra baggage, or that the designers of one system had some great insight that went completely ignored by the designers of subsequent systems is simply misrepresenting the situation.