MainakGhosh.com

For years, discerning Windows users have relied on Tweak UI, a semi-official Microsoft program for system settings not available on the default desktop. Now, in the same tradition and with something of the same name, Ubuntu Tweak (UT) offers the same advantage to Ubuntu users. Currently at version 0.2.4, for now UT is limited to features for GNOME and focuses mainly on changing default desktop and system behavior and how GNOME interacts with your hardware, but this small feature set is more than enough for proof of concept.

UT runs on Ubuntu 7.10 and 7.04, and is available as either a Debian package of 127KB or as source code. Since UT apparently searches for the distribution and version, it does not run on earlier versions, or — unlike many Ubuntu packages — on other distributions that use Debian packages.

The package creates a menu item under Applications -> System Tools, and the program opens on a plain but effective interface, with a pane of icons on the left serving as as a table of contents and a right pane displaying the available options in the currently highlighted category. The interface is self-explanatory, although a few categories could be more plainly labeled for ease of use. For instance, “GNOME” actually refers to panel and right-click menu items, while “Desktop Icons” is more specifically about the default icons. However, perhaps such category names will become more appropriate as more options are added.

By contrast, one place where online help is needed is with the options themselves. The sort of desktop users that UT is aimed at are going to be spooked by options like “Metacity theme active window opacity shade” or wonder exactly what the advanced permissions, BurnProof technology, or OverBurn options for Nautilus entail. Both brief mouseover explanations and more detailed help would be useful for UT’s target audience, but such finishing details cannot be expected in an early release.

A selection of options

Computer, the first entry in UT’s table of contents, summarizes system and user information, but — contrary to first glance — does not allow any editing of this data. Below this summary, UT lists dozens of options, largely in terms of the part of GNOME that they apply to. Many are concerned with changing Ubuntu’s default behavior. For instance, under Session Control, you have the option of whether to show the splash screen as GNOME starts up, or replace it with a graphic of your choice. Similarly, under Desktop icon, you can choose whether the Computer, Home, Trash, and Network icons display, and rename them.

Other options are concerned with the dialog windows you encounter. Under Session Control, you can disable the Logout prompt, while under the GNOME category, you can disable the Confirmation dialog that appears when you remove a panel.

A third category of options affects how GNOME interacts with your hardware. Under Power Manager, you can disable the Hibernation and Suspend options, or, if you are on a laptop, adjust the CPU frequency depending on whether you are running on AC or battery power.

An especially powerful set of options is placed under the general category of Security, where you can choose to disable the Alt-F2 popup command shell, printing, or saving to disk. All these features could be ideal for a system administrator who needs to limit what users can do.

So far as I can see, UT offers no options that you could not get by editing the ./gconf folder in your home directory. However, desktop users are unlikely to be aware of that folder unless they happen across the Show Hidden Files option in Nautilus. And, even if they are aware of gconf, they might well be daunted at the idea of editing XML files, particularly without a guide.

Ubuntu Tweak fills a definite need. If the steady trickle of suggestions for additional options on the project’s Web site is any indication, there are plenty of Ubuntu desktop users who appreciate such ease of use. If UT is somewhat limited in functionality now, as it develops, it should evolve into a useful addition to Ubuntu’s desktop tool kit.

source:linux.com

Even people who don’t live and die by their mobile phones sometimes need to send SMS messages. Did you know you can do that from your computer? Likewise, it’s easier to clean your mobile phone of all the numbers you’ve not been dialing in the last few years using a mouse, rather than navigating repeatedly through the phone’s menu system. Here are some Linux tools that can help you manage your cell phone.

Using a Windows Mobile-based smart phone or PDA in Linux is easy as pie. In most cases you just have to connect the device through USB and start up SynCE. For phones that don’t use a Microsoft operating system, such as my Motorola SLVR L7, applications like Moto4Lin and KMobileTools come in handy.

If you just need to view, delete, or send SMS messages and manage your address book, then KMobileTools, a part of KDE 3.5.x, is a good solution. If you don’t use KDE, you can download and install the program anyway. Configuration is straightforward: you pick a device brand from the list (Nokia, Motorola, Siemens, Sony Ericsson, and LG phones are supported) and choose a connection type. If you wish to use Bluetooth, pick /dev/rfcomm0. For USB connections choose /dev/ttyACM0 or /dev/ttyUSB0, and for serial ports use /dev/ttyS0. Leave the port speed at the default (115200). Configure the PhoneBook and specify whether you want the import settings to overwrite stored PhoneBook entries and whether the imported names should be in the Name, Nickname, or Name-Surname format. Then click on Refresh and choose the items you want to import: phone number list, missed calls list, quick dial numbers, SIM phonebook, own numbers, and others.

In the SMS window, click Refresh and choose whether you want to import text messages from phone memory or a SIM, and you’re all set.

If you download the latest beta from the KMobileTools site and you have an AT-compatible device, chances are that it will be detected automatically. Basically, the program uses AT commands to get information from the mobile phone, just like PC modems. In the 0.5.0 beta version of the application, the user interface was radically changed from its predecessor. It’s more intuitive and better integrated into the desktop environment.

As with the previous version, you can check the phone’s battery level and the signal strength from the main window. The contact list is clearly laid out in tabbed categories, and clicking on one of the names reveals all the info on that particular person in the right side of the window. In the lower-right side you have a list of actions that can be applied to the currently selected contact item: edit, delete, add new, import, and export. Right-clicking on a name brings up a context menu from which you can choose to call that contact’s number or send an SMS using one of the connected mobile phones. And speaking of SMS, in the new version of KMobileTools, these messages are beautifully structured into two main categories: Inbox (SIM and Phone) and Outgoing (SIM and Phone). In addition to letting you compose new messages and manage existing ones, the application lets you export text messages directly into KMail. If you use a different mail application there’s also the option to export to a CSV file.

You can minimize KMobileTools to the system tray and it will sit there quietly until someone calls you on the phone or you receive an SMS message — then the application will pop up a message and play a sound informing you of the event.

Wammu

There are other tools you can try. The Wammu GUI for Gammu, written in wxPython, offers the same functionality as KMobileTools. Since Gammu is basically a set of scripts, drivers, and CLI applications, Wammu greatly simplifies your work with them. The Phone Wizard function offers several connection options, such as USB, Bluetooth, and IrDA, and three configuration options: automatic, guided, and manual. Unlike KMobileTools, Wammu can display detailed information about your mobile phone, such as manufacturer, firmware number, and serial number. It can retrieve SMS and contact information from the device, along with to-do data, calendar, and call lists.

One of Wammu’s advantages is the ability to create and restore backups of your mobile data. The application can import *.vcf, *.ldif, *vcs, *.ics, and Nokia *.lmb files. On the downside is the time it takes to import messages into Wammu and the occasional freezes of the GUI.

Moto4Lin

Sometimes you want to do more with your phone. What about those moments when you need to download an image from the phone or want to upload a music file as a ringtone? For Motorola phones, try Moto4Lin. While KMobileTools can be used to manage contacts and text messages, Moto4Lin is strictly for file management.

Before you start, check the compatibility list to be sure your Motorola phone model is supported. My SLVR L7 had no problem connecting, although I had to manually edit ~/.qt/moto4linrc to get the program to remember my settings. In the Preferences window I set /dev/ttyACM0 as an ACM device. You’ll also need the vendor and product IDs from the previous link. If your mobile phone is not supported, you could still get lucky. Install usbview or use lsusb and write down the vendor and product ID it reports, then paste them accordingly in Moto4Lin. The P2K (Paragon Filesystem) vendor ID the utility reports should be the same as the AT vendor ID. As for the P2K product ID, it should be one unit smaller than the AT product ID above it. For example, in the case of my Motorola phone, the AT Vendor ID is 22b8, AT Product ID is 4902, P2K Vendor ID is 22b8 and the P2K Product ID is 4901.

Now click on Switch To P2K and click OK.

In the main window of the application, click on Connect/Disconnect, and when the mobile phone has successfully connected, press the Update List button. Moto4Lin will scan the device for all multimedia and Java files and present you with a directory structure. You can then download and upload files from and to your mobile phone, insert ringtones, copy 3GP and MMS files, and assign different types of attributes to them. A file can be marked as read-only, hidden, system, volume, directory, or archive.

Moto4Lin also has a nifty seem editor with upload and download functions, so you can edit your phone settings information from these storage containers. Since most mobile phones support Java applications, Moto4Lin also offers an interface for uploading and downloading Java midlets (Java applications for embedded devices) and a file manager that outputs information regarding the name, vendor, version, size, and startup status of the selected file.

Other functions include rebooting and suspending the phone.

Below is an example of my ~/.qt/moto4linrc:

[device]
cfgACMdevice=/dev/ttyACM0
cfgATproduct=4902
cfgATvendor=22b8
cfgAutoConnect=0
cfgDetachDriver=0
cfgP2Kproduct=4901
cfgP2Kvendor=22b8

[filemanager]

cfgAutoExpandDirTree=0
cfgAutoUpdateFileList=0
cfgGoLastFolder=0
cfgLoadList=0

In addition to the tools above, there are other applications you can try for establishing a connection with your mobile phone, including Phone Manager, KitchenSync, GMobileMedia, and ObexTool.

source:linux.com

One of the most welcome additions to OpenOffice.org 2.3 is a new export filter that allows you to save Writer documents as MediaWiki-formatted pages. That’s all fine and dandy if you are using MediaWiki, but what about other wiki systems? The answer to this question comes in the form of the OpenOffice2UniWakka export filter. While it’s designed to work with the UniWakka wiki, with a bit of hacking you can adapt it to other wiki systems as well, even if you are not familiar with XML and XSLT.

The OpenOffice2UniWakka filter itself consists of the OD2UniWakka.xslt file (or OOo2UniWakka.xslt, if you are still using OpenOffice.org 1.x.x). You can think of this file as a simple conversion program written in XSLT (Extensible Stylesheet Language Transformations), “an XML-based language used for the transformation of XML documents into other XML or human-readable documents.” Since the content of an .odt document is stored as an XML file, XSLT is a perfect tool for transforming Writer documents into wiki-formatted text files.

To start hacking the OpenOffice2UniWakka filter, download its latest version from UniWakka’s main page and unpack it, then open the OD2UniWakka.xslt file in a text editor. Let’s start seeing how we can modify the output with something simple like specifying transformation rules for basic formatting, including bold, italic, and underlined. The filter defines three variables that describe each style: font-style, font-weight, and font-underline:

<xsl:variable name="font-style" select="//office:automatic

-styles/style:style[@style:name=$style]/style:text-properties/@

fo:font-style"/>

<xsl:variable name="font-weight" select="//office:automatic-

styles/style:style[@style:name=$style]/style:text-properties/

@fo:font-weight"/>

<xsl:variable name="font-underline" select="//office:

automatic-styles/style:style[@style:name=$style]/style:

text-properties/@style:text-underline-style"/>

It then finds all text fragments containing the specified formatting and wraps them in wiki markup:

<xsl:when test="$font-weight='bold' and $font-style='italic'

and $font-underline='none'">**//</xsl:when>

This means that all you have to do is to locate all the statements that start with <xsl:when test= followed by the “style” condition, and replace the existing markup with the one you want.

The XSLT file also contains a separate section called “my styles” (it starts with the <–! my styles –> comment) where you can specify custom transformation rules. If you take a closer look at the default transformation rules, you’ll quickly notice that each rule has the following structure:

<xsl:template match="//text:span[@text:style-name='emph']">
   <xsl:text disable-output-escaping="yes">**</xsl:text>
   <xsl:apply-templates/>
   <xsl:text disable-output-escaping="yes">**</xsl:text>
</xsl:template>

You don’t need a degree in rocket science to figure out how the rule works: it simply finds text with a specific style and wraps it in the appropriate wiki markup, so the sentence “This is <b>bold</b>” is converted into “This is **bold**.” Knowing that, you can quickly add your own rules. If you are using, for example, DokuWiki, you can create a Writer template containing custom styles like dw-bold, dw-italic, dw-underlined, and so on. You can then specify transformation rules for each style in the “my styles” section of the OD2UniWakka.xslt file:

<xsl:template match="//text:span[@text:style-name='dw-italic']">
   <xsl:text disable-output-escaping="yes">''</xsl:text>
   <xsl:apply-templates/>
   <xsl:text disable-output-escaping="yes">''</xsl:text>
</xsl:template>
<xsl:template match="//text:span[@text:style-name='dw-bold']">
   <xsl:text disable-output-escaping="yes">**</xsl:text>
   <xsl:apply-templates/>
   <xsl:text disable-output-escaping="yes">**</xsl:text>
</xsl:template>

