Why thin clients and zero clients haven't lived up to "last PC you'll ever buy" hype. (Part 1 of 2)

Listen to this podcast

I've been collecting thoughts on this blog article for a few weeks now. It seems this was quite timely given Brian & Gabe's recent interview with Tom Flynn from HP where they talked about thin clients, zero clients, etc.

I've been collecting thoughts on this blog article for a few weeks now. It seems this was quite timely given Brian & Gabe's recent interview with Tom Flynn from HP where they talked about thin clients, zero clients, etc. Here are my thoughts on the topic.

If you've been around the SBC / VDI industry for any length of time, you should know all about thin clients. Thin clients were the devices that were going to usher in the end of the PC industry as we know it. The benefits of a thin client over a full-fledged PC are numerous (in principle), including:

Less moving parts = less component failures

Not having a spinning hard disk is one major reason why thin clients should have a longer life. If you look at the failure rates among PC components, hard disks rank as one of the highest failure rates among the components that make up a typical desktop PC. Look at this chart from a Carnegie Mellon University paper on the topic of component failures in PCs published in 2006:

Source: Parallel Data Laboratory - Carnegie Mellon University

While hard drive manufacturing practices have improved since 2006, the rate of failure vs other system components is still pretty much the same. Changing the spinning hard disk to an SSD drive may ultimately improve the reliability (though that is currently being debated as to whether or not it actually reduces failure rates) but it certainly won't help the cost of the PC devices. Thin client manufacturers must keep costs down in order to be competitive against a common PC that it's attempting to replace. By a thin client not having a hard disk means they have one less component that has a high failure rate and ultimately it means less power consumption as well.

Less Power Consumption

Typical thin client devices consume anywhere from 2-10 watts. With a typical PC systems consuming anywhere from 20-60 watts it's pretty clear why an organization would want to standardize on thin clients vs full blown PCs because power consumption translated to real cost savings. Now, in order to say that thin clients are more cost effective than PCs when looking at power consumption one must also compare the back end infrastructure power costs when calculating power savings, but in most cases you can still save power even with the back end infrastructure considered.

Less Cost for i.m.a.c.

No I'm not talking about Apple's latest all in one PC. i.m.a.c. is an acronym that stands for Install, Moves, Adds, Changes. Arguably a thin client substantially reduces the amount of time it takes to deploy an asset, move it from one place to another, swap out a failed one, etc. Just because you've made the endpoint device super easy to manage does not mean you necessarily have made the desktop management method any better. Therefore, implementing thin clients to replace PCs does not eliminate the burden associated with managing the Windows instances unless you've take steps to minimize the administration of your windows instances through things like PVS, Common Image, Layering, App Virtualization, User Virtualization, etc. That being said there will still be time saved in the actually effort require to deploy the asset itself.

"The Last PC you'll ever buy!" Really?

"The last PC you'll ever buy" was a common sales tactic among early thin client manufacturers and yet that never did happen. There are several reasons why this never happened:

Relative Immaturity of Remoting Protocols and Fragmentation

In the early days of Citrix WinFrame, Citrix did a pretty efficient job at remoting basic Windows applications. The reason for this is a majority of Windows applications were made up of GDI objects painted on the screen with a handle of bitmap graphics here and there. Animation and video were almost non-existent and even graphics were fairly simple in terms of dpi and color depth. Citrix had a technology within ICA that allowed for a Terminal Server host to send down graphics commands a primitives to the endpoint device. You can think of GDI primitive remoting like this. Let's say you want to create a Window in a Windows app that creates a display area that is 800x600 pixels with a scroll bar, maximize/minimize/close buttons, etc. When that Window is displayed (or painted) it's done so using a set of Windows APIs used for painting GDI objects. Once those items are to be painted on the host system, you need to find a way to get them to display on your remote client device over your remoting protocol. This can be done one of two primary methods:


  • Intercept the API call to paint the window and transmit it to the client device where that local operating system will in turn process the API call to paint that object in that position. This is GDI primitive remoting.
  • Bitmap Remoting is the other method for getting host screen content onto the client device.


Bitmap remoting is, for a lack of a better term, taking a screen scrape of the host side system and then sending that graphical image down the the client device to be displayed. GDI primitive remoting turned out to be the best way to display static screen content onto a remote system and it worked very well over limited bandwidth connections that were quite popular in the days of dial-up modems.

The ability to do GDI primitive remoting only worked on a system that could understand painting GDI objects. Windows-based thin clients could do this. Linux thin clients could not and therefore Linux thin clients would always receive a host rendered bitmap object rather than a GDI primitive. This took more bandwidth on the wire and didn't look quite a fluid as GDI primitive remoting. In my opinion, this is the reason why Linux-based thin clients never really took off well early on. Having multiple different client operating systems with different rendering capabilities also leads to fragmentation in terms of what is capable on which operating system. This fragmentation creates a lot of confusion among customers about what capabilities of the remoting protocol they are going to be able to take advantage of. This fragmentation is also present in areas like printing support, too.

