Slashdot Mirror


Thin Clients in a Computer Lab Environment?

chachi8 asks: "I work as a lab administrator in a university, and I currently look after about 500 Windows-based PCs spread out over 20 locations. The IT administration at my school has recently (and quite suddenly) decided that thin clients are a direction we should be pursuing, and I've been doing some research over the past few weeks. We've recently been visited by representatives of Citrix who basically showed us some really impressive software that is far from cheap. Because we're a university facing budget cuts, cost is a major issue for us, so what I'm interested in knowing is whether anyone has implemented a thin-client solution in a computer lab environment, and whether it turned out to be cost effective over a 3-5 year timeframe. Clearly, the idea of being able to add an extra few years to the lives of our lab PCs is very attractive, as is the thought of being able to centrally administer the software in all of our labs, but I'm as yet unclear as to whether the costs of servers and licensing (and everything else) will really result in a long-term savings in money."

11 of 377 comments (clear)

  1. K12Linux LTSP by James1006 · · Score: 5, Informative

    www.k12linux.org

    Absolutely phenomenal. We installed it today and will be deploying it in a lab environment soon.

    Not a SINGLE problem in install or setup.

    --

    - Nothing is true, everything is permitted
  2. Get reference sites by larien · · Score: 5, Insightful
    Ask Citrix to give you a list of other sites where they have implemented their software successfully and visit them. Ask the local administrators (and users!) how they find it.

    However, make sure that it's a site similar to the one you are on; no point getting a business as a reference site for a uni.

    Finally, if things don't go as planned post-implementation, point out to Citrix that you are educating the future decision makers of the world; if they perceive that Citrix is crap, they won't buy it in years to come. That should get them to help fix your problems!

  3. Thin Clients - University Lab Style by CyberKnet · · Score: 5, Informative

    I know a few years back at an Australian university we looked at thin clients for our computer labs. FWIW, the cost (Back then) of thin clients was about the clost of a Celeron computer, and did not come with a monitor either. The server (IIRC) had to have a whole bunch of memory (some 64mb per client, plus a very large overhead for windows + citrix), then they added Windows access licenses for NT on to each terminal that needed to access the server, plus NT client access licenses ... in the end it was just WAY more expensive than individual computers, even including total cost of ownership. However, I will re-iterate, this was some three years ago though... the scene has probably changed...

    --
    Video meliora proboque deteriora sequor - Ovidius
  4. Thin clients are not good for labs by Talsan · · Score: 5, Informative

    My university has experimented with thin clients, and has chosen to continue to use full PCs for the labs. The client boxes were nice, but they did not work as well and tended to be harder for them to keep running. Now the only thin clients they use are some Compaqs that they've placed around the school as email terminals. --These are actually very popular among students, as they don't have to fight for lab space just to check their email.

  5. My experiences by yamla · · Score: 5, Informative
    At the university I attended, the computing science department tried something similar to this.

    Having a central Windows machine and thin clients for each of the users was a horrendous mistake. Whole labs spent as much time non-functional as they spent functional. Even having users change their passwords was problematic. Now, this was a few years back now and things may have improved. However, the only way I'd consider this is if the company you are buying the hardware from will guarantee uptime. This should be at least 99.9% uptime (and yes, this includes security patches and hardware failures), otherwise you are going to get crucified.

    On the other hand, the computing science department also maintains several labs running OpenBSD for the client operating system. A student can log in to any computer in any lab because the /home directories are exported (over NFS, I think, but I could be wrong) from central file servers. The default software is installed locally so things can run very quickly but a large amount of additional software is also installed on central file servers and exported out to all the machines.

    That setup is not bulletproof but the uptime is measured in weeks or months rather than hours or days. Depending on the year, it probably approaches 99.9% uptime. It also has the nice advantage of almost all of the software being entirely free.

    So which should you go with? From my experience (ymmv), the clearly superior technical solution is to run OpenBSD on a large number of semi-thin client Intel machines. This is far more reliable than a competing Windows solution. From a cost perspective, there's really no comparison. That said, this assumes that you can migrate over to a Unix style environment. Not everyone can. Do not forget that you'd be throwing out all your Windows software using this solution. Also, you require sysadmins who are familiar with Unix. I assume this is the case.

    --

    Oceania has always been at war with Eastasia.
  6. Depends on what you use your labs for... by zubernerd · · Score: 5, Informative

    Products like citrix are targeted to the business environment or low bandwidth use such as spreadsheets, wordprocessing, etc. (Where your screen updates are minimal) If you are going to do graphics, Citrix is not for you. Sound is okay, though Terminal Services (RDP 5) seems to have better sound. So what do you use those lab machines for? Simple office like apps, or programming, or graphics. That will dictate if Citrix, or anyother product liek it, is worth the money.

    --
    Accentuate the positive, don't waste your mod points on the negative.
  7. Comment removed by account_deleted · · Score: 5, Informative

    Comment removed based on user account deletion

  8. Count ALL your costs by plopez · · Score: 5, Informative

    Figure out your annual costs to support the network as is for 3 to 5 years. Software + labor + security (virus software) + hardware. Root out ALL the costs, don't ignore anything ("Oh, we only pay work/study students $8 an hour, it's not important") and any impact down time may have. Call up some locations which have already implemented the solutions you are looking at, approx. the same size and also academic institutions, and see what their costs are (it's not like you are in direct competition).

    Get a spreadsheet of the current cost of doing business vs. the solutions you are looking at so you can show it to mgt.

    I think, however, that getting away from a PC/Windows based system is the correct solution. Gartner Group once published a study stating that the cost of supporting a PC based network was up to $10k/yr in some situations. Sure the software *looks* expensive up front, but over 3-5 years moving to thin clents would probably be a great idea.

    But run the numbers first, get competing companies and their products in the door and let them make their best presentation. Make sure they know you are looking at 3 to 5 year costs, not just initial purchases, because PC/Windows always *looks* cheap when you do not factor in the add-ons and support.

    Then decide.

    --
    putting the 'B' in LGBTQ+
  9. SunRays! by boopus · · Score: 5, Insightful

    I got to Cal(UC berkeley) and we have a couple labs full of SunRays, which I have found great from a user perspective. Now, the thing you're not going to beleive is why. The sunrays are silent. You never notice how loud the fans from forty computers in a lab are untill you walk into one that's quiet. It's much easier to think for long periods of time. The labs are about 50/50 divided between unix pc's and sunrays, and I'll only work on the PC's if I have to, though the (computer desktop) environment is identical.

    There are some disadvantages with sharing a Big Computer with a lot of people, but overall the plusses seem to outweigh the minuses. Last year about halfway through the semester the workload increased on the servers and everything slowed down... This was the bad part. The good part was that a month later, they added another server, switched a number of the clients over to it, and everything jumped back up to speed. If these had been PC's that weren't cutting it any more they would have had to be replaced.

    I have no idea what they've gone through on the administrative level, or if Sun gives us a good deal or not. They deployed a new lab last year, so they must not hate them...

  10. Citrix and "thin" dont go together by ByTor-2112 · · Score: 5, Informative

    I work at a General Electric facility where we recently changed MMS systems to a citrix-driven system, and let me tell you that it is SLOW. A big honking Sun machine powers the Oracle backend, but the user interface runs on Win2k advanced server. On a p2-3xx with 64mb ram and win95, the interface is visibly slow. Another problem we have had is with printing -- the server is supposed to map your printers, but we find that PCs with more than one available printer either won't print, or print to random destinations.

    My understanding is that the "thin client" is supposed to save in hardware costs, which it MIGHT. The software costs, however, can't be that much lower unless you use the Linux citrix client. You still have to pay your Microsoft tax for the OS, and then you need NT CALs, and licenses for Office (which I assume will be the major app used). I just don't see the benefit. Citrix is selling buzzwords and hype with terrible performance.

    Universities have enough problems with bandwidth, imagine having to share all your applications over that pipe with all the mp3s and video traffic!

  11. Best of both worlds by Anonymous Coward · · Score: 5, Informative

    The trick is to balance cost of hardware/software of server/client with the flexibility of upgrading hardware/software on the server end, yet keep performance high, and security in mind.

    So, If i was doing this, this is how i would approach it:

    1. you have to keep the cost of the thin clients under $250... thats without monitor. These need to be small, dependable, and easlily replaced. In other words, you should be able to walk into someones office, and unplug it, and plug in a new one, and they should be ready to go in under a min. if you have to do lots of configuration on the client side to get things working, then get a better thin client from another vendor. Make sure the thin client comes with something like a san disk or something you can overwrite. What you want to be able to do is run a *nix on it that can do remote X connections, or do rdp connections. forget about getting in bed with citrix, its way too much money, and you really dont get that much back. unless you use all the whiz bang features, and have lots of time to learn how to tie it all together.

    2. Use a combination of windows terminal servers and *nix terminal servers. By default you want people to use the *nix servers, but their will be some folks who want or need to use windows apps, and letting them be able to do so, is a good thing. You can use rdesktop to let the thin client connect to the windows terminal server. it is a little slower than the native windows rdp client, or the citrix ica client, however its free, and it runs on *nixes. If you had to use the windows rdp client it would cost you a windows ce license at least, and to get the citrix client you would have to spring for the whole citrix package which gets expensive.

    3. Get solid dual proc servers with as much ram as they can hold! dont skimp! get fast scsi drives, and try to squeeze it into a small footprint. If you can use the same hardware for both the *nix and windows terminal servers, that will be a plus, since you can shuffle them around incase of failure, or more demand for one kind than another.

    4. cookie cut the systems. in other words, have it designed that you can get another server up and configured in under an hour. this way, incase you need to scale quickly, or have massive hardware failure, you have a system that can be brought back online asap.

    5. stress test the hell out of your design before you go into production. nothing will be worse than realising down the road that you have a design flaw, and you have to scrap and rebuild stuff. that will piss the users off, your boss off, and probably get you fired. tune for performance, and plan to scale. it doesnt matter if you only have 500 users right now, if your design isnt good enough to scale up to 5000, or even 50000, go back to the drawing board and see where your bottleneck is. Why? cause that bottleneck may come back to bite you one day.