Thin Client In client/server applications, is a client designed to be especially small so that the bulk of the data processing occurs on the server. Although the term thin client usually refers to software, it is increasingly used for computers, such as network computers andNet PCs, that are designed to serve as the clients for client/server architectures. A thin client is a network computer without a hard disk drive, whereas a fat client includes a disk drive. A Thin Client PC is a computer that depends heavily on some other computer (its server) to fulfill its computational roles. This is different from the traditional fat client, which is a computer designed to take on these roles by itself. The specific roles assumed by the server may vary, from providing data persistence (for example, for diskless nodes) to actual information processing on the client’s behalf.
Thin clients occur as components of a broader computer infrastructure, where many clients share their computations with the same server. As such, thin client infrastructures can be viewed as providing some computing service via several user interfaces. This is desirable in contexts where individual fat clients have much more functionality or power than the infrastructure requires.
Thin-client computing is also a way of easily maintaining computational services at a reduced total cost of ownership. The most common type of modern thin client is a low-end computer terminal which only provides a graphical user interface – or more recently, in some cases, a web browser – to the end user.
What are thin clients?
A thin client is a general term for a device that relies on a server to operate. It provides a display
device, keyboard and mouse and basic processing power in order to interact with the server. A thin
client device contains no moving parts such as fans or hard drives (in the case of a dedicated thin
client device). It does not store any of the data locally – it is very thin in features and functionality –
hence the term ‘thin client’.
A thin client often does not contain local storage and requires little processing resources. Thin client
hardware can be a converted old PC, a new dedicated thin client device or simply a new low cost PC
with a thin client OS installed.
Thin clients present a user with the same look and feel of a traditional desktop and can run any
software – Windows, Linux, UNIX, Mainframe, Java, etc. – allowing for easy integration with the
existing IT solution.
Reduced administration and end user support – Thin clients are far simpler to manage since the thin
Benefits from thin client computing:
High-security areas where data protection and security are important such as government offices,
law firms, etc.
Public use facilities such as Internet cafes which are virus-prone.
Environments with a tendency to user tampering such as public libraries and schools.
Companies that need to integrate different IT environments quickly, for example, when undergoing
a merger or purchase.
Desktops with frequent data and/or application changes.
Environments which cannot afford desktop downtime such as an airline check-in desk.
Companies with mobile workers who need access from anywhere.
Environments with complex software license management.
Administrative workers and support staff.
Re-purposing a PC as a thin client
The following options allow a PC to be used as a thin client – in some cases, even if it has no working hard drive:
Linux Terminal Server Project
Thinstation
OpenThinClient
AnywhereTS
Remote desktop software
2X ThinClient
Ultra-thin client, Zero client, or Clientless
Traditionally, a thin client ran a full operating system for the purposes of connecting to other computers. Some thin clients, such as the Sun Ray, use a simpler protocol for communicating display updates, and these are sometimes called ultra-thin clients or a zero clients, Their tiny operating systems merely initialize the network, begin the networking protocol, handle display of the server’s output, and transmit user input events. The full desktop is run remotely and the displayed graphics and text are compressed with either a remote display protocol such as PCoIP, or even just a video codec such as VP9 or Daala, and sent to the zero client. The client silicon is now much simpler and lower cost as all it requires is a video decoder and basic I/O.
RTE client
A Run Time Environment (RTE) client contains task specific applications (e.g. Mozilla Firefox for Internet browsing) and only the minimal (often customized) underlying and supporting code (BIOS, firmware, kernel, libraries, plug-ins, etc.) to run only those applications. It contains all and only the code needed to accomplish its specific task, thus it is more than a zero client but less than a typical thin client computer. The RTE client does not have a general purpose operating system – it usually lacks shells (terminal windows), is not designed to be patched (updated online), has minimal connectivity to external resources, and is often found in read-only media (e.g. tamper resistant ROM chips, CD-ROM, etc.). Attempts to inject or run any other applications/processes/threads results in crashing the kernel (system). Due to the need to physically update the device, RTE clients are mostly found in stable environments demanding high security.
Web thin client
Web thin clients only provide a web browser, and rely on web applications to provide general-purpose computing functionality. However, note that web applications may use web storage to store some data locally, e.g. for “offline mode”, and they can perform significant processing tasks as well. Rich Internet Applications for instance may cross the boundary, and HTML5 Web Applications can leverage browsers as run-time environments through the use of a cache manifest or so called “packaged apps” (in Firefox OS and Chrome).
Examples of web thin clients include Chromebooks and Chromeboxes (which run Chrome OS) and phones running Firefox OS.
Chromebooks and Chromeboxes also have the capability of remote desktop using the free Chrome Remote Desktop browser extension, which means, other than being a web thin client, they can also be used as an ultra-thin client (see above) to access PC or Mac applications that do not run on the Chromebook directly. Indeed, they can be used as a web thin client and an ultra-thin-client simultaneously, with the user switching between web browser and PC or Mac application windows with a click.
Chromebooks are also able to store user documents locally – though, with the exception of media files (which have a dedicated player application to play them), all such files can only be opened and processed with web applications, since traditional desktop applications cannot be installed in Chrome OS.
Web thin clients are similar to RTE clients, but unlike first-generation RTE clients the operating system can typically be updated. Chrome OS, for example, automatically updates itself if its update servers (which are hosted by Google) are not blocked by a firewall – while still being tamper-resistant due to its use of Trusted Computing technologies.
Applications as thin clients
The notion of a thin client extends indirectly to any client–server architecture, in which case, a thin client application is simply one which relies on its server to process most or all of its business logic. This idiom is relatively common for computer security reasons. A client obviously cannot be trusted with the logic that determines how trustworthy they are, because an adversary can circumvent that logic. However, in web development in particular, many client applications are becoming fatter. This is due to the adoption of heavily client-side technologies like Flash and Ajax, which are themselves strongly driven by the highly interactive nature of Web 2.0 applications.
Contact Alpha Computer Group for all of your Thin Client needs @ (877) 608 – 8647
Planning guide for the stated service area
How to evaluate thin client computing
The strongest project scope explains what must work, who relies on it, and how completion will be tested. This page from Alpha Computer Group treats Thin Client Computing as a specific planning subject rather than a repeated location phrase.
Begin with the users and operations that depend on the outcome. Document existing systems, recurring problems, required availability, security expectations, current vendors, account ownership, physical limitations, business deadlines, and the evidence that will prove the change is complete. Account ownership, carrier timing, site access, existing wiring, and user availability may affect the schedule as much as equipment delivery.
Thin: discovery
Inventory devices, services, users, locations, integrations, permissions, contracts, support contacts, and known defects related to thin client computing. Mark each unknown that requires a survey, administrator access, carrier confirmation, or stakeholder decision.
Client: comparison
Ask every provider to address the same facts. Separate required capabilities from optional features, and compare one-time work, recurring costs, prerequisites, exclusions, training, warranties, support hours, and the effort required for later changes.
Computing: acceptance
Write observable tests before implementation. Identify who attends, what evidence is recorded, how failed checks are corrected, and when responsibility changes from the project team to ongoing support.
A focused checklist for Thin Client Computing
- Describe the business outcome connected to Thin, including the people and workflows affected.
- Record quantities, locations, ownership, and current limitations for Client.
- Confirm how Computing will be configured, secured, tested, documented, and explained.
- Identify dependencies involving Continuity, site access, external vendors, carriers, or unavailable records.
- Define the fallback if Documentation is delayed or an acceptance check fails.
- Assign ongoing responsibility for Support, routine changes, urgent incidents, and future review.
What a complete proposal should show
Look for equipment, licensing, labor, configuration, coordination, testing, documentation, training, taxes, recurring charges, assumptions, exclusions, and optional work to be clearly separated. The proposal should explain how existing operations are protected and how the result will be supported.
Planning questions
What must remain operational?
List busy periods, critical users, customer-facing functions, compliance needs, shared resources, and acceptable interruption windows. This guides staging and rollback decisions for thin client computing.
Who owns each dependency?
Assign customer, provider, carrier, software vendor, landlord, contractor, and internal approver responsibilities. A named owner and due date are more useful than assuming another party will handle the task.
What happens after launch?
The customer should leave the project able to request help, authorize changes, verify future work, and recover essential information. That makes the finished work maintainable and reduces dependence on memory.
Decision notes specific to Thin Client Computing
The following prompts use the exact page subject, thin client computing, to keep this the stated service area discussion distinct from a general technology overview.
While proposals are being compared for thin client computing, record the operational pain points connected to thin client computing. The same information later helps support staff understand why the selected design differs from a generic configuration. For schedule control involving Thin, protect administrative accounts and record who receives continuing access. That control makes exceptions visible while there is still time to choose a response.
During internal planning for thin client computing, identify the records and diagrams still missing from thin client computing. This makes tradeoffs easier to explain to both technical reviewers and the people approving the expense. For documentation quality involving Client, capture test results in a form the customer can retain. This makes schedule changes and added cost easier to approve or reject responsibly.
During early discovery for thin client computing, compare required outcomes with optional features for thin client computing. The discovery record becomes the source for scheduling, change approval, testing, documentation, and handoff. For service continuity involving Computing, require each important claim to map to an observable acceptance check. A written control also makes the implementation easier to review without relying on memory.
Before a migration date is selected for thin client computing, write the measurable outcome expected from thin client computing. That record gives reviewers a common baseline and prevents each proposal from answering a different question. For vendor coordination involving Continuity, document exclusions and optional work beside the related requirement. It becomes especially useful when several organizations share responsibility for the outcome.
As acceptance tests are drafted for thin client computing, map the busiest workflows that depend on thin client computing. Decision makers can then compare implementation effort, recurring cost, risk, and support on equal terms. For change management involving Documentation, define how routine requests differ from urgent incident escalation. This keeps urgency from replacing judgment during a cutover or on-site visit.
At the site-review stage for thin client computing, separate confirmed facts from assumptions surrounding thin client computing. This approach keeps the discussion tied to operating needs rather than a list of features with no stated priority. For implementation risk involving Support, stage disruptive work around real operating hours and customer commitments. This prevents a small uncertainty from silently becoming the critical path.
Contact Alpha Computer Group to discuss the facts, constraints, and priorities behind this requirement. Do not send passwords or other sensitive account information through a website form.
Editorial reference 7BC6BD42C5 · Record 384 · thin-client-computing