Frank Cox wrote: > On Tue, 25 Sep 2007 15:11:50 -0300 > Celso Junior <celsojr2007 at yahoo.com.br> wrote: > >> But when I think in Linux, it comes to my head the scene of a Strong >> Server, which keeps the files and the programs, and some terminals that >> access scribus via SSH.... I'm doing this just to feel the heat... O_o > > http://www.ltsp.org > > It works very well indeed. We use Neoware Capio 616 terminals on (currently) > Fedora Linux. Soon to be Centos once I finish getting this application > server set up.
Yep, for basic users Linux thin clients are pretty good, and LTSP makes them rather easy. Like most things there are lots of upsides and lots of downsides. The upsides are mainly management (there's some, but overall it's not bad), security and the ease and affordability of adding and moving users. Some issues are to be expected. For example, Flash is a pain - I've installed flashblock on the machines because the background load of 20 users with browsers idling on some site with flash ads really adds up and starts to bog the system. That said, it's only a 2.4GHz dual Xeon with 4GB of RAM, and the LTSP guest Xen domain only gets 1 CPU most of the time. Audio is a pain on LTSP, as is client-connected storage like CD-ROM drives or USB keys. Hopefully this will improve, as right now it stinks. Don't use GDM. It's hopelessly unreliable. Use good old XDM or even KDM. You'll get really sick of apps with broken and unreliably single-instance-per-user crud, like Firefox, Thunderbird and OpenOffice. I have a `kill_braindead_programs' script that kills all instances of these for a given user and removes their lock files since one or more of them will sometimes just break. This isn't really LTSP related, but is made worse by these apps sometimes flakey handling of X11 disconnects. LTSP isn't much good for really graphics intensive work. Scribus works over it, but is very slow because it redraws the canvas by blitting tiles, and redraws large parts of it if not all of it when even small things change. It's still usable, though, and on gigabit (with a dual or quad gigE trunk from server to switch) could be OK. GIMP is similarly unthrilling, but works surprisingly well nonetheless. If your server will do tasks other than serving LTSP guests, consider using something like Xen to split the tasks. You'll want to upgrade the GUI bits more often than the rest of the server OS, switch distros, etc, and this is a right pain without some sort of VM setup. If you're going to do this, consider setting up LDAP authentication to save yourself a bunch of hassle down the track. Get lots of RAM. I mean *LOTS* of RAM. Don't consider a host with less than 4GB of RAM if you're building a server (though in fact I find 512MB + ~100MB per user to be quite usable even with fat apps like Firefox, OO.o, and Thunderbird). Get a 64 bit host, too, as this is one area that'll help a lot down the track as you add RAM. If at all possible get some fast disks with good multi-user load handling, like WD Raptors or preferably some SAS drives. Get at least a mirrored pair. If you need lots of storage, consider a RAID 5 array or similar of bigger slower disks for the bulky stuff. In either case I'd only bother with a hardware RAID controller if you're going to get a battery backup unit (so you can safely turn on write-back cache for a *BIG* speed boost); otherwise Linux s/w RAID does a pretty good job. I have a Linux S/W RAID server that's *lots* faster than a 3Ware 8500 based machine that's otherwise similar. No matter how you set up your low level storage, use LVM to manage it. You will never be able to use static partitioning again. The CPUs really aren't that important, but that plural is. I honestly think a 1GHz quad core would be better than a 4GHz single core. By a lot. A dual CPU dual core box should be very nice up to quite a lot of users (I'd be surprised if, with 8GB of RAM and a 4 core box you couldn't happily support 40 or more users). Avoid NFS. It's frustratingly unreliable in real world use (on Linux; Solaris's is perfect). It also works poorly for home dirs due to apps that make very strict assumptions about ordering etc and thus run into problems with lock files, among other things. Let's not even talk about berkeley DB. Under absolutely no circumstances permit Evolution anywhere near your LTSP server. I've clocked that monstrosity at more than 1GB of RAM. It's not shared system friendly. Firefox's page caching is bad enough, but Evolution is mind boggling. Above all else ... give it a try, even if you're not at all sure you'll like it. A test deployment or a real world one for a small set of users can be done on a mid to high end desktop PC (modern CPU, 1GB+ RAM, modern 7200RPM or 10kRPM disk(s)); you can use your existing desktops as clients without making any software or hardware changes at all if they have PXE (netboot) BIOS support. It's well worth a play. -- Craig Ringer
