'Dumb Terminals' Can Be a Smart Move for Companies

Carl Bialik from WSJ writes "More companies are forgoing desktop and laptop computers for dumb terminals — reversing a trend toward powerful individual machines that has been in motion for two decades, the Wall Street Journal reports. 'Because the terminals have no moving parts such as fans or hard drives that can break, the machines typically require less maintenance and last longer than PCs. Mark Margevicius, an analyst at research firm Gartner Inc., estimates companies can save 10% to 40% in computer-management costs when switching to terminals from desktops. In addition, the basic terminals appear to offer improved security. Because the systems are designed to keep data on a server, sensitive information isn't lost if a terminal gets lost, stolen or damaged. And if security programs or other applications need to be updated, the new software is installed on only the central servers, rather than on all the individual PCs scattered throughout a network.'"

Comments

Not good for large installations.

[Short Circuit]

Sounds like it would introduce a single point of failure. One malicious user or virus, and the sytem goes down for everyone. Plus, software needed by different groups often doesn't play well together, leading to irritating misbehavior. Plus, netwo

I wouldn't want something like this campus-wide.

I could see having one terminal server for each department or lab, though. Not only would that localize failures and software requirements, but you wouldn't need to invest in upgrading your existing network infrastructure.

Re:Not good for large installations.

[brunascle]

my school actually did have this pretty much campus wide. or at least most of the computer labs were terminals.

it wasnt too bad except for the bandwidth (slower response time than a desktop).

Re:Not good for large installations.

[delymyth]

In a company like the one I work for, where users use anyway all the same applications, this would be great.
No need to reinstall clients, no need to change broken fans and hard drives and search the whole office for a spare dvd player just to install the operating system into a machine.

Right now it takes me about 2 to 3 hours (4 in the worse cases) to get a client machine ready for the user, and we already have centralized /home directories.
Switching to thin clients could cost a little bit more when it comes to servers, but surely it will be less time-consuming when installing clients (no need for installation) and supporting users (one-time server-side install for all OO.org dictionaries and other applications).

And, most of all, I wouldn't have all the "version inconsistencies" I have right now across the network clients, where one has application X version Y and the other a newer or older version (and plugin problems because of this).
Oh, sure, people won't be able to install their own stuff, but they already can't do it anyway ;-)

Re:Not good for large installations.

[bev_tech_rob]

If you lock down the server and no users have admin rights (except IT), then no danger of viruses, malware, etc. We support over 200 facilities using Citrix (with users either accessing via workstations with only the OS and a Citrix client installed or a thin client (Windows Imbedded), no problems with malware from end users since they don't have rights to install anything. You do have a point about the single point of failure. If one server goes down, many users can be affected. As well as in our case, each site is connected to corporate via a dedicated circuit. If the connection goes down, the site goes down. But our communications vendor actively monitors the connections and immediately starts work to correct outage (which typically only lasts a few minutes)..

Re:Not good for large installations.

[AKAImBatman]

Sounds like it would introduce a single point of failure.

It works both ways. A single point of failure becomes a single point of security. So it's a lot easier to make sure that everyone has the latest patches, and that the system is fully locked down. Besides, you rarely have only one server. You usually have a cluster of servers providing service to the users with the home directories on the network. If one goes bad, you can take it down and do maintenence on it while the users who were using it just log into a different server.

The truth is that there are very few business units that actually need their own desktop machines. The problem is that we developers are some of the few who actually need workstations, meaning that we often fail to push the best solution for the company as a whole. :)

Re:Not good for large installations.

[Anonymous Coward]

oi twit - multiple servers for failover and load balancing

Re:Not good for large installations.

[Anonymous Coward]

I understand your points about the network being a single point of failure but in a traditional client/server enviroment with a network down, clients wouldn't be able to attach to network storage to complete their tasks anyway. Given that in most corporate networks most work is performed in congunction with shared files, email or network printers the screens almost may as well be black for the amount of work they could do without an operational network to support them.

Also in terms of single point of failure. Anybody deploying a thin client solution would be strongly considering failover redundancy and load balancing across multiple application servers. Which can of course be placed at different points around the network infrastructure.

