Talk:Thin client

Intro rewrite

The introduction needs to be rewritten to take account of the fact there are two related definitions - see the Definitions section in the article.—greenrd 18:22, 15 April 2007 (UTC)

Article too broad?

When I think of thin clients I think of one additional criteria -- that of hardware or software clients that allow me to disconnect a session and then reconnect to it from the same system but more importantly from a different system (or unit). I don't think terminals quite fit this nor does X-Windows without help (like from NOMACHINE). Actually, I would probably throw in a GUI element as well since all of the modern thin clients are GUI based. If we do want to claim that things like text based terminals belong in the same category then perhaps a distinction should be made between thin clients of old, modern thin clients, and how usage of the term has evolved. For what it is or isn't worth I have been a Sun Ray and MetaFrame for UNIX administrator for 7+ years. Argel1200 23:29, 24 April 2007 (UTC)

If you could cite a reliable source for your definition, that'd be great. Otherwise, we can't base the article around it, I'm afraid. And even if you can, we might not be able to, if (as seems likely) there are multiple "correct" definitions. (Incidentally, I've been having difficulty finding definitions that I can nail down for related topics recently - I am looking for a copy of the original Network Computer Reference Profile, for example).—greenrd 23:50, 24 April 2007 (UTC)

This InfoWorld article comes to mind: Think Thin. Finding an exact definition is going to be difficult as the industry has just ended up moving in this direction -- e.g. all the major products support these features so I think they are taken for granted. Regardless, the InfoWorld article is certainly a better reference than the webopedia one when it comes to modern thin client technology. Argel1200 22:19, 21 May 2007 (UTC)

The article doesn't seem to provide a definition, which is what the Webopedia link is for - and in my experience, even trade journalists are not reliable sources for definitions about technology ("trade publication" journalists, as opposed to "enthusiast publication" journalists, aren't always that technically knowledgeable, and rely too much on what PR people feed them).—greenrd 00:04, 22 May 2007 (UTC)

Trade publications may not be the most reliable source but how can you in effect claim webopedia is more reliable? This article needs a good rewrite -- e.g. the software thin client section mentions Knoppix but fails to mention the actual industry leading products like Citrix, Windows Terminal Services, and Secure Global Desktop -- but you have sapped pretty much all of my motivation. Enjoy your article! Argel1200 04:02, 22 May 2007 (UTC)

Are technology distinctions really the key point?

I read the article and much of the discussion here and feel as though I'm eavesdropping on a private discussion amongst technologists. Fascinating though all these distinctions (terminal, dumb terminal, hybrid x, thick y) may be they all seem to have the discussion upside down for those readers visiting the site for a more practical understanding of the issues in the thin-client concept. Here's a start?

The impetus towards thin-client is away from the "thick client": the current personal computing standard, with its desktop operating system, applications and data. Following is a simplified presentation of the issues.

A major problem for large organizations having perhaps thousands of desktop computers is the problem (cost) of purchase and maintenance of such individual systems. Each purchase of a desktop computer requires perhaps a day of set-up/configuration; within a month however that desktop will likely be different from every other desktop because of the user's preference, personal installs, and perhaps computer viruses. So that each subsequent (inevitable) user problem has to be solved by a technician who has to unravel all these local mysteries. Standard upgrades and new software multiplied by thousands (of desktop computers) add further burdens to an already large maintenance budget.

Imagine then the appeal (to management, anyway) of replacing all of these "fat" clients with a simpler device that gets all its programs and data from a single central server. The "thin client" requires negligible setup/install costs; the user is permitted only standard, limited customization; there is only one copy of the operating system and all software on the server; a quick upgrade to the server software is all that is needed to instantly upgrade all user software.

Such a picture is highly appealing--idyllic even--to those who maintain systems, so what possibly could be wrong with it? Well at least three things (say its critics): speed; personalization; and autonomy.

speed: with thin client you have one (or at least a limited number) of central servers doing all the work previously done by a thousand or more local hard drives, and sending that information over thin wires rather than fat wires. This actually works quite well...but not perfectly. Users must get used to a different, often jittery, feel to their experience and not everyone likes it.

