LinLog

Remember my last post on binary compatibility under Linux? Well, I got hit again. For the first time in months, I tried to play my old copy of SimCity 3000 Unlimited - the old Linux port of it that Loki Games did way back. Didn't work in Kubuntu Gutsy.

Fortunately, I was able to find this blog entry on fixing SC3U. The fix requires setting some environment variables and using some libraries from Ubuntu Dapper.

The simple, three-step process goes like this:

1. download the Dapper libraries and extract them someplace on your machine, e.g. to /usr/local/games.
2. Adjust your shortcuts, launcher scripts, or whatever you use to start SC3U to use the following command line (lines broken for readability):
   LD_LIBRARY_PATH=/path/to/loki_compat \ LD_ASSUME_KERNEL=2.4.28 \ /path/to/loki_compat/ld-linux.so.2 \ /usr/local/games/SC3U/sc3u -w
3. Run your script/shortcut/whatever and hope that SimCity starts.

I guess soon it's going to get to the point where I'll need some alternative method to run these games, e.g. VMware. Loki Games did go out of business 6 years ago and these games have been unsupported ever since, so it's only a matter of time until I can't make them work anymore. And that's sad. I shouldn't have to consider using virtualization to make the native Linux port of a program run on Linux.

I wonder if the Windows versions of the Loki games still run on Vista?

I enjoy an occasional video game. However, I am by no means a "gamer", as evidenced by the fact that I don't have a copy of a single proprietary game published later than 2002. Rather, I enjoy open-source games like Battle For Wesnoth, vintage games such as Bandit Kings of Ancient China and Wing Commander, and the occasional old strategy game, such as my old Loki games for Linux. I also have a soft spot for emulated console games for the NES and Super NES. I even break out an emulator for my old PlayStation disks every now and then.

Well, the other day the mood struck me to play one of my old PSX games, so I clicked the icon for the ePSXe PlayStation emulator in my application menu and waited...and waited...and waited. And it never came up. So I tried running it from a command prompt and...nothing happened. And when I say "nothing", I mean nothing - no error message or output of any kind. I just got my command prompt back immediately.

Mind you it had been a while since I'd used ePSXe, but there was no immediately obvious reason why it should fail. It's installed in my home directory and has been sitting there, fully configured, for over a year. I used it regularly for a few weeks back in September and October and it worked perfect. Absolutely nothing has changed with it.

Fortunately, a little Googling turned up this thread in the Ubuntu forums. Apparently the ePSXe binary is compressed with UPX. After installing the upx-ucl-beta package via apt-get and running upx -d /path/to/epsxe to decompress the binary, it worked as expected. Apparently something about running UPX-compressed binaries changed between Ubuntu Feisty and Gutsy. I have no idea what, though.

This actually leads into one of the things that really annoys me about Linus: binary compatibility. It's also one of the reasons I prefer to stick with open-source software on Linux when at all possible.

In the Windows world, binary compatibility between releases is pretty good. Granted there are always some applications that break, but given the sheer volume of code out there, Microsoft does a good job keeping that number relatively small. In fact, if you've ever heard any of Raymond Chen's stories of application breakage between releases, you know that the Windows app compatibility team sometimes goes to truly heroic lengths to enable badly broken applications, many of which never should have worked in the first place, to keep functioning when a bug they depended on is fixed. The sample chapter (PDF) from Raymond's book has some really great examples of this.

In the Linux world, on the other hand, nobody seems to give a damn about maintaining compatibility. If you have a binary that's a few years old, it may or may not work on a current system. And if it doesn't, sometimes you can massage it into working, as was the case with ePSXe this time, and sometimes you can't. Not that this should be surprising: some developers in the Linux world are so lazy they won't even allow you to change the paths to application support files - they just hard-code them into the binary at compile-time with preprocessor defines! If they don't care if you can install the same binary in /usr or $HOME, why should they care if it works between distributions or even releases of the same distro? The attitude seems to be, "Well, it's open-source anyway, so who cares how compatible the binaries are?"

