I have been dragging my feet on remote display, and have just gotten VNC going to have SOMETHING to move off the start line. But I need the 'best' for different situations, so I want to rate them.
1 to 3 where 1 is the 'best' for the catagory and 3 the loser.
VNC RDESKTOP FREENX
Server memory Server cpu client memory client cpu bandwidth
thanks. I AM search the net for this information. So far have not found the magic query request :)
On Dec 6, 2007 5:05 PM, Robert Moskowitz rgm@htt-consult.com wrote:
I have been dragging my feet on remote display, and have just gotten VNC going to have SOMETHING to move off the start line. But I need the 'best' for different situations, so I want to rate them.
1 to 3 where 1 is the 'best' for the catagory and 3 the loser.
VNC RDESKTOP FREENXServer memory Server cpu client memory client cpu bandwidth
thanks. I AM search the net for this information. So far have not found the magic query request :)
There are numerous ways to remotely access a Linux machine, and honestly the "remote desktop" style that Windows uses is the worst of them. VNC, rdesktop, and freenx all replicate that method of access, where you basically get a picture of what would be on the monitor if you were sitting at it.
As was already mentioned, ssh is really the main way for remote access, but for people not familiar with Linux, there's no GUI and no mouse beyond copy/paste, so you may look for another solution.
The real *NIX way of accessing a graphical application remotely is by using a remote X desktop. It sounds strange if you're not familiar with it, but basically you run the 1 application on the remote server, and the application window (and only the application window), shows up on your local workstation. SSH provides a way to do this securely. The drawback is you will need an X server running on your local computer, but that can be had for free in Windows from cygwin.
Having stepped your foot in all of that now, the simplest GUI to get working is the vnc/freenx style of remote access. I have only used VNC, and it works well enough, but I hear good things about freenx. If you go the VNC route, make sure to set up a firewall to block direct access to the vnc port, and only access it through ssh forwarding, as vnc is not secure by itself.
On Thu, Dec 06, 2007, Brian Mathis wrote:
On Dec 6, 2007 5:05 PM, Robert Moskowitz rgm@htt-consult.com wrote:
I have been dragging my feet on remote display, and have just gotten VNC going to have SOMETHING to move off the start line. But I need the 'best' for different situations, so I want to rate them.
1 to 3 where 1 is the 'best' for the catagory and 3 the loser.
VNC RDESKTOP FREENXServer memory Server cpu client memory client cpu bandwidth
thanks. I AM search the net for this information. So far have not found the magic query request :)
There are numerous ways to remotely access a Linux machine, and honestly the "remote desktop" style that Windows uses is the worst of them. VNC, rdesktop, and freenx all replicate that method of access, where you basically get a picture of what would be on the monitor if you were sitting at it.
As was already mentioned, ssh is really the main way for remote access, but for people not familiar with Linux, there's no GUI and no mouse beyond copy/paste, so you may look for another solution.
The real *NIX way of accessing a graphical application remotely is by using a remote X desktop. It sounds strange if you're not familiar with it, but basically you run the 1 application on the remote server, and the application window (and only the application window), shows up on your local workstation. SSH provides a way to do this securely. The drawback is you will need an X server running on your local computer, but that can be had for free in Windows from cygwin.
I don't Do Windows(tm) so rarely have to deal with them. When working with Linux and other *nix systems, it's always through ssh with X11 forwarding for those rare occassions when I need to do something like run Firefox from a client's machine to access a router from their private LAN. That can get a bit clunky on slow connections, but it does work.
If I'm on a fast connection, I'll run the xterm on the remote system with ``ssh -f remotename xterm'', but if it's a slow connection ``xterm -e ssh remotename &'' to run the xterm on my local machine.
Once I get around to upgrading my Macs to Leopard, I may use the Apple remote desktop feature occassionally when I need to see what a client is doing on their desktop which should be faster than trying to talk them through a GUI on the phone.
Bill -- INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
Capitalism works primarily because most of the ways that a company can be scum end up being extremely bad for business when there's working competition. -rra
Bill Campbell wrote:
The real *NIX way of accessing a graphical application remotely is by using a remote X desktop. It sounds strange if you're not familiar with it, but basically you run the 1 application on the remote server, and the application window (and only the application window), shows up on your local workstation.
Or you can run the whole desktop remotely - or many of them on thin clients. Freenx does this just as well as X locally (perhaps with a bit more overhead, but the tradeoff is that you can suspend and reconnect).
SSH provides a way to do this securely. The drawback is you will need an X server running on your local computer, but that can be had for free in Windows from cygwin.
You can use the easily installed (and free) NX client from windows and macs without installing anything extra. And it uses ssh so you only need port 22 open to the destination.
I don't Do Windows(tm) so rarely have to deal with them. When working with Linux and other *nix systems, it's always through ssh with X11 forwarding for those rare occassions when I need to do something like run Firefox from a client's machine to access a router from their private LAN. That can get a bit clunky on slow connections, but it does work.
Freenx isn't all that clunky even on slow connections, which, aside from the ability to reconnect to running sessions, is the main reason to use it. It takes a bit of time for the initial screen to draw, but the protocol does a good job with subsequent updates.
If I'm on a fast connection, I'll run the xterm on the remote system with ``ssh -f remotename xterm'', but if it's a slow connection ``xterm -e ssh remotename &'' to run the xterm on my local machine.
I like to keep a freenx session running on a machine at the office with windows already open to a bunch of other systems (it is just like any other X desktop). When I'm there I connect from a multi-head windows box with the NX client filling one monitor with this session so it is pretty much indistinguishable from a local Linux box except that I can cut and paste between it and the windows programs on the other monitor. When I leave, I suspend the session and can pick it up from a Mac at home or a windows laptop on the road. Any long-running commands are still there and if there is a problem with connectivity it doesn't kill anything - you can still reconnect with things running.
-
Bill Campbell -
Brian Mathis -
Les Mikesell -
Robert Moskowitz