There are other issues to consider however. One biggy is that with MS Terminal server there is no saving on licensing (i.e just because you are running terminal server doesn't automatically mean that you could move to a concurrent licensing model) Plus to make it work really well you need to invest in third party products to suppliment Microsoft Terminal server.

Re:Not good for large installations.

[Frumious Wombat]

Actually, it isn't. If you're doing this right, then you've set up some form of clustering and failover with redundant machines, the same way you run RAID arrays rather than single huge disks, or don't base large commercial web-sites on one standalone machine. If you add in that now the end-user can't access the server, even indirectly (no cd-rom, ports, etc), and the devices lack moving parts like harddrives, then cost of management goes way down. In the end, this is actually ideal for large companies. Having supported stand-alone desktops in a small environment (60 desktop systems), I would say that unless you're harnessing the compute power of those desktops when they're not being used (Folding@Pfizer, for instance) then the cross-over point of easier is around 2-4 machines for Windows, maybe 8 for Unix.

I saw U. of Chicago do this with SunRays years ago for public spaces in the library, and it works beautifully for anything other than intensive 3-d rendering. Unfortunately, too many IT departments are dominated by people who only look at the up-front cost (I can buy a PC for what that thin-client costs), and not the entire life-cycle.

Re:Not good for large installations.

[Short Circuit]

For some of the situations I work in, you can't completely lock down the user accounts. Some software is simply written that poorly. (Take, for example, the Gordon Food Service client. Saves all data to the hard disk, in a specific place. No user-accessible option to save it somewhere else.)

Re:Not good for large installations.

[Silver Sloth]

I wouldn't want something like this campus-wide. This is about business computing. We have hundreds of users using PCs for Three Layer Applications where the PC is effectively acting as a dumb terminal. It isn't that long ago (12 years or so) that we ditched the row upon row of Wyse 370s, and now they may be back again. The old mainframe has been replaced by Unix servers but the principle is the same.

One malicious user or virus How can they, they're only allowed to get to what I let them (ahhh, the good old days), there's no more usb ports, no more downloading stuff from the internet, the user gets the applications and access they need and no more.

In an achedemic environment I agree with you, but, here in the business world, 90% of users are quite happy with a dumb terminal with one dedicated application - think airline checkin desks.

Re:Not good for large installations.

[tinkerghost]

I think you're a little backwards. This is perfect for large installations - under specific requirements.

1. Competent IT/management
2. Limited variety in software between departments
3. Software writen for thin-client/server environment

Software writen for server or thin-client environments is designed from the ground up to not interfier with other software, so proper software selection goes a long ways towards making sure that this type of project will work at all. Also note that this isn't about completely eliminating workstations/PCs it's about replacing them where it's not needed. Got a secretary pool of 40 and a call center with 200 stations? That's 240 fewer HD's to re-image after a virus gets past your defences. The Secretary for the VP of Marketing still keeps her PC since she is going to have to open/work with image files that no other secretary will.

My last scan of thin-client tech showed that a client server ration of 150:1 is possible for moderate level usage, with it dropping as low as 25:1 for specialized software that's resource intensive. For a 250-300 seat call center, 2 servers can cover the whole floor. Add in the added security of dumb terminals - no vector for USB thumbdrives, floppys, or CD burners to be used to steal data or inject a virus, and the ease of configuring them - usually you either turn them on & DHCP takes care of them or you point them at a server, and it's a winning combination for IT workload and Data Security.

Re:Not good for large installations.

[Short Circuit]

This is about business computing. Microsoft has a campus. Google has a campus. IBM has several campuses. X-Rite's campus is just a few miles from me. These are not educational facilities.

How can they, they're only allowed to get to what I let them (ahhh, the good old days), there's no more usb ports, no more downloading stuff from the internet, the user gets the applications and access they need and no more. Let me know when you can guard against every vulnerability before it's announced. Drive-by website malware, network worms and email viruses aren't necessarily eliminated just because you've switched to a locked-down terminal server.

Re:Not good for large installations.

[pipatron]

One biggy is that with MS Terminal server there is no saving on licensing (i.e just because you are running terminal server doesn't automatically mean that you could move to a concurrent licensing model) Plus to make it work really well you need to invest in third party products to suppliment Microsoft Terminal server.

You could also move to an operating system built from the ground with this kind of usage in mind, for example Linux. Then you can stop worry about licensing too.

Re:Not good for large installations.

[Anonymous Coward]

What you need to be doing is using images (or remote install pxe) either of a dvd or share. No way you should spend that much time on restoring a pc.

Re:Not good for large installations.

[ggeens]

Last year, I worked for an organization that was looking into a thin-client solution.

This organization (unemployment agency) has a large number of offices around the country, connected to the central servers by ISDN lines (or ADSL at best).

Their current workstations are running Windows XP. Each time a user logs in, the machine checks for updates with the central servers. Any significant update makes the machine unusable for a long time while it downloads the new software over a slow link.

The servers are Solaris. If they decide to roll out a thin-client solution, they will probably use Sun Rays.

Re:Not good for large installations.

[kiatoa]

What kind of terminals? vt100, xterminals or some sort of windows citrix or similar terminals? I've used all and with splitvt and screen I'd rather be on a 19200 vt100 terminal than a citrix terminal on a lously network. In all seriousness though for a lot of applications I think text only would make more sense than gui based. At the dentist the other day and the receptionist was going back and forth between the mouse and the keyboard. I think that if she had been forced to learn the , and similar keystrokes it would have saved a good two minutes for getting my data in the system.

Fancy new stuff ain't necessarily better for everything.

Re:Not good for large installations.

[Anonymous Coward]

Actually... The environment I'm in now used to have ALL dumb terminals in a network that covered about 1/3 the state of Ohio. They only went away from that system due to vendor pressure and buyouts in 2004. Of course, many of our clients had abandoned the dumb terminals in favor of Windows PCs with terminal emulation in the 90s during the PC boom. However, what they didn't understand and that they lost was the simplicity of configuration from an admin's point of view. Essentially a dumb terminal was much easier to swap out than a PC. You'd have a user back up and running in a few seconds not including the time to get a new terminal out.

With the decentralized approach of a PC, you now had users beginning to (mis)use the power of the local device for their own purposes depending on the policy of the local admin. With that (mis)use, you wound up with PCs that suddenly had a lot more value to the end-user, but not necessarily to the organization. So, when the PC would inevitably blow up or get replaced due to upgrades, the users would complain about what they perceived to be the important stuff that was now missing. You also got saddled with people making requests for software that they weren't able to use on dumb terminals and the associated evaluation to determine if it should be allowed. Wasted time in many cases (witness the people who want iTunes on their PCs).

There are definitely benefits to having decentralized desktop systems, but they have to be weighed against the type of organization and it's work. In our case, dumb terminals were perfect as the majority of our organization is in the public service arena. They don't need to be able to do a lot of extras that extend outside of their realm of experience. However, the desktop PC allows for them to do more than they should even though some of those functions may be relevant to work. Take web browsing for instance. You could proxy them so that they only go to approved sites that relate to their jobs, however in this arena, since they provide public service, there are times when hitting something that would be considered entertainment is quite appropriate. So for our organization, that doesn't work.

In addition, the vendor buyout/pressure I spoke of was what I see as a disastrous migration from a set of old character based applications to a poorly designed GUI application. One of the nicest things about a centralized model is that ALL the work is being done on a single system or cluster of systems in one place. The client is actually local to the server in terms of the actual application. So, if the network connection for the dumb terminal goes down, there is much less of a chance for partial transactions to hose the data as the local client can time out and the server process knows to stop or roll back the transaction.

The current system we have has a really stupid client that is local to the PC and talks in a proprietary fashion to the middle tier server. If the network connection goes down, the client just disappears with no notification to the server. The server (being of a poor design) has all sorts of cruft left over in process. This is apparent when the network connection returns and the client attempts to connect, but the server says the client is already connected and rejects any further connections from that user. The only saving grace is that the back end DB server is robust and knows how to manage its transactions properly to prevent things from getting hosed. The fact that they are now using this particular DB for the back end is relatively new as they used to use their own proprietary DB in the past which likely would have suffered corruption if it's designed like the rest of their software.

So my experience has been that centralization, especially on a non-Windows system, is the best way to go. I do it at home as well with Linux and VNC for the family desktops (as in virtual desktops, not real ones). I've been running that way for the past five years with no issues. My wife and daughter can e

Re:Not good for large installations.

[Anonymous Coward]

Dang it! I missed it in the preview. That should read ", "

Re:Not good for large installations.

[poot_rootbeer]

the added security of dumb terminals - no vector for USB thumbdrives, floppys, or CD burners

How do you think the keyboard and mouse are going to be attached to the terminal? Hardwired?

USB ports on terminals is a given. It will be up to access policies at the operating system level whether to allow removable storage devices to be mounted on these ports, and the CTO will be hearing a lot of compelling arguments as to why it should be allowed. Once one user has a storage device mounted, it could be all over.

Re:Not good for large installations.

[Alky_A]

The main problem I've seen with these systems is stupid people testing programs containing infinite loops and forgetting to shut them down. Way to take up 50% of the CPU capacity, ass hole.

Re:Not good for large installations.

[Chazmyrr]

Your cost of management goes down. Your hardware cost goes up. The thin clients cost the same as the PC but do a lot less. That means you probably need more servers. Which means more floor space, electricity, etc. Your network traffic probably goes up. That means additional cable runs, more switches, higher bandwidth connections to other sites, etc.

The numbers usually don't work out in favor of terminals.

Re:Not good for large installations.

[Ironsides]

Simple. Rremap that location to a directory in the user's directory. This should be doable in NTFS given some of the remaping things I've seen done. IT would have to set it up, but once done, that should fix the problem.

Re:Not good for large installations.

[Richard Steiner]

The disk of things like viruses, etc., depends on a whole array of factors including the hardware and OS being used, the amount of actual "access" a remote end-user has, etc.

There are still some types of applications (like mainframe airline reservation systems) which have never stopped being "green screen" applications (albeit often with an updated GUI or web interface), and some of those can run 100,000's of terminals concurrently and do so worldwide without issues.

Re:Not good for large installations.

[ErroneousBee]

I like to go for 100% myself.

I like to vary the loop amongst APF authorised tasks, a TSO user, CICS regions, batch, and occasionally a non-swappable system task.

Its been some years since I've taken down a running mainframe, though.

Re:Not good for large installations.

[Short Circuit]

I'll pass that along to the guy who prepares the ghost image. I think he hates it when I get advice from Slashdot. :-)

Re:Not good for large installations.

[Richard Steiner]

Argh. C/disk/risk/A (or s/disk/risk/, or whatever).

Re:Not good for large installations.

[tallguywithglasseson]

We have hundreds of users using PCs for Three Layer Applications where the PC is effectively acting as a dumb terminal

You're a dumb terminal.

Re:Not good for large installations.

[Hal_Porter]

What kind of terminals? vt100, xterminals or some sort of windows citrix or similar terminals? I've used all and with splitvt and screen I'd rather be on a 19200 vt100 terminal than a citrix terminal on a lously network. In all seriousness though for a lot of applications I think text only would make more sense than gui based. At the dentist the other day and the receptionist was going back and forth between the mouse and the keyboard. I think that if she had been forced to learn the , and similar keystrokes it would have saved a good two minutes for getting my data in the system.

Dang it! I missed it in the preview. That should read "<tab>, <shift><tab>"

Maybe your account should be modified to only allow Extrans to save us a few minutes. Or you should be 'forced' to read every 'lously' word of the preview.

Re:Not good for large installations.

[el_womble]

I use Citrix as an end user for internet access. I can say that it is the worst user experience I've ever had. Slow page loading, having to log on twice (once to the OS, then again for Citrix) and perhaps worse of all it is incredibly unstable. I've ended up using a 3G phone and a personal laptop to access the internet because its faster.

Re:Not good for large installations.

[necrogram]

If done right, its not a single point of failure. build in abstraction and redundancy. Farm of Citrix servers and keep your data on a seprate set of servers with a Fibre Channel backend and viola. Apps dont play well.... seperate citrix box for those apps As with anything, you just need to plan in what you need/want.

Re:Not good for large installations.

[UnknowingFool]

Sounds like it would introduce a single point of failure.

That would be if you only used one and only one server. I can't think that an IT department wouldn't have a backup/standby server or even a cluster.

One malicious user or virus, and the sytem goes down for everyone.

That assumes you're using Windows only. Those deploying Linux or BSD or even OS X would not suffer this problem

Plus, software needed by different groups often doesn't play well together, leading to irritating misbehavior

Again, there is the assumption that there is only one server. You might have multiple servers for different groups, functions, etc. The accountants have their own server and network; marketing has their own server and network.

I could see having one terminal server for each department or lab, though.

Why can't that terminal server be centrally managed?

Re:Not good for large installations.

[Nile Maiden]

I suppose you have to be over 40 to remember when the majority of corporate installations were unix based servers with dumb terminals..(remember Wyse?) Microsoft managed to convince everyone that cheap PC's in an easy to manage(?) network were the way to go and the rest is history....

Re:Not good for large installations.

[brunascle]

no idea. at the time i didnt know anything about the types of terminals. tell you the truth, i still dont.

it was running X Windows though, on Tru64. i dont remember if the windows machines were terminals or not, but pretty much all the Unix machines were terminals, as far as i could tell.

Re:Not good for large installations.

[jazman_777]

Way back when I was just starting on UNIX I did that. Sorry. All alone in the lab late at night, no internet yet, I couldn't remember how to kill the program...Ctl-Z seemed to work... Next day I tried to login and I couldn't, because I'd used up my resource allocation with my backgrounded infinite loop.

Re:Not good for large installations.

[SpiritGod21]

That's why you run the applications on virtual machines. Then you don't have to worry about conflicts.

The issue is, like you started to say, bandwidth/networking needs. For a smaller company, sure, this is definitely the best solution. Roaming profiles, everything through a terminal... cuts costs, there's massive redundancy, higher security, less maintenance and tech support needed. But when you've got 20,000+ people with over 2-3,000 computers (like our university has--I've never gotten an exact count on how many compys we have), trying to do everything over the network just isn't feasible.

Departments aren't going to pay for servers. It's much cheaper to buy individual machines with good warranties.

Re:Not good for large installations.

[Anonymous Coward]

I've seen thin clients that cost less than a full PC, not by much.

Where I'm working bandwidth is plentiful, we're using less than half the single-mode fiber we have running between buildings, most buildings have gigabit to the closet, which we are slowly upgrading to two connections for redundancy over bandwidth.

We don't do thin clients because licensing costs so much. We have to license the terminal software and then there's the application vendors that may change their licensing terms when used in a terminal session. It would basically chew up the rest of the savings.

It's kinda why VMWare doesn't seem that great, it costs about the same as another server, so you have to run at least two VMs on each server to break even.

Re:Not good for large installations.

[Anonymous Coward]

Your cost of management goes down. Your hardware cost goes up. The thin clients cost the same as the PC but do a lot less. That means you probably need more servers. Which means more floor space, electricity, etc. Your network traffic probably goes up. That means additional cable runs, more switches, higher bandwidth connections to other sites, etc.

The numbers usually don't work out in favor of terminals.

If that's the case, I'd be interested in seeing those numbers.

The cost of a thin client is an issue, but what is the relative lifespan of your TC vs your desktop? Is the cost still the same once you factor that in? If you roll out an application that needs a lot of resources, do you have to update the TC or forgo the app? Either one could cost a lot of money.

Floor space, electricity and cooling are all needed outside the server room as well, it just doesn't show up on the IT budget. You didn't think those dual-core processors magically start generating less heat or using less electricity when you put them in a desktop did you? Your company will definitely have a smaller electric bill when you move to Thin Clients. TCs almost always have a much smaller footprint for the box itself and any cables, which has the potential to give more workspace on desks or simply more comfort under them.

Usually when you centralize and dole out something close to the current needs of the individual rather than block out all he might possibly need, you save money. Examples include PBX systems and VOIP. You don't need a line to everybody's desk, you just need enough lines to cover everyone who would need to make/receive a call during heavy usage periods. That number turns out to be quite a bit lower than one line per person so your PBX ends up saving you a boatload of money. With VOIP, the same thing holds true, but on a per call basis. Instead of blocking of full analog capacity for every single call, you dynamically assign bandwidth as it's needed. Pauses between words take something close to zero bandwidth where pauses takes the exact same bandwidth as complex speech if you use a POTS line.

Same thing with servers vs. PCs. Some people need massive horsepower at their desktop and some don't. Why do we give it to people who don't need it? And if you need it only once a week, why do we have it on your desk the other four days? If you centralize this processing power, I would find it difficult to believe you wouldn't achieve cost savings from this alone, even before maintenance is thrown in.

Storage could be an issue because SCSI drives in RAIDs are dramatically more expensive than what you have on your desk, but who says you need all your data on SCSI drives in RAIDS? There are some nifty high-end schemes to take long-term storage off line and then bring it back relatively quickly when it's needed. This can all happen almost seamlessly to the user. He'll only see a a delay when he needs a document that he hasn't touched in 3 years. He wont have to decide when to archive and he won't have to request a restore from backup.

As a real world example, the last company I worked for used Citrix for some telecommuters. Citrix is expensive. However, the bandwidth for the telecommuters was also expensive. Getting us enough bandwidth for our telecommuters to run client/server apps from their home would have been prohibitive compared to the Citrix solution. We also ran a reporting app for our accounting folks that used a tremendous amount of processing power. We would have have had to upgraded quite a few desktop computers to give this app to all the people who needed it. Instead we just upgraded a few servers and they were able to get the job done.

Re:Not good for large installations.

[Vanye1]

The company I work for switched to thin clients about 5-6 months ago, and frankly, they suck. I'm sure it's compounded by our servers being housed across the country from my location, but we frequently experience buggy connectivity to vital customer support databases.

Re:Not good for large installations.

[Fordiman]

I just priced the following system:
8-core Opteron @ 2.8GHz/2MB Cache per core
128GB RAM
6TB (750GBx8 RAID-0) HD
4-Port Gig Eth (3-ports serving, 1-port internet)

Cost: ~$76k

Number of users I estimate would be well served via VNC:
512 Users would get:
256Mb RAM
1.95G swap
~750Mhz, assuming 5% average CPU time per user
(From Task Manager: 1037952 secs active, 7588 secs CPU time, I work 7 hrs/day, 3 days/wk)
9.76GB storage/user
5.85 MBit to server, 1.95 MBit to internet

cost of a thin client per user: $75, total: $39k

To have an individual desktop per user for 512 people, at $600/cheap workstation, you easily break $300k. So, yeah. Savings.

Run Linux and VNC on it, and you could have the users nicely sandboxed (max. CPU use at 5% or most available, max. RAM use at 512MRAM/3GSwap or most available(whichever's less), strict access controls, no direct hardware access, automatic remote registration of USB/CD) and still let them do things like work on office documents and surf the web in safety.

Re:Not good for large installations.

[Short Circuit]

Why VNC? Wouldn't you be better served running the X protocol natively over the network? That's what it was designed for...

Re:Not good for large installations.

[rtw]

I would even say that the amount of RAM necessary for a centralized server servicing all the users is less than 256 MB due to memory optimizations the operating systems do (e.g. under windows dll code memory sharing between processe or with Linux intelligently mapping the code from the disk to virtual memory).
Also resource usage is a lot better because on most fat-client networks exist users which idle with only some small apps opened and others need more powerful-than-standard PCs to fulfill there special requirements (e.g. special applications). Getting a homogeneous environment is not very easy, if possible at all. Such resource distribution between users can be done automatically and on-demand on centralized servers.

Running VNC is probably not the best solution for Linux environments (even with Windows CE thin clients). Running X11 natively (e.g. via -query) or using terminal servers like Thinstuff RDP Server provide a lot more performance and manageability.

Re:Not good for large installations.

[Anonymous Coward]

I do hate it. Stop bothering me.

Guy who prepares the ghost image.

Re:Not good for large installations.

[eldepeche]

PS2 ports work pretty well.

Re:Not good for large installations.

[CommandNotFound]

The thin clients cost the same as the PC but do a lot less
If you stick with Windows RDP terminals, they can, particularly the Wyse Winterms. Now there are Linux terminals (that can be configured via LTSP to be RDP clients) as low as $90 in volume and $149. (The NTA 6020P is $149, although they have removed the line-item pricing for some reason).

So things are looking good for these units. The City of Largo has an administrator that keeps a blog that is interesting reading on how they are stepping up from basic terminals to using advanced terminals to add 3D eye candy, presumably driven by the cost savings over the past 5-10 years. I particularly like this posting that shows some daytime loads on the different servers.

Re:Not good for large installations.

[eno2001]

VNC is lower in bandwidth utilization. But there's also the NX protocol which is a compressed X. The other benefit to VNC is that you can have persistent sessions. (Leave apps open for when you reconnect later). This is something that X can't do yet. Although from what I've seen it's being worked on if you look at the latest gdm config files and the options for an X proxy server. That proxy server would remain running and hold all applications so that on reconnection with your session, you'd have everything right where you left it.

In my case, at home, I've been running since 2002 with Xvnc as the X server for my desktop application server. it works very well on the Unix platform. If you've experienced VNC only on Windows, then you might not have a good impression of it. It's actually pretty good. :)

Re:Not good for large installations.

[mrbooze]

It's only a single point of failure if your implementation is bad. Who says there's only one server on the other end of the thin client terminal?

For example, you might have a farm of servers running VMWare virtual desktops and Vmotion, designed to automatically shift to a new server if one goes down.

VMWare, of course, does a fair amount of evangelizing solutions like this. I've seen demos using thin client devices from Wyse.

Re:Not good for large installations.

[CommandNotFound]

[...]and it works beautifully for anything other than intensive 3-d rendering.

The SunRay units use a buffered display like Remote Desktop (RDP), VNC, or NX, and while these methods give good low-bandwidth results, they don't improve past a certain point when given LAN-class speeds. However, "stock" uncompressed remote X11 can do 3D graphics beautifully on a LAN, because OpenGL was created in the beginning (by SGI) to run over remote terminals. The GL operation is sent to the terminal, and the graphics card actually performs the operation, rather than the actual pixels getting passed over the wire. You can get 50+fps on an OpenGL application and only use about 100K/s of LAN bandwidth. Advanced 3D games tend to load/unload textures often and do other tricks, so they can use a lot more bandwidth, but for 3D applications, X11 terminals work great if they have a 3D card.

Re:Not good for large installations.

[Anonymous Coward]

I can't think that an IT department wouldn't have a backup/standby server or even a cluster.

I can easily see that happening. My brother recently joined a small logistics company (about 40 employees) that doesn't really focus on IT as part of their core business. Companies like this won't always have extra resources on hand for their servers (I forget if he said they even keep spares on hand for any of the desktops).

That assumes you're using Windows only. Those deploying Linux or BSD or even OS X would not suffer this problem

While this is may seem to be true, I wouldn't depend on that remaining the same as non-MS operating systems take hold, especially for non-traditional server roles. Maybe changing the statement to "would less likely suffer this problem" would be more appropriate.

My employer has setup some MS Terminal Server environments and we haven't run into any business applications that have had any major problems (only one that comes to mind is a problem running Hummingbird Exceed but for me, I have that on my desktop already so it isn't a problem that I have thoroughly investigated to see if it is a configuration issue or a software issue). Oh, I've been using MS RemoteDesktop to work on servers located in the UK from my desktop in the US. This work just fine (performance/applications) for my coworkers and I but we're a small department so the UK servers aren't supporting a large number of US based users.

Jim

Re:Not good for large installations.

[tinkerghost]

USB ports on terminals is a given. It will be up to access policies at the operating system level whether to allow removable storage devices to be mounted on these ports, and the CTO will be hearing a lot of compelling arguments as to why it should be allowed. Once one user has a storage device mounted, it could be all over.

The rule of thumb is you can't help stupid. It is actually quite simple to allow the keyboards & mice to connect without allowing data storage devices to attach/mount. As for the CTO hearing about why they should be allowed, I doubt it. The only people who would get to compain to the CTO aren't going to be effected by the issue to begin with. DTs & TCs go to the drones out in the workspace - the secretaries, the phone drones, and the pencil pushers - where everyone in the department gets exactly the same software and they share periferials. Anyone with 3 letters in their titles is going to get the biggest [smallest if it's a laptop], newest, shinyest system just like they always have.

The few 3 letter people I know who know how to use a thumbdrive, guard them more closely than they do their laptop. They aren't going to just hand it to their secretary and say 'print off 3 coppies of report.doc'. So what exactly is it that people are going to need to add to their DT/TC? Printers? most are already network printers shared between entire departments/workgroups. Scanners? the few that are needed are usually printer/scanners & still network shared.

Overall, you'll see these systems in bullpen type installations where everyone is a replaceable cog in the system - because that's what they are designed for.

Re:Not good for large installations.

[jacksonj04]

It's actually quite difficult to do with modern ones. For example, Sun's thin client system using containers can effectively isolate and stamp out a glitch one user introduced without affecting the rest of the network. Likewise they can cap your CPU time and spot runaway processes pretty effectively.

I'm not sure they're ideal for labs dealing with computers because of the level of access and control sometimes required, but for businesses and general school purposes they're ideal. My school is looking into replacing every system with a big Sun network and thin clients. You can even, for example, pull your smartcard from one machine (it logs you off), move across the campus, find another free machine, insert your card and log on and have your entire desktop as you left it. Ideal for 6th formers needing to do the same thing in 3 places.

Re:Not good for large installations.

[Anonymous Coward]

I'll add my 02 cents which others have already touched on.

In our environment, we have about 1000 Windows machines that are pretty much configured the same with a few exceptions, meaning almost anyone could login to someone elses machine and would not know the difference.

Our email, document storage and indexing solutions, faxing, printing, corporate intranet (HR, IT, Accounting interfaces etc) and many other functions are all handled through the network already. The advantages of doing this is very obvious to most IT people in a corporate environment. If our network, a server, or conectivity to our other offices goes down we are screwed so the redundancy, maintenance, and capacity to keep that up and running is already in place. Moving the end user units to this concept would not be a weak link by any means.

Now would there be an advantage to moving to thin clients for us? I don't know. We already have a very efficient backup and recovery method for end user computers that get trashed and they are down no more then 15 minutes while a replacement is in route. Our recovery method includes most users specific configurations as well like desktop walpaper, Outlook signatures, Word toolbars, printers they used, IE favorites and many more. This is all scripted and only takes a few minutes to run and place back on to the new machine. Since most of the real work done by the employees is network based (email and documents), moving to a different cube while waiting the 15 minutes for a new computer is possible as well.
Just looking at those specifics, I assume thin would be better as the need for updating workstations portion would be removed but on the flip side, I don't think updating a few application servers would take any less time then updating all of the workstations so it may even out.
Our updates are smooth as well. One or two people build packages and push to all of the machines in the background. Updating 10 machines takes no less time then doing several hundred.

If you have a rough time maintaining workstations and that takes a considerable amount of your IT budget for time and money, you have to realize that the root problem is your lack of management of those workstations. You can take steps to make that process easier with a good network and desktop engineer coupled with more consistent equipment base or use thin clients (which also requires a consistent equipment base). Hodge podge PC equipment purchases by department heads without a grand vision and goals for support more often then not, is the real cause. They save money now by buying 10 completely different computers a month and do not think ahead even a few months on how to maintain them all as a whole. Overall, I have no doubt that any money saved initially is lost 10 times over in lost productivity and support costs.
I've worked at both types of places and the difference is amazing.

Re:Not good for large installations.

[tinkerghost]

Place I worked at did a bad Citrix install - they ended up trying to run ~300 PC's on 1 Citrix server with a bad network. It was ugly until they upgraded the network & put in the 2nd server.

Re:Not good for large installations.

[Frumious Wombat]

What is your company paying admins versus machines? If I can de-hire or reallocate 1/3 of my $40K/yr + benefits humans, and replace them with $25K machines, then my net costs go down. If I replace PC's with their several hundred watt power-supplies with something running on 60watts or less, then my power and cooling of offices goes down as well, generally much more than my server room goes up. (let us remember that the servers are generally running on 208V as well, which is more efficient) U. of C. did that switch to LCDs and SunRays because retrofitting the room with the additional cooling for tube-monitors was prohibitively expensive, even given the cost of LCD's in the late '90s. In a similar manner, I switched out the firebottles in the lab, and noticed the cooling became a lot more manageable during the summer when we were threatened with brown-outs.

As far as do a lot less, since the vast majority of the working world uses a web-browser or similar interface to access a remote database, makes spreadsheets, and types unreadable memos in Word, the lower functionality of the dumb-term doesn't really matter. Once again, easier maintenance, less to break, and less for the employee to mung makes them rather desirable. Frankly, if we had fibre to the curb in this country, there are a lot of people out there who should have WinTerms, LTP, or SunRays in their homes, and let someone else worry about the anti-virus, security, backup, etc. Probably not *you*, but the Great Untrained, certainly.

Re:Not good for large installations.

[ncc74656]

the added security of dumb terminals - no vector for USB thumbdrives, floppys, or CD burners

How do you think the keyboard and mouse are going to be attached to the terminal? Hardwired?

Maybe you've heard of PS/2 keyboard and mouse ports...you know, those 6-pin mini-DIN connectors that 99.9999% of computers (excluding Macs) have on the back? You're probably using them right now.

Hell, if they also wanted to keep people from ripping off keyboards and mice, they could even use ADB (which is what older Macs and the Apple IIGS used), or they could use some sort of modular jack (common on dumb terminals from various manufacturers back in the day).

Re:Not good for large installations.

[Dan Farina]

Berkeley uses a bunch of Sun Rays in the computer science lab. They've worked well, from what I could tell. You should contact inst AT eecs.berkeley.edu if you want to hear a story from the administrator side (if they are nice enough to respond to such a non-standard query)

The system has multiple machines of mixed architecture hooked up to a file server via NFS and has probably on the order of 40+ Sun Rays.

Re:Not good for large installations.

[5of0]

A few minutes? More like ten seconds max. And maybe you should consult a dictionary before going after someone's spelling. I'm quite happy to be forced to spell things correctly in school, but I shouldn't be forced to do so on /. unless I want to. I can understand if every other word is misspelled, or random gibberish like "i c u l8r" is thrown in. But not if I spell one lousy word wrong in a lengthy, well-put-together response. Oh, I'm sorry, did you think it was spelled forsed ? Or some other mangling of the word used very properly by the OP?

Re:Not good for large installations.

[Short Circuit]

My most frequent use of VNC has been to connect to a Linux X desktop behind my friend's cablemodem, from a Windows machine. (I can only use standalone apps.)

When I had two Linux desktops and a Linux laptop, I used X's network functionality a great deal. I loved how it allowed me to seamlessly integrate apps running on multiple systems almost seamlessly into one X display. VNC is capable of serving up single applications from a Linux application server, but it's not nearly as seamless.

Today, I occasionally use x2x to link my laptop and my new desktop system.

Re:Not good for large installations.

[pnutjam]

I beg to differ. I'm in a department of three, director, admin (me), & tech. We support about 200 users at 17 different sites. Only one site has more then 30 users. and more then half only have 2 users. If we didn't use thin client we would need at least double, if not triple the staff. We do use some full PC's, mostly laptops. They are used like a terminal to access citrix, nothing is stored locally.

Some things need work, but all in all it's a remarkably cost effective solution.

Re:Not good for large installations.

[ecliptik]

I remember reading about the City of Largo's thin client setup six years ago and that's great it's still going strong and the admin keeps a blog detailing it.

I didn't even know it was possible to run 3D desktops over a network like that, and the menu system he's devising with launching different apps off of multiple app servers is brilliant.

Now excuse me while I trudge off to manually update adobe on 60+ computers...

Re:Not good for large installations.

[clydemaxwell]

Actually, it is better for security, assuming you aren't caught by something unpatched. Single point of failure? Single point of patching! Typically you don't run one server for a large environment. We run thirty terminal servers, some of them providing individual apps, some full desktops. No issues!

Re:Not good for large installations.

[gr8dude]

having to log on twice (once to the OS, then again for Citrix)

You could either use a single sign-on solution, or use an alternative approach to automate authentication and to secure the mechanism of credential storage (use smart cards or tokens).

Take a look at these:

• Logon for Windows
• Logon for Citrix ICA

Note: this is for Windows only.

Re:Not good for large installations.

[Nutria]

The old mainframe has been replaced by Unix servers but the principle is the same.

Don't forget that Unix started as a green-screen timeshare system, not too-unlike the mainframe.

However, the efficient and clever (but expensive) design of the mainframe ( I know both IBM & Burroughs, and maybe the UNCH) was such that tiny mainframes could handle hundreds of concurrent online users.

Re:Not good for large installations.

[eric76]

Don't forget the reduction in personnel surfing the web all day.

Nearly every time I walk up to the front of the building, someone is sitting there surfing the web instead of working. I think that using dumb terminals could easily improve our productivity by at least 10 percent.

I already use a dumb terminal on my desk in addition to several computers and associated monitors. I can log into a computer and use the screen ("screen manager with VT100/ANSI terminal emulation") program to maintain multiple windows. It's not all that different from using ratpoision directly on my development BSD machines.

Re:Not good for large installations.

[Short Circuit]

Somehow, I wiped half my comment just prior to clicking submit. I meant to add that depending on the network for such a high-bandwidth task as graphical terminal services would require additional infrastructure investment. If your LAN gets clogged, your entire system will be slow.

If your LAN goes down, well, there's another vulnerability of routing your services through one or two machines.

Re:Not good for large installations.

[scruffyMark]

Yeah, Citrix is heavy on the suck alright. But we're not talking about Citrix here. We're talking about real thin clients, not software that emulates a thin-ish client running on top of a fat operating system, with the server end running on an OS that was only ever marginally designed for multi-user use.

Re:Not good for large installations.

[Anonymous Coward]

Do you really think that only Windows allows a problem user to take down a whole server? In college we had to deal with that sort of thing all the time, where one person's simulation brought down the whole machine. It's certainly easy enough to get a machine in a state where it requires an admin to fix it. Sure, you can lock it down, set resource limits and such, but any program can still cause VM thrashing and effectively freeze the whole system -- at least for a while.

And how could you possibly bring OS X into this? You can't run OS X apps in a terminal server environment, so it's nothing but an expensive server for X clients with extremely limited hardware options!

Re:Not good for large installations.

[llefler]

2. Limited variety in software between departments

This isn't a problem, at least with Citrix. You can publish to specific user groups. So apps for departments like AP, HR, or IT are not accessible to other departments.

3. Software writen for thin-client/server environment

You don't need to write specifically for thin client, but the apps need to be multi-user aware. Another windows example; your application should install to the normal program files structure and store it's user specific info in Documents and Settings or HKEY_Current_User. Writing to other locations would be limited to admin installation and configuring. Basically, following the guidelines MS has been giving for at least 7 years.

Otherwise, an app that behaves badly on the server is a badly behaving app running on the client too.

Re:Not good for large installations.

[Fordiman]

X11 is out of the question. The system I have in mind would have both persistable sessions and people logging on via their home computer/laptops. I don't know the performance viability of Thinstuff RDP v. VNC, but I do know that VNC allows jpeg compression of the session image data.

Re: Not good for large installations.

[Dolda2000]

The problem is that we developers are some of the few who actually need workstations, meaning that we often fail to push the best solution for the company as a whole.

This is a quote I've heard often, but never really understood. I, too, do a lot of programming, both for a living, for my university studies and in my spare time, and I only very seldomly (if ever) need root access for any of that work. I could understand it if one does kernel/driver work, but for normal application development, why would one need one's own workstation? I've always been fine with compiling and installing into my home directory for testing and for final usage of a program.

Care to explain for me? Is this, mayhap, some kind of Windows thing that I don't understand?

Re:Not good for large installations.

[Architect_sasyr]

We run it nation wide... yes a single point of failure, but considering our network security and the fact that a "malicious user" only has a Terminal to try and inject a virus into the system locally we're pretty safe.

Now all we need is Telscum to get their shit together and stop disconnecting us between site.

Re:Not good for large installations.

[Zaiff Urgulbunger]

I used to support a single multiuser CPU with 100+ dumb-clients. It *does* mean there is a single point of failure, but since you are aware of the importance of keeping a single machine working properly, you make sure you get things right! You plan and check everything you do and you also make sure you have a plan B.

From a support perspective, things are super-easy. If there is a problem with the application, you can easily control the users terminal and see what is going on especially since in our case we were in the same building as the main CPU, so the traffic is local and in any case, text-based dumb terminal don't generate much traffic.

If you have a hardware problem you can have the user power-cycle the terminal; it'll be back running within seconds -- or not if it has actually hardware failed. In this case to replace a terminal, pick up a spare, walk out to the user, power off their terminal, unplug keyboard, power, serial (yeah... we were using serial terminals), remove old terminal, drop in new and plug in the 3 cables, power on and they're running again. Thus, a hardware problem can be quickly diagnosed (its pretty obvious) and resolved within 5 minutes.

In my case, we had to switch all our users over to Windows based machines which in theory shouldn't create problems but in practice meant *vastly* more support dealing with silly problems like increased hardware issues, weird problems that you never really get to the bottom of, and missing toolbars (older versions of Windows didn't allow locking of toolbars.

I honestly believe that giving most people something like Windows is very counter productive for a business. Yes, Word can product much prettier documents than we could before, but to a large extent, this doesn't help the day to day business operations. It absolutely definitely does increase the support costs however.

Obviously it depends on the company/organisation, and I can imagine that any company/org currently using thick clients would find it very hard to switch -- people expect to use Word/Excel these days, but I do think it's a shame; people can end up spending a lot of time not focusing on business objectives.

BTW, FWIW, I was subjected to using an AlphaMicro which for various reasons wasn't a bundle of joy. But I still hold with the idea of using dumb-terminals! :D

Re:Not good for large installations.

[Anonymous Coward]

Would you mind sharing how you are doing the end user system backups?

Re: Not good for large installations.

[AKAImBatman]

Who needs root access? I need to be able to run web servers and the like. Having a dozen developers trying to open port 80 on the same machine is a problem. Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.

Re: Not good for large installations.

[fabs64]

Depends on the type of programming really, as another poster has said a whole heap of people trying to open port 80 on one server is a problem.
But also developers tend to be more likely to need to install their own apps, which is usally locked down on a terminal server.

Re:Not good for large installations.

[YGingras]

Yet, all the servers are just a fork bomb away from death. How do you prevent something like that if you need to let the users run arbitrary commands?

Re:Not good for large installations.

[AKAImBatman]

How do you prevent something like that if you need to let the users run arbitrary commands?

Fire them for improperly tampering with company equipment? Seriously, not everything is a technology problem.

Re:Not good for large installations.

[Anonymous Coward]

Scripts!
Well I am the Network engineer, not the Desktop engineer but I was around through the development.
We initally started with the tools that came with Powerquest Drive Image Professional (PowerMigration DNA and the Deploy toolkit). I believe that is still the bulk of our application but VB scripts were added to the end of it as well. We have two applications under an IT folder on every computer, one for backup and one for restore. These apps can be triggered remotely through Landesk (or psexec) or locally by cliking on them (locally requires administrator access before it will run, we don't want users running these for no reason and reg access requires admin as well). When running the backup portion, the currently logged in users settings are plucked out of various directories like Documents and Settings/username and others specific to our environment like specific ini files for various apps and specific registry settings and are placed into a folder on a network share. The "restore" is run logged in as that same user on their new machine and everything is restored. It does have limits for multiple users on the same PC but that is very rare because we actually use common directories for that stuff like "My Documents" is redirected to c:\Documents which is a common location for all users of that machine. We have about 5000 computers worldwide and we use a total of two drive images, one for our laptops and one for our desktops. This was easy because we only have about 10 different computer models and sysprep and some configuration scripts for the things that are beyond the capability of sysprep makes that possible (one example is we have a script that changes quite a few setting based on what DHCP server you have. During the initial bootup after sysprep, if you get an ip address from our NY office DHCP server, this implies this machine is in NY office and scripts will point applications and configurations to the NY office servers, like our NYEXCHANGE server, NYFAX server, NYDOUCUMENT server etc.. It even joins the computer to the domain under the correct OU for that city. Then you login as the user, run the restore and you are done. Any additional apps very specific to that user can be placed on the machine by the tech via a "Application Policy Manager" (a function of Intel Landesk) through one click, or can be pushed automatically in the background by the desktop engineer. Nothing to install manually.

When we have visitors from one office in another and their laptop needs replaced, we can specify a city if needed during the initial boot but the same scripts work across all offices.

Uniformity is the key. It takes a while to setup but it takes very little IT to keep it running and the users downtime is very minimal.

Re:Not good for large installations.

[Fordiman]

I know this is my own post, and thus a bit fart-sniffery, but I gotta.

Imagine a beowulf cluster of *those*

Re:Not good for large installations.

[Ph33r th3 g(O)at]

What does APF authorized mean?

Re:Not good for large installations.

[Ph33r th3 g(O)at]

(replying to own post--sorry) Took awhile, but finally found it -- "Authorized Program Facility". Programs from those libraries can run in key zero (supervisor mode) and bypass RACF and other protections.

Re:Not good for large installations.

[Pingla]

How on earth was this rated as 'Funny'?
IMHO this was a good point, dumb terminals and a configured linux would be rather cheap and quite stable. A worthy alternative to desktops.

Re:Not good for large installations.

[k12linux]

Rating of "Funny" isn't appropriate here. City of Kenosha, WI already does this as do several other cities accross the U.S. All tend to report 1/2 to 1/3 total IT costs compared to similar sized cities in their areas.

Re:Not good for large installations.

[Ironsides]

Wouldn't happen to be in Virginia, would you?

Anyway, I had to use that at one of my last jobs. And it can always be used to redirect to a directory with controlled permisions.

One other question, though. Why not just make it so that only the folder/file that it writes to has the permissions set such that only those authorized may read/write to it? We are talking access controls where it can be specified down to the individual user or user group today.

Re:Not good for large installations.

[Short Circuit]

The poor guy who sets up the ghost images for the lab I work in needs to satisfy the application software requirements for over fourty classes from our department alone, plus a few from other departments.

One other question, though. Why not just make it so that only the folder/file that it writes to has the permissions set such that only those authorized may read/write to it? We are talking access controls where it can be specified down to the individual user or user group today. We use Novell for per-user authentication, but Windows sees each user as "DLUStudent". All that's really needed, though, is to redirect the GFS directory to the J drive, which is mapped to a student's network storage upon login.

I can pass along the info, but I, a lowly student tutor, am likely to have my information discared. The only time anyone pays attention to me is when I find security flaws.

Re:Not good for large installations.

[Hal_Porter]

I wasn't implying forced was incorrectly spelled. I was just teasing the GP because he was criticising someone else's typing skills and advocating forcing them to work with his choice of tools, whilst at the same time making typographical errors himself. So by his own logic, since I've shown his typing skills to be inadequate, I could suggest that he use my choice of tools / working methods, or even that the choice be taken away from him.

But suggesting the receptionist be forced to work in a different way would be wrong even if he hadn't made a single typo because it violates the Golden Rule. The fact that he did make typos in the same post just made it a more tempting target.

I've highlighted forced in a different way in this post, since it's a golden rule violation rather than a typo, sorry for any confusion caused by the original post ;-)

Re: Not good for large installations.

[Dolda2000]

I need to be able to run web servers and the like. Having a dozen developers trying to open port 80 on the same machine is a problem.

That's why I run my web server on port 8080 when programming. Sure, port allocation might become an issue if there is a huge number of developers on the same system, but certainly not unsurmountable.

Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.

I'm pretty sure my emacs and gdb session takes less than a fifth of the memory used by Firefox or OOo, though. And since when did debugging cause system crashes? For sure, I've never experienced that or anything even remotely like it. Is that some kind of Windows issue?

Re: Not good for large installations.

[Dolda2000]

really, as another poster has said a whole heap of people trying to open port 80 on one server is a problem.

I already mentioned it in the reply to his post, but that is why I use another port when debugging web stuff.

But also developers tend to be more likely to need to install their own apps, which is usally locked down on a terminal server.

Is that some Windows stuff? I've never heard of not being able to put executables in one's home directory on any POSIX system, for sure.

Re: Not good for large installations.

[fabs64]

I agree with you for UNIX, where I went to University the entire CS dept was in fact using dumb X based terminals with a Solaris backend, worked beautifully for the hundreds of comp sci students doing dev work.
Also with UNIX there are ways to get around things like ports, while still using very similar code.
But yeah, I was referring to Windows developers. (where there's also the problem that a bug in your program can quite easily crash the whole server :-))

Re: Not good for large installations.

[AKAImBatman]

That's why I run my web server on port 8080 when programming.

Good idea. I'll just tell all the developers to user port 8080.

Wait...

(rolls eyes)

In addition, you're assuming a lot about the development environment. One of those assumptions is that it's easy to use other ports. With various callbacks, SOAP interfaces, EJB servers, and whatnot, your ports not only fill up fast, but there may be too much code designed around existing port designations to make it practical.

There are also issues dealing with many servers that attempt to prevent more than one copy from running. (Normally, this is a feature.) They may open a fixed port, or hold onto a lock file, or pull a variety of other tricks that aren't so easy to get around.

Then there is Windows development (blech!) where you can only have one instance of an ActiveX control installed across the entire system. This not only sucks for developers, but it sucks for Windows servers which tend to breed like rabbits because of problems like these. I won't even go into problems like multiple .NET versions on IIS. (Though I hear that Microsoft has finally patched that one. Sort of.)

First thing you learn in professional programming: There's a huge gulf between what is possible and what is practical. It's a lot less hassle to simply give developers their own machines than to waste time on troubleshooting collisions.

Not to mention the excess computing resources used or outright crashes that a developer might accidently cause while debugging.

I'm pretty sure my emacs and gdb session takes less than a fifth of the memory used by Firefox or OOo, though.

Hello? McFly? See this bug?

while(i < 10);
{
  i++;
}

Guess what it does. Want to guess how common it is?

How about this one?

for(int i=100; i>=0; i++)
{
  myobj = new MyObject();
}

Do you see it? That's what happens when you reverse a loop when you're used to doing it the other way around. And those are fairly benign examples of what you can frack up. You should see some of the multithreaded code people write. Ugh. Can you say, "Thread Bomb?"

And since when did debugging cause system crashes? For sure, I've never experienced that or anything even remotely like it. Is that some kind of Windows issue?

Then you're not doing anything involving. Fun things like changing the screen resolution and obtaining a DirectX context can crash or lockup your system. Or accessing external hardware at just the wrong time. (Yes, this happens on Unix as well. Though to somewhat lesser degrees due to focus on stablility rather than performance.) Never locked up an X-Session before? Then you're not doing anywhere near anything interesting. ;)

Re:Not good for large installations.

[Pikoro]

The place I work for does it like this:

We have a couple of BigIP load balancing appliances which manage access to the terminal servers.

120 terminal servers in each location, one location in each major city. The users who connect from the branch offices are using thin clients running windows embedded.

They punch in thier branch id and that takes them to one of the terminal servers assigned to their group. All of thier user files, configuration files, applications, etc are stored on nas volumes and re-mapped at each login.

The user can access any of thier applications, files, document directories, and group shared drives from any thin client in thier branch and each of the terminal servers is configured the same.

This way, if one terminal server goes down, all they need to do is power off thier thin client and log back on. Then they are right back where they left off.

If an entire city or one of the many reduntant backbones goes down, we switch everyone to an alternate location (from thier city to the next closest city) and they can still work just fine.

If either of the bigIP appliances goes offline, the other detects it and switches the users to the next available location automatically.

It all works very well over adsl lines (themes turned off, 256 color desktops at 1024x768).

We also have a bunch of developers scattered all over the world who connect to a "special" development TS farm but each of their accounts have the same restrictions concerning network storage, etc.. If one of them forks off an infinate loop, the number of users impacted is minimal since they are all spread out over the entire farm.

We have yet to have a user crash a server, and even when CPU loads approach 100%, it is generally not a problem on that server since users will generally log off and back on if the system gets to slow to use.

Also, just to be on the safe side, we reboot all of the servers once a week (they ARE windows after all) to clean out disconnected sessions, hung processes, etc...

Just a perspective from a Terminal Server administrator...

Re:Not good for large installations.

[el_womble]

Perhaps you missed my point. I'm an end user. If I was an admin I wouldn't have chosen Citrix in the first place. Your solutions are valid, but Citrix has robbed me of that kind of control and I am forced to rely on the 'expertise' of the MSCEs. I just wish that they had as much knowledge as you.

Citrix is as much about social control as anything else. I think thats why it smells so bad.

Re: Not good for large installations.

[Dolda2000]

[specific rebuttals]

Good idea. I'll just tell all the developers to user port 8080.

Well now, my point was, of course, not that everyone should use port 8080 instead of port 80, but rather that simply using another port than the default often fixes the problem in question. My point about 8080 in particular was that it is >1024 and therefore bindable by !root.

Hello? McFly? See this bug? [Snip code taking 100% CPU]

Since when did hogging the CPU crash anything? I run Gentoo and often have 1 or 2 emerge instances running in the background (each using -j2 to make) on a comparatively slow UP machine (AMD XP 2200+, 1 GB RAM) while doing other things without even thinking about it. Especially, then, when such a process is stoppable within seconds, and many timesharing servers would probably even be SMP machines.

How about this one? [Snip code eating all memory]

"uname -Sv 200000"

You should see some of the multithreaded code people write. Ugh. Can you say, "Thread Bomb?"

Either that, or fork bomb. Add "uname -Sr 30" and maybe a fair share scheduler.

Then you're not doing anything involving. Fun things like changing the screen resolution and obtaining a DirectX context can crash or lockup your system. Or accessing external hardware at just the wrong time. (Yes, this happens on Unix as well. Though to somewhat lesser degrees due to focus on stablility rather than performance.) Never locked up an X-Session before? Then you're not doing anywhere near anything interesting.

Indeed, I have only extremely seldomly had my machine crash because of weird hardware access. Buggy device drivers? I have most definitely never had to reboot because of a locked up X-Session (Ctrl+Alt+Backspace and log in again).

[/specific rebuttals]

Anyway, my point was never that noone may ever, under any circumstances, need their own machine. I did mention kernel/driver work in my original post (although the ITS developers sure seemed to get things done even despite that), and although I was ignorant before your post (And happy! Damn you for destroying my pure innocent eyes! ;), I am hardly surprised that development under Windows has special requirements (Windows seems that have that effect on a great many things). My point, however, was that there almost seems to be a general stigma (I've seen it in many other places as well) that developers cannot timeshare a system, and considering how the vast majority of developers are very unlikely to require their own boxes for any of the reasons stated above, I didn't understand whence that stigma has come.

Re:Not good for large installations.

[rtw]

In my experience Thinstuff RDP performs a lot better than VNC. Jpeg compression is nice, but RDP client side caches are a lot better. Our tests have shown that the bandwidth necessary for proper operation is a lot lower compared to VNC (especially interesting for home users with ADSL lines).
The Thinstuff RDP software also has a lot of advantages in management and features compared to VNC.

Re:Not good for large installations.

[YGingras]

This can work in a corporate environment but you'll have a hard time to enforce it in a school, for example. And remember that the good old bash bomb (:(){ :|:& };:) don't leave much trace. With fat clients, when you fork bomb your machine, you are the only one affected. But, I can understand why someone would like to see if it works on the big server too. There are so many ways to kill a system when it thinks you are safe.

Re:Not good for large installations.

[CommandNotFound]

I didn't even know it was possible to run 3D desktops over a network like that, [...]

Yup, OpenGL is network-transparent. It connects to the glx server, which is an extension to your X11 display and passes 3D operations at a higher level than just "draw pixel (1,1), draw pixel (2,1), etc.", so it is surprisingly light on the network if you don't constantly reload lots of textures.

OpenGL was created by SGI in the late 80's or early 90's and it was designed to have small SGI Indy-class boxes connecting to large Onyx-class systems that did the heavy data lifting, so it needed to be network transparent at a time when big iron was needed for the applications.

Sometimes Not Good

[mfh]

We have dumb terminals at work and their caches are always clogged. We are constantly rebooting them. While setting the cache to a larger size is likely a good idea, someone at head-office has the perms to do this, so we have to sit back and stomach it.

Re:Sometimes Not Good

[Anonymous Coward]

If the terminal has a cache, it isn't a dumb terminal. You're probably thinking about Citrix boxes. A dumb terminal is more like something like an NCD X terminal. That might even be too much. I use a DEC VT420. I don't think I'd even call a Sun Ray a "dumb terminal". Way too much smarts there.

Re:Sometimes Not Good

[geekoid]

Improperly managed systems are problems with any system.

The only time thats a valid argument is if the system inherently lends it self to making bad decsions through its adminstration system.

Otherwise it's a perfectly good system being managed by dumb shits.

How many times have we heard this before?

[elrous0]

I swear I've heard this "companies migrating to dumb terminals" prediction about 100 times since the early 90's. And, in all that time, I've yet to personally see a company actually doing it. I'm beginning to think some dumb terminal or server company periodically plants these articles or something.

About the closest thing I've seen to this is a few companies I've worked for who ran certain applications (like Office) on a central server. But even that has become passe I think (in fact, the agency I work for recently abandoned that model due to server strain and just started installing the apps on individual computers).

Does anyone here actually work for a company that currently (or ever has) used true dumb terminals?

-Eric

Re:How many times have we heard this before?

[Lumpy]

Um.... autozone did it. All dumb terminals in the stores and one linux server.

Works great, and they have a far lower TCO per store than Advance does with their windows based setup. Wyse terminals are dirt cheap. Hell, thin X terminals are dirt cheap compared to a PC running windows for a sales terminal.

Re:How many times have we heard this before?

[timshead]

I was just about to say the same thing. It's like every year or two the MSM gets convinced that the world is going to shift to dummy terminals. They're useful for retail stores and for other limited usage, but that's about it.

My company has never used dummy terminals but we have certainly configured and installed them for clients. Let's just say they're good for government usage if you're concerned about information storage and retrieval.

Re:How many times have we heard this before?

[thetroll123]

As usual, this coverage blurs the software/hardware aspects of thin clients. While Citrix etc. use is fairly widespread, the client software is typically running on a standard PC, not dedicated dumb termial client hardware.

Although this model does give the advantages (and disadvantages) of centralized administration, it certainly doesn't meaningfully reduce the client hardware TCO.

Re:How many times have we heard this before?

[und0]

Don't know how dumb they are, but city of Largo use thin clients. I've read somewhere the blog of one of the IT staff, last time he was testing some HP models with 3D HW accelerated support, to run Beryl, IIRC...

P.S. first hit searching "city largo beryl" with Google

Re:How many times have we heard this before?

[MindStalker]

Autozone? Yep many retail outlets use dumb terminals especially for computers located at the counter many that double as a POS (Point of Sale.. IE Cash Register). The question is are there companies out there that use dummy terminals for office machines. Oh sure, some do, but its not widespread.

Re:How many times have we heard this before?

[Anonymous Coward]

Sure, my company uses thin clients rather extensively throughout the corporate environment. We use Citrix with a few servers at each site, and at least half the desktops are thin clients.
We use a mix of Wyse terminals and PC's running a version of the Thinstation project from sourceforge that I customized, running the linux Citrix client.
The Thinstation terminals skipped at least a major upgrade cycle, as we can run it fine on P400 desktops, and the users have a much more responsive environment than if they were running XP. With only an 8MB linux image and citrix client running, it's much faster than running XP on the same machine. Even local drives, CDs, USB and printers are supported, pending policy allowance.

On top of that, application upgrades and rollouts are much faster and easier.

Re:How many times have we heard this before?

[Daemonstar]

The local newspaper where my parents work at used to use terminals to write their stories (even had the black and green monitors!). I don't remember what type or anything about them; I just know they used them for a long time.

A few years ago they migrated to Windows; they had some software company come in and deploy their software suite (another newspaper in the chain had migrated over, so this one followed suit). The company I worked for was supplying all of the hardware (Win98 and NT4 Server) except for 1 Mac that is hooked to the WIR service. They knew enough about networking to be dangerous (their internal NAT is a public routable IP). They also didn't allow Win2k on the workstations because they claimed their software wouldn't run on it (they said their software was 16bit and wouldn't run on 2k). They no longer support that software suite. FSI (Freedom Systems Incorporated) is the name of the company, in case anyone cares.

Re:How many times have we heard this before?

[yorugua]

We dont need no stinkin dumb terminals. We already have a lot of dumb users around here.

Re:How many times have we heard this before?

[Anonymous Coward]

At the lab I used to work at we had X terminals for the students (we used basic diskless PCs booting Linux over the network), with dedicated machines only for those
that needed local processing power. Most of the staff had Linux workstations on their desk, with access to a Windows terminal server for those tasks that could only
be done on Windows (this was around 2000 or so). Worked pretty well over a 100MB switched network. Since technology has advanced since then, I'ld say using
thin clients is perfectly viable if you don't need to do any "serious" computing or graphics work, and if you don't have too many clients per server.

Re:How many times have we heard this before?

[gad_zuki!]

These stories might be plants, but this stuff is out there and it works fine. I think the big holdup is the IT mentality of 'one computer per person' Thin-clients go against the norm and is probably a very hard sell for management, who can only think of things as 'how is this like my home version of windows.'

I did visit one company that ran citrix on every desktop. I believe the desktops were either full blown versions of windows or windows ce. The citrix client ran on top of that and connected to a server on the lan. They all use the same apps anyway so it works out.

Where I work now we run citrix as a remote solution but I dont see any reason why we cant move all of our desktop users to it. Most wouldnt even notice a difference.

Re:How many times have we heard this before?

[edgr]

I work for the largest retailer in Australia (supermarkets, mainly) and all the POS computers are thin clients. They appear to run on some kind of Windows.

Re:How many times have we heard this before?

[mikael]

Sun proposed the JavaStation.

The only problem was that just after Sun was introducing this hardware, the target markets started using the advanced JAVA multimedia API's to implement basic applications - medical students were using the image
library to view MRI scans by loading in hundreds of 2D images. And other companies needed to play video files
for staff training purposes (including DVD's).

It more or less remains the same now. By the time all the necessary hardware (video card, sound card, CPU) is
put together with an OS, device drivers, windowing system, video/audio codecs, a hard disk drive for caching applications and data, it's all but a desktop computer. And using a hard disk drive to cache applications and data off the network is worse than just stamping on a standard installation downloaded from a server, as old versions can become munged up with new versions.

Re:How many times have we heard this before?

[eln]

Sun Microsystems uses thin clients extensively. Each employee has a little card that they carry along with their badge. Any system they walk up to, they can put their little card in, and up pops their desktop. They also have systems at home that will work the same way, gaining access through the corporate VPN.

I'm not sure of all the details of how it's implemented, but we had a Sun engineer out here a couple of months ago, and he gave us the basics. He said basically everyone in the company uses the same system.

Personally, it sounds sort of appealing. It makes you a lot more portable if you don't have to lug your laptop around to various company locations.

Re:How many times have we heard this before?

[jm91509]

Sun use sunrays throughout their network. They are stateless terminals with smartcard readers in them. You put your id badge into them and you desktop pops up. This works globally, so if you are normally based in the US and travel to Europe, you just stick your card into a sunray and (after a short pause...) your desktop appears, just as you left it back home. All works perfectly smoothly and mostly hassle free.

http://www.sun.com/sunray/sunray2/faq.xml

Re:How many times have we heard this before?

[Secrity]

Many moons ago I worked for AT&T and used many dumb terminals. Most were either AT&T/Teletype 3270 clones or were vt100 terminals. One particular terminal I worked on did windowing and supported several different async protocols. Another type of sort of dumb terminal was attached to an HP minicomputer, the terminal had two small tape drives in it and the operator could run programs from the tapes.

I now work for a different company and support over 200 SunRay stations.

Re:How many times have we heard this before?

[Dan East]

MEDITECH is a healthcare software system used extensively by hospitals (thanks mostly to a terrible decision by Columbia, now known as HCA), that uses dumb terminals with a proprietary server-side OS called MAGIC. It's a wonderful, cutting edge technology if you think it is 1980. These systems are still being installed. In fact, our local hospital was just bought out by a chain, and they installed MEDITECH within the last few months.

Interestingly, the exact opposite of what this article is claiming is happening in these hospitals with regards to client hardware. They started off with mainly dumb terminals 10 years ago, but have switched almost completely to PCs and Laptops running terminal emulation software. Laptops on carts provide portability, and actually end up cheaper than dropping cables into every single patient room, installing hardware on which to mount the keyboard and display, and buying the actual terminal, keyboard and display. In addition to saving money with laptops, they save a lot of room not having to permanently mount hardware in the patient rooms.

The thing is, the cost of PCs and laptops have dropped so much that they can compete with the cost of dumb terminals. Both require keyboards and monitors anyway, and the massive gains from having a multi-purpose computer (able to view HTML, etc) simply outweigh the small increase in cost.

My partner's practice had dumb terminals for over a decade for patient registration and billing at the front desk. They recently replaced the dumb terminals with PCs running terminal emulators.

Dan East

Re:How many times have we heard this before?

[NVP_Radical_Dreamer]

I work in a company where Dumb Terminals were installed a few years back because they were "the wave of the future" and as it turns out, its a wave I didnt like being a part of. It was a constant struggle with bandwidth and apps locking taking 100% of a servers cpu thus slowing eveyone down to a crawl.

We are currently in the process of moving people to real pc's and the difference in productivity is very noticable. Also the line about them being more reliable since they have no moving parts is BS, we use Neoware terminals and end up sending them back or throwing them away fairly often due to the network controller on them crapping out, or the onboard ROM gets corrupt somehow.

I can see where they would be very useful in places like autozone where they are dedicated to a single app, but thats about as far as i would go with them.

Re:How many times have we heard this before?

[Blikkie]

I've worked at three companies (work in a outsourcing company) that have applied this solution. One mental health institution, one school, and now a car dealership. One employed thin clients, one employed fat clients, and the car dealership works with a mixed environment. The car dealership (or actually a chain) has the most challenging setup, they have specific software of some ten brands, many of which aren't written for terminal server use, but integrated nonetheless with softgrid. They partly deploy thin clients, but there are some pc's with a cardreader, or diagnostic software that run that software locally, but integrated in the SBC environment with RES Powerfuse. That way we are able to run a 1000 employee company with some 150 different programs with a 10-person IT staff.

Re:How many times have we heard this before?

[speculatrix]

are there companies out there that use dummy terminals for office machines?

a dummy terminal would be one that doesn't do anything other than look like a terminal.
I think what you meant to say was a dumb terminal
OTOH, a terminal for dummies could be a dummy terminal or a dumb terminal

Re:How many times have we heard this before?

[Richard Steiner]

Just FWIW, the airline industry still uses them heavily. In a flexible mainframe transaction environment, you can have thousands of different input screens and data requests on a system (usually controlled by a transaction code in the upper left corner), and you can use some fairly flexible security measures to ensure that only certain sign-ons can perform certain types of transactions.

Even the ancient system I worked on five years ago at a major airline (first developed in 1966) allowed you to arbitrily assign a series of mode numbers to each transaction code and to each and every user of the system, and if things didn't match, the transaction didn't work. That sometimes included the location of the terminal as well as the modes assigned to the person's signon. And everything ran inside an isolated transaction sandbox, meaning that direct access to the OS simply didn't exist. Folks running TIP applications were at the mercy of the TIP scheduler.

Add a sophisticated text form-editing environment to the mix, and you end up being able to do quite a bit even though we're talking about 80x24 green screens for the most part.

Re:How many times have we heard this before?

[AnimeNathan]

I actually work for a company that uses dumb terminals. We have 70+ locations spread out over Texas and Louisiana, most of which run entirely on the Neoware e140 brand. Setting up these dumb terminals is a snap (average 20-30 minutes) and having them log into the main server here in the home office to do their work ensures that the back-ups manage to snag all of the work that would otherwise be lost when a hard drive fails. Pretty much the only PC's in the entire company are given to the store managers, the programmers, and the tech desk; everything else runs off of these dumb terminals. Security is made much easier, but the potential for catastrophic failure becomes more evident when a server goes down. When that happens, anyone logged into that server ends up unable to work, or at least until they log back into one of the other 9. In the case of a (rare) massive failure, we lose all 70 stores until we can get up and going again. There are good and bad points to all. Nathan

Re:How many times have we heard this before?

[THESuperShawn]

Actually, TFA shows multiple examples.

Re:How many times have we heard this before?

[Anonymous Coward]

My company has never used dummy terminals

Dummy Terminals != Dumb Terminals

Dummy == Fake, for show, non-existent
Dumb == Low intelligence, only follows orders

Re:How many times have we heard this before?

[eno2001]

Where I work we used to have around 2000 dumb terminals deployed at the peak (early/mid 90s). The initial installation started in 1982 and grew quickly. Eventually, people who didn't know any better (myself included at the time) replaced the dumb terminals with PCs. At the time I wasn't aware of the admin friendly features of dumb terminals. I thought that by giving users PCs, they'd be able to do more and I'd come off looking great. There were things that the PC could do that the dumb terminals couldn't. But, what I lost in the long view was something that would preserve sanity if it were available for the PC world: centralization and the benefits that an admin gains. So really, it's all about balancing the needs of a user vs. the needs of an admin. If I could move everyone to some modern centralized system tomorrow, I'd do it in a heartbeat. But yes, to answer your original question, we had quite a huge deployment of dumb terminals, and I do miss them.

Re:How many times have we heard this before?

[DaMattster]

The home improvement store Lowes uses the thin client model with Red Hat Enterprise Linux

Re:How many times have we heard this before?

[MindStalker]

?? If you are in Europe and it copies your information over, are you now running using the computing power of whatever SUN server your plugged into, are you simply limited to your local computers power. Otherwise this is just fancy roaming profiles.

Re:How many times have we heard this before?

[ivan256]

The big two autoparts software packages both used dumb terminals. Even autoparts stores that have PCs as terminals run either a browser or a terminal emulator to access the package.

Anybody who thinks the trend back towards dumb clients and centralized applications must not have been paying attention for the last decade as browser based apps have become so commonplace.

The original poster needs to crawl out from under his rock...

Re:How many times have we heard this before?

[tinkerghost]

For office machines I am going to assume that you mean running Office Suite type software - if not ignore the following:

1. Citrix offers Word pocessing & spreadsheet capabilities for dumb terminals.
2. 50+% of the cycles on the average desktop machine are wasted - even when the person is 'busy' - heck, unless I am compiling something my system is idling at less than 30% usage most of the time - and I have 20+ windows open & active.
3. The number of companies using internal web apps for custom software is growing.

Given those 3 things, I would say that it is very likely that you will see more and more companies dropping back to thin-client/dumb terminals for the majority of their employees. The upfront costs are slightly higher - you need a more robust server, and the server/client software has a cost independent of the actual programs- but maintenance time is reduced, repair costs are minimized, in house version incompatility is eliminated, and the thin client can drop you from a 85W idle PC to a 8W loaded client. @ $.20/KwH, (slightly up from the US average in 2003) that can save a 100 seat call center $13K a year in electricity alone:

• 75(W/seat)*100(seats)/1000(w/Kw)=7.5Kw continuous savings
• 7.5Kw(continuous)-> 7.5KwH/Hr
• 24*365=8760 Hr/Year
• 7.5KwH/Hr*8760Hr/Year= 65700KwH/Year
• $.20/KwH * 65700KwH/Year = $13,140.00/year

Re:How many times have we heard this before?

[skiflyer]

No, we keep looking into at a small company I work for... but if you don't need a hefty desktop, then you can pick up a tiny, low powered PC for $400... dumb terminals aren't cheaper enough... in fact they're often more expensive... it keeps negating the move. The JackPC is the only dumb terminal which really has me interested, but I have a lot more to learn about running such a setup first.

Re:How many times have we heard this before?

[Marillion]

At the airline I worked for, we wrote tiny little UNIX apps that registered with a mainframe message handler. Quite often the terminals at the airports are provided by the airport and link in through industry networks like ARINC or SITA. Montréal (YUL) is one airport that comes to mind. They have airport PC's with a SITA terminal emulator on it. Any airline can use any terminal in the complex.

The environment is supprisingly web like. All editing is done within the emulator, when the user presses "Enter" the request form is sent to SITA, which sends it to the carrier, which routes the form to either a mainframe or UNIX or Java app that does the back-end processing and the response is then painted on the screen.

Re:How many times have we heard this before?

[Lumpy]

...are there companies out there that use dummy terminals for office machines...

WEll yes, some salespeople and managers are so incredibly stupid they replace the computer on their desk with a cardboard dummy terminal and they never notice.

Re:How many times have we heard this before?

[drinkypoo]

The environment is supprisingly web like. All editing is done within the emulator, when the user presses "Enter" the request form is sent to SITA, which sends it to the carrier, which routes the form to either a mainframe or UNIX or Java app that does the back-end processing and the response is then painted on the screen.

AFAIK this is what IBM terminals have been doing since approximately forever.

Re:How many times have we heard this before?

[UnifiedTechs]

For those who have never seen a thin client in actual use:

I work for a small technology company in a small city (Technology Partners, Vero Beach, FL http://www.techpart.net/), and a quick list over our clients shows 18 are using Citrix and thin client solutions. I can only assume after you multiply that out by all the cities in the US that you would come up with a rather large number of users. Not all of them are 100% thin client installations, many are a mix of thin clients and domain PCs, but a good percentage of the users are thin clients.

The key is using some type of remote server software like Citrix, Microsoft Terminal Server alone just won't do what you need it to.

Re:How many times have we heard this before?

[hodet]

I totally agree with you on this. I have never seen an installation anywhere. I would have added a line to the end of the decription that said, "In other news there are no reported plans of anyone ever taking this option seriously."

That's too bad because many places could use this. Many PC's are used for very light tasks and require too much maintenance in relation to their output. Dumb terminals make sense. It seems to me that Microsoft prices terminal server way too high which discourages companies from taking it seriously. Before someone says to use Linux (you are preaching to the converted so save your breath), Microsoft is what the "suits" want and that means full desktop PC's for everyone.

Re:How many times have we heard this before?

[nuintari]

I work for an ISP, so I see lots of networks. We provide transit for a few auto dealerships, and they all seem to like using thin clients, as they take up less room, make less noise, and are easy to monitor. For some odd reason, auto dealers seem to watch their employees like they are hawks. We service about 4 dealerships, and they all work this way.

We provided transit service for a political party this past election, won't say who, suffice to say they never paid their bill and are being sent to collections..... They used a few thin clients.

And my favorite, is a data processing company that has never migrated away from the dumbest of dumb terminals. They have those old IBM clients that you used to see in airports. They expect some proprietary IBM serial proto over a 56k leased line. We set up their network using DSL at two locations, and a VPN to cut down on the costs of the 8 or so leased lines they were getting. The connection is priceless.

It is proprietary serial proto, encapped in IP traffic, which is carried over SDSL which is carried over ATM.... oh, and a VPN in there somewhere too. All that, to get 8 dumb terms from the remote office, to the main office, where the AS400 lives.

All because they didn't want to upgrade. Somehow, it has yet to break.

Re:How many times have we heard this before?

[Anonymous Coward]

What about the network bottleneck on the server side? What about failing nick in the terminal that can't be fixed or replaced? In real life, the terminals have proven to be more troublesome and prone to hardware failures (speaking from exp.). And one can't simply replace the nic or whatever, one must replace the entire unit.

Also, a PC can be locked down to act as a terminal, a dumb terminal is a dumb terminal, no flexibility there. Wait, you may save money on the purchase price, you say!!! YES, if you still live in the 90's!

Two thumbs down! NOthing but a bait for CEO/CFO's.

Re:How many times have we heard this before?

[the_womble]

Well is a small business with four desktops counts then yes. One decent PC running Linux + four old ones turned into X windosx thin clients.

If a slightly bigger (about thirty desktops), yes, using Windows and Citirx. It was a complete disaster. I suspect the first wave of this stuff (before hardware was fast enough) gave the hold idea a bad name.

I also use thin clients at home.

Re:How many times have we heard this before?

[Knara]

AFAIK the smartcart just replaces your need to do a keyboard login. There's no local storage on the Sunrays.

Re:How many times have we heard this before?

[kmt]

> Does anyone here actually work for a company that currently (or ever has) used true dumb terminals?

Yes. I have worked on a SunRay for a few years. I was pretty happy. What I really liked was the silence (no fans!). The only downside was dependence on the network. If network went south, you couldn't do anything. Those occasions were rare, though.

Re:How many times have we heard this before?

[ben there...]

Does anyone here actually work for a company that currently (or ever has) used true dumb terminals?

I used to work for a GIS mapping company that utilized dumb terminals for their 500 or so employees who edited the maps. The mapping software ran in X11 on several HP-UX servers. Their terminals were directly connected to these servers, and then they would rlogin to other servers which contains individual state datasets of the US. The editors/drafters also used Citrix to connect to several Windows Terminal servers for Excel, Word, Access, online timesheets, and Track-IT, and could connect to a different server if theirs was down.

I wouldn't say they were "migrating to dumb terminals" because they had them the entire 4 years I worked there, but they were deploying additional servers and terminals.

Re:How many times have we heard this before?

[Marillion]

I know, but the average slashdot reader wasn't alive then.

Re:How many times have we heard this before?

[geekoid]

"Dumb Terminals" are great for data entry.

There is nothing faster and easier for people whio just enter data.
At this creent stage of propegated technology, 'Dumb Terminal' is actually a Hybrid. Mostly there is a window for data entry, but the computer will still have a hard drive for other uses.

I can't really think of many application used in the business world that shouldn't be 'centrally located'.

Re:How many times have we heard this before?

[hazem]

Where I work, more and more of our applications are accessed via a bank of citrix machines or have been transformed into web-apps. These are things like time-sheet tracking, product design, product development, logistics management, etc. The main things that people actually "run" on their desktop are Microsoft Office, IE, and iTunes.

As more and more of our aps are virtualized and run off large farms of computers, I can easily imagine many of our employees being put on terminals.

Re:How many times have we heard this before?

[Richard Steiner]

Sounds like they're using Liason and IATA Type B messages?

We used to use the Attachmate UTS emulator's API for UTS connectivity in UNIX environments when I worked at NWA, and we used Type B for just about everything that needed guaranteed delivery (ACARS, WX, even printer and some types of unsolicited CRT traffic).

Now that I'm actually working for SITA I suspect we'd use Liason a lot more internally, and we have a much more diverse messaging infrastructure. 50+ years of connecting to doznes of airlines creates an interesting mess. ;-)

Re:How many times have we heard this before?

[MetaKey]

Does anyone here actually work for a company that currently (or ever has) used true dumb terminals?

I do, I do! I'm typing this on a Sun SunRay1 and I love this thing!

You find SunRays in a lot of places where security is taken seriously (ie. security clearance is required for the job). To log in, you need to have a valid smart card and know your usual login credentials. So, security is based on something you have and something you know.

Plus, if you want to move to a different physical place, you just pull your smart card out of the SunRay, go to the new place and insert it into that SunRay. BOOM! Your desktop session comes up and you go back to work, right where you left off. Your apps are still open, nothing has changed. And, there is nothing left behind, the session followed you.

Further, if someone comes in who isn't cleared (or doesn't have a need to know) simply pull the smart card and the screen goes blank. Once they're gone, reinsert the smart card and go back to work.

I've come to the point where I'd rather work on a SunRay. I had a nice multiprocessor SunBlade workstation in my office that I replaced with this SunRay. Since the server is rather beefy, my work (I'm a developer) is actually faster. I also use typical desktop apps (scalc, swriter, etc.) and they're faster too.

As to the single point of failure argument, Sun's SunRay server software has auto fail-over stuff. Multiple servers can share the load and, if one goes down, it's users fail-over to another server transparently. Non-issue.

What happens when the beige box in your office fails? Yes, your important work is probably stored on a server but what about all your configuration stuff? What else did you store on your local workstation that's now gone? If a SunRay fails you unplug it, walk down the hall and hand it in. They hand you a new one and you go plug it in, insert your smart card, log in and go to work. Nothing is lost, not even your session.

The SunRay is completely silent, draws something like 8 watts and the footprint on my desk is about 3" x 10" or so.

It's seriously cool stuff!

Re:How many times have we heard this before?

[BovineSpirit]

I used to. The server software was heavily customised for the company, and it ran everything, sales, hire, payroll, contacts... And it was rock solid. I was there for nearly 3 years and don't remember any downtime at all. It used to run on dumb terminals and PC terminal emulators.

Re:How many times have we heard this before?

[Richard Steiner]

Yup, and same with UNISCOPE/UTS terminals. Local editing on a screen form with the cursor restricted to input fields, a transmit key to send the data to the host, and no network traffic at all until a request is sent.

Both terminals had a lot of smarts built in (a UTS terminal enforce data alignment and alpha/numeric data types on a field-by-field basis all by itself after the initial screen is sent, since the terminal protocol contains field attributes which can specify things like "Left-Justified Numeric", etc.). It's rather nice.

Re:How many times have we heard this before?

[Hercules Peanut]

I swear I've heard this "companies migrating to dumb terminals" prediction about 100 times since the early 90's. And, in all that time, I've yet to personally see a company actually doing it. I'm beginning to think some dumb terminal or server company periodically plants these articles or something. Considering that this article cites data from a Gartner study, you may be more right than you know.

To me, this has been a "Duh" topic for a long time. The hold back is not the cost, it's the application availability. Sure, you can do Windows/Citrix but I'm not convinced you're saving anything. You still have to pay for Windows server licenses, client licenses, citric licenses and a few more windows taxes I'm certain. The defining moment, however, comes when you try to save the big buck going Sun to NCD or Sunray or linux, basically Unix where IMHO this really works as advertised and someone needs a windows only app. I'm not even talking about MS Office. I'm talking about some of the more obscure things like browser plug-ins that are windows (or win/mac at best) only. I'm talking about major vendors like Lexis/Nexis who deliver their content over the web but only support I.E. for the management of the apps. It's S.S.D.D. The network computer model works and can cost less but the Windows monopoly closes it off every time.

I've said it before and will say it again. Computers are tools. None are bad (ok, some may be) but they all have a place and Windows doesn't merit 95% of those places. Until we fix that issue and the problems that it causes, much innovation and potential for improvement will ignored.

Re:How many times have we heard this before?

[Greyfox]

Oh I've seen companies do it. Fortune 100 companies with well funded IT departments. The end results inevitably sucks. Thin clients always feel sluggish compared to a desktop machine and if server ever goes down your entire company grinds to a complete standstill.

Thin clients are one of those "shiny" things that attracts management types who believe everything that C-Net says. Like most other shiny things it only looks good on paper.

Re:How many times have we heard this before?

[Anonymous Coward]

umm. Sun Microsystems has been using thin clients as the primary desktop for most of its employees for several years.

I drove a SunRay thin client myself for 2+ years.

Yes, there is the single point of failure issue. You definitely do not want to be in the office on the day the network gremlins come out. However, on the whole it works pretty well.

Sun is actually pushing out thin clients to staff who work from home as well (with a VPN module of course). Reviews so far have been mixed from the folks who participated in the pilot but service levels seem to be at acceptable levels and are improving, generally...

Re:How many times have we heard this before?

[mrwacko]

I work for Halfords (a car parts supplier in England) and we have always used dumb terminals. There is one server per shop, and approx. 5-6 dumb terminals. The servers are all unix system V (copyrighted before I was born) and provide a flawless system to the terminals. The terminals are 386 processors with 64bytes of cache. Each night the servers (about 400 in the network) all "call home" to recieve updates and backup data The system never every breaks. I have worked for them for 5 years and I have never needed to fix any problems, software or hardware. In one store the systems were started July 23 1983 and have an uptime of over 12 years thanks to unix and a UPS There is something to be said for systems like this where the users dont need to access anything other than essentially a huge database Alastair

Re:How many times have we heard this before?

[Anonymous Coward]

While you personally haven't seen this, there are many instances where the dumb terminal works extemely well. As has been stated by many people already, retail is a huge area where these are very beneficial. This also works well for the average office worker who only needs access to basic things like email, office apps, internet, and possibly ERP/CRM applications. Apps that are very graphic intensive, such as CAD, will run poorly and at this point still require a powerful workstation. In a Windows environment, Metaframe works very well, while in a Linux environment, NX is a good solution. The servers can be setup with roaming profiles and load balancing so that if a single server goes down, the end user still sees the exact same thing and has no idea he's on a different server. Same goes for the dumb terminal. If the dumb terminal dies, it's just a matter of swapping it out for a good one, all the while the end user can't tell the difference and is back up and running in a matter of minutes.

Re:How many times have we heard this before?

[danheretic]

We use them in the Engineering College at our university -- about 30% of lab computers and 5% of desktops. We're trying to push them because they make way more sense financially. It's an uphill battle against user ennui (they're used to Windows and our thin clients are Solaris, although we do have Citrix-to-Windows-server functionality). We're also part of a pilot program to push them out to dorm users (slogan: a SunRay for every pillow!)

We're using SunRay thin clients from Sun, which have just gotten better (actual USB peripheral support, and real graphics!)

I'm also in the midst of a project to convert old semi-useless (PIII and lower) PCs to linux-based thin clients at my daughter's charter school, which is chronically strapped for funds. It would free up about half of their IT budget to get rid of the Microsoft tax.

Re:How many times have we heard this before?

[jgrahn]

Does anyone here actually work for a company that currently (or ever has) used true dumb terminals?

I have, a few years back. X terminals and a heterogenous mix of at least five different Unixes, one per server. Worked wonderfully with (as I understood it) very little maintenance.

At my current job, my bosses probably think I work on a full Windows PC. In practice, what I do with my local admin privileges is install PuTTY, turning it into a big, expensive terminal multiplexor against the Linux servers.

An old-fashioned timesharing system (which is what we're really talking about, not dumb terminals) is, in my experience, a great place to be. For one thing, if you need something, someone else probably needed it before you, so it's most likely installed already.

Re:How many times have we heard this before?

[llefler]

The hold back is not the cost, it's the application availability. Sure, you can do Windows/Citrix but I'm not convinced you're saving anything. You still have to pay for Windows server licenses, client licenses, citric licenses and a few more windows taxes I'm certain.

There is still plenty to gain, depending on your organization.

1. The ability to swap someone's "desktop" in a matter of minutes is good if your support staff is limited. Same for setting up new PCs.
2. Lifecycle can be 2 - 3 times longer than PCs. If you upgrade an app and it needs resources, you handle it at the server.
3. Software patches/upgrades are all at the server level. Everybody always has the right version.
4. If you have to have licenses, having them in once place beats any license management system I have seen.
5. User shadowing. Nothing like connecting to a user's session 6 states away and walking them through a problem.

If you aren't fully accounting for support costs, then the numbers will never look good.

Re:How many times have we heard this before?

[Anonymous Coward]

I use dumb terminals now and then (at home as a development tool mostly)

Personally, I look forward to the return of the dumb terminal, they're quiet, cheap and best
of all, if the terminal gets trashed, you can reboot it w/out loosing whatever it was you were working on. (which is why I tend to run everything under the 'screen' utility)

Unfortunately, these newer "thin terminals" will likely be graphical. With the exception of web browsing, a good VT100'ish terminal beats everything else hands down.

Re:How many times have we heard this before?

[allenw]

There's no "copying" involved.

Basically, your card is tied to a session. When you pull your card out and go to a different client, the server locates where your session is at and reconnects you. Now globalize this: if all of the servers worldwide have access to the session information, then all servers are now capable of redirecting you back to your home session.

In other words, you're at your desk in the UK. You pull your card and hop on a plane to Singapore. You put your card in. The server in Singapore does a lookup to locate your session in the UK. It now reconnects (after an authentication) you to your session back in the UK. All of your apps that you were running previously are woken from hibernation and you're back in business.

One of the big gotchas about this type of setup is that your infrastructure MUST be globalized. This means things like printers need to be accessible from any location on the network!

This is very different than a roaming profile; there is only one session, ever. (Unless you override of course)

Re:How many times have we heard this before?

[fabs64]

I worked part time for a company that I personally saw migrate an accounting firm and a shire council over to a dumb terminal system, the administration and cost of running these setups was so much better that they intended to encourage other clients to do it.

Re:How many times have we heard this before?

[bobcote]

Gartner said it. I believe it. That settles it!

At least that's how my management acts.

Seriously, yes. I have worked with dumb terminals in a Unix environment. The reason they aren't accepted is because everyone likes to add their own software to their PC.

My argument is that UPS doesn't let their drivers pimp their trucks, why should users feel they have a right to customize their PCs?

Old is new again!

[Anonymous Coward]

We go back and forth over and over. PC's, Terminals,PC's, terminals!, LAPTOPS!, Thin clients!

Honestly, there are advantages to both, just most CTO's and IT managers are not educated enough to understand that a hybrid works best.

We call them thin-clients

[genessy]

And all of our tellers and member service employees use them. Not only are they easier to maintain and support, it's a lot harder for users to really screw things up! :)

Re:We call them thin-clients

[Frankie70]

it's a lot harder for users to really screw things up


It may be a lot harder for the user to screw up hardware,
but I don't see how it makes harder to screw up software.

You can make it harder to screw up software by setting
permissions, but that can be done both on thin or
thick clients.

Re:We call them thin-clients

[genessy]

You are right, but as we're just upgrading to an Active Directory domain from an NT domain, there were a lot less options for setting permissions. The ease of being able to "shadow" users with one click to provide tech support without another bloated software installation is also a definite plus. Hoestly, they're cheaper, easily managed and maintained, and a good choice for any business running centralized applications that don't require a lot of individual processing power. We can't run the whole organization on them. A lot of our users run more intensive programs than I'd like to see on a shared server, but they do serve a purpose and they perform that purpose well.

Re:We call them thin-clients

[fabs64]

Contrast locking down one terminal server with locking down 150 PC's...

Re:We call them thin-clients

[L0rdJedi]

150 PC's can be fairly easily locked down with Active Directory these days. Set some policies on the Domain and every single PC that's a member will suddenly be much more secure. These aren't the days of NT anymore.

When the cost less to purchase

[Jinjuku]

I'll go with dumb terminals when they cost less to purchase than a standard PC. There are scenarios like car dealerships that we have had success. But for general office computing environment, we have stuck with a 'traditional' desktop PC.

GE did this to avoid rewiring office building

[DrDitto]

I heard of General Electric doing this at a few of their old, large buildings because the AC wiring couldn't handle power-demand of the next PC upgrade cycle. Instead of incurring the cost of rewiring the entire building, they installed low-power terminals at desks. Makes sense to me. GE has some very old office buildings (they are an old company!).

Re:GE did this to avoid rewiring office building

[Anonymous Coward]

GE has a wonderful ip range. 3.0.0.0/8
Now, i believe that's more than China has ;)

they can also have a computer named 3.13.3.7 which is awesome ;)

Re:GE did this to avoid rewiring office building

[DrDitto]

GE has a wonderful ip range. 3.0.0.0/8
Now, i believe that's more than China has ;)

Yup. Its insane the GE has more IP addresses allocated than most other countries. When I was an intern there, I pinged until I found the lowest active IP address. I don't remember exactly what it was, but is was not 3.1.1.1. Not positive, but 2.x.x.x and 1.x.x.x are unused? The one division of GE I interned at had over 3000 subnets alone.

Re:GE did this to avoid rewiring office building

[moosesocks]

Does anyone else find it ironic that a company named General Electric has inadequate AC wiring in their headquarters?

Re:GE did this to avoid rewiring office building

[StikyPad]

Actually I'm more impressed by their ability to come up with workable solutions to save power. Now if only they'd show me a viable alternative to running a water line to the location of my new GE fridge.

You're too early!

[Anonymous Coward]

Dumb terminals arn't due to come back into fashion for at least two more years yet!

I guess we'd better decide quickly then: we've tried "Dumb terminal", then "Thin client", so what do we call them this time?

Re:You're too early!

[ebvwfbw]

I guess we'd better decide quickly then: we've tried "Dumb terminal", then "Thin client", so what do we call them this time?

How about "Dumb client" or "Thin terminal". Oh wait, "Dumb Client" is already taken. The people that use SCO.

Re:You're too early!

[geekoid]

Dumb terminals and thin client's are two different things.

One is a type of hardware, the other is a software paradigm.

Back to the old-days

[lemmen]

Back to the old-days, but yes, it works fine!
This is one of the suggestions I always make, but nobody wants to give it a go... They should have listened.

Dumb terminals....

[lofoforabr]

...for dumb users! Doesn't it seem right?

Re:Dumb terminals....

[maxume]

Do you think they also have asshole servers for asshole sys admins?

Re:Dumb terminals....

[i.r.id10t]

Used to but the goatse.cx domain has expired....

Re:Dumb terminals....

[Ykant]

Oh, you're just jealous.

Re:Dumb terminals....

[Anonymous Coward]

Or, following on from MS's latest marketing phrase:

    "Rich clients for rich clients"

well, not as rich as they used to be at $150 a pop..

Re:Dumb terminals....

[Zaiff Urgulbunger]

As the president for Asshole Systems Inc. I am deeply offended by your remark and demand an immediate retraction!

Re:Dumb terminals....

[maxume]

King turd huh?

Re:Dumb terminals....

[Anonymous Coward]

There's plenty down at your local gay bar, where they're called "tops" instead of "asshole servers".

Re:Dumb terminals....

[Zaiff Urgulbunger]

Yes yes, my wife does call me that, but how on earth did you know?!!

Cost

[Jon Eiche]

I realize that total cost of ownership involves a lot more than the initial purchase price, but you can buy a nice PC for what a typical dumb terminal costs. That's hardly an incentive to go thin-client. Plus there's the specter of Jeff Goldblum uploading a virus and bringing down the entire armada.

Re:Cost

[delymyth]

Don't forget installation time.
It's a matter of more that an hour for a pc (without actually reinstalling the whole OS), while it's a matter of minutes for a thin client.
As for viruses, simply don't give users administrator privileges and viruses can have a hard time trying to infect your servers.

Re:Cost

[tinkerghost]

Look at TCO again:

• Initial price

  About the same - $300-400 for a low end PC or a thin client w/ monitor, keyboard, & mouse. The slight savings in the TC will be eaten by the heavier server needed

• Installation cost

  A custom install of corperate software can take over an hour - 40 minutes even if you are installing a Ghosted Image and with registration it's not unusual to have them require you to re-validate your OS.

  Connect power/network cable/keyboard/mouse - turn on - DHCP can handle most of the remaining configuration.

• Software Cost

• Per seat licenses usually cost slightly less than individual software packages.

  This is offset by the added cost of the actual server software.

• Maintenance Cost

• No HD failure, no virus cleanup, virtually no per seat maintenance at all.

  Software upgrades go on the server once - everyone get's the same upgrade at the same time - no need to take a seat out of production to upgrade it.

• Operating Cost

• The low end processors/MBs eat a lot less electricity - depending on load averages, you can be talking 75+W/machine - in a 100 seat call center that's $13+K a year savings

• Lifespan

  A typical business PC is on a 3-5 year upgrade cycle (not coincidentally the span of the average extended warrenty) This is where fans & HDs start to go at a higher than acceptable rate.

  A typical thin client is on a 5-7 year upgrade cycle

So, if you examine the TCO, thin clients are highly desireable. Examining the initial outlay, they come in at slightly more costly due to the increased costs of the server & server software

Thin Clients! The Future of Computing Since 1994!

[Nova Express]

I look forward to the 2017 Slashdot article proclaiming how thin clients are the wave of the future as well, right next to the stories about how practical fusion and "real" artificial intelligence are just around the corner...

In theory..

[cccc828]

"Because the terminals have no moving parts such as fans or hard drives that can break, the machines typically require less maintenance and last longer than PCs."

Yes, but only if the manufactor also provides updates for the -usually propritary- firmware. The hardware can life as long as it wants, but if the software lifecycle ends after two years you can basically trash it.

cccc828

Re:In theory..

[DaMattster]

Technically, you could build your own thin client. All you need is a PC and a network card. From there, you can boot off of the network card. It is fairly manufacturer agnostic. If the network card goes, just replace it.

SWEET!

[cepler]

...now where'd I put my DEC VT102? *Scurries off to the attic* Time to eBay it! :)

ad campaign

[Anonymous Coward]

I can envision the ad campaign now: "Dumb Terminals for Dumb Users"

Depends on the area of use

[doktorstop]

We have recently switched to thin clinets.. a whole big organisation. Plues, sure: quet, fast to start, less desk clitter.
Downsides: VERY unsuitable for graphic applications because of bad graphics, sound problems and the frustration of connecting any USB periferals.
Thin clinets or dumb terminals are ok if you have an organisation where everyone uses Excel or Word the whole day long. Creative work, extensive use of periferals - forget it.
Just my 2C

Re:Depends on the area of use

[Anonymous Coward]

...Plues, sure: quet, fast to start, less desk clitter....
No, MORE clitter

Sunray, Linux, Windows or ???

[amulder]

The article doesn't say what kind of OS these thin clients support.

Presumably it isn't Solaris, since they would have mentioned Sunray terminals otherwise. Poor Sun, they've been trying for years -- halfheartedly -- to push their sunray terminals without much success.

Personally, I'd be interested in Apple producing a thin client solution. But not just for the office. Consider how many of us have 3-4 computers at home these days for our families? I'd like to see a small home setup where a G5 tower (or smaller!) would support up to four thin terminals around the house. Much easier to administrate and backup.

Re:Sunray, Linux, Windows or ???

[lewiz]

I'm guessing that you've never used a SunRay. I use them at work and home (over a 2Mbps ADSL connection) and they're really great pieces of kit.

Sure, they're not suited to all purposes (video and graphics editing, for one), but for office use they are a very good solution. Of the top benefits are noise, power and space. The first time you walk into a workstation-free office it all seems a little eerie, but I'd honestly have trouble going back.

From what I understand Sun are the largest SunRay consumer, but the CIA, FBI and other security-conscious government bodies are also heavy users. It's true they haven't become "mainstream", but I wonder if this isn't because Sun didn't want to deliver a half-baked solution?

Thin Clients?

[JoeCommodore]

I think they are thinking more of thin clients with some sort of remote desktop thing.

I myself would like to strive for Linux Termimal Server type of installtion at our work, check out this Story from Newsforge and the one year follow up which chroniclaes the city of Largo Florida government deploying Linux Terminal Server/Clients.

I think it's happening a lot more then you think, it just takes time to configure and roll-out.

Re:Thin Clients?

[greenhaven]

I'm still at school, but the school could save some money if instead of using PC's for computer access in the labs, they just used terminals. Of course, most of the students here aren't computer experts by any stretch of the imagination, so a Unix/X11 solution is out. It's a shame, since most of the time, people just run a word processor and a web browser. If anything, schools are probably the best market for terminals to make a comeback, since in the lower grades, people are still learning and there wouldn't be much of a 'culture shock' moving over to an X11 environment. The only place where Wintel boxes would be needed is in the Computer Apps classes, where they have to learn MS Office.

Re:Thin Clients?

[drinkypoo]

I'm still at school, but the school could save some money if instead of using PC's for computer access in the labs, they just used terminals. Of course, most of the students here aren't computer experts by any stretch of the imagination, so a Unix/X11 solution is out.

What the hell are you talking about? Unix can provide you with all the software a student is likely to ever need, and it's not any harder to use than Windows. In fact, it's arguably quite a bit easier; you can pare it down to precisely what the student needs. OO.o, gimp, inkscape, dia, firefox, and gaim if you want to let them use the lab for what they usually use it for. Put all the icons in a big fat navbar. Works just like Windows, except with 95% less suck.

Wow i was unware a new kind of computer was out

[Ksempac]

"More companies are forgoing desktop and LAPTOP computers for dumb terminals"

Everybody welcome the "dumb laptop", a keyboard and a screen that automatically connects to your company main server no matter where you are in the world.

Joke aside, i fail to see how a dumb terminal could replace a laptop for a commercial/engineer who needs to travel frequently. And theses are the computers that are most likely to be lost/stolen so this is the kind of computer where you should improve security (disk encryption, ...)

Re:Wow i was unware a new kind of computer was out

[teh_chrizzle]

i think the "dumb terminal" for the laptop crowd is the "outlook web access + citrix web apps + securID" stack where all you need is an internet connected PC and a browser. i have seen it used by folks on vacation, home sick, or when a firewall doesn't play nicely with your VPN client.

Dumb Terminals...

[Paulrothrock]

... for the terminally dumb.

what maintenance costs?

[Anonymous Coward]

where i work we have CSR's using 7 year old Compaq PC's that never break except for being slow once in a while and they are long out of warranty. and we have 10 year old servers we still use for testing.

we use Citrix for a few things but have no plans to upgrade our 5 year old version because it's not cost effective. by the time you spend the cash for fault tolerant hardware that can handle 1000 users you might as well leave things the way they are

k12ltsp.org remains a great way to use this

[Anonymous Coward]

It's a standard Fedora Core 6 install, with terminal server configured to be installed with a pointy-clicky menu. One moderately beefy terminal server can easily serve 40 plus clients. I have used this at home for three years with zero problems. Pentium 1 166s/233s with 64 meg of ram work perfectly as a terminal.

Yes, it has kindergarten programs available on it, in addition to Firefox 2, OpenOffice, etc. No, you don't have to install the kindergarten programs.

that "dumb" laptop replacement...

[LM741N]

Is going to need an awfully long cord, as well as a large supply of batteries.

This actually sounds like a VMware ad....

[8127972]

.... when I first started reading it as they have a concept called Virtual Desktop Infrastructure. The article sounds like the link below:

http://www.vmware.com/solutions/desktop/vdi.html

When the power/server dies, it's a paperweight!

[ysaric]

Unlike laptops/desktops, when the server goes down or we have power problems, my computer becomes a paperweight unlike some of my co-workers who got laptops/desktops before the thin-client requirements were instituted. They at least can continue work with documents and files stored on their local drive. Me, my work just stops.

Also, responsiveness in a large company is a huge problem when it is a broken process. If I need to add a piece of software, I can't do it on a thin client, I have to go back through IT which might only take a few days (still too long) but can also take significantly longer. Yah, I can't do significant damage but I also can't get crap done when it needs to get done. I know that's a systemic issue and not the fault of the thin clients themselves, but companies in my experience are not adjusting well and it's terribly frustrating.

Finally, it's worth noting in my company anyway that senior management, of course, is exempt from the this client requirements. So when I was describing the paperweight problem to a senior director one day she said "I had no idea!" Hey, no sh**, you with your nice laptop and docking station. They don't give a crap 'cause they don't have to deal with it.

Re:When the power/server dies, it's a paperweight!

[poot_rootbeer]

when the server goes down or we have power problems, my computer becomes a paperweight

Do you have power outages frequently at your workplace? I only recall two times in my career where the building I was working in went black, and both times we all had better things to think than "If I had a battery-powered notebook, I could still be editing that Powerpoint presentation right now!"

If you're expected to work by candlelight, I'd say your company has bigger problems than a poor terminal implementation.

Re:When the power/server dies, it's a paperweight!

[analog_line]

So, your company is poorly run, has an IT infrastructure that's poorly maintained, as well as enough issues with power that you regularly have building-wide power outages? That sounds like a far bigger issue than whether you, personally, are able to get any work done with no power.

Re:When the power/server dies, it's a paperweight!

[Peter Simpson]

>in my company anyway that senior management, of course, is exempt from the this client requirements.

When I was at Data General, the fastest workstations with all the options and the color displays always went to the managers first. Nice to know some large company traditions remain intact...

Re:When the power/server dies, it's a paperweight!

[doghouse41]

Down time should not be an issue with a well maintained server system. I've had experience with systems on these lines that had uptimes measured in years. (They were running UNIX or VMS in those days of course, not Windows.).

If you are worrying about the time you would loose on the very rare occasion that a server goes down - ask yourself how much time you waste wating for your desktop PC to startup/shutdown?

Personally I can recall the days of the VT220 terminal. Boot time was a couple of seconds. I could come into work, turn it on, log in and start working immediately. Even sharing the same server with 20 other developers, it seemed faster to me.

Today I come into work, turn on the PC and then go and make a cup of tea. If I'm lucky it's ready to log in by the time I've done that. Then it's time to make another cup of tea while Windows churns through whatever it does when I first log in (i.e. running all the anti-virus/spyware that cripples my computer for the first five minutes of the day).

It's probably not an exageration to say that I loose ten minutes every day to this sort of activity.

I could also talk about the problems of trying to shut down Windows. Who hasn't tried to shut it down, turned the monitor off, gone home and come back the next day to find a message saying "Application XXXX didn't want to stop. Do you want to terminate it?" So you then have to wait even longer for W£$%£$$%s to shutdown and start up again.

I could of course leave my computer on overnight, but that only works till the oil runs out or rising sea levels drown my office!

Re:When the power/server dies, it's a paperweight!

[Bazman]

When your desktop box dies, IT look at it and think.. Hmmm one person's problem. When the main server dies, IT look at it and go hmmmm, 200 people's problems. Which shall we fix first boys and girls? The one person's problem, or the 200 people's problem? How many people do we want screaming at us? Especially if one of the 200 is the boss.

Re:When the power/server dies, it's a paperweight!

[lahvak]

If I need to add a piece of software, I can't do it on a thin client, I have to go back through IT which might only take a few days (still too long) but can also take significantly longer.

I got through grad school using pretty much exclusively thin clients, pretty much every application short of the OS itself I used was installed by me in my home directory, including windows manager (for some reason Solaris came with an ancient version of fvwm), terminal emulator (no rxvt on Solaris at that time, only xterm), text editor etc.

Re:When the power/server dies, it's a paperweight!

[SuperIan22]

*Some* people might find this advantageous. "Oh, all you guys are still able to work? Lucky. My terminal has been reduced to a paperweight. I'm forced to go home, have a beer, and relax. How irritating."

No, probably good for everyone but IT

[ciaohound]

The economics of web-based apps are going to hit local IT departments hard. It's not just the availability of web-based spreadsheets and word processors. Very soon the same concept will be applied to back-office apps like accounting, etc. Look at Netsuite and Salesforce.com for a hint of what's coming. Replicating that functionality in-house will probably become akin to trying to reinvent an app like Google search in-house -- it just won't be economical to do so.

Same thing could happen to the user hardware. If your competitors are all on cheap terminals and your employees are still slinging around fragile and expensive laptops, the cost of supporting that could really drive a move to terminals.

We thought about this...

[SlashdotCrackPot]

I work for a POS dealer, and we thought about using this type of machine for our terminals. In the long run for us, it would actually cost us money, since we make most of our money on support and maintenance. On the other hand of this matter, the same equation for in-house equipment can be a tremendous savings. With alot of medium to large companies using SAP servers these days, it really is not that bad of an idea to run these "dumb" terminals. Due to the fact that if your VMware server goes down anyway, you aren't going to get much done anyway with centralized storage and application deployment.

.02 cents

I've been working at a thin client site for a bit.

[kahei]

I've been working at a site that went to a thin client solution back the last time that was fashionable (so there's been some time for it to settle down). They've saved some I.T. costs but it's at considerable cost in functionality -- application responsiveness is OK for light Office and web use but terribly slow for heavy-duty Excel users, the network is studded with PCs installed for people who just had to have some bit of software or just had to run things fast, network bandwidth is a constant problem and there's also a strange issue whereby users connect to the BigSystem server to run BigSystem, and to the BiggerSystem server to run BiggerSystem, and are surprised when they can't use the same paths, settings, clipboard etc on both.

I think they could have achieved the same effect by just scaling back IT in the usual way -- cutting staff, sticking with older computers, fixing only the most critical problems. I'm not saying the thin client system hasn't worked, because this organization isn't computer-focused and doesn't generally demand much from its computer systems. But it certainly makes me doubt whether the idea would work well in a demanding, information-driven business.

Not a dumb terminal

[oshkarr]

This article is talking about network appliances, not dumb terminals. See http://www.webopedia.com/TERM/D/dumb_terminal.html

I don't think anyone is going back to using green screens anytime soon. In fact, even the VT100 wasn't so dumb. It could show bold, blinking and double-width characters, among its other features.

Re:Not a dumb terminal

[ratboy666]

A REALLY big AHEM.

I use a Wyse 30. It even uses green phospor.

Good points - it does VI, compile commands, and even spreadsheets (I use SC). The control key is in the right place. It should last a long time (its already been a long time). Its power requirement is low. I don't get distracted by "pretty pictures". I get amazing geek cred.

Bad points - the keyboard is a bit flimsy (I would like to use my Model-M on it!). I still need access to a GUI because a lot of web sites won't work with lynx. (and why not?).

Yes, the GUI is nice, but most of what I do is based on CHARACTERS. Even when I program for Windows, I code in C++, using CHARACTERS. No, the MS IDE won't work, but I prefer VI anyway.

When I do accounting, I work with CHARACTERS and NUMBERS. SC and VI work just fine. I can switch to a GUI when I need it -- but the terminal keeps me on task.

Home solutions?

[Stone316]

I'd love to have a couple of dumb terminals around the house hooked into my main computer. What options are out there for home users? I know there are some diskless linux options but I really don't almost full systems around the house... Just something compact with most of the room only needed for monitor, keyboard and mouse.

Re:Home solutions?

[squatex]

I thought about installing some jack pc's in my house (http://www.chippc.com/thin-clients/jack-pc/index. asp). We bought a couple at my company and they work pretty well. They are wince based however.

Re:Home solutions?

[Anonymous Coward]

iMac - it's just a screen (with a full computer built in) with a keyboard and mouse. Not actually a dumb terminal but you can use it as one, and it'd be a good OSX joke.

Any old laptops - also not dumb, but a 500 Mhz laptop off ebay is about as powerful as a modern thin client and likewise can work as one. Not exactly the form factor you want but it's comparable in size.

Sun Rays

Re:Home solutions?

[flyingfsck]

$ ssh joesoap@basementserver
password
$ starticewm

---

$ ssh janesoap@basementserver
password
$ startkde

---

I guess you get the idea...

Re:Home solutions?

[hab136]

Any old laptops - also not dumb, but a 500 Mhz laptop off ebay is about as powerful as a modern thin client and likewise can work as one. Not exactly the form factor you want but it's comparable in size.

Laptops with broken screens are cheap on Ebay. Hook up an external monitor, and you're all set.

Re:Home solutions?

[BrianRoach]

Sun Rays on eBay. I bought a ton of them for about $30 a piece three years ago for my business.

Looking right now, it would appear they've gone up to about $50, but still a fairly cheap solution.

- Roach

Re:Home solutions?

[drinkypoo]

Basically ANY X terminal will work with Linux. That's kind of the point of X, or part of it anyway. Try to get one with good color depth (24 bits) because lots of your favorite programs won't work right in 8 bit color and even websurfing is pretty horrendous. Just configure gdm (or kdm, or xdm) to accept XDMCP connections - the man page or other help will tell you precisely how to do this. Then either configure your X terminal to look for connections, or to connect to that machine directly. You can use any PC as an X terminal - including a laptop, as others have suggested; you can get laptops with broken displays but otherwise working very cheaply and hook them up to a cheapie display - still lower power, smaller, and quieter than using anything bigger than a Book PC. Another but much more hardcore option is to use a Sun ELC, which IIRC was the color one (the SLC being 1 bpp, not even greyscale.) There's a project called "Xkernel" (I can't find it any more since some people named their protocol development test suite "x-Kernel", sigh - stop poisoning the namespace!) that lets you netboot it as an X terminal. It's really only good for nerd factor, and the fact that it's cheap as hell. I wouldn't ever buy one without RAM though, because THAT can be expensive :)

Re:Home solutions?

[julesh]

Just something compact with most of the room only needed for monitor, keyboard and mouse.

If you can find space for a PC within 10m of each of the points you want to use it from, you could hook up multiple monitors, keyboards and mice. You'll need powered USB hubs within 5m of the PC for the mice and keyboards. With a little work, Linux can be made to run independent desktops on each.

Re:Home solutions?

[piranha(jpl)]

A combination of X.org and Linux do an awful job for running multiple, independent X displays. Some things that work okay in a Xinerama or dual-screen configuration (X jargon: 1 display, two independent screens, not like Xinerama) fall flat when you want separate displays. First, you're at the mercy of your X display drivers. I know the nVidia binary driver works okay with Xinerama on my dual-VGA card ("Twin-View"), but neither the nv or the nvidia drivers can drive two separate X server processes for the same card and different connectors. There's also compatibility problems if you'd like to use two separate cards: I had an nVidia dual-VGA PCI card, a 3Dfx Voodoo3 2000 AGP, a 3Dfx Voodoo3 3000 PCI, and some other forgotten card. The only combination of two cards that I could get working together reliably with two separate processes were the two 3Dfx cards. Also, running long lengths of VGA cable may be expensive and result in poor quality. It's probably a "choose one of cheap or clear, but not both" situation. A single Ethernet cable is much thinner, more flexible (physically and conceptually), and supports longer runs than VGA and USB.

Re:Home solutions?

[piranha(jpl)]

All iMacs win for new enough OpenFirmware to support netbooting. Certain iMacs win for having no cooling fans. That means: remove the hard disk. When you're not using the CD-ROM drive, you have no moving parts.

Re:Home solutions?

[julesh]

Also, running long lengths of VGA cable may be expensive and result in poor quality.

I didn't make it clear that to achieve that length, you'd really need to be using DVI.

Regarding compatibility problems, the people I've talked to who've done this (I'm planning on doing it myself within the next year) have used framebuffer-based X servers with acceptable results for most applications. The Matrox 1x PCIe graphics cards tend to come highly recommended, not least because on most modern motherboards you can stick 3 or 4 of them in.

Re:Thin Clients! The Future of Computing Since 199

[Anonymous Coward]

Don't forget "Linux on the Desktop in 2 years"

*hides*

They are fairly popular in call centers

[sczimme]

And, in all that time, I've yet to personally see a company actually doing it.

Obviously such companies must not exist since you have never seen them... (Sorry - I find that logical fallacy quite irksome.)

The new+improved dumb terminals are reasonably popular in call centers. The terminals offer detailed granularity over the limited and very specific needs (including required permissions) of the call center employees.

I have seen terminals that run Linux as well, and appear to be sold with the server and requisite applications as a package.

Re:They are fairly popular in call centers

[elrous0]

Obviously such companies must not exist since you have never seen them... (Sorry - I find that logical fallacy quite irksome.)

I'm not saying my experience is typical. But if this truly were a trend (as indicated in the dozens of articles I've read over the last 15 years or so) one would expect it to at least be NOTICEABLE to the typical office-worker/geek such as myself.

As for the call-center/"front desk at autozone" thing, that wasn't what I meant (and these articles and lofty predictions clearly didn't mean that either). I'm well aware that dumb terminals have been and continue to be used for modern cash registers, teller machines, etc. But I mean for general office use.

-Eric

Re:They are fairly popular in call centers

[sczimme]

Unless you are a consultant, you probably haven't spent time at enough different organizations in the past 5-10 years to gauge the overall industry usage of dumb terminals. (I'm not saying I know everything about all industries, but I have seen a lot of widely-varying environments.) Even if you are a consultant, if you spend time only at certain types of companies, you won't see a lot of variation.

You shouldn't conflate "call center" and "front desk at AutoZone": desktop terminal != Point of Sale (POS) system.

I did some contract work about four years ago for a small manufacturing company: all workers (factory and office) were on Citrix terminals. However, the PC model is still prevalent in most office environments: it is a known quantity, and the issues have generally been solved. Conversely, people might not be aware terminals even exist. In a lot of cases - as you mention with the general office worker - terminals might not represent enough of an improvement to justify the expense and work of moving away from the PC model.

Re:They are fairly popular in call centers

[StormReaver]

"But I mean [dumb terminals] for general office use."

Most of the departments where I work use text-based dumb terminals for most operations. They are actually full PCs with telnet interfaces, but they are essentially dumb terminals. The main reasons we didn't use X-Window terminals were:

1) The bandwidth at the time was limited, and full GUI interfaces saturated our network. With everything now being gigabit fiber, this wouldn't be an issue anymore.

2) Most of our programmers at the time knew nothing about GUI programming. This is still a problem, as all the primary systems are still text based and maintained by those same programmers. The apps are slowly being replaced, but management has allowed some of those apps to be written without consideration for remote execution (C# and C++ Builder, with the latter thankfully being abandoned).

3) Even now, only two of us have any experience with any X-Window toolkits, and only one of us (me) has any extensive experience (Qt). Fortunately for me, I am able to write all my desktop apps with Qt, and I keep remote execution in mind when designing my apps.

4) The cost of X-Window server licenses.

All this took place before I arrived and started introducing Free Software. There is now nothing technical holding us back from basing all our operations on Linux X-Window terminals for most departments, and doing so would be a very smart move. The only obstacle at this point (that I can think of) is scanner support. We are imaging all of our historical documents, and SANE does not support the high volume scanners we use.

Re:They are fairly popular in call centers

[BumpyCarrot]

My current employer (Capita) makes extensive use of dumb terminals.

Live in the UK and not heard of them? Understandable, other companies outsource to them, namely the entire Dixons group, and a ton other companies. Not a marketing pitch, just realise that the building I work in is just one installation and they recently bought another building in Nottingham, as well as the collection of buildings I have no reason to deal with.

Re:They are fairly popular in call centers

[geekoid]

wether or not there is something wrong with that type of arguement depends on the context.

Just because I hven't seen a giant purple teapot circling the sun, doesn't mean there is any chance that one exists.

Re:They are fairly popular in call centers

[harborpirate]

Fairly common also to see PCs running terminal emulators in call centers. It allows the terminal to connect to multiple servers (which are often running completely different incompatible platforms) at the same time, as well as do PC stuff (office, email, web browsing, etc) without loading down a central server with a lot of unnecessary "wasted" cycles. Call centers are generally full of folks who are great at wasting CPU cycles...

And really to me, thats the reason why the dumb terminal idea breaks down a bit in many environments. Scalability is a major issue when you've got big iron. When the big iron isn't big enough, you've got a difficult choice: either buy another huge slice of big iron, or let your users suffer with less CPU cycles than they require. When you're talking about a business, investing millions to add another piece of big iron doesn't look too great when the majority of the CPU cycles you just bought with it will go unused for months or perhaps years.

With PCs, you just throw down workstations on desks and you're good to go. The cost scales directly with the employees, and thats a big reason why its so attractive for many businesses.

Dumb terminals are great for certain situations: when you have a known number of users that use a known set of applications. At least, within a certain tolerance, you obviously don't need to know the exact number of either one, an approximate upper bound will do. Then you can be very comfortable knowing that your users have all they need in terms of functionality and CPU cycles. When both of those are the case, there's no doubt that dumb terminals are a huge cost saver.

PCs, meanwhile, excel in the opposite environment: where your users need a changing range of applications and/or the number of users is a moving target. This is especially true of the case when the user count is a vacillating target whos general trend is upward.

In a modern large corporate PC environment, application installations can be controlled from a central environment, PCs are set up with a standard image, and often users do not have rights to modify a number of settings. This helps keep maintenance down a bit in comparison to previous environments. No doubt that overall though this still does not meet the level of a term service setup.

So, all in all, I think its about the "right tool for the job". Certain environments suit a dumb terminal setup, and for those that do a definite cost savings exists. But for those that don't, dumb terminals can be a bit of hitting a nail with a screwdriver. Sure, it works, but it'll take longer and you might even hurt yourself.

Thin Client

[wolf31o2]

I think the author's choice of the word "dumb terminal" is unfortunate, as these sorts of systems are anything but dumb. Most people think of these as a "thin client" instead these days. However, the author is spot on about how these can drastically reduce the cost of a system. One company that I have done work for decided to start using their old systems as thin clients. I built a custom software set for them. The hardware platform was old Dell Optiplex GX1 machines, with the hard drives removed. The machines boot solely off the network, load Linux, then connect to the appropriate resource. This has saved the company a ton of money, not only in the support costs required to maintain these machines, but also in the disposal of this aging hardware and the savings of not having to replace the machines with newer ones.

For a company just starting out, buying thin client hardware is a good investment. It shouldn't need updating of any kind, and most hardware is field-programmable anyway.

Questionable Language?

[Speed Racer Sr.]

Anyone else object to the phrase "Dumb Terminals" "TM"? This language isn't needed, no need to use such insulting language. "TM" Dual Twin Turbine Racer Car Driver of the Year. "TM"

Re:Questionable Language?

[Roger Carmichael Jr.]

I also object "TM". Dr. Speed Racer "TM", thank you for pointing this out. Quad Twin Turbine Racers Association President. "TM"

Dumb Terminals

[Anonymous Coward]

Have support more tubes for connecting to the internets

Missed the point

[plopez]

FTA:
Because the terminals have no moving parts such as fans or hard drives that can break, the machines typically require less maintenance and last longer than PCs. Mark Margevicius, an analyst at research firm Gartner Inc., estimates companies can save 10% to 40% in computer-management costs when switching to terminals from desktops

The TCO is not in hardware, but in software and support. What makes a PC network so horrendously expensive (Gartner estimated 4K to 10K USD per seat per year at one time) is the army of technicians required to keep them running. Dumb boxes allow centralization of support which is much less expensive. So you spend less on hardware and labor, and use some of those savings for a really, highspeed network and a really reliable server cluster.

BTW, now-a-days this is often pronounced 'Citrix' or 'Remote Desktop'. Same basic principle.

Re:Missed the point

[Kjella]

The TCO is not in hardware, but in software and support. What makes a PC network so horrendously expensive (Gartner estimated 4K to 10K USD per seat per year at one time) is the army of technicians required to keep them running. Dumb boxes allow centralization of support which is much less expensive.

Central documents (yes, users are supposed to stoer things on shared drives, but unless you bolt them down...)
Central settings (no fiddling around customizing the machine, which you'll easily lose)
Drop-in hardware (I know places that have a "support closet" of spares, rather than on-site)

All of these things means there's no reason to have decentralized support, because there's nothing of value at the edge.

However, you do need some perspactive on how far to push it. I remember one solution which was suggested and just so barely avoided, that involved a 550km link to the server at the central office. That link goes down and you've got nothing, not even notepad or a printer.

One word

[LS]

Google.

They are buying up lots of companies that provide Office-type applications, web-based or otherwise, and are also providing business customized versions of their services. Perhaps they are converging towards this type of model...

NC warmed over?

[Sneftel]

Oracle called. They want their ten-year-old miserable failure of an idea back.

Re:NC warmed over?

[flyingfsck]

You must be very young. Never heard of the sadly departed Digital Equipment Corporation and the DEC VT100 terminals have you?

What is today called an ISP, used to be known as a Computer Bureau, thirty odd years ago. These places ran DEC mainframes or minis with an army of terminals scattered throughout a city to run UNIX accounting systems.

Re:NC warmed over?

[Sneftel]

I have, actually. And I remember when we stopped using them. The stupid idea was trying to bring them back.

These aren't "dumb terminals" (TM LSI)

[argent]

The things they're describing aren't "dumb terminals" (which is a TM of Lear Siegler International), by any stretch of the imagination. They're dumber than Xterms, but they're smarter than any of the "smart terminals" that LSI was competing with.

More like a fancy PDA than a simple PC

[ewg]

One manager used the term "culture shock" to describe the user's experience switching from a full PC to a thin client. That sounds about right: thin clients are sold as a cheap alternative to PCs, but end up functioning more like a fancy PDA.

I work for an .edu

[nsanders]

Our department here has looked into moving to dumb terminals to replace our current Linux desktops. Having a single server with 200 some dumb terminals would make updates and auto mated tasks a lot easier. The main reason we haven't switched is because we are a math computation/research department and a lot of our users make use of the core 2 duo's provided to them in their desktop machines. But for staff, we are certainly looking to move.

author

[DaMattster]

For the most part, the author of this article seems to be on target. However, one of his reasons for not going to Thin Clients is just so plain wrong that it is worth commenting on.

Simplified terminals can translate to less freedom for individual users and less flexibility in how they use their computers. Without a hard drive in their desktop machines, users may place greater demands on computer technicians for support and access to additional software such as instant messaging, instead of downloading permitted applications themselves. Analysts say it takes time for employees to get used to not controlling their own PCs.

Most companies lock the desktops down so tightly that the employee has no freedom to install applications whatsoever. In fact, one company I worked for allowed customization of keyboard, mouse, and background display only. And, you had a limited range to choose from on approved backgrounds.

In fact, going to thin clients, from a managerial stand point makes an incredible amount of sense. The downside is the phasing out of the desktop technician. Many people would be facing unemployment but networks would ultimately become more secure and stable. The Active Directory and SMS woes would be gone because instead of having to manage several thousand desktop PCs, the IT professional would be looking at management of a few hundred servers.

Re:How many times... (about SunRays)

[Anonymous Know-It-Al]

Having worked for Sun I must say that this is one of the things I miss the most. Apart from being able to bring your card to any colleague when asking for advice, the absence of noisy fans is really noticable.

Re:Thin Clients! The Future of Computing Since 199

[elrous0]

It will be right next to the articles entitled "Why aren't there more women in IT?" and "Is PC gaming dead?"

-Eric

I welcome our new dumb overlords

[ahodgkinson]

I would welcome the return of dumb terminals, provided they have the traditional black background with green or orange foreground. The (default) bright white settings of most PCs hurt my eyes.

..and I'd also like the 'gold' key to come back too.

Re:I welcome our new dumb overlords

[Richard Steiner]

That's one of the reasons I still use fullscreen text applications to read mail and USENET -- the cyan and green on black combination which I tend to use is very easy on my eyes. :-)

One laptop as a terminal?

[flyingfsck]

Using terminals is only useful, if they are much cheaper than PCs. The old DEC VTs were much more expensive than a PC, which caused them to fall out of favour. A terminal should cost about $100 to be worth it. Maybe the $100 laptop project will make good terminals and then the office workers can get their daily exercise by winding them up...

Sunrays on eBay

[BrianRoach]

I did this for my small business, and it rocks.

I run an online and brick-and-mortar retail shop. Starting out on a budget is always a challenge, and for our computing needs I went with eBay (this was 3 years ago):

Sunblade 1000 workstation with 2G ram, 2x700mhz uSparkIII, D1000 raid array: $700
Sun Ray thin clients: $30 a piece
21" monitors: $50 - $100 a piece (Now a days I'd prob go with cheap flat panels)
17" sunray 150 (monitor/thin client combo for the counter) $70
HP Laserjet 4mp+: $50 (And it's still cranking out pages 3 years later)

Done. Everyone has a nice setup on their desk, I have one machine to admin, and life is good. We don't need any MS software, so that wasn't an issue for us (the Sunblade is running Solaris 10)

The sunrays really work great ... I bought a couple to use at home as well because they were so cheap on eBay and the sunray server is available for linux (and I think Windows now).

- Roach

Dumb Terminals for Dumb Clients

[SatireWolf]

Personally, I applaud the idea of dumb terminals for dumb clients. Most people are too ignorant to operate a fully functional battle station, I mean windows computer. Besides, at least when Mr. Smith figures out how to get his Doodad Game 9k to run on the Terminal server and it starts spitting out 5 googazillion email messages per second and the network guys start running around like chickens with their heads cut off, it'll only be one 8-16 processor server with 10GB x 4 worth of bandwidth at its disposal. I mean seriously, who needs to fix a measly little celeron box with a 100MB connection when your terminal server is romping and stomping the entire global intranet?

data is not lost when a dumb term is stolen

[mrjb]

"Because the systems are designed to keep data on a server, sensitive information isn't lost if a terminal gets lost, stolen or damaged."

Yeah, but what if some thief runs away with the mainframe?

Re:data is not lost when a dumb term is stolen

[3.5 stripes]

He gets about two feet before his back gives out?

Re:I've been working at a thin client site for a b

[Lehk228]

Excel?

windows is not designed for this kind of use of course it is going to suck

We have all been using dumb terminals for years

[mrbill1234]

It is called a "Web Browser".

I'm surprised thin clients have not become more common - all you need is a screen, a keyboard, some memory, perhaps some local flash, and a network connection.

Someone who does it

[Anonymous Coward]

Did some consulting at Rothschild where they use dumb terminals (ok, thin clients - whatever) for most users. The big claim that it saves costs doesn't really pan out. Maybe in an 'ideal' implementation it might but in reality when was the last time your boss said 'how much does it cost to do this RIGHT, i'll get you whatever you need'.

So what happened there? Well it was almost a daily excercise to pull servers out of the pool because people couldn't log in. Responsiveness was...medocre. Ok for 'outlook + MS word + one MSIE'. When I opened 5 MSIE windows while doing some research my terminal slowed to a crawl. Forget anything graphics-intensive or video. Sound/USB? Usually worked. Usually. The terminals were small and had no moving parts but pricing wasn't that much more attractive than cheapy desktops today. Plus when one stopped working it was trash. I can swap out PC parts if something goes wrong. Having done desktop for 10+ years I can honestly say their 'desktop' problems (the ones not directly related to being thin clients) were almost entirely the same as every other client i've worked for.

Oh, and the kicker? Eventually they stopped buying the thin terminals and used FULL-SPEC DELL PC's to connect to their terminal servers. WTF?

Oh, and i did see a 'terminal laptop' or two in the junk pile. It's basically an off-brand cheapy laptop with a CF card for a hard drive. Why bother? Its small to carry around but useless outside the office.

Overall, my thin client experience was a thumbs-down. They did *NOT* save money. They did *NOT* lower support requirements. They did *NOT* improve the user experience one iota.

We use them. It's generally good.

[mgiuca]

At the University of Melbourne (Australia) department of Computer Science and Software Engineering, we have a dumb terminal architecture (UNIX) for most of the machines. There is a cluster of central servers, and we log in from anywhere in the building with these terminals. They get a GNOME X server so we get a full desktop, and we work from there.

It's rarely clogged, and it provides us with instant access to our home directory from anywhere in the building. Furthermore, we can SSH in from any computer in the world. So it works really well, and of course the entire department gets updates when they happen. (Note: This isn't just for access to your files, but all of the applications available in the unix environment).

This is as opposed to the Windows and Mac computers that are installed in certain rooms of the facility - they are all desktop computers, and while you can still access your drive using samba, each computer has its own software installed. This is frankly quite annoying, since there are differences between each machine - some aren't configured properly, and also you have to set up all your prefs on each computer you use - a maintenance nightmare and not fun for anyone. So most of the time we just end up using XWin to log into the Unix servers anyway.

Thin clients are good in PRACTICE

[Paul Doom]

Until you have worked with thin clients you don't know what you are missing. We have over 500 employees spread over the country in offices and a centrally located, 3 person IT help desk. (I think they spend at least 75% of their time on laptop or other non-terminal issues.) You ship out a router, a switch, a printer, and some Wyse Blazers, and that is it.

PROS
* The base models (like Wyse Blazer) are still quite cheap, and for the average worker, just fine.
* Huge security win. Reduces many threats and reduces the tempatation for users to do foolish things. "I like using the local Starbucks WiFi for Internet access..."
* No more users installing junk and breaking things. (Users don't like it at first, but most things are web based now anyway. Not a big loss.)
* No more crashed drives and messed up PC registries.
* We can roll out an app without installing anything on PCs.
* The user gets the same experience everywhere.
* We can provide a remote desktop over the Internet; same experience. Eliminates the whole issue of GoToMyPC, etc.
* No more local backup issues or other local file problems.
* No more worm infected PC hell. (Or PC security patch/AV updating hell)
* No more local desktop support needs, shipping PCs back and forth, etc.

CONS
* Network quality and performance become more crucial. (Our typical WAN link is only 256Kbps and fine for a small office.)
* You need a terminal server farm. (Not that huge a cost considering current PC server strength.)
* CAD/CAM, graphics work, etc. still need local PCs.
* Desktop video becomes much harder.
* Some apps don't work or have huge screen update needs. (Core Office, web apps, etc. are generally just fine.)
* Vendor lockin for thin client software.
* If the network goes down, they are 100% dead in the water instead of 99% dead in the water. I guess with a PC they could edit a local Word doc or something, maybe play some solitire. (Ok, they would like to have their address book. I think that is the major complaint.)

It depends on the organization. Many places have already centralized data centers moved a lot of systems to web apps. Things really are all moving onto the web. Do you want to support a PC just to run a web browser?

Re:Thin clients are good in PRACTICE

[Anonymous Coward]

* Desktop video becomes much harder. Actually, this paper claims to provide full-motion video with a new thin client architecture called "THINC": http://portal.acm.org/citation.cfm?id=1095810.1095 837 Now I can't find out where to try it out, but it doesn't seem like smoke-and-mirrors since I'd think that the good people refereeing ACM SOSP would be hard to fool. Hope they make it downloadable soon.

Re:Thin clients are good in PRACTICE

[Neo-Guy]

There are ways to achieve full-motion video with a "thin client". For example, there is software that streams the entire OS and applications (Windows Media, etc) down to a PC and then runs locally in RAM. There is no local hard drive, and the information is streamed down from the server to the PC when needed. Since the OS and applications run locally in RAM, you get the best of both worlds - local processing speeds and performance of a PC and the safety and security and manageability of a thin client.

Re:Thin clients are good in PRACTICE

[Citizen of Earth]

How prevalent are disk-free PCs? These would offer most of the benefits of thin clients but give you full, dedicated PC power for each user.

Re:I've been working at a thin client site for a b

[140Mandak262Jamuna]

It is not the network load that is the issue here. The short burst activity followed by long idle time that makes the applications respond slowly.

In our shop we use clearcase to do the source code management. To get developers stable update time, there is a code freeze between 3AM and 8AM. Most of us schedule our machines to update our sources sometime in that period. The network load is something like 100 developeres updating about 45,000 files each including four remote replica syncs. We could easily handle that kind of load and we are a very small company. Just made grade to Russell 2000 index. Nah, it is not the network load.

What kills them is the usage pattern. If you run Excel in one server and GUI in another everytime you move the mouse there is a burst of mouse moves to be transmitted to Excel, and its response to roundtrip back to the cursor on the screen. Many of these pure PC software is not designed to work that way. The network is not good for very short burst of activity followed by long idle times. Establish a connection and pump million packets from one end and get it at the other end, it will work flawlessly.

The new kind of Web2.0 and browser based applications are designed from the ground up to be asynchronous. They can work very well with thin browser running on dumb terminal with all processing done in the server. Google's office suite is primitive. But its spreadsheets and wordprocessing are really big breakthroughs. After debugging the process of editing a spreadsheet over an internet connection, it would be trivial for Google to offer to host that app in your server. Over intranet, it would work flawlessly.

Large Companies = Large Problems

[boxxa]

It still doesnt solve the problem of the user being the worst part of security and problems. Someone runs the wrong code on that mainframe and you might be in a whole new world of hurt. You do save money on repairing a PC but I would perfer to swap out a desktop at an office and get the user back up and running than going and repairing a corporate server that prevents the whole company from operating.

Recently in my county I work at, the county clerk mainframe died. All the clerk computing that used dummy terminals on that mainframe were unable to be used.

Secondly, imagine running all your applications on a remote site off the central server. Again, saving money on workstations but there is terrible slowness over the internet lines.

I live in tornado alley, soooooo yes.

[ysaric]

So, yes, a few times a year we end up in the tornado protection areas of our building, and a couple times a year we find ourselves without power for certain spans of time. It's a bigger problem on the manufacturing side, where a power loss can have more significant effects. No, I don't know whether the company cares or what they're doing about it.

I included it because it is one of the two circumstances that definitively makes this worthless POS on my desk even more useless. And yes, sporadically there are server problems also. In both cases it would make my time less of a waste if I could do something, especially when doing a specific something at that specific time happens to be important. And that's just one of the gripes about this setup. I hope that is responsive.

What I like is that the responses this comment is receiving is focusing on the smallest of the issues and treating it as if it's the biggest one. Makes a ton of sense.

Re:I live in tornado alley, soooooo yes.

[fabs64]

What you don't realise is that by having your own PC you're just changing the times when you're out to different ones.
With a terminal server, the server goes down, everyone can't work and every IT guy frantically tries to fix that one server, with PC's, computers go down all the time but just separately and the IT guys spend their days fixing individual machines.
If anything your downtime should be worse with an individual PC, because the terminal server should be rock solid compared to it.

The fact is the downtime is just more noticeable because it's everyone at once, but overall imo it would be less.

Re:I live in tornado alley, soooooo yes.

[Anonymous Coward]

Umm, hopefully for this setup there would be at least 2 servers with failover. Once you start getting fancier servers and expensive terminals instead of PCs running terminal software, the cost savings at purchase time probably evaporate (I'm assuming Linux, using windows will mean lots of licenses, costing even more..) The savings are with maintenance and administration. Usual scenarios:

          1) Every machine is backed up. In case of machine failure, restore to another machine, or at least restore files the user has "lost". Needless to say, quite time consuming.

          2) Make the user save everything to a file server. Backup the server. In case of machine failure, they may loose files if they didn't follow the rules and saved to the desktop or whatever, and they also probably had the machine "set up" the way they liked -- even if it's pretty restrictive, people tend to move the windows around a little or the like. Unless a totally standardized image is used, the new computer also tends to behave a bit differently from the old one.. not worse but some users stress out over this. Additionally, if the user can use a web browser etc, they'll probably lose bookmarks etc. as well. I guess for Windows the user's "profile" can be stored to the server and read back, helping some.

          3) No backups at all, and probably no spare PCs either. Holy shit! But, more common than I'd expect. A smallish call center I worked at a bit, they didn't even appear to have a single spare PC in case one of the (I'd estimate 6-8 years old) PCs we were using died.. luckily, they did not croak while I worked there 8-).

          4) Terminals. This is like the server scenario, but users *CAN'T* save to the local desktop, and any personal tweaks are saved to the server too. Machine died? Swap it out, and it's just like the old one.

It is all about support

[sheldon]

Considering you can pick up a PC for about $1,000... The thing with the Citrix solution is you need to buy the dumb terminals for $500/each, plus you also need to buy a hefty server on the back end. Figure $50k or so for every 30-40 users.

So you're not saving anything on hardware.

But for every 100 pc's you need one support person to handle the various needs, whereas you can likely handle say 500 dumb terminals with a single person(now mostly doing Move/Add/Remove, rather than repairs so it's a cheaper resource), and multiple consolidated citrix servers. So while you have that extra hardware cost up front, that hardware will last 3 years or so on the server side, longer on the terminal side. But you don't have the recuring costs of the support persons.

Now the downside. My girlfriends company uses these. She's an accountant for a big grocery chain. In general they work.

Occasionally though, the citrix server will go offline. Since groups tend to be put together on a single citrix server, because that's the server which has installed their particular set of applications. It means their entire group is out of work until the server is back up.

For whatever reason, this seems to happen about once every three months, where they are out of work for about two hours.

I don't know how these things are setup over there, if you can load balance, or cluster. Clearly they need to divide a work group up onto multiple servers, as they take phone calls from vendors and it's useless if nobody in the group can lookup the status of something.

But really it's not a bad deal, if you are talking about users who do nothing but data entry into one or two apps, and then use email and word/excel. Any users which are more advanced, loading custom apps regularly, etc. it won't work for.

We use them at our company, because you can run these apps remotely. So instead of hiring temps and bringing them in house, we can farm out this work to a remote location, because it's expensive to keep around extra office space for those occurences where we need extra help entering in applications for a month or so.

Re:Thin Clients! The Future of Computing Since 199

[D4rk Fx]

Don't forget Duke Nukem Forever! I can't wait!

dummies!

[Grinin]

I'm even starting to see people using remote terminals in small / medium sized businesses which is a great sign. Easier to manage if you use the right environment.

LTSP

[scarolan]

We actually implemented thin clients at the company I used to work for. Since the IT budget was tight, we used old Pentium II and III machines along with a Linux server running LTSP. What we found was that although the dumb terminals worked ok, the server choked with ten or twelve users all running Firefox, Open Office, and especially Adobe Acrobat. There were times when an end-user would open a PDF, and you'd see a noticeable slowdown on all the other machines. In the end we put each user on their own desktop box with home directories mounted over NFS.

Re:LTSP

[Nexus7]

When you have programs that pull a lot of data such as images from the internet (that is, web browsers) and graphics-intensive work such as your PDF viewer, then you use local apps in LTSP. For example, Firefox would run locally on the client; you can also get sound on the client with local apps. Each client is then pulling stuff directly from the internet, and not moving all that stuff through the server, and also not using server memory.

PS: I mean graphics-intensive in the sense of having to redraw the screen a lot, not intensive as in gaming.

Re:LTSP

[scarolan]

At the time we set this up, running local apps was still on the drawing boards. Besides that - it sort of defeats the purpose of using a thin client to begin with. If you're going to run apps locally, you might as well go whole hog and run everything locally, and store the data on a server.

Re:LTSP

[Nexus7]

I wouldn't agree that it defeats the purpose of having thin clients. No configuration is done on the thin client, it's all on the server. Once setup, the executables are moved (over the shared FS) and run on the client, and when done you can simply shut the client off; it's just an X session. You still have a single point of control. You get all the advantages of thin clients, at the expense of a more sophisticated configuration. But with that, you also get to use the memory and bandwidth of the client, meaning the server doesn't have to be a very big machine. Since a lot of LTSP thin clients are older PCs, this approach puts the memory already installed in them to good use.

Re:LTSP

[scarolan]

In our case this would not have worked. The machines we were working with had 64mb of memory each. As I type this, Firefox is consuming 45mb of memory (and that is with only ONE tab open).

Don't get me wrong, I think thin clients are fantastic for certain environments. I think AutoZone has some kind of custom Linux distro setup. At least I thought it was a KDE desktop I saw on the screen when I bought some parts there. But all this system had to do was open a browser to the company's POS system.

At my office we had sales reps who needed to be able to browse the web, run an email client, open Word docs and PDFs on a daily basis so the overhead was just too much for the thin-client system to handle effectively.

One of the by-products of today's powerful computers seems to be sloppy programming that does not make efficient use of memory and CPU cycles. Instead of optimizing code to be lean & mean less skilled coders can write stuff that works, but uses a lot more memory and CPU than it has to. In other words, most modern software is not optimized for multi-user environments on a single machine.

I've been there, done that, and it works sometimes

[Yonder Way]

For most /. users, this is not going to work as a desktop replacement. But for most general office workers, this can and does work.

I don't have much experience using Windows as a terminal server. What I do have is experience using CentOS Linux as a terminal server, with HP thin clients on the desktop. It works phenomenally well.

The thin clients themselves cost about $350 a pop in small quantities, closer to $300 a pop if you do a mass migration. You put some of your funds into nice displays, but most of your funds into the back end server. Lots of cores, lots of RAM, very fast disk. Plan on replacing it every 2-3 years with newer faster hardware.

The vast majority of the users will be idling the processors most of the time, so long as you disable fancy screen savers and other CPU-wasters on the central terminal server. Depending on what kind of hardware you use on the back end, you could potentially have hundreds of office workers happily working with one back end server. Honestly, though, I think the ideal way to go would be with something like an IBM pSeries box with a bunch of department level LPARs so you don't have one department hogging resources and crapping all over everyone else.

The thin clients can boot off a local read-only flash drive, but better yet have them boot off a tftp server so you can more easily keep their software levels up to date.

X11 has been doing this stuff for ages. The technology is pretty mature. :) Though I am not thrilled with the security, nor am I thrilled with the state of remote audio in X11. Those are the two big caveats I would warn you of if you're considering something like this.

