The Steam software distribution network and native games are finally available on Linux!



I stopped gaming a few years back when my dual-booted install of Windows crapped out. I decided I wasn't going to re-install Microsoft Windows again. I started spending time doing a lot of things other than playing video games.

My desktop computer is somewhat old. I'm still using the same hardware I posted in 2010. The graphics card is an ATI 4850 (DIAMOND 4850PE3512 Radeon HD 4850 512MB 256-bit GDDR3 PCI Express 2.0 to be exact) which I bought in 2008 for $195 and is the most I have ever paid for a graphics card. The motherboard and CPU are hand-me-downs, so most of the components in the system are at least 5 years old. One of the things that I love about GNU/Linux is that my computer is still quite happy running the latest editions of the open source operating system.

However, getting Steam and TF2 running on this older hardware was not completely trivial. As of a few days ago, the Steam client provided by the Steam web site is 32-bit and does not install correctly on my 64-bit Ubuntu workstation (complaining about Wrong architecture 'i386'). Once I made it past that obstacle, I installed TF2 from my Steam Library, but it would quickly error out because the Ubuntu-provided ATI proprietary drivers were missing a required OpenGL feature:

'Required OpenGL extension "GL_EXT_texture_sRGB_decode" is not supported. Please update your OpenGL driver.'



Many of the suggestions on the net did not work on my system (for example, using the Ubuntu-provided experimental driver packages). However, I'm encouraged that the folks at Canonical, Steam, and AMD are continuing to work on the issue and improve the situation. I would expect that the Ubuntu Software Center may have updated package and drivers over the next few weeks / months (if it does not already) so the solution below may not be required.

But in the meantime, I found a way to get Steam and TF2 working on ATI Legacy adapters (in particular the 4xxx and 5xxx series). Most of this information is available via searching google and reading various forums. Thank you, Internet!


Here are the 3 steps that finally worked for me:

Thanks to an ancient http://PHP.net comment (http://www.php.net/manual/en/features....php#26201) and a Joomla! forum post (http://forum.joomla.org/viewtopic.php...3#p1318363), I was able to figure out how to run a Joomla php script from the command line and
specify query parameters *without* having to modify any of the PHP code to parse the arguments / options. Most of the examples on the net suggest modifying the PHP script to parse the argv options. I also did not have luck using environment variables to specify QUERY_STRING.

For example, take a Joomla! article with a URL something like this:

mysite/index.php?option=com_content&id=10

Many people running Joomla have SEO-friendly URLs enabled, but the above is the simple (simplest?) query string to get to a particular article using the article id.

Now we can test a particular article at this site from the command line.

Change directory to the appropriate document root and run php as a command-line program:

$ php index.php '&option=com_content&id=10'

The magic sauce is that the first character of the query argument list is just another ampersand rather than the traditional question mark.

Why would I want to do this at all? As one of the Linux system administrators responsible for helping our University customers with their hosted web sites, I sometimes have to debug unusual issues. Having system administrators modify production customer code is not standard practice and unfortunately some of our web hosting customers are not saavy enough to debug unusual issues themselves. One of the tools in our sysadmin toolbox is strace. If I can get the script to repeat the behavior in the command line while strace is running I can often determine the cause of the issue. Running the script in the cli is frequently much easier than trying to catch the issue with strace on a live production site, in shared web infrastructure, etc. We can see file accesses failing, network requests to external servers that don't allow the php page to render until after the remote content is fetched, slow performance from a mysql database... all via the output of strace.

ClusterSSH is a nice tool for manipulating multiple *nix machines simultaneously. For example, if I want to run some commands on two Linux machines named server1 and server2, I could:

# cssh server1 server2

And I will get two xterm windows that I can control simultaneously by typing into the cssh command window. Since cssh will send keystrokes to both servers, any series of commands can be run, including editing files, etc. I have found that my daily patterns of behavior make cssh preferable to similar tools such as pdsh. Also, cssh uses very similar options syntax to the ssh command, so I don't have to remember different options (I frequently use -l and -p).

I might want to tail the logs on all of the machines in the cluster, but then focus in on one particular machine after I have identified a particular cluster node of interest. Similarly, I might work out a long command line on a single node before running it on the rest of the machines via the cssh command window.

In Debian and Ubuntu, cssh can be installed with:

# sudo apt-get install clusterssh

Cluster SSH is also available for Mac OS X (http://code.google.com/p/csshx/).

A clusterssh package seems to be working its way into Red Hat flavors via Extras or 3rd party repos such as rpmforge.

After running cssh for the first time, you will have a .csshrc file in your home directory. This file can be tweaked in various ways to make connecting to groups of machines easier. To save a group of machines into a list that you can re-use, cssh can use a plain text cluster file.

To use a cluster file:

 

 

This week I participated in a programming contest hosted by the local Linux User Group, the GatorLUG.



The contest was sponsored by a local Gainesville company, Main Street Softworks, who make the Monetra payment processing software.

Contestants received these really nice t-shirts:

I ran into a dependency issue trying to upgrade a particular PHP application to the latest version. Geeklog 1.8.0 requires PHP 5.2 or higher.

The default PHP packages in Centos 5.x are apparently based on the older PHP 5.1 branch. To upgrade php, just remove php and install the specific PHP 5.3 packages:

# yum remove php-common

# yum install php53-common

and any additional php packages needed such as php53-mysql, php53-pdo, ...