I have yet to find any good webpages or documents explaining if a workstation-grade graphics card would be beneficial to me.  I don’t do any 3D work, I only view 4GB of aerial photography in MrSID format at one time.  I don’t know if a workstation card will display this imagery better than a gaming card or if the quantity of memory matters.

I found a couple of mid-level workstation cards that won’t increase the cost of the PC too much.  The initial specification was a Visiontek Radeon HD3850 with 512MB of GDDR3 memory for $189.99.  The first is a PNY nVidia Quadro FX570 256MB GDDR2 card for $209.99.  The second workstation alternative is the ATI FireGL V3600 256MB GDDR2 card for $249.99.  Some reviews showed other Quadros far outpacing the FireGL cards, but the newer FireGL cards like the V3600 were on par with their nVidia competition and in some ways superior.  But I don’t know how this all relates to imagery in ArcGIS.  These workstation cards only beat out my Radeon 9550 by having faster memory, a faster GPU, and a certified driver.  I don’t know if I should be going for more memory (Radeon HD3850) or an optimized card.  I’m leaning toward the FireGL for a workstation card because of my positive experience with ATI-built cards and I read on the Internets that it can communicate with multiple CPU cores.

So this would place me near $1500 territory for a new PC.  I don’t think it’s worth it, even though it looks like I will have my contract extended through June and will have additional funding.  A new PC would only benefit me from Feb-June.  I don’t think four months of superduper computing ability is worth $1500.

I got a new laptop at work in late August. The date is especially significant because it’s now mid-October and I’m still sorting out issues with video drivers, network cards, and bluetooth functionality.It’s a Lenovo T60p – a nice machine. Speedy. Sleek. Full-featured – it even comes with some built-in biometric features. Oddly, these are the sorts of hardware features that open source geeks love to play with. And it’s a good thing for us users because otherwise they’d just be extra baggage on an otherwise nice machine. Manufacturers just don’t spend a lot of time yet on Linux drivers.

For example, the package I ordered came with a Logitech M-RBB93 bluetooth wireless mouse. Now, this is a nice piece of hardware. I’ve had wireless mice before, and they all come with a USB fob that takes most of the joy out of using a wireless mouse. This mouse has an on/off switch on the bottom. That’s the extent of the init/shutdown process. I love it! But it didn’t work with my laptop out of the box as it should have. I didn’t even bother to open the CD that came with it. I would only have found myself disappointed by the instructions, as they nearly always begin with “Press the Start button, and select the Run option…” I hope this will change in the near future – not everyone runs Windows these days.

SLED 10

My new laptop came with SLED 10 (SuSE Linux Enterprise Desktop, version 10) pre-installed. Now, this Linux variant is clearly designed for non-technical people, as it comes completely configured to work well with several hardware configurations, including my Lenovo T60p. But it still had troubles with unforeseen additions such as the bluetooth mouse. It turns out that SLED 10 does work pretty well with the mouse, but you need to perform a few command-line gymnastic stunts in order to get the laptop to connect. Secretaries and executives will probably just toss the mouse in the garbage can, assuming it’s broken. Geeks like me know better.

I didn’t even hope that I could get the fingerprint reader working. But it turns out that there’s an entire community surrounding this little built-in device, known affectionately as the ThinkFinger. There’s a wiki site for configuration that contains very complete information on getting the fingerprint reader working on a variety of platforms, and Ubuntu actually has it’s own ThinkFinger community. I must say, it works very well. Sometimes it requires more than one pass to get a good reading, but usually it works on the first try – much of the quality of experience involves training yourself to swipe your finger in just the right way, but it’s an easy habit to pick up.

ATI is making big advances in coming to terms with the open source world, but they still have a long way to go. Five years ago, I installed a version of Mandrake Linux on my home computer (dual boot) just to play with it. I had an ASUS NVidia card installed. The desktop graphics came up out of the box in 800 x 600, 8-bit color. I was a bit disappointed at first, but then I decided to dig a bit deeper. I went to NVidia’s website, downloaded their latest open source Linux drivers, ran the installer and rebooted. When it came back up, I was viewing my X desktop in 1280 x 1024 24-bit color – perfect! I didn’t even have to select the resolution and color depth (although I had plenty of choices).

I can only wish for the same experience with ATI drivers. Five years ago, ATI drivers for Linux were unheard of. The answer to your question was simply this: You bought the wrong video card. Since AMD acquired ATI, things have changed. Video drivers for ATI cards can now be downloaded from AMD’s web site. They even (usually) work – if you have the patience and technical prowess to mess with them for long enough. But to the average user, my answer to your question is generally still the same: You bought the wrong video card. Give it a couple of years, and ATI will have caught up to where NVidia was five years ago. Now, don’t get me wrong. ATI cards are wonderful, but if you want to take full advantage of them, you’d better stick to Windows.