Other than those issues, I have been thrilled with the technology. It's an idea that was pushed out there before the technology was ready before. Now the hardware has caught up with the concept. It's worth another look now.

"Diskless" + Disk Cache

[SanityInAnarchy]

This has been talked about on and off for awhile now. Basically, any kind of "thin client" can't possibly be cheaper than, say, some random Dell. Get your random Dell to boot off the network, have all storage be on the network, but use AGGRESSIVE local caching -- figure the standard-ish 40-80 gig drives for a local cache -- and it should be almost as fast as if you had the box to yourself. Local disk also means you have some swap.

We talk about "hibernating", too -- and the concept of, say, having your session stay open on the server while you switch to another thin client. But, there have been multiple specs for years now for how programs should save a session. Think about when your desktop computer hibernates -- it basically flushes all RAM out to disk, then restores from disk->RAM when you boot back up. A lot of RAM is junk, though -- imagine programs handling this automatically. Instead of saving OO.Org's entire RAM image, just tell it "we're shutting down" and have it save some basic geometry, save the open documents to a temporary file, and shut down.

This kind of thing has generally been handled by one or two things -- for instance, GNOME supports "saving your session", but so far, only Nautilus seems to pay attention.

So, that particular approach may not allow what we want now, but if apps were written with this in mind, you could "save your session" from your "diskless" machine, then switch to another box and "restore", and very quickly have exactly what you were working on back.

