OSNews

I've used such and I haven't found X to be slower really at all. In fact, because two machines are involved, it created a sort of dual core environment, where one CPU did X and the other (on the remote machine) ran all the programs.

Of course, GTK+ was a little laggy, but it's that way even with a local connection.

I've also done remote X across a campus network (actually, between two networks on the campus) and it was tolerable, with a little bit of lag. Part of the problem was the shitty X server running on a slow Windows machine on my end.

If the application is well written (properly uploads all its images to the X server and reuses them), X still rules over a 10 mbit network compared to RDP, because you have an Xserver with all extensions activated. RDP can only do 2D RGB screen updates (which it does this very well), but cannot do YUV, 2D rendering (Xrender) or 3D.

Watching a DVD with Xine on a remote Unix server, for example, works rather well because a PAL frame is just 720x288 pixels 50 times a second. YUV data is only 16 bits per pixel. Xvideo on the Xserver takes care of RGB conversion, deinterlacing and scaling.

Doing this with RDP works very badly, because if you watch full-screen at 1280x960 the RDP server needs to send 1280x960x32bit@50Hz, which is even doubtfull on a 100mbit network.

Further, note that X is not so much bandwidth but more latency limited. Therefore, over the internet is performs poorly, while RDP shines when running over the internet.

It sounds like you're thinking of VNC. I'm pretty sure that RDP only sends the *instructions* and raw image data (if needed) to draw the window on the client side.

So no, watching a DVD wouldn't be a full-screen update @ refresh rate.

Work is being done to alleviate at least one of the limitations you mentioned in RDP. The video problem is interesting too, and the general solution adopted by some folks (but not RDP afaik) is to send the compressed video data through a side channel and decompress it on the client side. This seems like the only workable design to me.

True but we're in 2008 now, not 1990, and no one is using 10baset and 10base2 anymore.
If you do, well, get with the program.

Actually, I did not directly address this issue in my previous response to tyrione. X works about as well under 10baseT as 100baseT. People have a tendency to think in terms of bandwidth. X actually does quite well over limited bandwidth. It is latency which kills the standard (non-NX) X protocols. 10baseT has essentially the same latency as 100baseT. The most dramatic way to demonstrate standard X's sensitivity latency is to set up a ppp connection over an external modem. Start an application like Firefox and watch the lights. According to, I believe, Keith Packard some years ago (who had worked on LBX previously), approximately 90% of the round trips were actually unnecessary and an artifact of the then current implementation, and not inherent in the protocol itself. He was working on eliminating those unnecessary round trips. Not sure where we stand today.

However, it does not really matter, because for any sort of WAN connection we have NX.

Edited 2008-06-29 17:26 UTC

You are comparing apples to oranges. Even more of my users run from remote offices using NX (which is still really X). And believe me... NX blows RDP out of the water for both speed and quality over WAN connections. They are not even in the same class. Proxying RDP (or VNC) through an NX server helps some, but not that much. The OSX approach is nothing but VNC, which is noticeably poorer in quality and speed than even RDP.

X has Xshm which is optimum for local clients, straight X which is optimum for LAN environments, and NX which is optimum for WANs. No other windowing system can touch that combination for performance and flexibility.

Edit: I should mention that as amazing as FreeNX is... it has the rudest and most unhelpful support mailing list in all of Open Source, to the point that if I had another option that was even remotely as good I would migrate to it.

Edited 2008-06-29 14:17 UTC

Let's not compare WindowServers of OS X to Xorg. Apple didn't design WindowServer around the notion of a VPN/RDP approach.

I will be interested to see how Apple reimplements NXHost and beyond for 10.6 and the Enteprise.