OpenSuSE 10.2

SLED 10, being designed for non-technical folks, has been tweaked and tested such that many of the processes that have to be done manually in even later opensuse offerings are well integrated and much more automated. However, SLED 10 is old. I’m sorry, but anything older than a year in this industry is out of date. I’m a developer, so I need the latest tools and libraries, and many of these just won’t install on SLED 10, so the first thing I did was upgrade to opensuse 10.2.

SLED 10 is actually ahead of opensuse 10.2 when it comes to integration. While the software may be older, the amount of integration testing and tuning is much greater with enterprise-level offerings. Frankly, given what I know about opensuse 10.2, I can’t wait for the next version of SLED. I still won’t use it, but for my non-technical co-workers, it will be a wonderful improvement.

Well, the devil (as they say) is in the details, so here they are:

Bluetooth Mouse

The bluetooth subsystem on Linux is called bluez. The bluez project is hosted by sourceforge.net. The trouble with the bluez web site and packages is (like many free software offerings) a woeful lack of both technical and non-technical documentation. The maintainers have done a great job of making it easy to build and install. Unpack the tarball, type “sudo configure; make; make install” and you’re done. The makefile installs a dozen tools and libraries, and even man pages for most of them. The trouble is that there’s no overarching documentation that describes WHY you’d want to use any of them.

Most of the tools are fairly low-level, designed to be configured and consumed by system integrators to provide a good automated end-user experience. The problem, of course being that system integrators in the Linux world generally stop short of the finish line.

Bluetooth is designed to work with a wide variety of devices. Most of these fit into a few categories. Bluetooth mice, for instance, are classified as input devices. The bluez tool that deals with human interface devices is known as hidd – human interface device daemon. This daemon is a system service that is supposed to be started by your system init scripts at boot time. It can also be called by a user logged in as root in order to configure it to bind to your mouse.

If you look on the bottom of your mouse, you’ll see what looks like an ethernet MAC address – a six part, colon separated set of values, two hexadecimal digits each (mine is: 00:07:61:6b:92:13). You can tell hidd to bind to your mouse by using a command like this:

>sudo hidd --connect 00:07:61:6b:92:13

Another way of doing this, is to tell hidd to just search for all devices it can see:

>sudo hidd --search

But if you happen to have more than one mouse lying around, it may connect to the wrong one.

The trouble with opensuse 10.2 is that it’s about 89 percent there with respect to bluez integration. Sometimes this works, other times you have to resort to tricks like adding the above hidd –connect command to your initialization startup scripts, so that it will connect every time. The hidd daemon is designed to remember connections, and the latest offerings really do work, but you may have to play with it for a while to get it to work consistently.

Fingerprint Reader

Download the latest version of the thinkfinger package (0.3 at the time of this writing) from the sourceforge.net thinkfinger project site. The package is easily compiled and installed. From the root of the directory into which you extracted the package, just run the following sequence of commands:

>su
#configure; make
#make install
#exit
>

Next, you’ll want to configure the pam module that comes with the package so that you can log into your desktop using your finger print. Pam modules are configured using the /etc/pam.d/common-auth file. Edit this file with your favorite editor and add the following line BEFORE the line containing the reference to pam_unix2.so:

auth  sufficient  pam_thinkfinger.so

This will cause the PAM (Pluggable Authentication Modules) library to query the fingerprint reader each time a password is requested. But you’re only half done. You have to supply credentials in the form of .bir files. For this, you use the tf-tool command (as root):

>su
#tf-tool --add-user jcalcote
#ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
Copyright (C) 2006, 2007 Timo Hoenig <thoenig@suse.de>

Initializing... done.
Please swipe your finger (successful swipes 3/3, failed swipes: 1)... done.
Storing data (/etc/pam_thinkfinger/jcalcote.bir)...done
#exit
>

Note that your .bir file was stored as username.bir in the /etc/pam_thinkfinger directory. Now, if all has gone well, the login prompt should say, “Password or swipe finger:”, instead of simply “Password:”. You’ll also get a prompt like this at the command line when you type “su”.

ATI Video Drivers

The Lenovo T60p comes with an integrated ATI Mobility FireGL V5250 video card. The “Mobility” part means it’s for laptops, the FireGL part means it’s one of their high-end offerings (along side of, but slightly lower than the Radeon series), and the V5250 part means it’s close enough to a V5200 that it works with any drivers designed for the V5200 – and that’s a good thing, because the drivers don’t actually recognize the card model number.

