[Scribus] Congratulations and initial comments...

[Craig Ringer]

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