Speed of thin client systems can be higher than thick client systems. Consider loading an application. A thick client has to seek the files and retrieve from the hard drive. A terminal server already has most-used applications in RAM. In UNIX systems using shared memory and file caching this is highly likely. For example, it takes about 2s to start OpenOffice.org for a user on my system normally while it takes abut 7s the first time a user activates OpenOffice.org after booting the server. Also, a terminal server will likely have far more RAM than a large number of thick clients so many files in the system will be cached. Yet another way thin clients are faster is they boot from a flash drive or a network drive (cached on the server) so there is no spin-up time. The only times when a thin client will appear slower to the user is for CPU or I/O-bound operations which may reach the physical limits of the server, which are faster on a server farm or cluster in many cases anyway. There is a range of tasks which are faster on a thick client but larger tasks should be done on a cluster. The only example of a task that I have seen in a school for example that was not appropriate for thin clients was showing full screen video on every seat. If a projector is used for such purposes in each classroom, there is no problem. That leaves a very large number of situations for which thin clients are faster than thick clients. The normal user browsing or word-processing is the bottleneck in a thick client and a server can deal with many human interactions simultaneously. 50 human clients per core is feasible and fast. If an individual user needs more power, give him his own server or put a small number of such power users on a server. Pogson (talk) 12:10, 28 June 2008 (UTC)

personalization: some customization is possible on a thin client but there is much more of a feeling of being a clone in a factory than having one's own desktop domain.

Lockdown of the deskktop is a matter of configuration and is not different between thin and thick clients. The user's desktop environment is stored somewhere on a file-system either way.Pogson (talk) 12:10, 28 June 2008 (UTC)

autonomy: what if the server goes down (or the line, if the server is in a remote location)? Where before, a thousand users would continue working with only minor degradation of service (no email?), with thin client, a thousand users would be without any useful computing power at all for the duration of the server/line downtime--a potential disaster for many types of business operation.

Thin clients are plug and play so are much less likely to fail because they are fanless/discless in many cases. Typically, the user can access his desktop environment from any thin client in a system, giving great autonomy. It takes very little extra effort to include redundant servers in a cluster for the terminal server. For all but the smallest systems, a cluster is needed anyway for the power. If a server fails, the user can easily reboot the thin client and connect to a different server. With X-sessions, for example, the system administrator can arrange to have users' sessions on one server, the word-processor on another, the browser on another, and so on so that in many cases (rare) of failure of a server, the user has only to click on the icon to restart the application without even a reboot. Similarly network failures can be eliminated largely by including redundant paths. Many large thick client systems are useless without networks and server, too, to this is not a negative for thin clients alone.Pogson (talk) 12:10, 28 June 2008 (UTC)

The discerning reader will detect tensions between two groups here: between perhaps those management and technical personnel who favour (for obvious reasons) the thin-client approach, and end-users, who resist it because of the speed and personalization issues. In the end it is often management, in spite of its desire to reduce costs, that cannot overcome its discomfort with the possibility of bringing a thousand employees to a dead stop in the middle of a business day.

This is a very simplistic description of the issues but it helps to illustrates both the perceived obstacles to the thin-client solution and the efforts by those seeking to promote it to overcome those objections. The following technologies have been considered (etc etc).

Obviously this needs work but it might be all that many readers will want to know and could be followed by the subsequent plunge into the history/technology issues. --207.216.139.134 18:10, 24 September 2007 (UTC)