I think this is a lot more sustainable than a true thinclient solution for a few reasons. It may be cheaper -- you need far less bandwidth, and the "main server" can simply be a fileserver -- which also makes it very easy to backup/replicate in case you have a disk failure or something. It could certainly feel faster to the end-user -- network issues only affect files, and most of your files will be cached locally, making it as fast as a standalone workstation. You get all the admin advantages, with the additional bonus that you aren't bound to any one company's idea of a "thin client" -- just grab any computer with roughly the same architecture, plug it in, and go.

And there's the laptop issue. Chances are, a solution like this would be much easier to integrate with someone's laptop. In fact, you could even let it think it's "netbooting" if the filesystem used supported full disconnected operation.

Only one problem: Most of the software just isn't there yet. Apps don't know about saving sessions. There's also been almost no improvement in the filesystems for quite some time now: InterMezzo is pretty much dead, and Lustre costs money. So, probably your best bet is Coda or AFS, and each have plenty of their own limitations.

power outtage, what about godzilla attacks?

[gad_zuki!]

POwer outages? Hell, those are excuses to not do work. I cant imagine what kind of special wiring problem you must encounter that just affects the server room but not the plugs running your desktop and power-hungry monitor. Or are you saying that if you had a normal laptop you could polish up that word document while the rest of your coworkers are thinking 'why is that moron still working?' Seriously, there are some decent criticism of thin client implementations but this isnt just one of them.

