On Thu, 2004-07-15 at 20:21, Jim Glutting wrote:
> I am requesting any success
> stories or testimonials from small to medium size businesses.
> This customer is 'comfortable' with the MS solution, so I
> would like to present to him some unbias testmonials.
> If you know of any links on the web, or have a story to tell,
> please post it to the group.
This message appears to have turned into a small book. I lack the time
to edit it down and clarify it, but I hope it is readable and clear
enough. I would be interested in hearing what sorts of users your client
has, by the way (and in fact generally interested in what sorts of
things people here use LTSP for).
--
The company I work for, the POST Newspapers (Western Australia), has
been using LTSP-based thin clients for 18 months now. The users I
initially deployed the system for have very basic needs - web access,
email, viewing PDF files, and accessing an old UNIX custom application
through a terminal emulator. These users are the sales staff - 12
people, plus or minus a few over time. The old systems were completely
unable to satisfy the needs of the users, and I decided to investigate
upgrade options.
The business was, at the time, in the process of developing a new
application to replace one of our custom apps, and this app was to run
on a Linux server. This new server was going to double as a file server
to store our (huge) archives of old editions, stories, graphics,
advertising information, etc, which previously had to be retrieved from
tape (a time consuming process). As such, it seemed natural to look at
upgrading the ageing client machines in sales at the same time, to try
to avoid too much duplication of effort and equipment.
The main choices I looked at were:
Windows PCs
Windows thin clients
Linux thin clients
We knew that essentially any software environment would satisfy our
needs as far as functionality goes, and that the main requirements were
security, minimal management requirements, ease of user training, and
low cost. I was happy that Linux thin clients would satisfy these
requirements. As the users needs were quite basic, training wasn't a big
concern.
In the end, the decision came down to cost. While the initial cost of
the basic Windows deployments was not too bad, once one counts in the
mandatory virus scanners and time maintaining, fixing, and rebuilding
workstations, things become less attractive.
The Windows thin client option would actually cost us MORE than Windows
desktops, as the antivirus solution was more expensive, we would need
some additional software to do what we needed, and TSCALs (terminal
server client access licenses) were ruinously expensive. Additionally, I
wasn't familiar with a Windows Terminal Server environment and knew it
would take some time to get the kinks ironed out. This was confirmed by
the advice of others I spoke to who had worked on such environments. We
would also have needed an additional server to run TS, as the already
in-progress application needed a modern *NIX server.
We had already been running Linux thin clients as a trial, and found
them to need considerably less attention than the Windows clients used
elsewhere in the business. We were going to be buying a new server
anyway, and decided to buy a much larger and more capable one that we
could expect to be able to run a bunch of thin clients off. If the thin
clients didn't work out, the cost wouldn't be so great that we couldn't
fall back on another option.
Once the server was supplied and installed, I set up a few thin clients
to run off it. At this point I was actually using a roll-your-own Linux
thin client setup, but quickly moved to LTSP (which was a delight). It
proved fairly easy to get the core software the users would need working
and configured, and it didn't take long before I had things set up so
that I could quickly and easily add users. There were a few annoying
bugs in Mozilla Mail and OpenOffice.org (1.0.0 at the time) had some
issues, but overall things worked very well. We were running XFCE4,
Rox-Filer, Mozilla (Browser and Mail), OpenOffice.org, and Adobe Acrobat
Reader off a Red Hat 8 server. User authentication was by LDAP (which I
heartily recommend).
We went ahead and implemented the system for all the users we'd been
considering it for. The bugs were being ironed out by the developers of
the sofware we were using, and things were going well enough that it
seemed worthwhile. There would be no change to the users' core
application (which just ran in a terminal emulator), and to a fair
extent email is email is email. User training turned out to be the
relative non-issue I'd expected.
We decided to buy second hand (and rather old) PCs for the clients, as
we were able to get a set of identical machines plus a few spares. While
this worked quite well, I would advise anybody setting up a network now
to instead look at dedicated thin clients, small form factor PCs, or at
the very least at machines with superior performance to what we chose.
We bought Pentium 133s with 32MB of RAM and S3 video for a pittance -
and while the CPU is more than adequate, the machines could really use
more RAM and above all else a superior video card. I recently upgraded
one to a GeForce 4 MX, and it's like sitting at the server instead of a
thin client. Make sure your client machines have good video hardware if
you like snappy displays (and trust me, your users will).
Overall, things have been quietly going well ever since. User migration
was fairly uneventful. The biggest challenge was converting the awful
mess that Eudora 3 (which we'd used on the old clients) calls a mailbox
into something we could import into our IMAP server. Upgrades to
OpenOffice.org and Mozilla have massively improved the quality and
reliability of both applications, and things just quietly work. I spend
a lot most of my time trying to keep the Production department's 6 MacOS
9 G4s running, and most of the rest I'm able to spend doing application
development.
A while ago, I ended up providing one of the journalists with an
upgraded thin client (64MB of RAM, GeForce 4 MX, and a 19" monitor). She
is almost blind, and it proved incredibly difficult to get Windows to
actually produce big enough type without the entire interface falling
apart. As there is no real 'standard' font and size on Linux, nor a
standard screen dpi, I knew applications under Linux would handle this
better. I put the machine in as a trial, and it did the job very well,
displaying 24 point type (real points, not points-at-pretend-96-dpi like
Windows uses) for menus etc without problems. Unlike the more basic
users, I set up GNOME as the login environment, and that seems to have
been a good choice. Thought the original journalist who used that
machine has since left, her replacement seems to find the system quite
usable as well.
At this point, I would happily recommend a Linux thin client setup to
anybody with a large group of users with fairly basic needs. The same
goes, oddly enough, for an organisation with technically competent users
(think of an ISP helpdesk at a well run ISP). I'd be less enthusiastic
about people who need to collaborate closely with advanced MS Office
users, as while OpenOffice is quite good in that regard and regularly
improving, it's IMHO still not quite good enough. Do note the 'advanced'
in the above sentence, though - unless you need pixel-perfect fonts and
layout, or to work with complex graphs, embedding, and scripting,
OpenOffice should do the trick quite nicely.
Linux desktop software is far from perfect, but in many cases it does
the job excellently (and the day anybody can show me some software that
is, in fact, close to perfect will be the first). Additionally, even in
the 18 months we've had this system deployed, the software improvements
have been incredible. Even more so because of the total lack of upgrade
fees - the only cost is the usually minimal time needed to test and
deploy the upgrade.
A pleasant and somewhat unexpected bonus for us has been the opportunity
to upgrade a lot of other services by moving them onto the powerful new
terminal server. Over time, I've migrated our mail services from MDaemon
on NT to Cyrus IMAPd (which I can't possibly recommend enough, it's just
incredible) on the Linux server. As the waves of viruses and spam have
increased in strength and frequency, their effect on us has remained
minimal thanks to MIMEDefang, SpamAssassin, and ClamAV. I also run
several small in-house web applications on the machine (written in
Python, backed by PostgreSQL), one of which has proved incredibly useful
to the business. We also use the same machine for our intranet web
server and are moving production file & print services for MacOS,
Windows, and Linux thin clients over to it at present. The server copes
with all this easily (but then, it is a dual Xeon with two gigs of RAM).
Most of this has been done step by step as we've outgrown old systems or
they've otherwise needed replacement, and in most cases we've
implemented it on the Linux server as a trial - which goes so well we
never need to bother looking at alternatives. I've been able to do a lot
of things that wouldn't have been possible on other platforms due to the
cost of the tools or server software required to even investigate the
viability of the idea. It's much easier to "just try it and see."
My biggest gripe with the whole thing is the inconsistency in Linux
desktops. In particular, the Open/Save dialogs of OpenOffice, Mozilla,
KDE apps, GNOME apps, and any other apps are ALL DIFFERENT. While not a
problem once users get used to it, it is a real bump in training and one
that to me seems entirely pointless.
Additionally, many applications make central configuration harder than
it could be. It is much too difficult to set a sensible set of custom
defaults in OpenOffice so that they're inherited by all users when the
global (all-users) configuration changes. The same is true of Mozilla,
but thankfully not of XFCE or KDE. A single consistent configuration
mechanism - such as the adoption of the KDE configuration scheme (which,
with Kiosk, is excellent) would be a big managability improvement.
So in the end, it's worked out extremely well for us and I'm absolutely
delighted. The initial deployment was good, but what we've been able to
do with it since, and its future potential, are incredible. I would not
be surprised if we have the entire business running off LTSP-based thin
clients, except the Production dep't (who need QuarkXPress, Acrobat,
Illustrator and Photoshop) and accounts dep't, within a year or two. The
amount of money we've saved in administration time, hardware, and in
software licenses is just incredible. If one takes into account the
improved services we've been able to offer, such as faster, more
reliable mail and a number of incredibly handy in-house web apps that
save a lot of time, the advantages are even greater. The massively
reduced worries about malware for the Linux clients is also a great time
(and stress) saver.
I do advise you to get good client hardware and a powerful server. Dual
processor if possible, but to be honest our server - even with all it
does rarely sees much CPU load. Rather, I'd advise you to get a LOT of
memory (2GB is OK for us, but with everything else we use the machine
for 4GB wouldn't hurt), a gigabit uplink to the core switch, and nice
fast disks (perhaps Western Digital Raptors for the /, /usr, and your
mail spools and databases). Of course, this will depend on your budget,
user needs, and user count. The opinion of others on this list may also
differ on this point.
Above all else, whether a Linux thin client setup is right for you
depends on what your needs are and where your competencies lie. Without
knowing what those are, all I can tell you is that for my company's
needs it has been brilliant.
I realise this rather long message has comments on LTSP mixed up rather
heavily with comments on Linux desktops and servers in general, but it's
my opinion that those are the points that really matter. LTSP works so
well, with so little fuss, that you can forget it's there and instead
spend your time making sure your users' environment is right for them
without having to worry about how they access it.
--
Craig Ringer
IT Manager
POST Newspapers
Western Australia
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