Application & Web UI Complexity

Application and Web UI in the early days was quite simple. It was often quite easy to achieve very efficient rendering of ICA traffic with very little bandwidth. However, in the early 2000's more an more of the web started to contain animated GIFs, video, Flash, etc. Years later other technologies like Silverlight, HTML5, etc continued this trend. Due to this graphical richness, the capabilities of the endpoints needed to evolve in order to cope with the demands of this higher level of graphics performance. Unfortunately in the case of thin clients, the CPUs weren't up to the task and since most of them lacked a GPU there was no ability to offload to GPU to assist in the graphics processing. Thin clients were hardly the last PC you'd ever buy.

Commoditization of the PC

When PC devices were selling for $1000-$1500 and thin clients were available for around $600-1000 it seemed quite compelling to go the route of thin clients and get rid of those fat clunky PCs. However, something remarkable happened to the PC market. It quite literally collapsed. PCs became commodity. With that commoditization, the market for thin clients eroded. It's not uncommon today to have a full blown business PC available for purchase for around $400-600. The thin client market is all over the place and there are some thin clients available for as low as $100-200, but the premium thin clients are still in the $400-$800 range. Given that a PC is quite cheap and the desktop management tools are quite good, it becomes a difficult struggle to recommend thin clients in the face of a well-managed desktop. What doesn't help this fact is that thin clients still require management themselves. Thin clients still have software on them. Software that has to be updated for security vulnerability as well as software enhancements to support the latest /greatest enhancements from Citrix and other vendors. The software process to update thin clients is of course completely different than the process of updating software on existing desktop PCs. Unless you were successful at switching to thin clients for 100% of your users, you now have a fragmented management strategy where you now have to keep two systems management products in place. Also, some thin client manufacturers charge additional money for their thin client management platform.

Thin Clients are NOT future proof

One of the long standing myths about thin clients is that they are "future proof" and have a 7-10 year life vs a PC that only has 3-4 years of life. Ask the people who bought the Wyse Xenith felt when the Xenith Pro was launched. The bottom line here is that a thin client is only as future proof as the components contained in the system. If the thin client manufacturer cuts corners and puts a low performance Via, ARM, Intel chip in the system or a low end graphics processor chances are that thin client has no greater lifetime than that $300 Dell PC you can buy online. In reality, the Dell PC probably has a long life from a capabilities perspective.

Enter the HDX Ready Thin Clients

Given the concerns I outlined above, Citrix embarked upon a marketing campaign in 2009 that included a component called HDX Ready to denote thin clients that met a minimum set of system specifications that would result in a good user experience when used with XenDesktop 4. Citrix began calling these thin client devices Desktop Appliances to separate them from the perception that a thin client was an underpowered device. All the HDX Ready certification really means is that the thin client device has a higher level of CPU/GPU power to support modern "high definition" desktop experiences. Again, this was really a marketing campaign about distancing HDX Ready thin clients from the legacy bunch of thin clients that were not high powered enough to run a "high definition" user experience. The biggest issue that plagues these "HDX-ready" thin clients depends on your definition of HDX. The important thing to take away from this is that "HDX is not HDX and not HDX". What I mean by this is several of these "HDX" thin clients only support a subset of features present in HDX. Check with your vendor to see whether or not they support UPDv3 printing. Since that solution is based on a Windows EMF driver, chances are that Linux based thin client won't support it. Maybe a big deal to you, maybe not. What about Flash redirection, etc? Do you homework carefully. Bottom line, HDX ready is nothing to see here folks.

Enter the Zero Clients

What's a zero client you ask? Ummm that's kind of a difficult thing to answer because it sort of depends on whom you ask. In reality there's two types of zero clients out there today.

True Zero Client

A hardware thin client device that does not contain firmware (aka software) that you need to update. One device in this class is the Pano Logic devices.

Psuedo-Zero Client

A hardware thin client device that does contain firmware, but doesn't leverage the traditional firmware update procedure but rather updates its firmware by receiving it via PXE. Wyse introduced the Xenith Zero Client at Citrix Synergy in 2010 that was this category of Zero client. This doesn't technically qualify as a zero client as there is still a software stack on the devices that you need to update. However, given the ease at which you can update the software it certainly makes it simpler than the traditional firmware update methods that have made thin clients difficult in the past. One big risk that you need to be willing to accept when adopting this form of zero client is that you thin client infrastructure is now heavily dependent on availability and health of your PXE services for their updates.

Enter the Citrix HDX SoC (System-On-Chip) Thin Clients

