The promise of a desktop environment accessible from anywhere on the Internet has been as alluring as it has been evasive. While many tools aim to provide network access to a single desktop computer, the desktop as a network service has yet to materialize. This article looks at a grid-based solution that may change that status quo.

http://www.artima.com/articles/desktop_grid.html

What do you think about the future of the desktop?

Both Microsoft (Vista) and Sun (LookingGlass?) are trying to promote better looking desktops which will be harder (need more bandwidth) to use via a thin client. Secondly poor multimedia handling is not a good selling point. It might be better if video/audio streams were sent direct to the client and buffered/decoded there. But that would need more computing power at the client.

So nice try, but I don't see this becoming common any time soon.

> Both Microsoft (Vista) and Sun (LookingGlass?) are trying
> to promote better looking desktops which will be harder
> (need more bandwidth) to use via a thin client.

Even at its present stage, the Sun Ray used only about 20% of the available bandwidth of an approx. 1Mb/s network connection. That provided acceptable performance with Sun's version of the Gnome desktop but, as you say, it will not be enough for graphically richer UIs. It is possible, I am told, to increase the maximum bandwidth used by a remote Sun Ray client.

A well, a parallel trend is the increasing amount of bandwidth available even via residential broadband connections. There are already 100Mb/s connections available, and fiber networks being built via cable and phone companies to residential customers will make even more bandwidth readily available. Such companies could offer, as part of a service package, a hosted desktop session, since they would be in an excellent position to provision their network resources for the best user experience.

> poor multimedia handling is not a good selling point. It
> might be better if video/audio streams were sent direct to
> the client and buffered/decoded there. But that would need
> more computing power at the client.

There are many thin-client designs that push more computation to the client. The Sun Ray, on the other hand, does only decoding/encoding of protocol commands and some I/O on the device, and pushes everything else to the server.

At some point (10 years ago), I used to think that Java was going to move code to the client to process data in the thin client. But it seems now that one can achieve better performance if computation is done on fast servers (on a grid that distributes load among many servers), and then use a highly optimized protocol (and a fast network) to send just the needed updates to the client.

However, I also think that more work needs to be done to achieve the kind of multimedia performance that would provide a seamless user experience. If such experience were possible to achieve via a thin-client design, then the "convergence" of multimedia and computing that everyone's talking about (and that's already happenning - just look at the Mac and the iPod), might partly be happening on the server.

Interestingly one motivation for doing more of that work on the server has also to do with mobile devices, where you really want to minimize computation on the client in order to preserve battery life. In the thin client's case, the motivation is to reduce maintenance and, possibly, customer support costs. But research and engineering issues are probably quite similar.

That increased domestic broadband bandwidth is in most cases very asymmetric. That's fine for the 'business' use of the desktop, but presents a problem if trying to replace the domestic PC. Personally created photographs and video would place considerable strain on upload bandwidths. Photographs from my current camera are 13MB EACH.

Certainly as a "primary" consumer device this might not be right at the moment. But as a secondary device to augment my home environment with additional "display devices" it might. However, I do agree that the consumer marketplace is very hard to address and once in which Sun with the Sun Ray has purposely not positioned it for. However, I wouldn't be so dismissive of "that might be fine for buiness". Seems to me that the "business" market segment is pretty big. Think of all the businesses that have to deploy some sort of desktop to remote "productivity users" whether in remote offices, home etc...

This article tried to focus on the WAN aspects of the Sun Ray (and, by extension, of thin clients). I think in a LAN environment the benefits of thin clients are pretty much established. I just don't see many reasons why an organization would want to deploy full-fledged PCs to user desktops, since most work done in a business setting can be done eminently well via a thin-client. Perhaps there are special cases, e.g., graphic design or engineering, etc.

