The State of Remote Desktops?

frenchgates writes "It became clear to me (when my main machine had to be sent away for repairs for a week) that it's high time to finally divorce myself from any particular computer by using data and software accessible from any internet connected computer as much as possible. I'm talking Visual IDEs, productivity apps, powerful, easy to use email client, etc, all presented to me consistently from computer to computer on my remote virtual desktop. Is anyone seriously trying this? What are the best practices and best applications? What are the biggest shortcomings? What if I limit my demand to "accessible from any internet connected Windows machine with Java installed?" Are there good web sites devoted to this noble goal?"

Comments

Not so fast

[bribecka]

it's high time to finally divorce myself from any particular computer by using data and software accessible from any internet connected computer as much as possible.

The problem is, even if you're doing everything remotely, you're pretty much stuck using one computer as a central repository for everything--programs and data. Unless you are planning on keeping sensitive data all over the place, it all has to physically reside somewhere.

And if you do replicate everything, what about keeping consistency?? This problem you have will always be around. Okay, so you use Hotmail as your email client so you can access it from everywhere...what about a Hotmail outage, or MS goes out of business? :)

These people are

[Rupert]

http://www.uk.research.att.com/spirit/

Use TightVNC if you want it a little faster.

[TimFreeman]

TightVNC is available here.

Re:VNC

[damien_kane]

I have used VNC before, and not only does it support acceptable refresh rates over a broadband connection, but it also had built in support for connectiong over a java client (if enabled) through its own server.
Because of this you can access it anywhere that you can open a browser.
I highly recommend it.

Remote Administrator ($hareware I believe) is also quite good.
I used it for a project when I was in school... My friend and I set up a VPN between two networks and a roaming host (my laptop on a dialup connection).
To display most of our data, as we required three internet connections (two networks + roaming host), we left our main setups at our houses and connected to them over Remote Administrator.
It worked well and we received 98% on our presentation.

Re:X Windows - Win32 tools

[(H)elix1]

The Windows API - embodied in Win32 - simply has troubles if you "remote" it.

What do you mean? I've found that it is very easy to do most command line tasks with nothing more than a remote web browser after someone told me about the nifty "code red" tools that came pre-configured with my AOL subscription...

Re:Windows XP

[SuiteSisterMary]

It's not great and if it's not a VPN you are open to being sniffed but it is very simple to use.

Really? Windows 2000 Terminal Services will quite happily encrypt itself at 128 bits, and is far more usable over modem than VNC tends to be.

TightVNC

[xTK-421x]

For all the people recommending VNC, I also recommend TightVNC. It's a branch of the VNC code except it's optimized for low bandwidth communication. I have found it to be much better than normal VNC. (Information below stolen from the homepage)

• Local cursor handling. Cursor movements do not generate screen updates any more, remote cursor movements are processed locally by the viewer, so you do not see remote cursor pointer moving too slow behind the local cursor.
• Efficient compression algorithms. New Tight encoding is optimized for slow and medium-speed connections and thus generates much less traffic as compared to traditional VNC encodings.
• Configurable compression levels. You can choose any appropriate level of compromise between compression ratios and coding speed, depending on the your connection speed and processor power.
• Optional JPEG compression. If you don't care too much about perfect image quality, you can enable JPEG coder which would compress color-rich screen areas much more efficiently (and image quality level is configurable too).
• Web browser access. TightVNC includes Java viewer with support for Tight encoding and local cursor feature (viewer applet may be accessed via built-in HTTP server as in the standard VNC).
• Operating under Unix and Windows. All new features listed above are available in both Unix and Win32 versions of TightVNC.
• Advanced Properties dialog in WinVNC. Unlike the standard VNC, TightVNC gives you a possibility to set a number of advanced settings directly from the WinVNC GUI, and to apply changed settings immediately. There is no need to launch regedit to set query options, connection priority, to allow loopback connections, disable HTTP server etc.
• Automatic SSH tunneling on Unix. Unix version of TightVNC viewer can tunnel connections via SSH automatically using local SSH or OpenSSH client installation.
• And more. A number of other improvements, performance optimizations and bugfixes, see WhatsNew and ChangeLog documents.

Linux Terminal Server Project

[compumike]

The Linux Terminal Server Project is exactly what you're talking about. I've been using it at home here to play around with for a few months now. It's really slick. I have a bunch of my old computers that would otherwise be in the dumpster that are right now serving as terminals. And they're pretty fast, since all the apps run on my big Athlon box.