To make use of the defined custom transformation rules, you need to create a Writer template containing the specified styles (i.e. dw-italic, dw-bold, dw-underlined, etc.) and use them to format text.

Once you’ve figured out the basics, you can tweak the rest of the OD2UniWakka.xslt file. The final step of the process is to add the modified OD2UniWakka filter to OpenOffice.org. To do this, choose Tools -> XML Filter Settings and press the New button. Enter the filter’s name in the Filter name field (e.g. “OD2Wiki”) and select OpenOffice.org Writer from the Application drop-down list. In the Name of file type field, enter the name of the filter as it will appear in the list of available formats (e.g. “wiki”) and enter “txt” in the File extension field. Switch to the Transformation tab, and enter the path to the OD2UniWakka.xslt file in the XSLT for Export field. Press OK, then Close, and the filter is ready to go.

If you want to add the filter to multiple OpenOffice.org installations, or you want to share it with other users, you can export it as a .jar package. To do this, choose Tools -> XML Filter Settings, select the filter, and press the Save as Package button. You and other users can then install the package by simply pressing the Open Package button.

source:linux.com

For many users, the xorg.conf file, which configures the system resources, graphics card, keyboard, pointing device, and monitor for a computer running the X Window System, is an exception to GNU/Linux’s do-it-yourself credo. Users who think nothing of editing /etc/fstab or /etc/hosts.allow will shy away from xorg.conf for fear of breaking their systems, relying instead on tools such as the KDE Control Center or Debian’s dpkg-reconfigure xserver-xorg instead. But learning your way around xorg.conf not only teaches you a lot about how your system operates — it can also come in handy when the graphical display fails and you either can’t remember the handy command that does the work for you, or you’re working with a distribution that isn’t blessed with it.

It’s easy to understand users’ caution. Not only does xorg.conf contain a lot that can go wrong, but it is only fitfully documented in man and Web pages. Moreover, because the file’s settings are specific to each system, borrowing an example of the file off the Internet is unlikely to give you more than basic ideas of how to get its settings correct. However, so long as you remember to make a backup copy of the file and keep within the settings defined by the documentation that comes with the hardware, the danger is actually minimal.

