Summary
Wherein I recount my experience of using a thin client over a DSL.

---

Advertisement

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:

1. Clean Slate. The customer purchases a new PC. When he receives it, he calls the local “computer guy” to set the PC up. He then calls us to help walk them through installing our software, which they use to run the business.

2. Gradual Decline. The way most computer guys set up a new PC is to provide the user access to the administrative account. The reason is simple: Leaving the admin account as the default allows the user to install any software without having to call the computer guy. Since most users don't understand, or care about, the difference between administrative and less privileged accounts, they don't understand the concept of “switching” between accounts. They also tend to forget account passwords, especially in environments with high employee turnover.

3. Crisis. Daily use of a network-connected computer with full administrative privileges leads to the crisis stage: Over time, viruses, spyware, and effects of the business owner's children playing on the computer take hold, the OS slows to crawl, eventually preventing critical business functions from being performed at crucial moments, such as making a sale or providing a quote.

   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.

That devil's circle has led me to believe that software is now a service business, and that software vendors can provide greater value with service than with their software products, simply because desktop crisis management service is what users need the most. This presents an enormous challenge to ISVs delivering mission-critical software, and makes such software practically unavailable to small enterprises unable to afford huge consulting and support fees. But observing this cycle led me to believe that there must be a way to break out of this circle, and that crisis can be turned into an opportunity.

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.

Day 1.

I received the SunRay via the local Sun office in Southern California. The thing comes in a single box, containing the SunRay itself, which is about the size of a largish book, a keyboard and a mouse. This version of the SunRay, the 1G, does not include a display, and can instead work with any PC monitor via a 15-pin SVGA connector. Since I have an old Sun monitor lying around, which is essentially a Sony with the Sun logo on it, I will just connect the SunRay to that monitor. The keyboard and mouse are USB-based.

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.

Day 2.

I finally have time to set up the SunRay. The instructions in the box are minimal, but the Sun folks provided me with a few lines of instructions on how to connect to the Sun prototype grid facility. Apparently, they loaded network settings on the unit before shipping it to me, so this thing should just work right out of the box.

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.

Talk Back!

Have an opinion? Readers have already posted 23 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

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.