However, this sort of technology could benefit consumers as much as it can benefit businesses. While larger businesses have IT departments responsible for managing user desktops, home users are mostly left to fend for themselves when it comes to desktop management. At the same time, many home users use PCs for only a limited set of functions, e.g., sending and reading email, browsing the web, listening to and downloading music, etc. If there were a consumer-oriented Sun Ray optimized for these functions, I think that could really benefit consumers as well.

Will there be one? Could that succeed, or what would be the reasons against such a "deskPod?"

I don't think bandwidth is a limiting factor any more, since compression techniques and intelligent screen updates can work with standard broadband connections already. And cable companies already pump HDTV into plenty of homes. Usability and device support might some areas where such a product would have to shine.

> I just don't see many reasons why an
> organization would want to deploy full-fledged PCs to user
> desktops, since most work done in a business setting can
> be done eminently well via a thin-client. Perhaps there
> are special cases, e.g., graphic design or engineering,
> etc.

This sounds dangerously close to the argument given by so many system administrators that think they know better than the users, what the users want.

I think one of the core reasons for the success of PCs on desktops in business is precisely that it allows the users to decide what they want. Sure, they get lots of functionality they don't need and it's a maintenance headache for the SAs. But when the alternative is inadequate functionality and denial of access to useful tools because someone else thinks they know better than the users do, what they need, then the users will take the option that gives them the most freedom every time.

Vince.

Prior to trying them out, I had no idea how thin clients worked and what user experience they provided. Thus, I assumed that using a thin client meant having to give up functionality for sysadmin convenience. In other words, I thought that, as you mention, thin clients provided inadaquate functionality.

I was very surprised to find that well-designed thin clients do not take anything away from using a desktop. If anything, they add to that experience, in that you can access many desktops simultaneously from a thin client, and that you don't have to sitting next to a computer to access a desktop running on that system.

For example, on the Sun display grid, there is an icon on the Gnome desktop that points to a Windows desktop. Clicking on that icon causes the Windows desktop to display, and I can even make that Windows desktop run in full-screen mode.

While this has worked for some time very well over LANs, the interesting thing now is how such systems can be extended to work on the WAN, i.e., the Internet. For most business applications, e.g., MS Office, Web browsing, email, etc., this already works with acceptable performance. Because of the nature of these applications (relatively infrequent screen updates, etc), accessing a business-oriented desktop via a WAN thin client is already a viable possibility without losing any functionality (it's the same desktop you get when sitting next to the computer).


> > I just don't see many reasons why an
> > organization would want to deploy full-fledged PCs to
> user
> > desktops, since most work done in a business setting
> can
> > be done eminently well via a thin-client. Perhaps there
> > are special cases, e.g., graphic design or engineering,
> > etc.
>
> This sounds dangerously close to the argument given by so
> many system administrators that think they know better
> than the users, what the users want.
>
> I think one of the core reasons for the success of PCs on
> desktops in business is precisely that it allows the users
> to decide what they want. Sure, they get lots of
> functionality they don't need and it's a maintenance
> headache for the SAs. But when the alternative is
> inadequate functionality and denial of access to useful
> tools because someone else thinks they know better than
> the users do, what they need, then the users will take the
> option that gives them the most freedom every time.
>
> Vince.

The interesting thing about the thin client is that implies fat servers (or highly distributed computing farms). This, to me, doesn't provide any distinct advantage from a hardware perspective. As you say, the cost of maintaining a machine and managing a users desktop environment can be more significant than most people will recognize. I'm investigating fat clients, instead, but using mobile code. The AJAX panacea is showing some of the things that the java Applet environment was targeted. The problem with Java was that it wasn't given as much access to the browser environment, as what Javascript now has. Thus, it never really provided the integrated control.

Jini's serviceUI mechanism is a great way to dynamically distribute new applications into the users desktop environment. I'm having good success at making updates and managing client software running on an unknown number of users desktops.

I, think this has a better opportunity to keep the users updated, allow the computing environment to be distributed (less impact due to natural disaster, or catastrophic failure), and speed the introduction of new software tools to help user productivity to be improved faster.