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.
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- RSS Feeds
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Weechat, Irssi's Little Brother
- Senior Perl Developer
- Technical Support Rep
- UX Designer