MILLE-XTERM provides a scalable infrastructure for massive X-terminal deployment.
Getting the Best User Experience

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



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Simple question about application in other settings

taplinb's picture


I have tested at home K12LTSP, Sun Rays, and Windows Terminal Server, and a decade ago used Citrix Winframe for a couple of mid-sized projects (2-3 servers). I have long been curious about LTSP and the like in small corporate settings but was and am concerned about (a) long-term support, (b) scalability, and (c) software maintenance and distribution.

Regarding the latter, Debian packages have been, in my limited experience, the easiest way to deploy new Linux packages, and I particularly like the wrapping I've seen in MintInstall, part of the Mint offshoot of Ubuntu 8.

How might the MILLE Project address my three concerns. Also, is there enough support in English? I do not speak or read French.

Brad Taplin,
former tech support professional
now in law school in St. Paul, MN

Errata : firefox memory setting

Francis Giraldeau's picture

To prevent Firefox to use memory for caching, the article says to set the parameter browser.cache.memory.enable to "False", but it should be written to set this parameter to "True" to get this behavior.

For more information, see the page

Sorry for the mistake.