The xorg.conf file is divided into a minimum of eight sections. The start of each section is marked by the word Section followed by the section’s name, and its end by EndSection. Sections can be placed in any order, and you can have more than one section that cover a certain purpose — for example, if you are using multiple monitors. As in most configuration files, you may also see lines that start with a number sign (#) that provide comments for human readers. These lines are ignored by the operating system, and you can add more for your own purposes.

Within each section, you can quickly observe the structure that additional entries should follow. For instance, most sections indent once for a field and again for its value, which is placed in double quotation marks. Similarly, hardware has an Identifier field, which can be anything so long as it is unique. The indentations are not needed by your computer, but they do ensure that the file is kept in human-readable form. Once you understand this basic structure, you are ready to edit xorg.conf.

Setting resources and improving font display

Resources for the X server are listed in the Files section. Some distributions include the path to the database used for the RGB color palettes used for the display (/usr/share/X11/rgb), as well as the path to the server modules (/usr/lib/xorg/modules or /usr/lib/modules), but these paths should be unnecessary unless your system has resources stored in unusual places. Recent versions of Debian, for instance, omit these entries entirely.

Most of the system resources are devoted to the paths used for fonts. Users must add all new fonts via a font server, the easiest one to use being the one built into the KDE Control Center, which stores fonts in /usr/local/share/fonts (nothing comparable exists for GNOME). Fonts that were added during system installation are usually stored in /usr/share/fonts/ or /usr/share/fonts/X11, which has subdirectories for TrueType, Type 1 or PostScript, and bitmapped fonts. You can add new font paths by following the format of existing entries:

FontPath "<absolutepath>"

If an application needs to display a particular font, then the X server uses the first instance of the font located. For this reason, you can sometimes improve font display on the system by changing the order in which fontpaths are listed. The “XFree86 Font Deuglification Mini HOWTO,” an old but still useful source, suggests that you place any directory for 100dpi bitmap fonts before those for 75dpi bitmap fonts, and add :unscaled to the end of all the paths for bitmapped fonts. These changes help to ensure that a higher quality font will be the one used by the X server.

Editing X server modules

xorg.conf’s Modules and DRI sections refer to modules loaded by the X server for such purposes as 3-D acceleration (glx, dri) and font support (freetype, type1, speedo). For the most part, you should not edit these sections. They are dependent on resources compiled in the kernel and supplied by various libraries added during installation, so simply editing xorg.conf may not have any effect on your system. Unfortunately, too, they are by far the least documented sections of the file, so if you’re not an expert, leave them alone.

However, if you are having display problems, as a last resort, you can try the hacker’s solution of commenting out all of the modules and adding them back one by one with each reboot. In particular, if you’re using the freetype module, other font modules may be redundant, such as type1, as well as the xtt module, which provides TrueType support conflicts with freetype according to some reports.

Defining the keyboard

The keyboard is defined in a separate Input Device section in xorg.conf that starts with an Identifier. The Identifier is followed by a Driver — usually just kbd in a 2.6 kernel — and, for the main keyboard in a configuration, the CoreKeyboard option.

Most users will also want to use the XkbRules options to define the general behavior of the keyboard, since the alternative is to define all aspects of the keyboard layout separately. This option should usually be defined as xorg, which indicates that the X server should use the standard settings for xorg.

However, even with the shortcut provided by XkbRules, you still need to define the XkbModel for the keyboard, using one of the options listed in /usr/share/X11/xkb/rules/base.lst, or else a generic one such as pc104 or pc102. You also need the XkbLayout option, which takes one of the standard two-digit locale codes that are also listed in base.lst in order to define the symbols associated with other keys.

If you want to use multiple layouts you can use XkbLayout to list multiple keyboard layouts in a comma-separated list, and use XkbOption to define a key or key combination that cycles through each layout. For example, to use Alt-Shift to move through the defined layouts, you would enter the line Option "XkbOptions" "grp:Alt_shift_toggle".

Similarly, if you want to define a Compose and an AltGraph key — two keys that are used to enable the typing of international characters, such as accents or currency symbols — you can use XkbOptions to define them. For instance, defining them as "compose:rwin, grp:lwin" would give those useless right and left Windows key a purpose at last.

Configuring the pointing device

A mouse or other pointing device is defined in a separate Input Device section. After the Identifier, the next three lines in the section will generally be:

Driver	"mouse"

  Option	"CorePointer"

  Option	"Device" "/dev/input/mice"

As you can probably guess, the CorePointer option defines the primary input device, and the Device gives the path to the device.

After that, an entry for a pointer device will have an option defining the Protocol, which describes the manufacturer and model of the device. The Auto option for the protocol is reported as broken in recent versions of xorg, so you should specify the exact protocol, such as Microsoft or Logitech, or the general type of mouse, such as ImPS/2 or USB.

If you have a two-button mouse, you should add the "Emulate 2 buttons" option. For devices that have more than three buttons, you can use the "Buttons" option to specify the exact number if you have more than three. More esoterically, you can use the "XAxisMapping" and "YAxisMapping" options to give a space-separated list of buttons to use when a scroll wheel is emulated, or "ZAxisMapping" to map the scroll wheel motion to another axis or button, either because you are using a device that lacks a scroll wheel but has extra buttons, or for simple convenience.

Configuring the graphics card

xorg.conf’s Device section controls the graphics card configuration. This name is obscure, but understandable when you consider that the graphics card drives the entire display. The basic configuration consists of the Identifier, followed by the Driver field. If you are having trouble with the display, you can try one of the drivers in the /usr/lib/xorg/modules/drivers directory, using the first element of the file name before the underscore as the entry for the driver in xorg.conf. For example, if the s3virge_drv.so file is in the directory, you would enter the driver name as "s3virge". If all else fails you can get basic video support by entering "vesa" or "vga" for the driver. Most of these drivers have a man page that you can consult for more information.

Increasingly, the BusID field, which defines the slot the video card is placed in, is also being used in this section. Usually, the first video card’s bus ID will be PCI:1:0:0, but you can find it for sure by running the lspci command and looking for the video card in the results. Depending on the card in your system, you may also need to add the VendorName and BoardName fields, using information that came with your video card.

Defining the monitor

At a minimum, the modern Monitor section of xorg.conf consists of a unique Identifier and the option DPMS, which enables Display Power Management Signaling in order to conserve the power used by the monitor. However, you can also set the horizontal and vertical refresh rates in the HorizSync and VertRefresh fields, or the monitor’s Gamma setting, using information supplied with the monitor.

Another option is DisplaySize, which is measured in millimeters and specifies the dots per inch to use at a particular resolution. To get the resolution in millimeters, multiply both the height and the width by 25.4, and divide each result by the desired DPI. For example, if your resolution is 1024 x768, the results rounded down would be 270 and 203, and the entire entry for the option would read:Option "DisplaySize" "270 203 # 96 DPI @ 1024x768".Alternatively, with some Nvidia cards, you may need to suppress the automatic setting of the DPI by including the option "USEdidDPI" set to “false” and following by the option "DPI" with a value for the desired DPI, such as "96 x 96".

Setting resolution and color depth

The Screen section begins with a unique identifier, followed by a summary of the display options, listing the video card (”Device”) and monitor by the Identifiers they were given in early sections of the file, followed by the default color depth (”DefaultDepth”).

The rest of the section is devoted to the Display subsection. For each color depth (”Depth”), the subsection lists each resolution (”Mode”) that the system supports. When the X Window System starts, it will try to use the default color depth at the maximum resolution listed for it. However, if X is unable to do so for any reason, then it will try each resolution for the default color depth, then repeat the process for the next highest color depth until it manages to load.

You can use this behavior to force your display to use a particular color depth and resolution, either because your system refuses to use the settings you want — possibly due to a flaw in the driver — or because you want settings lower than the maximum. All you need to do is change the default color depth, then, under the listing of resolutions for that depth, place your preferred resolution first.

You may also choose to delete the resolution listings for other color depths, as well as other resolutions. As long as you have a backup of the original xorg.conf file, the worst this practice can do is force you to restore the backup and reboot.

Final steps and final words

If you have added hardware to your system, your last step in editing xorg.conf must be to make sure that the xorg.conf references it. That means adding the Identifier for a new monitor or video card to the Screen section, and the Identifier for a new pointing device or keyboard to the ServerLayout section. When you have done that, either reboot your system or restart X using Ctrl-Alt-Backspace to test the new configuration. Should X fail to start, you can still edit xorg.conf from the command line, or, when either all options or all patience is exhausted, restore your system using the backup copy you made of xorg.conf. You can find log files for Xorg in /var/log, although, since the problem is bound to be in your recent changes, you may not need the log to figure out what is wrong.

These are only the most basic options for editing xorg.conf. Depending on which manufacturer you buy your hardware from and whether you are using multiple pieces of the same type of hardware, you can significantly complicate the contents of the file. However, the information here is enough for a basic orientation. You may never have to edit xorg.conf manually, but if you do, knowing what to expect can only help.

source:linux.com

The alpha 1 development release of Damn Small Linux (DSL) 4.0, which hit the Net on Tuesday, is “a very different version” that includes a number of features requested by users on the DSL forums.

In the release announcement, developer Robert Shingledecker specifically detailed the key elements, including:

• New 2.4.34 kernel.
• Easier to use user interface.
• A real desktop framework.
• Drag and drop capability.
• Better and more flexible file associations.
• Closer coupling of the icons and file manager.
• Optional menuless mode.
• More intuitive interface to MyDSL extensions.

Shingledecker urged would-be testers to read the new Getting Started document. “There are many changes in icons, file manager, accessing menu and mydsl,” he pointed out. He said he placed a minimal number of icons on the desktop so users could choose which applications they wanted. As DSL has four different installation methods — LiveCD, Frugal, Hybrid, and Traditional — Shingledecker asked that those posting bugs in the forum be sure to note which method they’re using.

DSL is a miniaturized Linux distro originally developed, according to its Web site, “as an experiment to see how many usable desktop applications can fit inside a 50MB live CD.” The developers have stated that the distribution will never exceed 50 MB. Over time, DSL morphed into a significant community project “with hundreds of development hours put into refinements including a fully automated remote and local application installation system and a very versatile backup and restore system which may be used with any writable media including a hard drive, a floppy drive, or a USB device.”

Despite its size, it includes what’s nearly a full desktop environment, and is highly versatile. Because it will fit on ultra-portable storage devices such as flash cards and USB flash drives, it has developed a loyal following. DSL even has a port that can run on an Xbox. And it works particularly well on low end or aging machines that would otherwise be put out to pasture.

For downloads, see the complete mirror list.

source:linux.com