At the time of this writing, the latest driver available on ATI’s web site was 8.41.7. The most difficult issue to deal with here is that ATI’s website driver guide will not lead you to the latest drivers for your card unless it’s a fairly late Radeon series card. This doesn’t mean the driver won’t work with your FireGL card – it just means that ATI hasn’t spent the testing resources on your card with that driver, so they aren’t going to lead you to it. Here’s the deal: Most of ATI’s drivers will work with most of their cards just fine – they’re all based on the same or similar chip sets, so the drivers can’t really tell the difference. If you want the latest features, you’ll have to just get the latest driver and see if it works with your card. In fact, I’ve found that the 8.41.7 driver does NOT work with my card, but the previous 8.40.4 driver works fine.

Drivers come from ATI in the form of an executable that runs either from the command line, or as a GUI-based application. This application is actually designed to build a variety of driver installation packages for several different flavors and versions of Linux. For instance, it can build an rpm package for opensuse or redhat. It can also build .deb packages for debian.

To use the driver generator, use the following command-line syntax:

>su
#ati-driver-installer-8.40.4-x86.x86_64.run --help          (optional)
#ati-driver-installer-8.40.4-x86.x86_64.run --listpkg       (optional)
#ati-driver-installer-8.40.4-x86.x86_64.run --buildpkg SuSE/SUSE102-IA32

This will generate an rpm installer package for your system. Note that the first two ati* commands are only for your information. The –listpkg option will display a list of all packages that CAN be generated by the package generator. Choose the one that’s closest to your system type. After this command has completed, you’ll find an rpm package named fglrx_7_1_0_SUSE102-8.40.4-1.i386.rpm in the same directory.

Here’s the tricky part. This installer is complicated. It actually builds a kernel module as part of the installation process, which means that you’ll have to have kernel source and development packages installed in order to install this package. So ensure that you have the appropriate kernel development libraries installed on your system.