Lots of clients and associates have been asking me for my thoughts on the recently announced HDX SoC design. That will have to wait for Part 2...

Stay tuned..

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I know you are talking about truly thin clients vs. fat clients.  But, there is also the pseudo "thin clients".  The endpoint devices with re-purposed fat clients, but with a "thin client" interface.  The nice feature of those, is that customers can leverage their existing endpoint hardware, yet gain access to their new VDI environment and reduce the end user interaction on the fat client.

I agree with you, thin clients are not the end all solution.  Each customer environment is variable and needs to be treated such, not giving them a rubber stamp solution.


Great Article Shawn! You definitely hit the key points. I deal with this often because the name of my company is Thin Client Computing and people are surprised when I explain the above to them.

While I would love to advocate TC devices, the reality is that they are only a great fit for very specific types of use cases, usually repetitive task workers running 2D apps and no, or a bare minumum, of multi-media.

The reality of today's environments is that mutli-media is almost everywhere from phones to netbooks to laptops to corporate PCs. A device which fails to deliver this capability is simply out of the running most of the time.

In addition, the ability to re-purpose existing PC's within our client organizations has often allowed us to fund the virtual environment with what would have been spent on hardware, manpower and software updates to the desktop PCs!!!


Fantastic article Shawn, nail hit right on the head.

Technology is changing too fast to claim anything larger than a 3 year lifespan on any device.


Great article Shawn!

Looking forward to part 2!


The cost vs relative lifespan of (lets call them all) thin clients is a real sticking point. A 500$ device that is absolutely software upgradeable/future proof for 8 years is a good deal. A more limited/technology restricted device at $100-$200 is a good deal. The problem today (as demonstrated by the wyse xenith example) is that we're paying $500 for a device that only has a 2-3 year lifespan, after which it is left behind in terms of capability.

User demand for an increasingly rich experience is now biting across the corporate world. The argument of "why do you care about video performance - do you WANT your staff wasting time on Youtube?" is no longer valid. Given the rapid changes at the backend, the every changing state of the protocol war (varients of HDX, PCOIP, now RFX etC) its nigh on impossible for a company to acurately predict which technology is the best buy for them in the medium to long term.

How to address is? Easy way - comoditise the endpoints - make em so cheap that we dont care about changing them every 2- 3 years to take advantage of the latest optimisations. Best way for consumers ? Make em cheap AND software upgradeable by using a DSP like HP or Thinlinx (and apparently HDX-on-a-chip,,,).

Lets face it, the money is all in the backend, management and licensing anyway, not in the endpoint. Current thin client OEM manufacturers dont want to accept this as it hurts thier business model, and is why the first decent single/mutli-protocol DSP based zero client product with enough ports will bury them all wholesale.


Contrary to industry mainstream, I consider the "Thin Client" to be a software solution, NOT a piece of hardware. By software I mean something you can install on an ordinary PC, and giving the user the impression to work on a Thin Client. Empowering users to have i.m.a.c. benefits, on their CHOSEN commodity hardware, be it something existing today, or a new cheap PC you buy tomorrow is a real game changer.

Truth is, I was so serious about this idea that I started a company which now runs well worldwide with offices in two continents, profitable with a decent customer base - www.stratodesk.com. It is funny because we picked up the "future proof" thing some time ago, for almost the same reasons Shawn is mentioning.

Speaking in terms of hardware, most people have care packs and what happens if the hard drive breaks down? Nothing. They get a replacement next morning and since the system is only running our solution without local user data, no work has to be done, no data is lost.

From a pure technical perspective we can not solve any GUI/remote protocol issues, but:

a) the protocols have improved a lot from the early days (anyone remembering RDP at 8-bit colors? :-)), AND

b) we lower the bar for using SBC or VDI because the software is inexpensive, independent, the user can go back to Windows any time without having hundreds of thousands sunk in hardware.

However, I have to say, there is some caution needed: If somebody offers you a repurposing software it might be just to lock you into this solution and later on buy your hardware. I say this because Stratodesk is about freedom of choice, being strictly hardware agnostic, and giving users a choice on which hardware they want to run their infrastructure, today and tomorrow and we don't see it as a sales tool for HW boxes.


@Shawn, great blog and good to see you  blogging regularly on this site. I agree with most of the comments but I would like to clarify few things around the “HDX Ready Program”

HDX Ready was indeed started around XenDesktop 4.  Customer wanted us to guide them around purchasing decision for thin clients which will be able to support most of the HDX features around multimedia.  

I agree that the program isn’t perfect but it is a good initiative and it gets better each year. There is always room for improvement and I would love feedback from the community.

So here are some points I would like to make

- HDX Ready is more than a marketing program.  Vendors like Wyse, HP and others have to pass 20+ test cases in order to qualify their thin client as HDX Ready.   Here is the link to test kit package which vendors have to pass in order to become HDX Ready https://bit.ly/wj8GQ0


