We do commercial ltsp solutions that solve a number of common ltsp problems. I am not trying to sell you anything I am just going to point out the common issues. I love gentoo but realize that if you deploy that on servers it would be in fairly bad taste to do the actually compiling on them and will not do wonders for your performance. You will need to manage a separate system or farm to do the compiling of the binaries and then rsync (or other transport method) the packages over two the ltsp server. I am not de facto against using gentoo on servers but that caveat is an important one. I will not recommend a specific alternative distro but any of the RPM based ones with apt-rpm or perhaps debian come to mind. 512mb is technically enough ram but ram is cheap and has a dramatic effect on ltsp performance. I do not know that number of users you have (starting at 6 but going to how many?, a good box with 1.5gb ram will do 30+ typical users) but going to 1.5gb is usually a very cost effective solution. Just noticed you have RDRAM sorry not so cheap but something to keep in mind. Also I didn't see any raid mentioned but ltsp represents a monumental single point of failure so even a cheap promise ata raid will help a little in the event the disk fails. Consider phoenix over mozilla your memory and processor with thank you. Internet explorer has all of the same problems on linux that it does on windows so keep that in mind. In our experience customers vastly prefer evolution to kmail but YMMV. PhpGroupware is in my opinion a truly atrocious hack of software, consider horde (horde.org) with its accompanying calendar and other modules instead. I don't know what type of authentication you use on windows be it active directory or old style domain but syncing is really troublesome. There is a solution in almost all circumstances to authenticating against the windows auth controller directly, google for you particular needs or be more specific. I assume you will be running quickbooks under wine or codeweavers? There are some errata with that and ltsp, check the wine and codeweavers lists. One very cool setup we have deployed lately for people in almost your exact circumstance is to run the windows system inside vmware on the ltsp box. obviously this requires beefy hardware but it takes server consolidation to a new level and has proved quite useful in the right circumstances. Codeweavers is the best bet for providing windows apps in linux directly, however using rdesktop and similar applications you can make it appear as though windows apps are running under linux and that is usually enough. Google for rdesktop, scripting and other hacks. Most of the things we have added to our ltsp deployments are local floppy/cdrom support, branded boot screens and logins for gdm so forth. Lots of performance improvements. Boot progress screens (make it look almost exactly like windows which may or may not be what you want). We now also have customers looking for sound and have been able to do that in our ongoing development. Google is your friend when it comes to ltsp, there exists many patches and hack to the base packages. Kernel/sysctl optimization can also usually have a large impact on ltsp performance (or general linux performance) so read up. If you compile openoffice yourself regardless of distro do so without frame pointers (i.e. --fomit-frame-pointer) it makes the binary significantly smaller (consequently using less memory) and does some good things to the generally sluggish openoffice performance. You can also compile OO without some of the junk you may not need. Going back to the distributions for a moment without question redhat 9 offers the most intuitive desktop for typical office productivity. This may be a point of contention with some but our usability research as well as our customer demand and feedback has made that very clear to us. Failover is a huge concern especially as you get past the 30 some odd users mark. There are no really elegant solutions at this time but by having raid and the likely faulty server hardware (disk, processor, mb) backed up with parts you could limit a catastrophic event to less than an hour downtime. On the client end PXE is often more trouble that it is worth, cd, floppy, or flash on ide are all things we have done in the past. The flash on IDE is what I like the best but it does cost about $10-20 per client. You can even get little headers that go right on the IDE connector on the motherboard and just pop the flash onto that. Feel free to drop me a note if you have other questions, duhlman at 50km dot com. The community could also benefit if you were to case study you situation and provide good documentation (even if you had to anonymize it). Sincerely, David Uhlman CTO 50km Inc. simply service wrote: > I've just recently been approved to rollout LTSP and a Win2k terminal server. I wanted to run my plan by the plug list to make sure I'm not overlooking anything (this is my first time playing with terminal services). > > I plan to install Gentoo to replace our main server (which is currently running SuSe 7.3). The server is a 2.4 GHz systen with 512 MB of 1066 MHz RDRAM. Another system will have the same configuration, but with 1 GB of RAM for the Win2k terminal server. Most of the workstations on the Lan have a Realtek 8139(A/B) network card that is not PXE capable so I'm going to have to boot these with a floppy. Here is a list of software that will need to be available for this 6 user (more later) system: > 1. Mozilla > 2. Internet Explorer > 3. KMail > 4. Quickbooks > 5. OpenOffice > 6. Adobe Acrobat Reader > 7. phpGroupware > > I am foreseeing a few problems and would like to know if anyone has any experience with these issues: > > 1. Linux to Windows password sync? (I know of "Services for Unix" package from microsoft, are there other options?) > 2. Is there a better way to provide linux users access to windows applications? (wine isn't good enough). > 3. Any problems I'm overlooking? I'm sure there are a few. > > Thanks, > > Jason Pfingstmann, CNA > Systems Engineer > Serendipity Telepresence, Inc. > (480) 731-9510 > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us > To subscribe, unsubscribe, or to change you mail settings: > http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss > >