For some N number of applications, thin clients make sense. As long as N>0, spending one’s time writing flames in the comment thread of a series about configuring thin clients makes _no_ sense.

There seem to be two solitudes here: those who like thin clients and those who like thick clients. Is it like cat-people and dog-people? It seems there is no communication between the two. Perhaps it would help to supply some critical numbers. Unless you can describe what you are talking about in numbers, your knowledge is weak (paraphrasing Lord Kelvin).

I built a system last year: 153 seats - 96 thin clients - 57 multi-seat X thick clients. I used a gigabit/s backbone and gigabit/s to the multi-seat clients. I used six custom-built servers, one file/LDAP/http/NFS and the others were terminal servers. We saved at least $30K on licences using GNU/Linux. I saved nothing on the thin clients because I could afford double the number of seats because I was using GNU/Linux. $30000/$300 = 100 seats. Because I actually had a larger budget we were able to afford all kind of extra printers/scanners/cameras to make the whole system more useful. My hardware cost, per seat was about $300 including servers, not including cabling. Thick client would have been about $100 more for a drive and a larger case. The capital cost savings from using GNU/Linux and thin clients are both real.

Now, the killer numbers. On top of the low capital cost, this system has run two years with very little downtime and no full-time tech support. It runs on its own and one guy spends a few minutes a day checking on it or fixing anything that pops up. In two years, two memory modules and one hard drive failed. The users love it. It is faster than a thick client with local drive because there is no seeking when a cached file comes out of RAM on the server, there is no spin up time on booting, and the shared memory of GNU/Linux allows so many more processes to run in the same RAM. In two years, I doubt any of the servers was over 50% utilization. In fact, the whole system could run with 3 servers quite nicely. The cost per-seat for server was about $50. Now that would be about $30.

This year, I was working in a smaller outfit. I had a single server and 24 thin clients. Side-by side tests of a P4 thick client and identical hardware as a thin client was illuminating: OpenOffice took 7s to start on the thick client but only 2s to start on an old Xeon terminal server viewed on a P4 thin client. I could measure loads/bandwidth/memory utilization on every machine over SSH. The server used all its RAM, 50% of CPU, and all of its network bandwidth (100 mbits/s) with 24 users. I bonded in a second network interface and the network then had breathing room. No bottleneck. Everyone getting snappy service. Look at a thick client. It is idling except when loading programmes. With a terminal server, most of that work gets done by the first user and the rest used cached files. Thin client is just a great way to run as long as you are not doing full screen video or something that plugs a bottleneck. Ordinary browsing/word-processing averages out very nicely with small bursts between long periods of inactivity (human latency).

The most fun I had all year was to do the side by side comparison among P4 as a thin client, P4 as a thick client, and AMD64 X2 2gB as a thick client running Vista. Vista could not even see the first turn for all the dust the others threw in her face. 2 minutes to boot instead of 22s on the thin client. Several varieties of users tried this array of machines. No one liked Vista. Most were happy with XP on the thick client. All agreed that GNU/Linux on the thin client was the fastest by a large margin. There is just no reason to fill every seat with a thick client when a thin client will do very well or better. We even could do full-screen video on several thin clients at once but why bother when we could look up at a projection screen?

It makes sense to have a few thick clients in the system but certainly not in the majority of seats. They are too expensive to buy, install, maintain and they wear out too fast. A fanless thin client should be good for ten years or until its video resolution is obsolete. Last time I checked, 1024X768 was still very popular and it has been around for 15 years or more. A new thin client usually is OK for 1280.

1. “A mini form factor that ran cool with no moving parts was a great move” - but could equally well have supported a fat client if the workload were nearly as light as the ones previously being discussed here (which it sounds like it was; if not, then you were tolerating increased overall system cost - due to the need for a very hefty server to handle the application load - to satisfy the client desire for a minimal desktop footprint).

2. “We also reduced the need for some licenses” - which is precisely what the final comment in the post to which you were responding observed: unlike the cases previously under discussion, when you throw commercial licensing into the mix anything can happen (but that has nothing to do with underlying resource optimization: it’s a commercial rather than a technical effect).