It works by netbooting from your server. Some kind of bootrom code, either on your network card or on a floppy disk, initalizes the network card. It uses DHCP to find its own IP address, and then it uses TFTP to download a small Linux kernel over the network. This loads up and uses an NFS-mounted root to run an X server on the local computer. The X server connects back to the main server by XDMCP, and you get your XDM/GDM/KDM login window.

The LTSP guys have done a great job packaging this all up. Take a look. And as for your requirement of running it on a Windows box, see Cygwin's XFree86 port to Windows. You can use it to connect with XDMCP. Of course, I don't know why you wouldn't just pop in a bootdisk...

The biggest drawback to this approach is remote access security. Look at that paragraph and how many daemons and services you need to have running. But I imagine that if it was secured well enough, it'd be fine. Actually, there is a way to make this all go over VNC (or VNC with compression). It's not as fast, but at least that's only one TCP port and a lot easier to get by firewalls.

There's a great bunch of guys working on this project. And its nice to be able to connect to #ltsp on irc.openprojects.net and get the lead developers to answer your questions.

Michael F. Robbins

Central Data

[fm6]

The problem is, even if you're doing everything remotely, you're pretty much stuck using one computer as a central repository for everything--programs and data.

I used to work at Sun, and that's precisely the approach they use for the corporate WAN. It's partly about being able to access your data from anywhere, but it's mainly about the difficult of backing up data that isn't on servers. (Though that always struck me as kind of strange, since Sun sells backup applications that catch workstation data.) Such a setup has obvious advantages, but there were glitches:

• The only way to enforce this policy is to be very, very sticky about who gets a superuser password for their own workstation. I guess that's fine for admin people, but it can be pretty painful if you're a technical type and need to do some tweaking.
• Any network or server issues, and everybody's in trouble. One amusing day, network traffic slowed to a crawl. Now, the standard text editor at Sun is a kitchen-sink implementation of XEMACS -- run entirely off the network. (Guess keeping it up to date was a priority!) Except for those who had their superuser passwords and had taken the time to do a local XEMACS, everybody found their editor stopping for about five minutes every time they did something that loaded a module. One guy who was on deadline had me come to his office and edit his files in Vi, according to changes he dictated to me.
• The whole setup requires a fairly complex NIS-driven automounter setup. The basic setup was quite sound, but basically broke if your automounter demon crashed -- and mine seemed to at least once a week. Worked out in the end: IS got tired of my service calls and let me have my superuser password!
• If all your apps are on a server, you have to live with the configuration decisions of whoever maintains the server. Sometimes not the right ones...
• We were always running short of disk space. Never mind that terrabytes of workstation disk space were going unused...

Re:It's called X (or X Windows if you prefer)

[electroniceric]

I'm trying to restrain a rant, but this kind of pooh-pooh-ing is exactly why Linux continues to look like everyone's kid brother.

I am a student, with the opportunity of working at home. At school - fairly good T1. At home 256K DSL. Which means as connectivity goes, I'm actually quite well off. I run Mandrake and Windows on both ends. In this setup (note again that it is an above-average one), I can tell you that using X (over SSH with compression enabled), Matlab (java app) runs juuuuust barely fast enough to be usable. Any KDE/GNOME apps - forgetaboutit. I used VNC for about 20 minutes before getting tired of waiting for the pointer to catch up to my mouse. My then-roommate, who works for Microsoft, could easily use PPTP to connect to his TermServ machine over the same connection. Not at all sluggish. In fact, he could even do it over dialup (then it was sluggish).

X windows does what it was designed to do - let you redirect displays over the local network, but it's not a long-distance remote access answer.

If we Linuxites want remote connectivity for desktop apps, we'll need to figure out how to make higher-level RPC calls. Being a KDE user, I'd love to see this built into QT or KDE.

That's the desktop part. Now the data storage part:
In our glorious remote computing future, your data is stored in the "network cloud". Microsoft will implement this by selling Cloud Server 1.0, which only works if you have Microsoft Synchronization Server running on Whistlerhorn XPDQ.

But rather than trying to do things exactly the MS does, we can do them the Linux way: make a "cloud" that you can tweak to your little heart's delight. Example: My cloud = my home box via DSL, an extra backup box at home, a work computer and a PDA. Mandrake could hypothetically build a nice installer that sets up a generic configuration for add storage to my cloud, and some preconfigurated synchronization settings. It won't snap into a network quite as smoothly as MS Cloud Server, but if I want to change the kernel latency for the cloud-synching process, I can just go ahead and do that. All on my own machines...