But if we're going to be honest, even being open-source only goes so far. Actively-maintained apps are usually OK, but have you ever tried to build an application that hasn't been maintained in 7 or 8 years from source? It's pretty hit and miss. Sure, if I really needed the app, had lots of spare time on my hands, and was familiar with the programming language and libraries it used, I could always fix it to build in an up-to-date environment. But for a regular user, that's simply not an option. (And even for a programmer it may well be more trouble than it's worth.)

But as annoying as I find the general lack of compatibility, as much as I wish I could just run a damn executable without having to cross my fingers, I can understand why things are they way they are. Quite simply, maintaining compatibility is hard. It takes care and diligence and it can make it hard to fix certain problems or make certain types of improvements. And really, when you're not getting paid for your work and have no real obligation to your users, you have to ask yourself if it's worth the effort. Heck, even many commercial vendors aren't that serious about backward-compatibility. Is it really reasonable to expect a loose association of unpaid volunteers to be any better?

But that's enough ranting for tonight. There are ups and downs to every software system. I'm just disgruntled that everything in my personal Linux-land seems to be 5 times more difficult than it needs to be lately.

Last week we had a database consultant come into the office. We in the development department didn't know much about it - were basically told that corporate headquarters in California had this database consultant they'd worked with in the past and he was going to be in New York, so they asked him come to our offices while he was on the east coast. We didn't really think we needed any consulting help, but at least that meant that we could get reimbursed for taking him to lunch, so whatever.

Little did we know that corporate had been working with a certified alpha-geek. It turns out that the consultant was none other than Jeremy Cole of Proven Scaling, formerly of Yahoo! and MySQL AB. Of course, we didn't find out about his background until a little later, but it was clear within the first 30 minutes that Jeremy really knows his stuff. Plus he's a really nice guy and is easy to work with. I think we all learned a lot and had a good time doing it. I don't know what corporate was paying Jeremy, but whatever it was, I can say with certainty that he was worth every penny.

Living in the software development styx, I've never actually met anyone who was as much of an über-geek as Jeremy. I have to say, while it was an honor and a pleasure, it was also a little bit intimidating. I mean, here's a guy who can't be any older than I am and he's already the know-everything super-geek that I want to be when I grow up. It just makes me think, "I should be like that!" I just need more dedication, more energy...another 6 hours in the day.

On the up side, working with Jeremy did inspire me to take the advice of the Typical Programmer:

Few programmers bother to master SQL even though they use it all the time. It may not be a “real” programming language but it’s worth mastering SQL and the relational database model. Once you understand relations and start thinking in terms of sets you will be able to solve all kinds of problems efficiently. Databases are everywhere, but if programmers learn about them at all it’s only enough to use them to persist objects into.

There is wisdom in this quote. When I think back on the stupid, impulsive days of my youth, databases seemed much like HTML. They were both little more than vehicles for "real" code. In those days, HTML was "just" the medium for web applications and SQL was "just" a way to get rows out of a data store. Everybody "knew" that the "real" programming languages was where the magic happened. HTML, XML, SQL and the like were just peripheral "toy" languages - if you could even call them "languages".

Ah, the stupidity of youth! Looking back, I'm amazed that at 20 I was able to think I knew everything, when it is now so very clear that I knew less than nothing. Even something as superficially simple as XML can be an entire world unto itself. To dismiss something as crucial as data access as a "toy" is just plain crazy. Without data, the most beautiful code in the world is utterly useless. Being able to skillfully manipulate and query your database is an invaluable skill, the kind that sets the dedicated professionals apart from the amateurs.

So my next project, as soon as I finish UML Distilled, is to brush up on my relational theory and get a good, solid grasp of real SQL, not just the basic to intermediate stuff I've been getting by on. To that end, I even picked up a copy of Joe Celko's SQL for Smarties: Advanced SQL Programming. I haven't started it yet, but it promises to be an informative read. Granted, it won't make me the expert that Jeremy is, but it's a step in the right direction.

I must be loosing my touch. Either that or I'm going senile. You see, I was always under the impression that you needed to plug in electronics to make them work. But apparently that's not the case.

A couple of months ago, I bought a new USB hub. I'd had my old one for about 5 years and it only did USB 1.1, which meant that using it to transfer large amounts of data to my thumb drive or MP3 player was painful. And due to an oversight in ordering the case for my current system, it only has one front USB port - the one in the memory card reader. So I ordered a nice little 4-port Rosewill USB 2.0 hub. Only problem was, it didn't work.

The wierd thing was, the hub looked like it should be working. The power light on the hub was on. When I plugged my MP3 player into it, it at least detected that it was connecting to something. But I couldn't get my system to detect any USB device I plugged into it - not my MP3 player, thumb drive, gamepad, nothing! They just sat there and udev never even made a device node for them.

So after putting it off for a couple of months (mainly because the only time I ever thought of it was when I was on my way out of the house and needed to dump something on a USB drive), yesterday I finally got sick of it and took a look at the hub. My plan was just to quickly verify that it was, in fact, broken and then just junk it and pick up a new one in Walmart. So I unplugged it, tried it in a different USB port, swapped out the cable - you know, the usual stuff. Well, just on a lark, at on point I decided to try it without plugging in the external power cord. And it worked!

Maybe I just don't know enough about hardware, but I found this bizarre. When I unplugged the hub, it worked perfectly. When I plugged the power cord back in, it stopped working. I have no idea why. Maybe it has something to do with the unreasonably huge converter on the plug - it weighs over a pound, whereas the hub itself is less than three ounces. I don't know if that would cause any problems, but it just doesn't seem right.

I still don't understand why, but at least everything is working now. The plug for my hub is sitting in a box in the closet and my MP3 player is transfering data through the hub. It just feels weird to have fixed the problem by getting rid of the power cord. Sounds like it should be a sign of the apocolypse or something.