3. “Maintenance was non-existence” (sic) - just as it would have been using diskless fat clients.

4. “group policies locked the user’s desktop” - now we’re getting into Windows-specific areas (which were not part of the preceding discussion about Linux-based servers, but are still interesting when discussing the merits of the two approaches). As I already observed, Windows is not as readily suited to distributing fat clients as Linux is, so while it’s possible to configure Windows diskless fat clients locked down by policies established at their (suitably protected) server-resident system data it 1) is more difficult and 2) requires individual client Windows licenses. So in the case where Windows applications must be run on a Windows server (unlike the cases previously under discussion) there’s considerably more reason to consider thin clients (which is exactly what I observed at the end of my first post here).

- bill

In our case we used some Neoware (now HP) clients. We did have a lot of old proprietary HP 120Mhz machines sitting around that we could have used but decided on new equipment. Some of the reason were we didn’t want to support 5-8 yr old fat clients. For the old computers still being used fans, hard drives, power supplies, and the occasional mobo would die. We would scavenge parts where we could but the whole point was to move away from senseless jobs. A mini form factor that ran cool with no moving parts was a great move. We mounted the box on the underside of desks as well as set them on desktops. The clients and managers were happy to see such a small footprint. It may not be an important thing to a techie but the solution was for the client not for us. We also reduced the need for some licenses, a single TS server’a antivirus covered the terminal servers, while we still needed TS cals for Windows (argh) we did not need a desktop OS cal (they ran Linux w/RDP). Maintenance was non-existence, group policies locked the user’s desktop, all-in-all a great solution.

About the only thing I agree with on Bill’s post is the need to centralize data. That should be part of any fat or thin roll out.

These days I still roll out thin client solutions. On average I can replace 30-50% of desktops in new build-outs. It does depend on your environment though - I support mainly medical offices. And there are times where it is a complete crime to try to force a thin solution.

Rich.

Some of what you’ve said suggests that you just haven’t been listening: when individual client loads are small, you can use a fat client that has *essentially the same hardware* (a comparable CPU, negligible additional RAM, no disk, etc.) that the thin client you describe does - and save the server resources that would otherwise be devoted to running the application at the server rather than at the client. In the example that you provide the additional CPU load and RAM impact of running the Web browser locally is negligible compared to the requirements of running the local operating system supporting the thin client.

I.e., whether at client is ‘fat’ or ‘thin’ is not (as least in the examples you have offered) a matter of *what* local hardware it requires, but of *how* it uses that hardware: if it uses it just for display management and communication, it’s ‘thin’; if it also uses it to run applications, it’s ‘fat’.

Or, to look at it another way, the incremental resources at the client required to run applications there cost very little (because they still fall well within the range of commodity products), whereas incremental resources at the server - and the application server itself, when compared with a simple file server - cost relatively a lot, don’t scale as well, and couple client loads together in a sometimes annoying manner.

Or to put it a third way, anywhere you’re *still* tempted to use a thin client for reasons of extreme economy you should instead be considering a dumb terminal - which requires even fewer server resources (green-screen form management loads are very low), costs less, and uses less power than a thin client does.

“Thin clients” aren’t exactly a new idea, you know: they were called “intelligent terminals” last time around, back in the ’70s. And they actually had some reason for existence back then, because they helped very expensive (and by today’s standards woefully under-powered) central computers scale up by off-loading a lot of their display management (which otherwise could bring the central computer to its knees when enough terminals were connected).

But PCs allowed both vastly more sophisticated display management and enough *local* computing power to handle most common applications as well (at least after 32-bit processors and operating systems arrived: earlier, PCs were used more as commodity-priced cost-effective replacements for the ‘intelligent terminals’ that had preceded them - or in cases where a user needed both a personal computer and a dumb terminal on the desk).

And after that PCs were increasingly used as intelligent terminals only to support legacy configurations that required such or when centralizing some processing activity actually made enough sense to be worth the effort (e.g., with a central, shared database server) - because it otherwise made sense to leverage that local processing power to distribute the processing load and decouple users from each other’s resource consumption.