The opensuse community and ATI itself provides a YUM repository for various flavors of the opensuse 10.2 kernel (found at http://www2.ati.com/suse/10.2 – note that this site is not accessible via the web – only through YUM). This package is NOT the same as the one you just generated. It’s pre-configured to run against a specific kernel version with a specific set of patches. Personally, I like the approach taken by this ATI package generator better. If you install kernel patches, you’ll either have to get matching updated community drivers, or simply reinstall from this rpm you just generated. It will rebuild the kernel module against the latest libraries and headers installed with those patches. If the kernel changes too much, then you’ll need to get a later ATI driver that’s designed to work with the latest kernel.

Now install the drivers with this set of commands (It’s best if you do this from a tty console – press Ctrl-Alt-F1):

Login: root
Password:
#init 3
#rpm -ivh  fglrx_7_1_0_SUSE102-8.40.4-1.i386.rpm
#sax2 -r -m 0=fglrx
#init 5

You should now be running with your ATI drivers. To test your configuration, open a terminal window, and type:

>su
#glxinfo

You should see the following lines among the output:

...
client glx vendor string: ATI
...
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI MOBILITY FireGL V5250
OpenGL version string: 1.2 (2.0.6747 (8.40.4))

ATI drivers are not as well integrated as they could be. They don’t hook into sax2 so that you can toggle settings and enable or disable 3D mode. However, they do allow you to configure clone and xinerama modes from sax2, if you want. This situation can cause some frustration until you understand it. Basically, 3D hardware acceleration can’t be disabled, regardless of what sax2 tells you its current state is.

To prove this to yourself, run the fgl_glxgears program that’s installed with the firegl drivers. You should see a spinning cube whose faces each contain a set of gears spinning within the plane of the face. You can’t do this in software, so if you have any sort of smooth performance in this demo, then you’re definitely runnning with hardware acceleration enabled. Note that there’s a more basic program called glxgears. This one shows a simple set of gears spinning in one plane.

Compiz to Beryl to Compiz-Fusion

Of course, after getting your 3D accelerated drivers installed, you’ll want to do something with your system that will prove the worth of all that effort every minute that you use your computer. This is where compiz comes in. You know all that yummy eye candy that Mac OSX provides for its user experience? Well, Linux isn’t that far behind. To quote the compiz.org home page:

“Compiz is a compositing window manager that uses 3D graphics acceleration via OpenGL. It provides various new graphical effects and features on any desktop environment, including Gnome and KDE.”

To enable the required OpenGL features, you’ll have to switch your display manager server from xorg to xgl. The default display manager server is the one that comes with the xorg system. It’s tried and true, and doesn’t often have a problem. In the vernacular, it’s stable. The xgl display manager server uses OpenGL to do everything done manually by the xorg server. The community calls xgl “experimental”, but the fact is it’s pretty good lately.

To change from xorg to xgl, you need to use your system configuration editor (YaST | System | etc/sysconfig Editor). From the menu on the left, choose Desktop | Display Manager | DISPLAYMANAGER_XSERVER. Change the setting on the right from “Xorg” to “Xgl”.

Close your applications and restart XWindows by pressing Ctrl-Alt-Backspace. If everything comes up as before, then you’re set. Now go to your main menu and from the section entitled “Look and Feel”, select “Desktop Effects”. The information in this dialog is a bit disconcerting. It tries to tell you that you can’t enable desktop effects (compiz) because your hardware is not recognized. It also tries to tell you that 3D acceleration is not enabled. Don’t forget that ATI drivers have bypassed the sax2 hooks for this feature. So applications that use sax data to determine 3D acceleration state are going to be misled into believing it’s not enabled. But just select “Enable Desktop Effects” at the bottom anyway (if it’s not already done for you). When you exit this dialog, you should see your windows doing cool stunts (sometimes without your aid or approval).

Probably because of the “experimental” nature of Xgl, occasionally you will lose your window manager. The effects of this are simple – the title bars on all of the windows on your screen will disappear, making it difficult at best to accomplish anything. Easily remedied however – just restart XWindows (Ctrl-Alt-Backspace). Unless you’ve really hosed things up, it should restart the window manager correctly.

OpenSuSE 10.3

After all of that (and that took me a month of research), opensuse 10.3 was released on the 3rd of October. I’m a bleeding edge sort of guy (if you couldn’t tell by now), so I immediately upgraded my 10.2 system. Believe it or not, nearly everything worked without a lot of tweaking and configuring in opensuse 10.3.

The only problem I’m having at this point is with my wireless network card. I got myself into a situation where there were two entries for my wireless card in the Network Devices dialog. One of them came from the udev hardware detection subsystem, and was listed as “unconfigured”. The other was a copy of the detected card that was listed as “DHCP” (meaning, configured to use DHCP). When I would try to delete the configured entry, and then configure the detected entry, it would look good until I closed the dialog and then rentered it, whereupon it would look as it did before. The solution to this problem finally presented itself accidentally, as I tried to do what I’d tried before, but in reverse order. That is, I first configured the detected card, and THEN deleted the originally configured card. For some reason, this worked.

One other problem I’m having with wi-fi is that I can’t seem to connect to my wireless network at work. At work, we have a wireless network with an unadvertised or “hidden” ssid – the network identifier. In order to connect to a network with a hidden ssid, you have to know the value of the ssid and specify in when you attempt to connect. I just can’t connect – I still can’t, and I haven’t got a clue why not. I can only assume there’s some sort of bug in the wireless drivers for 10.3 because I can connect just fine at home, where my ssid is advertised. I’ve googled this one for hours, but apparently no one else has had this problem, or they’re not speaking up. In truth, I did find some references to a problem like this last November – nearly a year ago, but it was quickly resolved with a patch to the wlan sub-system. Apparently, the bug is back with a vengeance – at least on my system.

But these things tend to sort themselves out in fairly quick order. People don’t like to go without network access, and whether or not they’re talking about it, this sort of defect is often more wide-spread than it appears at first glance.

Regarding ATI video drivers and opensuse 10.3; ATI provides a web-based repository for 10.3 drivers along side of their 10.2 repository, but be aware that it provides an rpm package with the 8.41.7 drivers. You’ll perhaps recall that these drivers didn’t work with my V5250 FireGL card, and this repository version is no exception. I tried them, and then had to back off to the 8.40.4 drivers. YMMV.

The bluetooth subsystem is substantially enhanced on 10.3. I was able to bind to my mouse using (get this) a GUI interface! If you’re coming from a Windows background, you’re no doubt laughing, but then I’m not talking to you, am I?

The fingerprint reader actually has a YaST panel plugin in 10.3. The installer detects the fingerprint reader and ensures that the appropriate packages are installed, so you don’t have to go looking for it.

Despite the fact that both bluetooth and biometric hardware integration is much better in 10.3, I still upgraded these two packages from bluez and thinkfinger – probably because I’m a glutton for punishment. But the latest packages do provide some small bit of extended functionality.

All in all, I’m so pleased with opensuse 10.3 laptop, that my co-workers think I’m weirder than I really am, walking around the office with a big grin on my face. But they’re not laughing at me when I show them something cool that my machine can do that theirs can’t.