I agree with Luke for a different reason. The other problem with centralising X is network bandwidth. All of the graphics have to pass to and fro which means you need both high bandwidth low latency and no network problems.
This makes the network a choke point to be watched and will put off some people. I'd run the apps locally and servers remotely but with an auto install tool. Unless you're restricted in the client PC end with old processors. Stu On Wed, 2002-11-13 at 22:18, [EMAIL PROTECTED] wrote: > On 13 Nov, Jeff Waugh wrote: > > Centralised execution is a huge win, or at least I think so. :-) I've done a > > number of rollouts for various clients, using X and Win4Lin; simple GNOME > > desktops and OpenOffice; and rdesktop for el-cheap-o terminal services on > > low end hardware. Lots of room for savings, bucketloads of room for > > administrative overhead reduction. > > The approach at work is to have a central /opt area, and OpenOffice > etc. installed there. It's a file server. This centralises admin > but scales well too - since the execution is done on the desktop > machines (which are supercomputers by previous generations' standards). > > Having more than a few X terminals executing typical GUI applications > chews a lot of CPU cycles, in contrast. > > Check out http://www.zip.com.au/~cs/syncopt/index.html for a writeup of > the scripts that govern this, how to build packages ready for central > installation, etc. > > There's a touch of auto-mounting goes on too, to serve up > architecture-specific binaries without changing any path names (e.g. > /opt/bin). > > It works very well. > > luke > > -- > SLUG - Sydney Linux User's Group - http://slug.org.au/ > More Info: http://lists.slug.org.au/listinfo/slug > -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