- The test cases include test for multimedia (server based, Client based), test for smart cards, VOIP capabilities, etc.

- We add more test cases each based on features we add to HDX.  There are 3 versions of test kits XenDesktop 4, XenDesktop 5 and XenDeskop 5.5.   Vendors must demonstrated HDX capabilities on both XenApp and XenDesktop.  They must submit HDX Monitor logs and prove which USB devices, Smart cards, web cams they have used to do the testing


- You can be HDX Ready for XenDesktop 4 but that doesn’t make you HDX Ready for XenDesktop 5 or 5.5.   We clearly show this via Citrix compatibility matrix.

- There are thousands of thin clients in market but only 39 thin clients have been blessed as “HDX Ready” for XenDeskop 5 and 5.5.  This clearly shows we care about the quality and don’t allow anyone to join the program or get listed without being tested.


- I acknowledge there is gap between feature sets for Windows client and Linux client but over the period of year the gap is really narrow.  A point of confusion you mention is that HDX Ready for windows thin clients is not same as HDX Ready for Linux.  I acknowledge that but we address this issue by making it clear on the  Citrix Ready product.

Here is an example page where a thin client does not support client multimedia redirection so we clearly mark it on the page


At the time the vendor tested their thin client they were using previous version of Citrix linux client which did not support client redirection.

We can always do a better job at this and I would like to see what feedback you have.

- FACT: HDX Ready is more than rubber stamp which vendors can slap on side of the Thin Clients. We now (starting XenDesktop 5.5) require each thin client vendor to ship us their device for internal testing at Citrix in order to qualify being  HDX Ready.

<Disclaimer> I work at Citrix and I am part of virtual team managing HDX Ready program</Disclaimer>


If Apple can make and sell an AppleTV device for $99 which in effect is a sort of thin client and can display HD content, why are other devices so expensive?


Great article Shawn, I hope more of my customers and prospects considering thin clients read this.  

80% of the companies I talk to considering thin clients want to use them to have a longer life at the endpoint.  My response...if nothing changes in your environment for (fill in the blank number of years customer wants to extend the life to) you should have no problem, if you plan on changing anything though...

The other 20% want less management, which to your point of pseudo zero or zero thin clients there are tradeoffs in this age of rich media.

Once in a great while physical conditions or power drive the requirement for thin/zero clients.

People keep looking for that magical solution which accommodates all of their current and future unknown needs...that solution is a unicorn.  In the end all solutions have compromises.

Again, great article.


The idea of hardware independence (one comment labeled it "hardware agnostic") coupled with zero, or near zero, clients and powerful management software can go a long way toward increasing the useful life of the Thin Client.  The client is nothing more than a dumb terminal, displaying the OS and applications of the Server.  Upgrade the server and the clients now display the latest of everything.

We (www.ThinManager.com) have customers who are running the same hardware they purchased in 1999.  Can you find any equipment you are using that is 13 years old?  And high-quality zero clients don't have to be expensive either - we are currently offering a very reliable client for under $200.


hi, Good to see arguments being tendered both for and against SBC/VDI. I accept most, if not all, of what you say, Shawn, but the points raised are ultimately points already laboured hard and long by many dyed-in-the-wool anti-SBCs (not meaning to tar you with that bruash at all).

in our own case, we only recently replaced 8 year old Wyse terminals (non-HDX ready!) on our recent migration to XenApp 5. Any self respecting infrastructure manager would easily regard eight years as a pretty good service for any piece of kit. As it turns out, we probably did not need to replace the Wyse devices, as it seems some staff are actually still using them on the XenApp platform, much to our bemusement.

On management of these devices, we use manufaturer supplied management software (IGEL UMS) to easily deploy firmware and config changes. We can even switch a user to a new platform without them knowing anything has happened. Works a treat. We can set up a thin client in minutes and our users all enjoy a 10 second bootup to login screen...each and every time...!

One downside, however, to going thin client is the whole user perspective thing. Once something doesnt work, no matter how small that may be (a website wont load or there is a 5 second delay opening a file or email - cos, hey, the file or email server is busy!), word spreads like wildfire that its the fault of this crappy little thing IT stuck on my desk...and user perception takes another hit.

I believe, if anything, that user acceptance is the bigger pain point, and ultimately a big drawback, for IT managers looking to implement SBC/VDI.


Thank you for your details interpretation about thin clients and zero clients

here I am introducing a Versatile thin client Terminal RDP XL-500

We can use it as a

1) high end thin client device

2) Mini PC/Individual PC

3) Virtualization Ready

It would be interesting to know where you stand now compared to 2014.
Where do folks stand on this topic now.  Suggestions on new technologies?