MILLE-XTERM and LTSP
The MILLE-XTERM Project focuses on user experience. A MILLE-XTERM X terminal has to provide the same functions as a regular workstation. In order to achieve this goal, extensive desktop personalization is required. Here are some of the most important topics:
Sound support: because the applications run on the server and the sound card is on the terminal, using /dev/dsp doesn't work. Solutions such as Esound, Arts, Nas and others have been developed over time. We have found that Arts can make a machine unstable (for example, TiMidity++ takes up to 99% of the CPU) and that very few applications support Nas. In our experience, the only workable solution is Esound (esd). GNOME support is native, and KDE, which uses Arts, has an option to use esd as its back end. Major applications, such as Flash Player, RealPlayer and SDL-based games, use it natively. When users first log in to the system, a script automatically creates configuration files to use esd. However, there is still work to do. For example, Audacity does not yet support esd.
Video support: with Windows, people usually use QuickTime, RealPlayer or Windows Media Player. They expect these essential packages to work on an X terminal. This is a bit of a challenge, as most distributions do not provide these players and appropriate codecs. Those familiar with the command-line swear by MPlayer, and others swear at it. A Mozilla plugin called mplayerplug-in solves the problem and neatly embeds MPlayer in the Web browser with Play, Pause and Forward buttons. MPlayer also can use Windows DLLs optionally to play popular file formats, but as with all proprietary programs, there are many licensing issues to consider.
Local applications: some applications simply cannot operate with the standard client/server scenario. For example, if users want to control the volume of the terminal sound card, they must run Aumix or Alsamixer locally on the terminal. Also, running the media player directly on the terminal is better than streaming 30 frames per second over the network, as this can quickly clog the network. In these instances, these applications run better when bunched locally on the terminal. To that end, a wrapper script called runlocal connects to the terminal with the user key via SSH and mounts the user's home directory via sshfs, allowing the application to access user files and settings.
Application configuration: most applications will create their own configuration files when first launched. In many cases, the default works well. In other cases, they need to be modified for use on an X terminal. For instance, several applications use the X-server memory as a cache memory. Although this is very efficient on a Linux workstation, it can cause an X-terminal crash when the memory used by the X server is bigger than the RAM of the terminal. An effective way to diagnose problems with X-server memory consumption is to use the xrestop tool. For KDE users, this kind of memory problem may occur when copying/pasting a large drawing with Klipper enabled. The only solution at this point is to disable Klipper. Here's a sample Firefox configuration that disables memory and disk cache:
// File /opt/firefox/greprefs/xterm.js pref("general.config.obscure_value", 0); pref("general.config.filename", "firefox.cfg"); // File /opt/firefox/firefox.cfg lockPref("browser.cache.disk.enable", false); lockPref("browser.cache.memory.enable", false); lockPref("browser.sessionhistory.max_total_viewers", 0);
Personalization: many projects are focusing on language issues, such as internationalization (i18n) and localization (l10n). However, still no personalization layer (p13n) provides an easy way to configure icons on the desktop, menus, browser preferences, bookmarks, backgrounds, screensavers, default applications and so forth. Work has begun in the freedesktop.org project and with Sabayon and Kiosk, for instance, but it remains far from complete and covers only KDE and GNOME. In the meantime, we use a set of homemade scripts and config files to configure the desktop according to an organization's needs.
Global infrastructure integration: to be successful, the system must be integrated fully into the existing infrastructure (directory server, files and printing). Take printing, for example. If a school district has 50 schools and more than a thousand different printers, how do you select which ones to display in Firefox or OpenOffice.org? We solved the challenge with a simple wrapper that intercepts calls to the CUPS shared library in order to apply a filter based on the user location. The printer list and the default printer for the terminal is stored in the configurator database.