Secondly, do you have permission to install software? I can give you a bad ass workstation and limit you to a limited user. The problem here isnt the thin client its policy. Most large environments have some kind of go-between/approval for software installs or all the users would muck up all the machines with bonzai buddy or whatever crap passes for the amusement only a spyware animated gorilla on your desktop can provide.

>They at least can continue work with documents and files stored on their local drive.

Who uses their local drive on a lan? You should be using a networked drive that gets backed up nightly. Especially with all those power outtages.

Re:power outtage, what about godzilla attacks?

[MightyYar]

Who uses their local drive on a lan? You should be using a networked drive that gets backed up nightly. I've tried to do that in the past, but I seem to end up with corrupt documents (especially PowerPoint for some reason). I started making a local copy before I worked on a document just in case, but then decided that this was stupid monkey work and just worked on the local drive. Then I set up an automatic backup to the network drive each night.

I think that the corruption happened more with Windows 98, but it could have also happened on 2000 (which I didn't get until 2005!).

Re:power outtage, what about godzilla attacks?

[Thomas Miconi]

I've tried to do that in the past, but I seem to end up with corrupt documents (especially PowerPoint for some reason).

Say what? If your network drive actually corrupts your data then your company has a much, much bigger problem on its hand than choosing between thin clients and workstations.

Using Thin Clients Now

[happyslayer]

I've recently installed (and I'm maintaining) a Linux Terminal Server Project (LTSP) system for a medical office. Once you get around a few peculiarities, it works great.

