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.
- The Tiny Internet Project, Part I
- Machine Learning with Python
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Bitcoin on Amazon! Sort of...
- Epiq Solutions' Sidekiq M.2
- Securing the Programmer
- Android Browser Security--What You Haven't Been Told
- The Many Paths to a Solution
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide