Manufacturer: Metro Link Inc.
Price: $99US (Linux)
Reviewer: Mark Nassal
One of the best things about UNIX is that it allows you to customize and configure almost everything. This is also its greatest downfall. Nine times out of ten, configuration requires editing long and sometimes cryptic text files. One of the best examples of this phenomenon is setting up an X server.
Most changes are made on a trial-and-error basis. This method entails opening, editing, saving and trying the configuration file over and over. When it finally works the way you wish, you pray you don't have to change it again. Of course, as soon as you upgrade your graphics card, it's editing time again. You can forget about changing color depth on the fly—it's too bad if some of your applications work only at 256 color and the rest allow true color. If you want to use those 256 color applications, you will have to run all your programs at 256 colors.
The X configuration is something Linux users have had to endure like an ancient tribal ritual. It is often accompanied by screams of frustration, loss of sleep and hardware flying across the room.
Well, all that has changed with the advent of Metro-X. Metro-X is an X server by Metro Link Incorporated. It is extremely robust and easy to configure. Metro is available for most of the leading x86 Unix platforms (Linux, Solaris x86, System V 4.0, UnixWare and SCO). Red Hat has also started shipping Metro-X with their commercial 4.x distribution of Linux.
Configuration is a snap. You are guided through the process by a clean, well thought out Motif based GUI (see Figure 1). If you make a mistake or upgrade hardware, changes can be made in a matter of seconds.
Metro Link recommends a minimum configuration of 8MB of RAM and 12MB of hard disk space. I would recommend a minimum of 16MB of memory and a 486 33MHz CPU, as less than 16MB doesn't leave much room for applications. Note that XFree86 must be on the system before Metro-X can be installed, since Metro-X uses libraries and fonts installed by XFree—Metro-X is not a complete replacement for XFree86, just for the XFree86 X Server.
Pricing is very reasonable. A single-user license is included with the Red Hat Linux 4.x boxed set which sells for $49 US. A general Linux version is $99 US, and all other platforms list for $199 US. Metro-Link also offers Motif, OpenGL and Metro-Media at an additional cost.
If you are putting the product on a Red Hat Linux system, installation is easy using the Red Hat Package Manager (RPM). Log in as root and enter:
rpm -i /path/to/Metroess.3.1.5-2.i386.rpm
To ensure that Linux uses Metro-X instead of the default XFree86 server, the X11 link must be changed. Create the new link using the command:
ln -sf /usr/X11R6/bin/Xmetro /etc/X11/XNote that some systems put this link in /usr/X11R6/bin.
Configuration is done through the Metro-X GUI (see Figure 1):
X11 will automatically load with the GUI as the foreground process.
The first drop-down box allows the user to select from fourteen standard input devices. There is support for bus mice, PS2 mice, keyboard mice, track balls and several touch screens. And, of course, it allows you to choose the button configuration, e.g., 1, 2, 3 or three button emulation.
The next drop-down box is for keyboard configuration. The keyboard list is pretty impressive. There is support for most languages and for my favorite, the Microsoft keyboard. Since I spend so many hours at the computer, it's nice to have an ergonomic model. I was surprised to see my Microsoft keyboard listed—it's a non-standard item for a Unix system.
Next is the video card configuration. Metro supports thirty six brands of video cards (see Table 1). For specific card information visit the Metro Link web site at http://www.metrolink.com/products/metrox/cardlist.table.html. They have created a detailed table which lists supported color depths and resolutions for each card. Most of the Diamond, Number Nine and Video7 cards are listed. The support for Trident is a little weak; only one of their cards made it to the list (Trident 8900).
Color depth, frequency, virtual resolution and physical resolution are set by the click of a button. Depending on the card, color depths from 16 to 16M can be chosen, as well as virtual and physical resolution range from 640 x 480 to an impressive 1600 x 1200. The nice thing about the GUI configuration is you can quickly change color depth and resolution depending on your application needs. I have several programs, such as Applixware 4.2, that don't work right above an 8 bit pallet. However, I like to do all my graphics editing in true color. With Metro-X, I can change the video configuration to match my applications in a matter of seconds.
The Monitor button displays a huge list of common monitor types, and automatically creates the allowable frequency range and synchronization. If your monitor isn't on the list, don't worry—there are lots of generic monitor types to choose from. You can even enter the exact screen size and select the screensaver delay time. If you have a energy star monitor, you can set standby, suspend and monitor off.
When everything is set up the way you want it, save the configuration file and exit.
Log in as a regular user and start the X server:
If you need to change the color depth or resolution, simply rerun configX while logged in as root. Make the necessary adjustments then log back in to X Windows.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- RSS Feeds
- New Products
- Validate an E-Mail Address with PHP, the Right Way
1 hour 49 min ago
- Keeping track of IP address
3 hours 40 min ago
- Roll your own dynamic dns
8 hours 53 min ago
- Please correct the URL for Salt Stack's web site
12 hours 4 min ago
- Android is Linux -- why no better inter-operation
14 hours 20 min ago
- Connecting Android device to desktop Linux via USB
14 hours 48 min ago
- Find new cell phone and tablet pc
15 hours 46 min ago
17 hours 15 min ago
- Automatically updating Guest Additions
18 hours 24 min ago
- I like your topic on android
19 hours 10 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?