Easy: here's mine that was removed

http://www.youtube.com/watch?v=1ReM0v3dVid

It now says it is "unavailable". Can you believe that? All because I said this Halibut was good enough for Jehovah!

Dammit, sorry, the technology I was thinking of was Xvnc's not x11vnc's. I apologize for adding to the confusion.

The big problem with VNCs like x11vnc is the latency incurred by screen polling. Xvnc doesn't need to do this, and neither does RDP. (This is why I thought that's what you were talking about.)

Even if latency were solved, there's still the issue of VNC just being a remote view of a local display and RDP is a remote display. The difference is that with the latter, the desktop takes on the shape of the remote end. Trying to view a 3840x1200 display on a 1200x768 display is just a disaster (not to mention the unnecessary performance degradation it also incurs as a result of needing to send vastly more data in my cases)

RDP's design isn't perfect, though. I prefer X's design by far if it were to fix the must-decide-at-startup and network performance issues.

Oh, and as an aside, the latency with X's protocol is in large part not solved by compression. What makes NX much faster is its elimination of a lot of the round trips inherent in X's protocol (by essentially faking responses) which are the biggest cause of X slowness, but much trickier to implement than just compression.

Really it appears that you don't know what I'm talking about, but I can't understand why. Perhaps you haven't read the thread. I never claim I can't watch videos etc over X and I never asked to do those remotely. I do these things locally now and have been for years. I've used Linux since 99 and exclusively since 2006.

And so can you. Fantastic, but on that same X where you watch videos, can you start a word processor (for example) use it for a while, then remotely resume that instance from a friend's house? With RDP this was possible, but I don't use Windows anymore.

So now I'm typing a message into a browser window. If I go to a friend's house and want to resume typing this reply, I can't. I could have if I had started this in x11vnc, yes, except I can't use x11vnc for my desktop because it can't do videos/opengl/etc. With RDP I could, but I don't use Windows anymore.

What looks promising is xpra, which I just learned about here, although I still have to choose between performance and remotability at application startup or find a way to do so automatically.

I have used x11vnc and its performance is unacceptable as I already said. But it is irrelevant anyway because I can't use it for my local desktop AND expect to watch videos, or do anything with advanced graphics. Windows RDP does not suffer from this limitation. It lets me use a local desktop with all its performance and then lets me remote the apps in that session.

It is not a fight I am looking for but a feature. And I know I am not the only one who notices this feature is missing, but whenever I bring it up I get these smart-associated non-solutions. I said "troll" after being accused of cheering for Microsoft.

...interesting, yes, but irrelevant, just to be clear, since a touchpad is not even the same class of device as a touch screen. In other words, it is not as if existing touchscreen games developed for a phone will be playable on the Ouya because they have this touchpad thing.

Yes, but Sherlock Holmes is also a master of disguise.

Sherlock Holmes, is that you?

It's X that has this limitation. With X, when I attach an application to a display (X server) it's forever tied to that display and can't be moved.

There is no such limitation in Windows. The only limitation in Windows is that I have to move all my applications in my session to that display, but this is hardly a noteworthy limitation since it's MY session and I'm not setting at the old display anymore.

With X, I have to stop the application, then start it on the new display. Hooray, I don't have to bring my whole session over if I don't want to, but I would gladly do so if it meant resuming the running instance of my already-running application.

The point of this whole (off-topic) discussion is that these are two completely different use cases. One is remote execution of an application. The other is remote control of an application. X only does the former. Windows is actually capable of either (with the caveat that it requires you to start a remote logon session to remote the execution of a single app).

I'm not "cheering" about Windows, you troll. My point is and has been that I hate Windows and love Linux and yet trying to do this simple task in Linux is still not possible a decade after Windows managed it which is extremely frustrating. The most frustrating part is that every time someone complains about the lack of this feature, someone comes along with a shithead response like yours. "What? You want a feature Windows has? Fuck you, you must be a Microsoft lackey."

No.

This uses controllers and not a touchscreen.

This is not a "dev" box in the sense that if you are a developer, you need one of these boxes. These are boxes that were specifically awarded to backers that wanted to do development. The only difference between these and the retail boxes is that these are early versions and therefore available earlier than the retail boxes. Also these are in "special edition" cases as a thank you to the devs for their support.

You don't. Sorry, didn't mean to suggest this was possible.

To be fair, I'd be perfectly happy to transfer the entire X session from one machine to another (provided X was also made as fast as NX), but that doesn't seem to be possible except through VNC which is unacceptable in its slowness and its inability to change screen dimensions, or xpra which is unacceptably slow also, and often cripples performance and features when running locally.

So the point is that the use case in Windows where I can start an application on my home desktop, then access that application later from my work machine with reasonable performance and at the client-side resolution, then do the same from my neighbor's house, etc, all without exiting the application.... this is all I am referring to.

Actually that's a blockquote. A citation is when you say where you got your info from.

Here's a citation:

See what I mean? That's not really a citation... I just put quote tags around my own words.

I suspect you actually copied and pasted that from somewhere instead of making it up yourself, but if you don't cite that source, then it is impossible to tell the difference between sock puppet and actual citation. I see you've been modded up which means people on /. don't really care whether there's a citation or not as long as it sounds official.

Replying to myself. XRPA does in fact work with the following caveats:

1. It does appear to use bitmap tossing and probably for this reason is painfully slow over low bandwidth connections - far more sluggish than Windows' RDP.
2. Like "screen" for console apps, you'd have to have started the application in the xrpa session in order to be able to attach it to a remote screen.

No, I mean can start an application running on machine A and displaying on A's display, then access that same instance of the application from machine B's display, then display C if I want etc., all the while never exiting the application running on machine A.

xrpa seems interesting but appears to be VNC for X, not actual X. This is what the GGGGP was referring to as "bitmap tossing" which is pretty useless over slow connections while windows RDP is not.

Which is exactly what I was talking about. Windows has provided this capability for over a decade and linux has not except with VNC which is unacceptable.

The X server that the application will connect to is based on the value of the DISPLAY environment variable at the time it is loaded. Backgrounding and then foregrounding won't result in it sending it's stuff to a new X server. In fact, once it's attached to an X server, it can't be detached and reattached to another X server. This is a limitation of X -- the very limitation that I was talking about.

In addition to this, the screen session inherits and keeps the DISPLAY variable set during the X forwarding session. Therefore anything started in that screen session, regardless of where that screen has been reattached to will actually run through the original X tunnel and back on the original SSH client machine.

I.e. if I SSH -X to a host and start a screen session that you attach to. Even if I detach my screen, as long as my SSH session is open, you could attach to that same screen and use it to start applications on my desktop.

The problem with things like XRDP is exactly the same as the problem I've been explaining. If I start an application against one X server, then network transparency is from there on useless to me. I can't simply move it to another server. With windows, this has always been possible.