Unfortunately, all this local autonomy created headaches for IT administrators, and their initial reaction was understandably to press for a return to centralized computing - a suggestion which the newly-liberated users resisted with equally understandable vigor. This struggle has see-sawed back and forth ever since, with the admins advocating thinly-veiled returns to yesteryear like thin clients and the creation of entire industries dedicated to the development of (complex) mechanisms by which admins can manage distributed autonomous PCs.

As I’ve been suggesting, all that’s really required to reconcile the situation is central (and centrally-manageable) storage. The network bandwidth is available: I helped design a diskless fat client network 25 years ago that used multi-drop 10 Mbit Ethernet fairly effectively, and Fast Ethernet’s point-to-point 100 Mbit/sec is more than adequate for any client activity short of streaming very-high-bandwidth data in bulk or heavily-parallel random access to many-disk arrays. But local storage is so in-grained in the PC mind-set (and in the Windows operating system) that such an otherwise obvious solution has yet to become the norm.

It’s nice that you’ve had good experiences using thin clients - just don’t kid yourselves that they also represented the most cost-effective use of hardware and management effort (license costs for proprietary software are of course a different story: a vendor can set prices fairly arbitrarily for different configurations to maximize profit, since proprietary software tends to behave a lot less like a commodity in this regard).

- bill

However, particularly in very large installations (call centers, banks, hospitals, etc.) or in remote installations that have good networking connectivity between the client and the server, thin client computing can make a lot of sense. We set up a kiosk in a library as a thin client. Despite the best tries of the library’s younger patrons to corrupt our system, if it does
hang at all, a simple reboot fixes everything. We have never had to visit the library….ever.

In addition, if you are doing true thin-client computing (only a web browser and perhaps a VoIP client), the CPU power and memory requirements that you need will come nowhere near what you need for a FAT client at the desk, and can therefore be satisfied by a much lower-power (3-5 watt) system instead of the 100-300 watt (or more) FAT client system. Multiply this times 3000 seats in a call center, and you now start to talk about real electricity savings, and real air-conditioning savings, as well as systems that have no fan, no disk, no moving parts, no noise. How long does your radio last versus your computer? Put a disk or fan into it and see how long it lasts.

Speaking of fans, hospitals are now realizing that the number one germ breeding area is inside a PC. Germs get into a nice warm environment, breed, then get blown out into the hospital by the fan. A lot of hospitals are now switching to fanless thin clients at nurses and doctors stations, with membrane keyboards that can be wiped clean with antiseptic.

As I said, thin clients are not the answer for everyone, but they have a lot of good points in a lot of areas.

maddog

Keith Packard gave a talk which described the issues:

http://keithp.com/~keithp/talks/usenix2003/

and today tunneling the X protocol over ssh with compression generally gives you better performance than LBX.

maddog

Why not change nothing but the client software and use them as *real* fat clients, with shared storage rather than shared application servers? They could still be diskless, CD/DVD-less, and floppyless, maintenance could still be limited to (file) server backups, and you’d still be able to manipulate the kids’ data directly - and I don’t understand where the ‘massive, massive’ software costs that you say you eliminated came from (unless you’re mistakenly chalking up money you saved migrating from Windows to Linux as being due to migrating to a thin-client configuration).

- bill

The really, really neat thing for me is that I can manipulate the kid’s data so easily - it is all in /home/learners/Grade7, etc.. (I know that this can also be set up from Fat Clients. However - I don’t have to constantly re-install hard drives - which used to be a nightmare (even with Ghost (’Doze))!

The obvious downside is that, when the Server does freeze up or go down, we are really stuck! There is nothing ALL the kids can do - things get a bit rough! With Fat Client this wouldn’t necessarily happen. Another downside is that - even though we have such a powerful server and virtually all our clients are new P4 2.6GHz machines with 512M RAM - if we load, eg. Open Office Write it takes a good while for them all to load their programs - even though we have a 1000MHz ethernet link to the switches and 10/100’s to the clients. (Any comments would be valued).

Just an observation: The P1 and P2 machines definitely are not as fast as the P3’s and P4’s. (Unless it is my imagination).

- keith