• Patient comes in and gets vitals checked and recorded in Room X on terminal X.
• Patient then gets moved to Room Y with Terminal Y, where the doctor brings up the same records.
• Doctor records findings and prints out necessary prescriptions on an local or remote printer, depending on need, speed, etc.
• Records are available for any patient at any terminal.

Because the needs are very straightforward, and the same data must be available at all treatment rooms, LTSP was the ideal fit. Upgrades and maintenance are as easy as working on a single machine (but I can walk into any room to do them while the staff is still seeing patients!), and backups/security are a snap.

We recently added another terminal (but it could have been 5, 10, or 20), and all I had to do was unpack the machine, add the MAC of the new terminal to the server's configuration, and give the workstation a name. Voila! Instant access to all applications.

Speaking from my experience, LTSP is ideal for situations where everyone needs access to the same data, and you don't want multiple copies of (sensitive) files floating around.

As an aside, I had to write the record maintenance software from the ground up, and the total size is only 350K to tie all the normal Linux parts together.

Dunno, what they do in India?

[gelfling]

The few of us left here are made to work at home on our fully depreciated laptops. Everyone else has been replaced by someone in India, China or Brazil. What do they do there? I'm guessing they have greybox minitower PCs that are built with a minimum of hardware.

And why does /. try to resurrect the whole thin client debacle again? Because the whores at Gartner and WSJ say so? What's their agenda? Because there IS one, you just have to look for it.

