City of Largo Adopts KDE 2.1.1

Dave Richards, Systems Administrator for the
City of Largo, Florida,
has just
announced
that the City of Largo has switched to KDE 2.1.1 as their
production system. According to Dave, "The City of Largo is a thin
client/X shop [which supports] 400 thin client
devices that support X, 800 total users, and run about 230 concurrently
during the heaviest part of the day." Dave shares his experiences and
problems in getting the system working below, and happily concludes that "the cutover has gone really well". Update: 07/25 8:25 PM by N: Dave answers your questions in this article. You can also check out his old presentation at SCO Forum 99.

Date:  Mon, 23 Jul 2001 15:09:14 -0400
From:  Dave Richards <[email protected]>
To:  [email protected]
Subject:  City of Largo Goes Live With KDE 2.1.1

Developers-

I am not on the kde-devel group, this message is being sent from
the outside and if anyone wants to contact me, they should do so directly.
I posted a message a few months ago about the City of Largos intentions to
go live with the KDE desktop and as of Friday that transition is complete.
I thought the cutover, and some of the things that I had to do would be of
interest to all of you. I also want to thank every person that worked on
this project because it has offered us a solution that has fit perfectly
into our technology and design goals.

Technology and Design Goals

The City of Largo is a thin client/X shop. We have 400 thin client
devices that support X, 800 total users, and run about 230 concurrently
during the heaviest part of the day. For the last 7 years, we have always
built one large 'desktop' system that everyone logs into and gets their
desktop. All of the icons do a 'rsh' to other systems and then start up
the various software packages that we have in the City. For instance, an
icon will say "WordPerfect" and the command executed is "rsh oa1
/usr/local/bin/sh_wordperfect $DISPLAY". Previously, this function was
done by the IXI Desktop on SCO OpenServer, and then later we ran KDE 1 on
OpenServer, then Unixware. The Friday cutover was moving all of these
users off of Unixware to RedHat Linux 7.1 and KDE 2.1.1 Because only KDE
is running on this machine, the performance is a good look at how KDE
scales.

Cutover & Runtime Issues

The cutover has gone really well. Most of the issues that we
have had have been people issues and not technology issues. I have been
keeping notes and the issues that came up are noted below:

• The server we built is a dual-933 with 3GB of memory, and 18GB of disk,
  this goes for about $9500 USD.
• It seems that we settled into about 11-12MB of memory per user on the
  server. 3GB of memory has allowed us to get the 230 concurrent users
  logged in without using the swap space.
• The dual-933 runs about 5-30% busy during the day with 200+ users on.
  Most of the load seems to come from using the Pager and window management.
• When a large amount of users are cut over, there is a spike the first few
  days while everyone customizes their desktops. Everyone pokes around in
  the wallpapers and colors and fonts until they are comfortable. And then,
  people tend to not change them often again. It's best to move people over
  in groups of about 20-30 at a time and then let them configure and then
  bring over another group.

Custom Changes

I had to make some changes to startkde to accomodate our thin
clients.

• I had to put in code to redirect the sound to the thin clients. By
  default, KDE tries to send them to a sound card in the server itself (which
  is sitting in the computer room). ;) Perhaps at some point, KDE could
  allow a plugin system to be deployed that would allow the administrator to
  select the desired sound system. For those using NAS (Network Audio
  System) the web page for that project and the redirection patch link is
  here.
• 8 bit color really causes some problems. Non-technical users cannot
  understand color allocation and how once cells are used, applications begin
  to not function correctly. I installed a dialog box that tells them they
  are on a low color terminal-->

  DEPTH=`/usr/bin/X11/xdpyinfo | grep "depth of root window:" \
  | awk -F " " '{print $5}'`
  case $DEPTH in
  8)
  /usr/local/bin/sh_8bit &
  ;;
  esac

• I also turned off ksplash for low color users, to help cut down
  on usage-->

  # the splashscreen and progress indicator only in 16 bit depth
  case $DEPTH in
  16)
  ksplash
  ;;
  esac

• What would be really nice is for KDE to allow me to force some
  rules on 8 bit color users, for instance:
• Use 16 color icons on the kpanel and kmenu automatically.
  They won't know to pick a lo_lo_color option like this.
• Allow me to turn off gradient colors when in 8 bit mode,
  allow them to only pick solid colors that are in the pallette.
• Allow me to turn off wallpapers for 8 bit devices. The
  option is grayed out, doesn't even work.
• Wallpapers that are selected on a 16bit display, don't
  display and just use a solid color wallpaper when the
  user moves back and forth between 8 and 16 bit
  color.

KDE Applications

I have some notes on certain features that would help with
deploying in a large shop:

• Kicker
• We would like to have the "Refresh" option back, when I install
  new icons I'm sometimes on the phone with users and it would
  be nice to have them be able to "Refresh" and see them
  right away.
• The autofresh feature of Kicker seems to really put a load on the
  server when you have hundreds of people on the same machine.
  It seems to hit them all at the same time.
• It would be nice to turn off some of the features in the lower
  part of the kmenu. We have some 'technique challenged' people and
  I would like to hide certain things from them. I would
  turn off "Run Command", "Quick Browser", "Recent Documents",
  "BookMarks". All of these make the assumption that
  documents and files are on the KDE machine, which isn't the case. Instead,
  what they are doing is opening up the GUI file managers and
  deleting their configuration files because they think they are just
  'unknown files'.
• There seems to be an issue where users that change terminals off
  have their DISPLAY variable get confused when running something like
  command=rsh oa1 /usr/local/bin/sh_whatever $DISPLAY
  directly from the xxxx.desktop file. There must be a pipe or something
  that is
  still being held. Instead, what we have to do is run
  command=/usr/local/bin/sh_whatever and have the program in /usr/local/bin
  do the rsh and then it works.
• AutoStart
• I have had some requests that Autostart allow you to select the
  room that the application start in. When you shut down KDE currently,
  and tell KDE to remember everything that is
  running, it doesn't do so if the programs were initiated via 'rsh'.
• Configuration
• We would like the ability to turn off the feature that lets users
  pick their own wallpaper instead of picking from our approved lists. What
  is happening is that people are installing their own
  wallpapers, and now I'm going to have to write a script to find all of them
  that
  are in use and check to make sure they are 'politically
  correct' in the workplace. We would rather they send them to us for
  approval and then install them into the main directory.
• KDE seems to have some problems when the terminals are turned
  off. Certain processes stay on the server if they do not log off
  correctly.
  Some of our users simply power off their temrinals at the
  end of the day. :( Could there be some kind of keepalive checks in the
  various programs to make sure the Xserver is still alive
  and then terminate process if not? I'm not sure how to fix this, but
  will keep experimenting.

Conclusion

I hope this information is interesting to you all, I hate to think I wasted
your time with it! ;) If anyone has any questions or comments, feel free
to drop me a line, I'll be happy to answer your questions. It's the least
that I can do considering how much this product has given us and our users.

Regards

Dave Richards
City of Largo, FL
Systems Administrator