Channels ▼
RSS

Design

The Ever-Fatter Thin Client


Since the earliest days of modern computing, the theme of thin clients has run a through the fabric of hardware devices like a wayward color thread through a tapestry. While all else tends in one direction, a persistent cross-theme of "less is more" pervades a fringe sector of infrastructure. In the post-PC era, you'd think that "smaller is better" would finally have its day in the sun, but the same forces that have historically constrained its emergence are just as active and effective in the present.

More Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

 In the days of mainframe hegemony, thin clients were simply dumb terminals. Computing was done on the host machine: Letters were relayed to the screen and key-presses sent back to the beast in the computer room. In industries that did heavy data-entry, smart terminals were an excellent solution and remained a mainstay of enterprises for decades. They were cheap, didn't break often, and could be swapped in and out easily.

Terminals appeared also in UNIX circles, where beefed-up versions competed with workstations in the form of X terminals: high-end, graphics-capable, dumb terminals. As with the mainframe add-ons, their principal selling point was lower cost of ownership.

When PCs arrived, the new devices became the de facto fat client — not cheap and certainly not easy to manage. Initially, they were no substitute for dumb terminals and so they were used primarily by "knowledge workers" and "power users" who needed local computing power to perform their duties.

Even when the prices of PCs dropped significantly, vendors of thin clients, such as Sun Microsystems, could still score sales my shifting the conversation to the cost of management of PCs. A Sun Ray device, for example, sported a card reader, which enabled the user to sign in and call up his desktop and work from there. The programs and all the data resided on centralized servers under IT's control.

If you've used SSH or Windows Remote Desktop from your PC, you have experienced the trade-offs: diminished performance and strict limitations on what you can do.

This brings us to the present day. For the last several years, Google has been touting Chromebooks as a solution to the common problem of managing PCs. The Chromebook is a laptop device with local processing but whose OS, applications, and storage are online. In effect, the local OS is primarily a browser and the software consists of HTML5 apps, such as Google Docs, and other services offered by a slew of vendors. Ads from Google make no bones about it: The selling point is reduced acquisition and maintenance costs. Sales come from the traditional segments for thin clients: data-entry-intensive sites and schools. It's important to note that Chromebooks are not dumb devices in the same sense that their forebears were. Chromebooks run portions of apps locally and have temporary local storage for use by the client side. This arrangement is somewhat different from a cottage industry that sprang up about five years ago, but appears to have died: vendors of hardware devices that enabled users to attach a keyboard display to a virtual machine hosted in the data center or cloud. Pano Logic was a representative vendor of this technology, and it made its pitch — which now appears to have been unsuccessful — on the basis of easy maintenance. In this model, IT updated and handled the hosted VMs, users plugged their display, keyboard, and mouse into a small, cheap device that passed graphics and keystrokes over the network to the VM. Products like the Chromebook have replaced this model.

For a few aficionados, there is a different raison d'être for the thin-client model, which is a return to a simpler model of computing. Their hopes might have been elevated when tablets first appeared and were touted as the successors to PCs. But those aspirations were and will always be frustrated, as they run athwart of all we know about consumer preferences, which strongly favor more features, rather than fewer. Each generation of tablets (smart phones even more so) has added more capabilities. For example, today it's not uncommon to see tablet users carrying a Bluetooth keyboard that attaches to their devices.

For some old timers, the view of a laptop being recreated by a tablet and keyboard is laughable as an advance; especially given the underpowered nature of the tablet. But focusing on the irony misses one point: the keyboard is a rarely used device for the tablet, whereas it is the primary input mechanism for laptops. In addition, the touch aspect of tablets provide a different screen interaction than laptops do. Other physical characteristics enter into the equation as well.

But the vision of a tablet cum keyboard as the new model of PC is right on. This is the fat client come to the new form factor. I believe the future is heading in that direction and that the Microsoft Surface leads the way. I've been using an Intel-based Surface Pro for several weeks now and very much like the combination of PC and tablet that it provides. The device, while considerably more expensive than the standard tablet, represents a believable next step for the industry — a full PC (with Intel processor, SSD disk, 4GB RAM, 1920x1080 screen) that can be used as a touch-enabled tablet. Only battery life and cost stand in the way of wide acceptance.

Over time, thin clients inevitably become thicker. And in the consumer space, they become thicker fast by adopting thick-client capabilities and delivering them with a new twist. If the post-PC era looks a lot like a highly portable version of the PC era, don't be surprised.

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy


Related Reading






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video