Re:Dunno, what they do in India?

[geekoid]

"Everyone else has been replaced by someone in India, China or Brazil."
I don't knwo where you live, but that certianly isnt true in the US.

But more to the point, someones location doesn't matter with the dumb terminals paradigm.
In fact, being able to look at what someone has done at any given time just by logging in to a central system is far more beneficial to a company then trying to get a status update across time zones just to be lied to.

Re:Dunno, what they do in India?

[gelfling]

Sure it does. As I said, we all work from home. Thin clients don't make any sense for that.

Nostalgia

[ajs318]

Ah, the good old days. At Aston Uni, we had mainly VT-220s and QVT-203+s. Some VT-100 clones, too; even at least one real VT-100 with the remotely programmable indicator lights! {Why did they stop putting those on terminals? Even the VT-220s didn't have them, not even emulated on the status line.}

VT-xxx machines were all character-mapped and text-only. But I suppose if you needed graphics, you could have a machine running just a very cut-down OS and X server, straight from ROM.

Re:Nostalgia

[fizzup]

VT-xxx machines were all character-mapped and text-only.

This is not entirely true. The VT-320 had graphics capability. I never used one, but I did use the VT-320 terminal emulation in PC-Kermit to connect to unixg at the University of BC. Matlab was able to draw graphs on the screen. (No GUIs, though, which is what I think you were getting at.)

Re:Nostalgia

[julesh]

At Aston Uni, we had mainly VT-220s and QVT-203+s. Some VT-100 clones, too; even at least one real VT-100 with the remotely programmable indicator lights! {Why did they stop putting those on terminals? Even the VT-220s didn't have them, not even emulated on the status line.

Over at Warwick, we had ADM-3es. Now there was a terminal and a half. So obscure that anywhere external you telnetted to was highly unlikely to have a termcap entry for it.

Re:Nostalgia

[lahvak]

That's true. For years, I didn't have a computer at home. I used an old Informer terminal, that was VT-320 compatible. I hooked it up to a modem and had it auto dial the university dialup server, and automatically telnet to the department server. It worked like a charm, and it did have some graphics capability. There was even a dvi viewer for it. The whole setup cost me $50 for the modem, I got the terminal for free from a friend who found it in the physics department next to a garbage bin. He grabbed it out of curiosity, but did not have any use for it.

Re:Nostalgia

[ajs318]

Ah, yes, I remember a few trips over to Warwick Uni on the 900 for awhile. That was in the days of Cheeseplant's House (wow, I got a great thrill writing my own version of something like that, many years later!) and Monochrome (kind of Slashdot forerunner, fondly missed). Those clunky ADM-3 terminals (evidently designed by somebody who liked vi) left me thinking that VT-100s were modern ..... mind, Aston had some old Newbury Data terminals (that were used with microprocessor development boards) that were even worse; the VAX couldn't handle them properly and tret them as a dumb terminal without backspace. When you tried correcting a mistake it would look like tji\ij/his (We'd recently scrapped an old Harris mainframe, probably where they came from.) And they had an absolutely awful display font, with bad attempts at rounding that really hurt the eyes.

Also, while it's correct that VT-3xx terminals had some graphics capabilities, I don't think they were bitmapped. And the charcell was incompatible with the VT-220, meaning that your carefully-created user-defined prompts (remember them?) had the odd row or column doubled. So did the Qume terminals at Aston, for that matter.

Re:Nostalgia

[julesh]

That was in the days of Cheeseplant's House (wow, I got a great thrill writing my own version of something like that, many years later!) and Monochrome (kind of Slashdot forerunner, fondly missed).

Cheeseplant was a little before my time, but Monochrome was quite popular in my day, and is still around. ssh mono@el.mono.org.

Re:Nostalgia

[ajs318]

Wow. Just like I remember it, only not monochrome anymore -- it's in full ANSI colour! I will have to sign up for an account -- my old login and password from c.15 years ago seem to have expired ..... Better not do it from work, though; it's more addictive than nicotine. But oh, the memories! See, this is what happens when you try to write a text editor ..... and then you introduce one more feature .....

And they seem to have the mother of all termcaps.

Oh, the memories! Thank you, thank you, thank you for this.

Perfect for home and school lab use

[Quevar]

This setup would drastically reduce the cost for anyone who has more than one computer to serve more than one person.

Home: I have wanted something like this for years. I would love to have a central server in my house and then have dumb terminals in various rooms. My wife wants to look at recipes in the kitchen while listening to her music that is on her computer. At the same time, I could be in the den writing email on the same computer. This avoids synchronization issues and allows all the data to be available at the same time from anywhere.

School Labs: Shared computers would be great for computer labs. Most of the kids are writing email or documents or surfing the web and using less than 10% of the processing power. Just add a little more RAM to the computer and hang 4 monitors/keyboards/mice off it and you just cut the price of a computer by 1/4th (plus a little extra for the memory). The software costs would even go down since they are per machine, not per user.

This makes sense for manufacturing companies

[UnknowingFool]

At my former company, they built a brand new plant. For each manufacturing station, they installed a brand new desktop. Back then, the Pentium IIIs were just released and every station had them. Each computer cost somewhere around $3K. The issue was that the manufacturing software ran in Unix, and the machines ran NT4.0. So each $3K machine had to have an X Windows emulator in NT to run Unix software. Because of these requirements, each machine had to have lots of HD and memory. They also had uneccessary things like a CDROM and a sound card. Hence the $3K cost. It was in the beginning of NT4, so it was unstable. Every week, the admins had to go to each machine to reboot it. Eventually, they bought remote software to do it.

At the time, Redhat was becoming noticed. I asked the CIO why we didn't go with RedHat Linux with XWindows on dumb terminals like Oracle's NetPC as opposed to XWindows emulator running on NT on a PC. His two reasons: 1) Not much support for Linux. 2) No money to hire Linux admin.

My response: 1) You can pay for RedHat support, and how much support did MS give us considering how much we paid for all the licenses and support. MS main response was to every issue: reboot the machine. 2) How much are we spending to have 6 people do nothing but reboot NT boxes? We could train some of them to be Linux admins. It wasn't well received.

Virtual desktops

[jaweekes]

What does /. think about virtual desktops? At my company we have someone who is pushing Virtual Desktops ( http://www.vmware.com/solutions/desktop/vdi.html ) although I cannot see the advantages over standard PC's. I would also think that Citrix (or something similar) would be a lot better.

Any thoughts?

I'd use em

[Cervantes]

I might have an opportunity to set up IT at a new, quick-growing oil business, and I'm definitely considering thin clients.

Costs are less, maintenance is much less, security is much better. I can install Gig ethernet in the whole place, put redundant servers in place with clustering for scaling up in the future, and with the roaming profiles, we'll be able to handle the inevitable "everyone moving everywhere" that comes with a growing business. And, with the damn dumb users not being able to install SuperHappyFunSmileyFaces.bat , support costs will be severely, wonderfully reduced.

If I was piecing together a system from parts, or trying to change an existing, broken infrastructure, I'd consider differently. But when you can set it up from (mostly) scratch, it just makes sense. The real cost of IT these days isn't hardware... it's users. Dumb users, who get a virus and don't tell you, who don't know how or where to save their documents (even when you set the login script to force their default save location to the network) and then lose them when they dump coke on their boxen, raging fucking moron users who "clean up" their computer, and then wonder where all their important stuff went, dumb wastes of space who wander over to another department, log in on a machine just sitting there, do some work, wander back when their station is finally working (what did you THINK would happen when you "organized" the power bar and ended up with 3 slots suddenly free???) and then wonder "where's my stuff I was just doing?", but you don't find out until 5 days later when they tell their manager they don't have their stuff done because IT lost it, which is the day after you junk that old piece of shit computer that had been sitting unused in another department for months...

Err, I digress. :) Thin clients are good. They stop the above. The End.

Hybrid Clients

[alohatiger]

I played with Edubuntu, which out of the box sets up a LTSP server. It's cool, but I think hybrid clients may be a better way to go: diskless, boot off the network, but applications run locally. You get less maintenance on the desktop (no disk = centralized configuration) and don't need as much server horsepower (apps run on each client).

Maybe somebody will release a hybrid out of the box distribution, similar to the way Edubuntu works.

Someone with mod points...

[mosel-saar-ruwer]

I work for a POS dealer, and we thought about using this type of machine for our terminals. In the long run for us, it would actually cost us money, since we make most of our money on support and maintenance.

...please mode this as hilarious.

Frankly it's a shame that Taco hasn't added a category of "+1 tragicomical": This one little comment says more about business models and business ethics in the 21st century than you'd be taught in a decade at Wharton or Harvard Biz.

Intentionally convincing [i.e. "conning"] your customer to purchase the wrong solution [undoubtedly at a loss, i.e. as a "loss leader"] - a solution that is, furthermore, INTENTIONALLY CRIPPLED - so that you can recoup costs and achieve your profit in the future on "support and maintenance" calls?

Edward Teach would be in awe of your audacity.

$199 HP t5125 thinclient from cdw.com

[Anonymous Coward]

http://www.cdw.com/shop/products/default.aspx?EDC= 811474

Sounds like Hell

[Quiet_Desperation]

All our document retrieval software is remote based. It runs like frozen molasses in the middle of an ice age in the lee of a witch's tit. Or words to that effect.

Besides, I compile FPGAs on my PC. Please don't make me do that remotely. I will have to take lives if I do.

Re:Sounds like Hell

[geekoid]

well then you have a problem with bandwidth, or the software is crap.

If all youde FPGA data was compiles on a performance mainframe, you would wonder how you survived without it.

Re:Sounds like Hell

[julesh]

Besides, I compile FPGAs on my PC. Please don't make me do that remotely. I will have to take lives if I do.

Would you rather have a single-core 1.5GHz celeron box, or shared access to a 2x quad-core beast with huge amounts of memory?

If I ran compute-intensive tasks, I think I'd probably choose the latter. Assuming the IT staff were competent enough to spread the demand for the processors and buy enough of those boxes to keep up with demand.

A smart move in many cases - this fact is not new!

[rtw]

In my opinion this article does not present any new facts. It has already been proven for years that server based computing can cut down costs drastically. Terminal server software like the Thinstuff RDP Server for Linux (www.thinstuff.com), Microsoft's terminal services (http://www.microsoft.com/), Citrix (http://www.citrix.com/) and others provide solutions which can never be perfectly solved in a distributed fat-client environment, with distributed updates, security policies for home working laptops,...

I'm offended

[The Monster]

Anyone else object to the phrase "Dumb Terminals"

I'll have the roast duck with mango salsa.

CPU time allocation prevents that

[spineboy]

And it's a fairly standard tool on any network with Dumb terminals. Otherwise you'd monopolize the CPU when writing your own code with an unfortunate infinite loop, like I used to do often, when learning PASCAL. If that happened, a simple call to the Operator would shut down your loop, and let you build up CPU time again. That happened to me twice before I routinely started to include count-up aborts in my programs.

Re:Thin Clients! The Future of Computing Since 199

[UnknowingFool]

You forgot about the flying car. :P

Dumb terminals are long dead

[swordgeek]

By any stretch of the imagination, these aren't dumb terminals they're talking about. Hell, the vt220 I have downstairs is a smart terminal by most definitions, and the vt520 definitely is. Modern thin clients are smart, fast, and capable of local graphics processing. What they're not capable of is storage, resident OS, or local compute cycles.

The good folks at the WST (and anyone else) should try setting TERM=dumb in a Unix shell session, and find out just how dumb a dumb terminal is.

Smart move

[Przemo-c]

Going from current instalation to terminals would be a smart move only if there were need to update hardware but switching just for it may not bring any improvement. For new offices It would be good cause there's no "lets leave our old desktops in place" Well prepered servers and terminals would beat the hell out of current instalations in terms of managiung them security etc. but if a company has an established infrastructure they would have to decide if it's worth the extra money.

Fair enough.

[ysaric]

I came from a much smaller employer to my current one, so I'm used to a lot more control over my working environment--not having to submit work orders for someone to come in and hang my pictures up on the wall, having control over my computing environment, etc.

Re:Dumb users...

[Anonymous Coward]

Simon, is that you in all your BOFH glory?

These things are PCs. But don't run Windows

[Animats]

These things are really x86 PCs, with upwards of 64MB of memory. They're quite capable computers. The Neoware C50 is a desktop Linux system with no hard drive, for $259. The Wyse S50 is another comparable Linux box. Wyse even has a dual screen model. The HP model runs Debian. HP is having a sale - buy 3, get one free.

Neoware even has a thin client notebook computer. It's only useful when it has a WLAN connection. This is promoted as a security feature; if it's stolen, there's not much data in it.

This may be the way Linux comes to the enterprise desktop. To many companies, this is a cheaper and easier conversion than moving to Vista.

Reliability is not a problem...

[try_anything]

... assuming that users aren't allowed to install software. That wouldn't be a suitable rule for labs and academic workplaces. For situations where you can forbid users from installing software, the reliability problem has been faced down by big businesses and is well in hand.

It starts with the fact that for many business applications, being dependent on a central server is unavoidable. My girlfriend works in accounting for a Fortune 500 company, and when access to the central accounting system goes down -- most often because network security configuration gets jacked up -- nobody in the accounting department gets much work done.

Needless to say, a great deal of expertise and technology has been developed to minimize those occurrences. It only happens a few hours every year, maybe the equivalent of one or two working days. That's less than 1% downtime for an application that depends on at least three servers: the network authentication server, the accounting system, and the network application server.

It doesn't take much savings to make 1% downtime worth it. (Who knows if it scales down economically to small installations, though.)

Old Machines

[MadnessASAP]

At my school we get frequent donations of old computers from various companies who don't want too spend the resources to dispose of them and instead let us take care of it while they pocket the tax break. So now the school board is starting to look into using them as Thin client running off of a couple servers(Using Linux.) AFAIK they already have a test case set up at another school. So hopefully this trend back to Thin Clients will result in some products to make out life easier.

Nostalgy

[mapkinase]

That is the type of terminals I have started my work with computers 20 years ago. [Sheds a tear].

Dumb terminals are more common than you may think

[falloutboy]

Many point of sale systems are designed with dumb terminals in mind. The major player in this segment is a company called Micros, and most of the new systems sold through their dealers are Win CE-based client terminals that boot from an image located on a Windows server on the LAN. Another manufacturer, Aloha, has a similar setup, instead using something called WEPOS ("Windows Embedded for Point of Service).

For maintenance, these things rock. Terminals are all interchangable, so if one fails you can roll in a new one from another part of your restaurant (or retail clothing store, etc) without needing to know anything other than where to plug in the wires. Very handy.

These systems are very common in retail environments, and are relatively pleasant to work with.

What next?

[julesh]

What's next? Minicomputers?

Re:What next?

[StikyPad]

I hear they're going to make calculators that can fit in your pocket soon. Also, nuclear power plants will soon spring up across the country to provide electricity without smog and reduce the dependance on foreign imports!

Sure, Sun uses x-terms (sunrays)

[davecb]

They're fairly smart, but only do user-interaction locally, so you can pull your ID card out of the slot and plug it in another terminal an hour later, and resume from where you left off.

--dave

Dotcom boom

[wiredlogic]

The dotcom boom just called. They want their thin-clients back.

Re:Dotcom boom

[sr180]

Call for you on line 2.. Something about the 70's wanting their joke back.

VDI

[TheRealFixer]

I've been working a lot in the VDI realm as of late. The concept is using virtualization (usually VMware ESX 2.5 or VI3 w/ VirtualCenter) to create a pool of standalone virtual desktops, a "connection broker" which can dynamically assign users to a particular VM and give them an RDP or VNC connection to it, and a thin client terminal (Wyse's S10 Blazer works well for this).

The Wyse terminal integrates with the connection broker, which handles authentication. Once the user is authenticated, the connection broker assigns the user to one of your virtual workstations and creates a remote desktop session to it on the terminal. The connection broker is responsible for tracking which users are assigned to which VMs. If one crashes, the broker knows about it, removes it from the pool of available workstations, and when the user logs back on they are re-assigned to another VM.

VDI has most all of the benefits of Citrix, like centralization of data and tighter control over user access. There are also some benefits of this over the traditional Terminal Server/Citrix model. One, the user experience is much closer to what they're used to with a regular PC, because they are essentially accessing a fully-featured workstation. Second, you don't have Citrix and Terminal Server weirdnesses, like apps that just won't run in a multi-user environment. Each user's VM, while centralized, is a completely siloed OS instance sharing the resources of the host server. What one user does on their VM typically has much less impact on other users than what can happen in a Citrix environment. With VMware VI3 and their dynamic resource concept, it opens a whole new avenue of dynamic load-balancing between your entire pool of hardware.

There are some downsides, too. A major one is cost. If you're using Windows, you're paying for XP licenses for each user, you're typically paying for VMware licensing for each server, you're paying for thin clients (the S10 is around $300), and you're paying for connection broker licenses. Citrix licensing isn't cheap either, but in my experience, VDI with VMware comes out more expensive. You can typically fit WAY more users per server in the Citrix world than you can with VDI, which adds to your per-user cost for VMware licensing and server hardware. You're also still having to manage individual desktops (although some cool disk streaming products like Ardence can help with this) for patches and new software installs, as opposed to the one-per-sever work you have to do under Citrix.

VDI is still pretty new, but the advancements I've seen just in the past year are making it a pretty exciting world to work in.

OTOH I don't see dumb terminals used

[Anonymous Coward]

where it would be appropriate.

My college has in several dozen public areas a table with six computers (3 on each side of the rectangular table) used to either access the college website or to surf in general.

The functionality is reduced to just that because of the many restrictions on these computers to keep them safe (running Windows/IE) so copy/paste can't even be accessed by mouse.

Even with these restrictions, IT is running themselves ragged to fix the 180 or so computers basically used as webterminals. Every table has at least one computer, usually two, that is pwned or inoperable. Every week a different one.

I would think these locations would be prime spots to put just one computer with a decent amount of ram, and just 6 dumb terminals to browse the web.

Re:OTOH I don't see dumb terminals used

[julesh]

I would think these locations would be prime spots to put just one computer with a decent amount of ram, and just 6 dumb terminals to browse the web.

Problem is, if there's any necessity to run windows, the cost of this would be higher than the normal PCs, because you'll need a Windows Server licence on one of them, with 5 client access licenses, and windows desktop licenses for the other 5. Cost of software = about $1500 rather than about $600.

Windows can't cope with using multiple monitors/keyboards/mice to give separate user sessions, so you can't just put in one PC with extra consoles. Linux can, with a little hacking, do this.

Some Caveats...

[Sir_Eptishous]

The company I work for decided a few years ago to move many users to a Citrix environment. In a laboratory, a pc's footprint can be too large, and the software and security maintenance of many individual pc's is cumbersome. Users access the shared desktop via HP thin clients, which itself has been secured. The Citrix desktop is locked down via Group Policy and some Citrix policies. All web traffic is directed to a secured web proxy, so that angle is secure and monitored also. Most of the time it works great, but there are some issues. Firefox running on Citrix sometimes gets confused, actually quite often. It can crash. Other apps can crash and bring the whole server down, or requiring a reboot, which isn't fun when there are 50-75 people logged on. Some apps work fine in a multi-user environment, while others don't.

Wrong!

[Archangel Michael]

One Word: Powerpoint.

Powerpoint has the unique ability to swallow all available computing power from just one person doing a Powerpoint "presentation". I know, because I see it daily.

Most of the time, word processing (Word), Spreadsheets (Excel), and even Internet (IE) and Database (Access) usage is such that a single box, properly configured, can support hundreds of concurrent users. Adding ONE presentation (powerpoint) the mix breaks that model every time.

And Powerpoint is such a big deal these days that everyone who doesn't actually need it, uses it for everything. Even Web people are using Powerpoint, converting them into Flash.

All it takes to bring a system down, is one person doing something the system was never desinged to do.

Re:Wrong!

[ckaminski]

Ok, you're not using your process accounting and quota services well at all. Worst thing a user should be able to do is waste his full 100% of the 10% slice of a CPU you gave him.

If you're not doing this in multiuser environments, you deserve the headaches you get. While native Windows Terminal Services does not have this feature, Citrix certainly does, and so do Linux and Unix terminal servers.

Re:Wrong!

[Archangel Michael]

I'm fully aware that Term Services doesn't have this feature. To do Term Services right, one HAS to use Citrix. I know this.

However, some marketing drone got a hold of the boss, and sold them a bill of goods, now I have to support the crap that was sold, and no more funding is coming to fix the problem I didn't create. I would scrap the Term Services tomorrow if I was allowed to, but the boss still believes that they are worth "saving" after two years of progressive problems and software incompatibilities and failures.

Sometimes, just sometimes, the problems aren't the Network guy's fault. They aren't going to spend 50K on Citrix anytime soon, and they don't want to scrap the investment in Term Servers, and they expect it to do everything the marketing drone said it would even though it can't. Oh well.

Re:Wrong!

[ckaminski]

It's a symptom of the ubiquitiousness of Microsoft. They make reliable, easy to use but mediocre software. Once you've gone past it's limitations, your screwed. Volume Management. Active Directory. File Sharing. Print Services. Quota management. Clustering.

Every single feature a line-item to compete vs. some form of Unix, all of them subpar, minimal functionality replacements. It's THAT I hate Microsoft for. Admit to the world, Microsoft. It's you versus everyone else in the software industry and be done with it.

I feel for you sir. I do. :(

Sounds like you need some imaging software

[Vr6dub]

Have you tried using any imaging software? It will greatly reduce the time required to prep machines for new people.

I think this is a very important point.

[ysaric]

People are saying yah, well, that's dumb--corruption problems, process issues, etc. but I think that's part of the point. Maybe I'm just mising all the wonderful success stories of companies who have migrated to thin clients while maintaining high levels of user satisfaction as employees of the company go about the business of doing their jobs. I'm sure those stories are out there, I'm just not seeing many of them.

And I don't lay that all on the feet of IT. The people who have pointed out that upper management is a problem . . . well, generally speaking, of course! They don't have to deal with the system the way most of the rest of us do because they secure the best resources for themselves, they don't give IT the tools they need to succeed, and what you end up with is a thin client implementation that is a bad as the decision to go to thin clients.

In other words, the types of business that I've personally seem so far that really think thin clients are the way to are the same ones that seem the most screwed up at the top. Maybe that has to do with where I am geographically, or the types of businesses I'm exposed to, I don't know. Maybe this /. topic will open my eyes to the successful implementation of these wonderful devices all over the United States. If it really does work, I'm not opposed to it just for the sake of being contrary.

MOD PARENT UP

[Anonymous Coward]

Yeah, that's all. He's got a good point.

We drank the Kool-Aid

[fabu10u$]

and it's been a mixed bag. On the whole, people seem to like the thin clients because they're snappy, but the TCO predictions haven't bore out yet because we have a bunch of software for various classes that has to be... (ahem) coerced into running on Citrix. Like this piece of @#$&*#$&^ Intuit tax software I'm fighting with right now.

Electronic Arts Gives These To Testers

[nevek]

Hugely inefficient, they are unable to run some of the test software EA spent millions developing.

In addition, the bug tracking software is made about twice as efficient by running 2-4 versions of it, the thin client only allows 1 version.

In addition to being painfully slow for most things they may save a bit of money for temporary employees - but they are painfully inefficient and frustrating.

On top of this a large amount of time is spent troubleshooting software that does not work on them.

I'm glad I don't work there anymore :)