A real as opposed to perceived problem with thin clients is software. Most of the world uses Windows, a single user system which is quite unsuitable for terminal servers for thin clients. Windows uses RAM for each copy/instance of an application. GNU/Linux and UNIX operating systems use one copy of an application in RAM for all instances of the application in use on each server. This allows many more users/processes/applications to run on a GNU/Linux terminal server with the same resources as a Windows terminal server. Many users run a browser and a word processor. These applications may take 50 to 100 MB in RAM just for the application. User-data is in addition. Thus a UNIX system can run two to three times as many users as a Windows system and give good service. The negative FUD surrounding thin clients is related to inadequate hardware from early UNIX deployments and the current poor performance of Windows. GNU/Linux is a spectacular performer with thin clients. With multiple cores, gigabit and GNU/Linux, thin clients are extremely desirable in all but a few cases. Certainly we can state that blanket installation of thick clients is a wasteful and unnecessary solution. There is no advantage to paying for hardware, its maintenance and provisioning only to have thick clients idling.

Some numbers: In a computer lab with 24 thin clients, a single Xeon (2.4 gHz) terminal server running Debian Etch with 2 gB RAM idled most of the time and never was above 70% CPU utilization even with more than 700 processes in use. All the RAM was put to use. Hundreds of megabytes of files were cached in RAM. Network load was typically less than 2MB/s but heavier graphic pages could reach 20MB/s. Two 100baseT NICs sufficed. As a thin client the machines used less than 64 MB of RAM and less than 1% of CPU. Users could observe no difference in performance between identical thick clients running XP compared to GNU/Linux after booting/loading applications.Pogson (talk) 12:40, 28 June 2008 (UTC)

Actually, Windows has not been single-user for some time. Windows NT with Terminal Server installed was multi-user ten years ago[1]. In Windows XP you had multiple users, and "fast switching" between them, without any additional software. I use Linux and I'm a big fan of it, but inaccurate advocacy does the Linux cause no favours.—greenrd (talk) 21:49, 28 June 2008 (UTC)

Greenerd is technically correct. I should have written that GNU/Linux and other UNIX OS were multi-user, conceptually, from the beginning. Windows was not, having a DOS base in the '9x versions. The single-user features of Windows that still remain: no shared memory, and a very complex API which opens many edges to exploit by mal-ware. The lack of shared memory severely limits the number of simultaneous users on a system. The complex API means the load on the processor is higher per user as well. Security is a much more difficult task in Windows because there are so many vectors to attack. So, the multi-user capability of Windows may seem effective to a few users who can use the same thick client, but it does not scale well to terminal servers. This can be seen in tests which max-out a server with 30 users in Windows but is quite comfortable with 50 users in a UNIX OS. A further complexity of Windows with multiple users is the EULA. A maximum of ten devices are allowed to connect and use the software by default. There is a direct cost per seat of connecting more thin clients to Windows whereas GNU/Linux has not except for a modest share of memory. Pogson (talk) 12:09, 5 July 2008 (UTC)

Thin clients vs. Terminals redux

Most of this article has slightly missed the difference between a graphical terminal and a thin client. A terminal is an I/O device which provides resources to the server whereas a client is a device which uses resources provided by the server. RDP/X11/VNC are terminal protocols, not thin client protocols. A "thin client" runs minimal application logic, and a terminal runs NO application logic. In general, a thin client runs the UI logic while the server does the processing.

If one were to find the first historical implementation of a thin client, the IBM 3270 would be a good place to look rather than X terminals.

Not sure a "smart terminal" is equivalent to a "thin client", or that your definition of a terminal vs a client is entirely correct. Gorbag42 (talk) 03:42, 16 December 2016 (UTC)

Please add a section describing the use of thin clients for bridging digital divide

