![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
![]() | This article is substantially duplicated by a piece in an external publication. Please do not flag this article as a copyright violation of the following source:
|
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)
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)
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)
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.
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)
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)
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 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)
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)
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)
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)
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)
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 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)
Just look at the result: a thin client article ( http://en.wikipedia.org/wiki/Thin_client) without any reference to, for example, the Linux Terminal Server Project (LTSP, http://en.wikipedia.org/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)
"""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)
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)
![]() |
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
|
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) |
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)
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)
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)
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)
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)
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
![]() | This article is substantially duplicated by a piece in an external publication. Please do not flag this article as a copyright violation of the following source:
|
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)
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)
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)
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.
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)
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)
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 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)
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)
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)
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)
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)
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 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)
Just look at the result: a thin client article ( http://en.wikipedia.org/wiki/Thin_client) without any reference to, for example, the Linux Terminal Server Project (LTSP, http://en.wikipedia.org/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)
"""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)
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)
![]() |
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
|
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) |
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)
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)
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)
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)
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)