The REAL Reason - Licensing

[Anonymous Coward]

People are missing the REAL reason why companies are being essentially FORCED into this route, licencing by large companies creating a certain operating system.

It's becoming cheaper to buy a new PC, complete with OS, than upgrade an existing OS at market prices of said software. The other advantage, from the software licensor, is guarenteed revenue. With the OS tightly coupled to a single machine, it can't be easilly copied, and with built in license management, you know exacly how many licenses are paid for and valid. Try to connect an extra machine, bang, nailed.

If companies had their way, we would go back to the dumb terminal way of doing things. Paying people for CPU time on their servers. License control is totally enforced. Just look at the way the internet is going with these "Internet Connected" Operating Systems. Get used to paying for bandwidth, CPU Time, and applications on a pay-as you go basis. Hey, it works for cell-phones, it can work for PC's too. Welcome back to the bad old days. There is a reason why they don't wanna call it the "Personal" Computer anymore. Your data is not yours anymore, neither are your applications. Welcome to the future, (C) 1979.

And it increases the exitement

[Quatl]

Hey! As a bonus when the server is down everyone gets a day off! Can't beat that for efficiency

Re:power outage, what about Godzilla attacks?

[MightyYar]

It could have been a problem with my PC, but in any case I learned my lesson. I'm sure that I could have filled out a trouble ticket, which would have fluttered around the world until I finally got a call from our Malaysian help desk. After a painful discussion, he would have referred the ticket to our local overworked guys. While very good good guys, they are way to busy to debug some intermittent problem with the network drive that no one is using anyway. I know that no one was using it because it had a default limit of 250GB... I ultimately was there for 10 years, and had a lot more data than that! I asked for a 1GB limit via a support ticket, and actually got a call from a VP asking why I needed "so much storage"! LOL. He gave it to me when he conceded that the only other "archive" method they had was to put my data on a CD... and hand it back to me!

Hey, I just worked there :)

(sorry, had to fix the subject line)

Dumb

[dcam]

Let me be the first to say: Dumb terminals, dumb users. Seems like a perfect match to me.

Lots of current solutions for your problems

[bigtrike]

There are tons of ways today which you can do to reduce the amount of time you spend with the above activities. Drive imaging, network booting to something like knoppix, diskless/cd rom driveless workstations using something like knoppix, network booted installers such as kickstart, wake-on-lan your machines at night to auto-install patches, USB2 dvd rom drives to reduce downtime, etc. I think even Windows offers a way to do most of the setup via config file which would reduce your time.

For the near future all of these methods will be cheaper when combined with $399 desktop+monitor deals from Dell and some reasonably fast disk image servers.

Re:Lots of current solutions for your problems

[Anonymous Coward]

I think the typical problem in a small shop is that out of perhaps 20 workstations you have no more than 3 with identical hardware. Whether you replace a failing computer or increase staff, it's never more than one or two at a time. That pretty much kills ghost or partimage as an installation option.

And by the time you need that image for recovery ---on a reasonably secure network with newish machines-- you will have upgraded or personalized the software to the point that the image is not much better than the Dell recovery CD. I'm not sure it's even worth investing time in Sysprep or RIS on a small network.

I'd love it if any of my clients wanted to try out a thin client solution.

Re:I've been working at a thin client site for a b

[tsstahl]

I think they could have achieved the same effect by just scaling back IT in the usual way -- cutting staff, sticking with older computers, fixing only the most critical problems.

I can't believe you got modded up for a post with that sentence in it.

This is the information age. Businesses who still operate that way will go the way of the bronze axe and buggy whip.

On the plus side, those type of operations don't know how to offshore jobs, either.

Computer Management Costs

[Mutatis Mutandis]

The clue is, I think, in the phrase "reduction of computer management costs." Dumb terminals may be good way for the IT department to reduce its operating costs. However, that is a bad yardstick to use for management, unless they run a Kafkaesque company where people have nothing better to do than keeping their computers busy. The goal of good computer management should be to increase the operating efficiency of the company as a whole, which is not the same as keeping IT costs down. On the contrary, it often will involve spending more on computer infrastructure and management, if that reduces costs elsewhere. After all you could reduce IT costs to zero by requiring everyone to return to paper and pencil.

Many companies will have a canonical half dozen application that are used by 90% of all users, for which dumb terminals connected to a central server may be a good idea. And then they will have several dozen of applications that are used by a few people each, for specialized tasks; centrally installing and managing these will make their cost skyrocket -- if it is possible at all.

Besides, I am not in favor of standardization even it is possible. Many IT managers love standardization because it keeps the costs of their operation down. But it encourages a technological mono-culture that tends to become an intellectual mono-culture as well --- it is quite curious how people's understanding of something can be warped and constrained by the software it is presented in. Having several different applications for "exactly" the same purpose may look wasteful, but it is more often beneficial.

There is one thing in favor of dumb terminals, however. The lack of noise and heat generation can make a big difference in an office environment, allowing people to work with less distraction and less background noise, which can be quite tiring to have. I would even argue that if it costs 10% more to remove the fans to another location and make people connect remotely to their computers, this may very well be worth it in increased people efficiency. I have been in places where the mere heat and noise of the installed computers cut my own work efficiency down to 50% of normal...

Solution: "Really High" volume scanner.

[Ayanami Rei]

They tend to be full-fledged networked computers with a webserver and FTP server containing your TIFF/PDF files and stuff. No need for "OS support" there.

DONT DO IT!!!!

[briancnorton]

Sure you can save some money, but at what cost? (is that a yogism?)

The $300/user hardware sounds cheap until you look at servers that cost $500/user and have to connect to $600/user windows terminal servers to run your windows apps, PLUS a lot of expert time spent in configuring your system. You also gotta upgrade your network if it's not up to snuff. (over 100 users, better have gigabit...)

Then the real fun begins when you have to make sure your windows apps are licensed properly for a multi-user environment. Then you get to figure out that you still need thick clients to upload/download media, and it finishes with the realization that any real processing is dirt slow and any current or future app needing direct hardware access won't ever work. (like Google Earth, ArcGIS, photoshop, etc)

Then you start to rationalize and come up with the "fix" that everybody will have a thin client and some will retain thick clients, meaning more network drops. Then you will survey your users and discover that something like 90% use at least one tool that either won't license properly or won't work over TS.

The moral of this story is that one needs to be very careful about what it is that your users are actually doing. Thin clients have their place in small, purpose specific applications (cash registers, single-app workstations, kiosks, etc) but may not work well with the broad range of applications and needs of the modern professional workplace.

Random pointers

[piranha(jpl)]

You're going to be doing a lot of tinkering.

If you get a big-endian (e.g. PowerPC) thin-client and use a little-endian (e.g. i386) back-room machine (your existing workstation), you're in for pain: conceptually all things X should be endianness-neutral, but lots of software simply has bugs that hinder features or render that software unusable. Examples: MPlayer, XScreenSaver, and things that do "exotic" things with the display: video playback, 3D graphics, etc.

For ordinary programs and plain graphics, X11 over a LAN works tremendously well. You'll probably be without sound, though: lots of programs expect to be able to open a local sound card and pump stuff out to that. You'll need to run a sound server (ESound works well) and ensure all sound-utilizing programs you'll run will work with that sound server. For GNOME on Ubuntu on a virtual machine without /dev/dsp, sound "just worked" as clients apparently deduced the location of the ESound server from the DISPLAY environment variable; I don't use GNOME much at all, though; YMMV.

If you do like tinkering, search eBay for the IBM NetworkStation 1000; I got mine for less than $20, after shipping. These are powered by PowerPC processors, and have Ethernet, PS/2 keyboard and mouse connectors, a serial port, and a parallel port. They also have sound and smart card hardware, not supported by Linux. They are extremely small, and contain no moving parts. They use a laptop-style power supply. There's an unofficial modification to the Linux 2.4 kernel to get it booting on these things; though the project seems dead.

You can find other thin-clients on eBay for dirt cheap. For maximum party pleasure, make sure you can run Linux on whatever you consider purchasing. If you want sound or USB support, make sure you check that the machine has this hardware. Make sure yours uses Ethernet; there's at least some Token Ring thin-clients in existence.

USB in a Linux thin-client environment blows chunks. There's a project to encapsulate USB over TCP streams; it's semi-dead and has some reliability and polish issues. There's no other way to smoothly support floppy or CD-ROM drives on your thin-clients, even if they have that hardware. Some people might suggest running an FTP server on your thin-client and SSHing in to mount or unmount; I find that disgusting.

As somebody mentioned, iMacs work. Linux runs fairly well out-of-the-box on this platform. These also support netbooting. Make sure to get one without a system fan—remove the hard disk, and you'll have no moving parts.

Whatever you do, don't waste your time with LTSP. It's a distribution of Linux specialized for running on thin-clients, but for some unimaginable reason the "LTSP way" also involves installing their opaque software packages on the (confusingly-named) "server." If you can even run Linux on some platform, you're better off installing Linux on it directly. After that, enable XDMCP with xdm, gdm, or whatever you use on your existing workstation, and throw a line into /etc/inittab on the thin-client (e.g. 7X:23:respawn:/usr/bin/X11/X -query workstation-address ).

Re:Random pointers

[gentgeen]

I call CRAP!!

USB in a Linux thin-client environment blows chunks. There's a project to encapsulate USB over TCP streams; it's semi-dead and has some reliability and polish issues. There's no other way to smoothly support floppy or CD-ROM drives on your thin-clients, even if they have that hardware.

Funny, I have 3 clients. Each are actually old sub-500MHz pcs. Each has a floppy drive, a cd-rom, and a usb slot. I can plug in any of the three, and they show up on the users desktop (if he/she is using GNOME/KDE). LTSP refers to it as localdev (local devices)

Whatever you do, don't waste your time with LTSP. It's a distribution of Linux specialized for running on thin-clients,

Just plan wrong. LTSP is not run ON thin-clients. It runs the thin-clients.

but for some unimaginable reason the "LTSP way" also involves installing their opaque software packages on the (confusingly-named) "server."

The confusingly-named server, as you say, IS THE SERVER. It serve out the desktop to the thin clients. You don't install anything on the thin clients.

If you can even run Linux on some platform, you're better off installing Linux on it directly. After that, enable XDMCP with xdm, gdm, or whatever you use on your existing workstation, and throw a line into /etc/inittab on the thin-client (e.g. 7X:23:respawn:/usr/bin/X11/X -query workstation-address ).

The method you illustrate will not allow for localdev access, will not allow for sound (unless you do some major work with esd as you mentioned earlier in your post), AND still requires you keeping an additional machine up-to-date. It can be done (I did it what a laptop so I could have a wireless "thin-client") Do a little more research before you begin attacking something. You clearly do not understand how LTSP works.

Re:Random pointers

[piranha(jpl)]

I call CRAP!!

...

USB in a Linux thin-client environment blows chunks. There's a project to encapsulate USB over TCP streams; it's semi-dead and has some reliability and polish issues. There's no other way to smoothly support floppy or CD-ROM drives on your thin-clients, even if they have that hardware.

Funny, I have 3 clients. Each are actually old sub-500MHz pcs. Each has a floppy drive, a cd-rom, and a usb slot. I can plug in any of the three, and they show up on the users desktop (if he/she is using GNOME/KDE). LTSP refers to it as localdev (local devices)

From what I gather on LtspFS/local-device support, they basically invented their own network filesystem. This is wrong in two ways: 1) it would have been better to modify NFS, an established and reliable network filesystem; 2) this is the wrong level to abstract—it's too high-level. They should be exporting block devices on a block device level, not block devices on a filesystem level. Otherwise, you can't burn CDs or DVDs, rip CDs, low-level format a floppy, create a new filesystem on your removable media, or perform a consistency check of the filesystem on your removable media. Furthermore, they should be exporting USB devices on the USB level, so that you can use arbitrary USB devices on your thin-client, like scanners, printers, webcams, and so forth. Tell me, can you do any of these things with "localdev?" If so, I'd love to read the technical details of the system and see how tightly-coupled to LTSP it is. If not, it's perhaps a small step up from floppyd or whatever.

Just plan wrong. LTSP is not run ON thin-clients. It runs the thin-clients.

LTSP is a bundle of software that installs on the "server," may or may not provide scripts and binaries to run on the "server," and definitely provides a Linux kernel and userland filesystem to run on the thin-clients. Arguably, most of the value of LTSP is in the distribution it provides for execution on the thin-client. Therefore, it runs on the thin-clients.

The confusingly-named server, as you say, IS THE SERVER. It serve out the desktop to the thin clients. You don't install anything on the thin clients.

As a matter of fact, the LTSP terminology flies in the face of that of X11 (around for decades), ESound, and probably other software and technology that LTSP depends on. The thin-client runs the X "server." The thin-client runs the ESound "server." The programs on what you call the server, and I call the workstation or back-room machine, are clients of the X11 and ESD protocols, and clients of the servers provided on the thin-client. That's why I say it's confusingly-named. I'll admit a fault in my usage of the term "thin-client;" the traditional term would be X terminal.

Are we done with the capitals and abused italics?

Re:Random pointers

[piranha(jpl)]

The method you illustrate will not allow for localdev access, will not allow for sound (unless you do some major work with esd as you mentioned earlier in your post), AND still requires you keeping an additional machine up-to-date. It can be done (I did it what a laptop so I could have a wireless "thin-client") Do a little more research before you begin attacking something. You clearly do not understand how LTSP works.

I think you missed a closing tag; sorry I missed this.

Sound is as easy as creating an esound system user on the thin-client and throwing sudo -u esound esd -tcp -public -nobeeps -terminate into its /etc/inittab—though for X and ESD process management, I prefer using supervise, part of DJB's daemontools. Many clients Just Work without setting ESPEAKER on the environment; for others, set that in ~/.xsession.

A thin-client is always an additional machine, and needs to be kept up-to-date as anything else. It runs software that gets new features and is subject to security problems from time to time: the Linux kernel, the X server, the sound server, any daemons to permit remote utilization of removable devices and media, SSH, and soforth. You're probably right in that I'm not familiar with many recent aspects of LTSP; it's been years since I've used it. I found that using a mainstream Linux distribution on my thin-clients gives me excellent package-management, extensibility, and doesn't require me to install "black-box" packages on the system running my workstation software.

Real-world physical reliability of thin clients

[adminstring]

I've used a lot of Wyse winterms in the past, and I've found that their Achilles heel is often the power supply. It's nice that there is no fan noise, but the downside is that there is no fan to keep the PS running cool, meaning you end up buying a lot of expensive, proprietary, 5V 4A power supplies to keep your "maintenence-free" winterms running. Hopefully other brands don't have these issues. For me, it negated a lot of the savings involved with a thin-client architecture.

Big in the automation world.

[compasseng]

These are all over the place in the automation industry. I just did a job last week where they were installed.

Been there, done that, gets a band-aid.

[Anonymous Coward]

"The thin clients can boot off a local read-only flash drive, but better yet have them boot off a tftp server so you can more easily keep their software levels up to date."

I've tried this with Knoppix's terminal-server on the main machine, and PXE an old Fujitsu laptop. Didn't get all the way. Also even with the tftp server, the process of creating a bootable image is a lengthy pain.

Re:Been there, done that, gets a band-aid.

[Yonder Way]

I've tried this with Knoppix's terminal-server on the main machine, and PXE an old Fujitsu laptop. Didn't get all the way.

Can't comment. Don't know where you got stuck. I don't believe I did get stuck. It worked.

Also even with the tftp server, the process of creating a bootable image is a lengthy pain.

No, it's not. It's not much more than an apt-get install away in Ubuntu, as well.

no green comments?

[Anonymous Coward]

I would think the carbon atoms would love this approach.

How many times have we bitched about this before?

[Anonymous Coward]

"It's seriously cool stuff!"

Just wait till it comes to the home user.

oh god

[Anonymous Coward]

If I have to fix another Wyse 2020 terminal I'll shoot myself in the head.

secure but slow

[icebones]

my company di dthis with citrix boxes or toasters as my co-workers call them. from a security standpoint i can completly see the point, the only way on is with a valid logon and the user can never install "smileys" or something equally annoying. however, they are slow as hell, probably our bandwith though, and everytime you log on all of your settings are reset. I mean all of them, even the standard, "don't show this again" boxes have to be rechecked everyday. It's something you learn to live with, but it would be nice if flash could be installed or i could listen to music on my pc again, but it's not their concern. one thing though, when it goes down, the company goes down. It's not like when the network went down and you could still do some basic things. just go to an early lunch or whatever , that's all you can do.

X Terminals

[Anonymous Coward]

The U of Iowa has used dumb terminals extensively. When I was in high school (in Iowa City, so I saw what the U of I had) they had 3270 terminals, and a lab of Adds Viewpoint terminals. These were really the skankiest text terminals I've seen anywhere, but did the job for E-Mail etc.. (some termcap/terminfo based programs just give up, claiming the Adds is too incapable to run the software.. running it under screen would make it work, since screen simulates a VT100.) The 3270 terminals were for logging into the 3090 for class scheduling and the card catalog. Later on, the U took the very silly route of buying fairly beefy machines capable of running Windows, and then just running a full-screen terminal emulator on them. It worked but I bet it cost far more than just running x3270 on a stripped Linux install 8-).

          When I was in college, they had HP and SGI computer labs in the computer science and math departments. Well, not really computers though! In reality, they were about 1/3rd computers and 2/3rds X Terms. With the HP lab, the machines and X Terms looked identical, and you really couldn't tell performance-wise or anything if you were actually at a HP workstation or a HP X Term except by reading off the model # on the case. These worked great! They were only running 100mb ethernet in the labs too, so it wasn't like it was that bandwidth-rich. Since this was like 10 years ago, I think even the X Terminals had fans, but they certainly wouldn't now.

          Obviously, just cutting machines by 2/3rd might not make it worth it (depending on power savings?) but CS guys were compiling software etc. all the time. For just some word processing and stuff, throw in lots of RAM and you should be able to run lots of users off 1 server machine.. (or really, you should have 2+ with failover preferably.) LTSP is supposed to be able to handle all this stuff. Rolling this kind of stuff out with remote desktop or whatever is a huge mess since Windows really isn't designed for it, but X is designed for this from the ground up. If you're looking more for the administrative savings, you can also mix and match real X Terms and PCs running X server software, reusing some existing PCs that might be "too old" to run a desktop on. Old PCs are certainly going to be less reliable, but remember that since it's a terminal, failure means like 5 minutes while it's switched out, not the end user losing files and also having to setup the screensaver, backgrounds, and window locations how they prefer -- since that would all be on the server.

Dumb Terminal?

[n6kuy]

Hey, I didn't know you could use Windows with a "dumb terminal"! I guess it's time to dig out the ol' TV Typewriter!

Re:Stupid quote

[Herby Sagues]

The comment on the article about terminals being better because they don't store local sensitive data demonstrate a total lack of network management knoweledge. Not only you can do the same on a PC (or any other thick client, for that matter) but it IS how it is done at most companies. Same thing for installing software and configuration: it should (and most of the time is) done centrally via policy. Yes, terminals have great value in many scenarios, and if the users don't need to run graphically intensive applications or very heavy workloads that would tax servers, they might reduce cost. But it is not because PCs are difficult to manage. Implementing a managed PC environment is not more costly than implementing a managed terminal environment.

Re:power outage, what about Godzilla attacks?

[L0rdJedi]

250 MB (I'm going to assume you meant megs since you said later you asked for a 1 gig limit) is usually WAY more than enough for 90% of just about any company. I think there are maybe 5 people where I work (out of about 50) that use more than 3 gig of file storage and most of that is their email archive. Even those people have agreed to delete their 2005 email (a 2 gig archive) once we reach the end of this year (2007).

Those people are the exception though, not the rule. Most everyone else keeps their mailboxes way under 100 meg and never even needs to archive. They also rarely store any documents on their network drive. Most of what they do store is on their desktops, but even that data comes out of the company database app, so it's still being backed up everynight.

Great for large installations.

[Askmum]

This is great for large installations. - you only introduce a single point of failure if you choose to. Who says that all terminals connect to a single computer and who says that every terminal always has to connect to the same computer? Never heard of Citrix? - Userrights have to be limited of course. No installing of own software, and proper viruschecking. - If two software packages don't mix, then install them on different servers. A lot of users here only ever start Word, Excel, Access, Outlook and a terminal program. And for that you have to support a complete computer? Work will even get faster. No pumping of large datasets in Access databases over the net, now they reside on a central server and get run on this central server. Plus the added bonus of less A/C in the summer because all those hot computers are gone.

Re:power outage, what about Godzilla attacks?

[MightyYar]

250 MB (I'm going to assume you meant megs since you said later you asked for a 1 gig limit) is usually WAY more than enough for 90% of just about any company. I agree, but I was surprised that my request was so unusual that I got a call from management! I was a process engineer, and we invent new processes and collect reams of data. There were about 20 in my department who should have been collecting at least as much data as me, and should have been backing it up. IT's policies should enforce this, but they actually discourage it.

I can't just throw away the data - I would have to comb through it to make sure that nothing with "potential lawsuit" written on it gets thrown away. Frankly, storage is far cheaper than me spending the time to do this. It would actually be cheaper for me to buy a DVD burner and rent a safety deposit box for the DVDs then for me to spend the time going through 10 years of files so that I don't exceed an arbitrary limit. We have been sued in the past, and had to go through 20 years of old backup computer tapes to prove that we weren't infringing on patents. If we simply deleted our old data, we might have lost the case.

Email is very much the same. I have about half-a-gig a year of email archived away. Most of it is probably crap, but it's not worth my time to go through it all. There are a lot of IP-related and technical emails in there, so I don't think that it'd be prudent to chuck it for the length of patent expiration. Actually, much of it are these stupid notices that IT sends out every day - as many as a half dozen. This server is down, a PDF of our latest press release, etc. I once harassed my buddy in IT about sending out PDFs to thousands of recipients. He looked at me proudly and said, "Oh, Exchange is smarter than that. It only stores one copy of the message." I reminded him that IT sets up everyone's Outlook client to auto-archive to the network. He looked at me and said, "But don't you just delete the messages?" I told him that I don't even READ the messages, let alone delete them and he was actually surprised. We did an informal poll and found that only about half were deleting them - he was using a lot more storage space than he thought! The PDFs continue, by the way. Doesn't Exchange have a way to flag a message as "do not archive"? If not, then why doesn't IT install an RSS reader on everyone's desktop to use for announcements?

I just worked there :)

Oh please, I have twor words for you.

[jotaeleemeese]

Virtualization.

Redundancy.

Problems sorted.

Next!

If your company is big enough....

[jotaeleemeese]

... they will gladly make any changes you order, I mean, request, from them.

I would kick you lot out of the machines.

[jotaeleemeese]

Then I would assign a port to each developper to start their own web server, and request more computing resources, since obviously you don't have enough CPU power.

OK, I'll throw a virtual machine at you.

[jotaeleemeese]

You still don't need a desktop and priviledged access.

This is 2007, not 1980.

Schools

[Tapd260]

I don't know about businesses, but Novell Citrix works great for my school...

This has never made financial sense.

[ACMENEWSLLC]

We have looked at this solution so many times it hurts. It's a great solution. But the money doesn't make it worth it.

I can negotiate with HP and get a Windows XP PRO PC with plenty of memory/disk space etc for a workstation @ the same price that I can negotiate the thin clients down to. This is likely due to volume differences.

So if the dumb terminal with CE costs the same a full fledged PC with XP PRO, then how does this make sense?

If I use Citrix, the CE thin client solution requires a TS license for $100. The XP PRO (to W2k server) does not. Plus I have the license costs for Citrix.

If they could get thin clients down to the OLPC price tag, then this would take off.