On 29/11/2007, Andrew J. Hesford <email@hidden> wrote:
2. The CPU time for SSH tunneling is just offloaded into extra
burden on the remote system, which has the responsibility
of rendering an entire display for users. Since these
remote systems tend to serve multiple users, this issue is
compounded.
This is untrue. However you mean by "rendering the entire
display" (whether sending the X commands or acting on the X
commands), the situation is identical as the situation where you
use an ssh tunnel. The remote system still has to send all the
X commands, and the local system still has to act on all the X
commands to do rendering.
The cpu cycles and memory used for ssh tunnelling are extra,
but, as you correctly point out, you also reduce the network
bandwidth. But as to loading on the remote system, if you have
tried running programs over ssh vs over plain X, you need to
agree that the loading is less without ssh.
This is fair. I happen to disagree with this in general, but
within the context I agree with you. In any case, xdmcp not
working properly is a bug that needs to be ultimately fixed.
Since I don't know why an application would "require xdmcp" (I
cannot think of any reason), what I say is useless. But if an
application works with xdmcp and doesn't work without xdmcp,
then it looks like something is done in the user's xsession
which should be moved over to a startup script for the app. On
another hand, if the app works without ssh but doesn't work with
ssh, maybe it's the new trusted vs untrusted forwarding thing...