Sponsored Link •
Wherein I recount my experience of using a thin client over a DSL.
Director Morgan Spurlock got the idea for the movie SuperSize Me! while sitting on a sofa after a Thanksgiving dinner, stuffed, unable to move. The idea seemed simple enough: Go on a McDonald's diet for 30 days straight eat nothing but McDonald's food, and document each day what happens. He did just that, and while I'm no fan of the movie, you can see for yourself the effects.
Starting this week, I will go on a reverse Spurlock diet: For a week, I will use a thin client to do my very technical work of producing software and other content, instead of using a PC or a laptop. While using thin clients over a high-bandwidth corporate network is not a novelty, I have only a plain DSL connection at my disposal. My desktop will reside on a remote server across the country, and I will be connected to that desktop via a DSL. Because some software I work on cannot be moved to that remote desktop, I will still use my laptop during the week. But for all other work, I will use the thin client.
My motivation for experiencing how thin clients work is to find out if thin clients can help solve what I perceive is a crisis on user desktops. For the past three years, I've been running a company that provides software and services to small businesses. Most of our customers cannot afford a dedicated IT manager to look after their desktops, which are almost exclusively Windows-based. As a result, most customers experience the following desktop lifecycle:
In the moment of crisis, the only contact that business owner can rely on is the software vendor whose product they use to run the business. After all, that's the only piece of software that really needs to work, and in the crisis stage, that software also malfunctions. With luck, and after a lengthy and expensive remote crisis management session on the phone or on the Web, we can either restore the user's desktop to some stage of normalcy, or have to suggest to the user to just wipe clean his OS, and install and start over. The circle now comes full, with the PC returned to a more or less clean state.
I got a glimpse of that better way when I visited an acquaintance who is a Sun exec. He had neither a PC nor a laptop in his house, and instead was conducting his entire business via a thin client, a SunRay, residing strategically on his kitchen counter. The most interesting aspect was not the SunRay itself, but the kind of performance he was able to obtain from it via a simple DSL line.
I contacted the Sun folks in charge of the SunRays, and was promptly provided with the device to try out, along with an account on Sun's prototype desktop grid facility. The following is a brief diary of the first few days of my living thin. I will add to it in the coming days.
The back of the SunRay allows four USB inputs, an Ethernet input, an SVGA video connector, inputs for audio devices and an S-video connector for digital video. Of course, there is a slot for a power cable as well. The front of the unit has a smart card reader, a microphone input, and a headphone output. The SunRay 1G is lighter than a 12 inch Apple PowerBook.
OK, so I connect the keyboard, mouse, and monitor, and plug an Ethernet cable to my Linksys DSL router and the SunRay. Then I turn on the monitor and plug the power cable into the device (the 1G doesn't have a power switch).
The monitor immediately wakes up, and displays an hour-glass like image. I guess it's indicating that it's trying to connect to the network. On the top of this hour glass, I notice a DHCP-assigned IP address, which must have been handed to the SunRay by my router. The lower end of the hour glass displays an IP address that must be the address of the network the SunRay is trying to connect to.
About 15 seconds pass. Nothing's happening. I start to wonder if the SunRay can make the connection to the remote desktop server via the Linksys router. Since the router performs network address translation, and also acts as a firewall, can the SunRay navigate itself through that NAT layer?
Another 5 seconds pass. Then I can finally see the hourglass on the screen change. After about another 5 seconds, the screen turns blank, and then immediately switches to a Solaris login screen. Whoa, so I'm connected to the Sun network. I enter the login name and password the Sun folks had assigned to me, and click on the login button. So far, the mouse and keyboard input feels as though I was typing on a local machine, whereas, in fact, the login screen is running on a remote server.
In a few seconds, I get a desktop that appears very much like the GNOME desktop I use every day on my laptop. It has some differences: the theme and some buttons and icons. So this is the Java Desktop System. So far not much Java, save for the neat Java logo desktop background.
I click on the Launch button on the lower task bar, and the program options menu appears. That menu is exactly the same as the GNOME launch menu, which, in turn, is very similar to the Windows Start menu. While I can now sense that the desktop is running across the network, the screen redraws are very fast.
I fire up a Web browser, which happens to be Mozilla 1.4 on this Sun desktop. I had used Mozilla on my laptop until I could get Firefox working, and Mozilla was always very sluggish compared to Firefox. Now, however, Mozilla seems to start up fast, taking me to the Sun home page as a default.
So far, so good: about six minutes from unpacking the device to the point of browsing the Web and being able to use the desktop.
I will post more comments in the coming days.
|Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market.
Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.