As projects as Ndiyo and Nstar are doing just that (using it to bridge the Digital divide, this should be added in the article. —Preceding unsigned comment added by 87.64.160.129 (talk) 10:05, 2 January 2008 (UTC)

Disadvantages

Are there any disadvantages to the Thin Client or the Thick Client? I have to look up both the advantages and the disadvantages for a school project but I couldn't find any disadvantages. --Destructo^{Talk to me} 01:38, 19 March 2008 (UTC)

I have been using thin clients for five years and see few disadvantages in most cases. Everything about system maintenance is far easier using thin clients. The cost of the box is way less because there is so much less in it. However, asking a server to send full screen video to every client is impossible for more than a few. At 1024x768, video takes 3 bytes per pixel, nearly 3 MB/s of bandwidth. 100 baseT can handle 4 instances of such video. 1000baseT can do better but the server will be a bottleneck at some level. I get by using a projector in rooms where everyone needs to see the same video. If an organization uses full-screen video regularly thin clients are not useful unless there are only a few clients per server. The usual Flash while browsing is a problem but not everyone always visits sites with Flash videos running. The law of averages works. If you have enough users, the load on the system will follow a repeatable pattern and the system admin can cope with approaches to bottlenecks by adding servers, network bandwidth or even giving particular users their own thick client or server cluster. I even recommend using a thin client as a portal to a cluster because no one wants kilowatts/decibels dumped into their office space.Pogson (talk) 12:58, 28 June 2008 (UTC)

I can understand why a Disadvantage section might be relevant, but why is there an "Advantages of thick clients" section in an article on thin clients? Most of it is FUD except for better multimedia. Even that is related to bandwidth which is a network/server problem, nothing essentially characteristic of thin clients. Lots of folks do some full-screen video at 100 mb/s and there are thin clients that do 1000 mb/s. Pogson (talk) 14:38, 28 June 2008 (UTC)

It's just another way of talking about the same thing. In terms of my personal contributions (I did not write all of this) I was comparing two things, thin clients and thick clients - therefore any advantage of a thick client over a thin client must be, logically, a disadvantage of a thin client compared to a thick client. As for FUD, again personally speaking, that was not my intention: I was just trying to give a quick overview of possible pitfalls. You're quite right that video can be done in some scenarios. Feel free to improve the current text!—greenrd (talk) 21:19, 28 June 2008 (UTC)

Agree that there should be more here, in particular there is no reference in the history section as to WHY PCs became popular in businesses and WHY business IT departments tried (unsuccessfully) in the late 80s to get everyone to move to a thin client. In particular, the revolt was against IT departments controlling the software that could be run, so individual departments bought PCs so they would have the control, not IT (who ran the databases and mainframes). IT has been trying to foist thin and cloud off on users ever since to regain control. Resist! Gorbag42 (talk) 03:45, 16 December 2016 (UTC)

Lower Network Bandwidth

TFA gives a good explanation but misses on video. The x window system does use very little bandwidth for the usual word-processing and browsing applications which update only changed portions of the screen. However, full-screen video changes almost every pixel on every frame which is why thin clients are not recommended for full-screen video. Thin client systems can handle full-screen video but with a serious reduction in clients per server. They are still more economical than thick clients even with only a few clients per server. One can keep video bandwidth off the LAN by placing a terminal server near the thin clients. That still costs less, and produces less heat and noise than a thick client for each user. Network bandwidth is not only a characteristic of thin clients but of the complete system. One can make a thick client using one terminal server and one thin client, in which case one gets all of the purported advantages of thick clients but only some of the advantages of thin clients without changing the network bandwidth if the server is close to the client. If one puts four thin clients on that server, the LAN will see very little increase in traffic if all watch the same video from Youtube but as thick clients would pull in four times the bandwidth.Pogson (talk) 13:45, 28 June 2008 (UTC)

I don't think your Youtube example is correct. Surely, regardless of whether the browser processes were running on the same machine or on separate thick clients, each browser process would download a separate copy of the video - unless a caching proxy server is used, but that can be used with either thick or thin clients.—greenrd (talk) 21:33, 28 June 2008 (UTC)

Yes but a thick client might use local caching, while a thin one might not. Ovi 1 (talk) 12:08, 15 July 2009 (UTC)

Thin Client vs Virtual Client

I feel this page is highly inconstant, the concept of a thin client seems to vary throughout the page. I would suggest breaking this section up int Thin Client and Virtual Client.

The definition section has 2 directly contradictory statements, The first describing what i understand as thin client, "designed to be especially small so that the bulk of the data processing occurs on the server. The embedded OS in a thin client is stored in a "flash drive", in a Disk on Module (DOM), or is downloaded over the network at boot-up", like the current HP thin clients which have there own modest hardware including a low power CPU, some system memory(RAM) and some flash memory and are capable of running the operating system, as well as some local programs like internet browsers and some media applications.

The second "Thin client (computing): A server-centric computing model in which the application software, data, and CPU power resides on a network server rather than on the client computer." i feel the second is more a definition of a virtual client something like a Sun Ray Client, which essentially have no system memory, and the "cpu" is little more than BIOS and network data processor, they are essential a NIC and a GPU in a box or now often built into the screen.

There are numerous other examples where this definition miss match is evident including a section touting "zero clients" as the latest concept, then describing the same Sun Ray client i was using 10 years ago.

There is a lot of other information which is weak, speculative or argumentative so a lot needs to be tidied up and whats left should be referenced

I propose the definition of thin client and virtual client be discussed so they can be formalized then everything can be reviewed and anything which can be salvaged should be chopped up into the 2 sections, i think a virtual client is fairly definable, thin client much less so as it's more of a concept than fixed hardware design, but at least if we can filter out what definitely isnt a thin client this page can be made a lot more consistent. Ging84 (talk) 23:25, 2 July 2008 (UTC)

Rewording of certain sentences

• Just made a small change in the second paragraph of the introduction section.
  Before - In a thin client/server system, the software for the user interface is installed on the thin client, some frequently/heavily used applications, and a networked operating system and nothing else.
  After - In a thin client/server system, the only software that is installed on the thin client is the user interface, certain frequently used applications, and a networked operating system.
  --139.147.113.155 (talk) 06:03, 8 November 2008 (UTC)

The truth about thin clients.

Thin clients are simply ordinary PCs running a variety of boot programs that allow the user to log on to a range of servers running a variety of software, or run cut-down versions of applications such as web-browsers.

If wanted, the O/S can be downloaded from a server or from any local drive.

The confusion of booting the bootstrap programs that log-on to servers and boot downloads is unnecessary.

You simply should be able to choose your method of further booting at the time of boot.

The confusion is orchestrated by people who want to proprietise this area of software and hardware.

If you go on sites run by thin client companies, you will find a maze of concealed technical data and obfuscation.

If we look at cloud computing, we can see that it doesn't really matter where you get your operating system or applications. A web browser is-a web browser. A word-processor is a word processor.

The only thing that matters is that the user is not charged more than a pitance for using software developed freely, which runs on simple computers. Of course, your home PC can be set to boot as a thin client. —Preceding unsigned comment added by Richk2301 (talk • contribs) 11:09, 12 April 2009 (UTC)

UNIX

Not enough UNIX. That's weird considering it is and was the 'thin-client'-oriented OS all the time. Moar unix nao! —Preceding unsigned comment added by 86.110.185.136 (talk) 12:46, 9 July 2009 (UTC)

License issues?

Should the article mention license issues associated with thin clients? A number of thin client servers (Especially Windows Terminal Services and Citrix ICA Server) have high licensing costs compared to a fat client. Additionally, software installed on the thin client server may have specific terms in their licenses relating to use with thin clients. Spinner2189 (talk) 20:51, 25 October 2009 (UTC)

OS and UI

The Article states: The most common sort of modern thin client is a low-end microcomputer which concentrates solely on providing a graphical user interface to the end-user. The remaining functionality, in particular the operating system, is provided by the server. Isn't the usuall work that the OS runs on the thinclient as well (example the OS like Linux kernel) with small set of system programs (DHCP, X11 etc) what shows all other software from server what runs there (desktop environment, window manager, application programs etc)? --Golftheman (talk) 14:08, 17 November 2009 (UTC)

External Links

Now someone has decided to remove the external links and I could not understand it. I think that there are no more than 4 or 5 open source proyects related to thin client technology, and surely those links may be interesting. —Preceding unsigned comment added by Jmartinezmateo (talk • contribs) 20:27, 27 January 2010 (UTC)

I have removed the other links as well. Such link are not in line with e.g. 'What Wikipedia is not' - Not an internet directory, and not with parts of 'Links normally to be avoided'. That link would be appropriate only on the page en:Lan Core, if that article is notable enough to exist (please see the Business FAQ and the Conflict of Interest guideline for more information for that). These guidelines are mainly for the English Wikipedia, but please be aware that similar exist on many other wikis (you might be able to find them through the interwiki links, though that list is not necessarily complete), and that Wikipedia is foremost an encyclopedia, not a place to promote something. I hope this explains. --Dirk Beetstra ^{T C} (en: U, T) 10:05, 27 January 2010 (UTC)

I see, you propose to write, for example, about of operating systems without naming Windows, Linux or Solaris (among others). Well, I have a different point of view. Please, could you tell me what is your background in thin client technology? I suppose that you must be an expert in order to remove those three projects from a thin client article. —Preceding unsigned comment added by 80.30.182.180 (talk) 13:19, 28 January 2010 (UTC)

No need for that, the links fail our policies and guidelines, en:Windows, en:Linux, en:Unix, en:Solaris, to name a few, have their own articles, and as you see, the official link of the producer is there. If you go to en:Computer, you don't see links to the websites of the companies, they are internal links.

So, does your external link belong on en:Thin client? Well, clearly not, your link belongs on en:Lan Core, and a wikilink to en:Lan Core may belong on en:Thin client (though you will see that on en:Computer not every possible operating system is named.

In any case, if you think that I am wrong, you are free to post on the talkpages, making your case why you think that inclusion is warranted, and then wait to see if others agree. Thanks. --Dirk Beetstra ^{T C} (en: U, T) 13:53, 28 January 2010 (UTC)

Just look at the result: a thin client article (http://wiki.riteme.site/wiki/Thin_client) without any reference to, for example, the Linux Terminal Server Project (LTSP, http://wiki.riteme.site/wiki/Linux_Terminal_Server_Project). Why? Because you have removed every link without review the article, without review those links, and surely without a minimum background in thin client technology. Do you know how old is the LTSP project? Do you know its impact? Do you know its importance/significance? —Preceding unsigned comment added by Jmartinezmateo (talk • contribs) 15:10, 28 January 2010 (UTC)

Advertising

"""Although in practice redundancy is provided both in the form of additional connectivity from server to the network as well as the servers themselves, using features like VMWare High Availability and Fault Tolerance or Citrix XenApp's load balancing."""

This looks like advertisements of a product. —Preceding unsigned comment added by 86.166.248.142 (talk) 03:20, 17 March 2011 (UTC)

Network computer

The lead currently begins A thin client (sometimes also called a lean or slim client) is [...] while a sentence in the Network Computer lead states The term, today, is also used somewhat interchangeably to describe a diskless desktop computer or a thin client. I therefore propose a mention of the term 'Network computer' (but importantly not 'Network Computer') in the lead of thin client.

Doing so would mean that network computer could be meaningfully redirected here in the future (if there is consensus) - but that would also probably mean the inclusion of a hatnote mentioning Network Computer. --Trevj (talk) 05:19, 13 June 2011 (UTC)

Further related discussion is at Talk:Network computer#Article content. --Trevj (talk) 13:44, 24 June 2011 (UTC)

File:Sun Ray Thin Client.jpg Nominated for Deletion

	An image used in this article, File:Sun Ray Thin Client.jpg, has been nominated for deletion at Wikimedia Commons in the following category: Deletion requests August 2011 What should I do?
	A discussion will now take place over on Commons about whether to remove the file. If you feel the deletion can be contested then please do so (commons:COM:SPEEDY has further information). Otherwise consider finding a replacement image before deletion occurs. This notification is provided by a Bot --CommonsNotificationBot (talk) 02:34, 3 August 2011 (UTC)

Clarification, confusion, maybe content?

From what I've heard in the context of clinical trials, the term "thin client" means a data system where the user directly modifies the fields in a database, as opposed to a "thick client" where the user has a separate program which typically acts as a gatekeeper of some sort (traditional case repot forms that go through data entry are functionally a type of "thick" client). This type of "thin" client is broadly similiar to the concept described in this article, where everything is kept centrally and the users interact with that central object, but the "client" in each of the cases I'm talking about is not a piece of hardware, it's typically a piece of software (typically web-based). Is this an unusual aberration for a specialized field, or is this type of terminology used broadly and is the Wikipedia article too focused on the hardware meaning and neglecting the software meaning? Am I just confused or missing something? 150.148.0.65 (talk) 17:44, 25 September 2012 (UTC)

ChromeBooks and ChromeOS is not a Thinclient

ChromeOS is basically a stand alone computer that only offers a browser. This article roughly defines Thiclient as "an end-user computing device which depends heavily on some other computer (its server) to function" the proceeds to cite ChromeBooks as a thinclient. ChromeBooks offer just one local application (browser) but if they are a thinclient so is any computing device that offers a browser -- which today is pretty much every computing device on the planet (making the category of thinclient useless).

ChromeOS and the whole category of "web thinclients" should be removed. They as they are really their own thing (they don't rely on a specific server to function) and probably belong in their own page as their own category --- say "browser kiosk" or "browser only OS" or something like that. — Preceding unsigned comment added by 184.71.250.14 (talk) 18:27, 23 September 2013 (UTC)

• The above comment is 8 years old, ChromeOS (Chromebooks etc) have evolved, they no longer fit the description in the articles 1st paragraph: "Web clients only provide a web browser, and rely on web apps to provide general-purpose computing functionality." Since 2017/2018 they also runs Android and full-fledged Linux apps. Since 2014 or earlier many of the web apps can work offline. Programs that that people incorrectly assume are web based only such as Gmail, Google Calendar, Google Keep, and Google Drive actually can work offline and do/will run locally, even Google Play video content is available offline accessing locally stored media. I will be bold and go ahead and modify/remove ChromeOS / Chromebooks from that section as I see the date of this section is 8 years old.--12think (talk) 00:47, 16 August 2021 (UTC)

To clarify: ChromeOS devices never actually fit the description of a thin client. Yes, they incorporated some of the ideas (low-power hardware, large degree of integration with cloud), but they could also be used as a regular offline device. Thin client, by definition does can not function without a server since thin client does not maintain state (user data). Some thin clients even boot from network. If anything, ChromeOS is a Rich client. Anton.bersh (talk) 22:19, 12 February 2022 (UTC)

The so-called "list of protocols used by thin clients"

Hey. I just deleted a section from the article whose title was "list of protocols used by thin clients". In fact, it was a list of random items; not everything in it was a network protocol or any other type of protocol.

For example, XML, HTML, and JSON are not protocols; they are file formats. HP RGS, X11 and Linux Terminal Server Project are computer programs, not protocols. "Various video codecs" is both not a protocol and a bunch of weasel words.

The second problem is the lack of citations proving the claims. I really doubt thin clients use XML, HTML or JSON; where is the source for that? Is there even such a thing as a "VMware Blast Extreme" protocol?

5.75.16.158 (talk) 05:39, 12 August 2018 (UTC)

"lightweight"

I've just tagged this term in the lead. I do not know much about the topic, but it is my understanding that the primary distinction here is that a thin client is essentially a terminal; that other units connected to the network are doing most of the processing. As a result, I think this is meant to imply that it is a computer with limited processing power, not that it is necessarily light in weight.

Again, I don't know and for someone like me -- a lightweight in terms of technical knowledge -- the wording is not clear. - SummerPhD^v2.0 16:33, 7 March 2020 (UTC)

Hardware and History updates

I added mentions of Raspberry Pi as it was missing from the article. Raspberry Pis have been adopted as a form factor for thin clients since at least 2013 and several of the thin client providers listed in the article also make Raspberry Pi variants. I inserted a couple sentences in the Hardware section and the History section, respectively. I also added a couple more citations and links to expand the list of references. Fairwin99 (talk) 21:00, 25 July 2022 (UTC)

Cheikh Kane 2600:387:15:813:0:0:0:7 (talk) 18:09, 17 October 2023 (UTC)