Thinking Thin
Once upon a time, there was the mainframe. All application processing was centralized to this enormous beast, and desktop equipment did nothing but display its output. Then the personal computer arrived, ending the tyranny of the mainframe. Individual users suddenly were empowered to install their own applications. Software development and innovation boomed. The personal computers were networked. Thus, the mainframe was slain.
But all did not live happily ever after. The cost of maintaining a workstation on every desktop outgrew the purchase cost long ago.The fact that the dominant operating system is like a Petri dish for viruses and spyware has exacerbated the situation to a point that should be considered intolerable. It has to be faced that, in most situations, it is not desirable to allow the user to install software. The only sane management decision is to draw a clear line between users and administrators.
This can be accomplished in large part by using a secure system like Linux on the desktop. Viruses and spyware disappear, and maintenance costs can plummet. But, there is still a full system on every desktop that must be maintained. Hard drives fail. Fans fail. Major OS updates are not automatic. Desk space is consumed.
One solution is a step forward that feels like turning back the clock. The thin client is the modern equivalent of the text terminal. It provides a low-profile, low-maintenance appliance for the desktop. Application processing is off-loaded to a centralized system called a terminal server. Linux has emerged as the OS of choice on the thin client, even when the terminal server runs MS Windows. But let's not go halfway. Let's explore in detail how to deploy a Linux thin client with a Linux terminal server.
What makes a client thin? Most important, thin clients have minimal local software that can be stored on a Flash memory module that is read-only for the local user. This is usually a standard CompactFlash card or a Disk On Module (DOM), which is Flash memory with an IDE interface. A small portion of Flash is made writable for saving configuration information, but in a properly configured system, the user will not be able to modify this. Once configured, it is very nearly an appliance as far as the user is concerned.
Because most of the processing is performed by the terminal server, a slower CPU can be used; 533MHz is typical. This diminishes the cooling requirements greatly, which means fewer or no fans. The silence is golden.
Because there are no internal drives or expansion cards, motherboard components are reduced, allowing very small form factors. The small form factor, reduced cooling requirements and lack of drives mean a very small enclosure. The model I typically use measures 9.5" tall and 1.75" wide, and has a maximum power consumption of 30W. The smaller power supply also means a smaller UPS. Compare a 700 VA workstation UPS costing $120 US and weighing 17 pounds to a 350 VA thin-client UPS costing $40 US and weighing 11 pounds.
Thin clients have two distinct modes of operation: client and standalone. In standalone mode, the thin client isn't really a client. All necessary applications are loaded in Flash and executed locally, which can drive the purchase cost up by increasing the Flash requirements. The most common application of this is a Web appliance. Any decent thin client will have the ability to boot directly into a Web browser and even prevent the user from exiting the browser or modifying its configuration.
Here is a big caveat to thin clients: vendor dependence. You can't simply download the latest version of Firefox and install it on a thin client as you can with a workstation. The manufacturer must provide a special image for your make and model. This is something that needs to change, but for now, the software that the manufacturer makes available is a crucial factor in selecting a thin client. If you want Firefox on a standalone thin client, the manufacturer has to provide it. If you want Flash and Java to work, the manufacturer must provide the plugins. Don't expect the plugins to be current releases either. The size of some plugins has outpaced even the plummeting cost of memory. In particular, Acrobat and Java have grown so enormous that it is more reasonable to use an older release than pay for the additional Flash and RAM required to run them.
How software is made available depends on the manufacturer. There are basically two methods. One is to provide individual modules. This allows you to pick and choose, but more labor is involved in preparing the clients. The other method is for the manufacturer to provide monolithic images with all the options needed. This can be practical if the manufacturer is flexible about providing custom images.
When using thin clients in client mode, the applications are all normal installations on the terminal server, which is simply a high-performance server with enough horsepower to do the application processing.
In client mode, the thin client has a dual nature. It is a client in respect to the application services provided by the terminal server, but it is also a server in respect to providing those applications with access to local hardware. The local hardware being served up is primarily a keyboard, video and mouse (KVM), but there also can be local audio, USB storage devices and printers.
Thin clients are available with Linux, Windows CE and Windows XP Embedded. Barring some desire to use Internet Explorer in standalone mode, there really isn't any reason to consider anything but Linux for a thin client. Even if the terminal server is MS Windows, the fact that Linux is running on the thin client is completely transparent to the user. CE and XP only add software license costs to each client, and XP doubles the Flash and RAM memory requirements on the client (128MB minimum Flash and RAM for Linux vs. 265 Flash and RAM for XP). Because of this, the most commonly deployed thin-client configuration today is Linux thin clients connecting to MS Windows terminal servers.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- RSS Feeds
- Trying to Tame the Tablet
- What's the tweeting protocol?
- Dart: a New Web Programming Experience






3 hours 54 min ago
6 hours 16 min ago
23 hours 4 min ago
1 day 1 hour ago
1 day 2 hours ago
1 day 3 hours ago
1 day 3 hours ago
1 day 8 hours ago
1 day 9 hours ago
1 day 11 hours ago