[Scribus] Congratulations and initial comments...

[Rolf-Werner Eilert]

Though we're getting slightly off-topic here, let me comment to some of 
your points on LTSP, Craig. We're using LTSP in a school-like 
environment with about 50 clients now.

> 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.

That's the point - we've got a similar system (older Xeons, not the 
Core-Duo ones, but those with 1 real and 1 simulated CPU, so 4 CPUs in 
total). But I do not limit their use, and the system scales 
fantastically. Sure you can see that flash takes processing power, but 
even if many users watch flash pages at the same time, there is no real 
break-down or even idling.

> 
> 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.

I tried to set up USB, but my old Suse which the system is based on 
prevented it by its own little geaks - it will play a roll in the future 
here. So I'll have to get through it again... :-)

> 
> Don't use GDM. It's hopelessly unreliable. Use good old XDM or even KDM.

Currently we're using XDM, KDM for the new server.

> 
> You'll get really sick of apps with broken and unreliably
> single-instance-per-user crud, like Firefox, Thunderbird and OpenOffice.

Never had any problems with it. I can't understand where your problem 
lies here. We're using all these three plus Wine with all those happy 
Word, Excel, PowerPoint and Outlook(!) things, and apart from some minor 
glitches (some functions calling Excel from Word or vice versa, 
sometimes redrawing in Excel), everything runs perfectly and smoothly. 
And if any process gets wild, this might block one CPU for some time, 
but there are still three to do the job.

As I'm writing this, about 30 users are logged in in two labs, and the 
system just "feels" like when I'm alone here in the afternoon.

> LTSP isn't much good for really graphics intensive work. Scribus works

You can watch YouTube videos, but not more than 3 at a time here. We've 
got 100 MBit connections.

> 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.

I'm working with Scribus on this system (my office has a thin client to 
this server) on a nearly weekly basis, but never had any of these 
problems you describe here.

> 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,

Never did, yes it's right. But I wouldn't do this on a mission critical 
system. Xen would help here a lot, that's correct though.

> 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

We've got 4 GB, and up to now it's enough for up to 45 users. It's 
interesting to watch how smartly Linux uses this RAM when more and more 
people log in. And the system has never used more than 30 MB of swap memory.

> + ~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.

I tried to set up the new system (the one I'm currently preparing) on a 
64 bit basis, but there were too many inconsistencies with the software 
we use. So I played over a 32 bit version, that seems to run better.

> 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

Nope, not my experience. Once a single user has a program up and 
running, there is mostly copying and pointers in the RAM when more users 
start the same app. So disc load is not that critical.

It payed however to split the most used parts of the file system to 
several discs: One for /home, one for /var etc.

> 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

100 % agree.

> Avoid NFS. It's frustratingly unreliable in real world use (on Linux;

There are some folks who have a second machine as an emergency backup 
system. Actually, I'm thinking to make something like that here, too. 
And there are some freaks who have several servers running with one 
machine holding the $HOMES for the users... They will all use NFS, won't 
they?

> Under absolutely no circumstances permit Evolution anywhere near your

We don't need it, don't use it here. Yes, it's slowly (I tested it 
once), but this doesn't seem to be LTSP's mistake :-)

Regards

Rolf