OS X Chess.app -- is it easier in Tiger than Panther -- or does it learn?

OS X includes a pretty darned impressive chess game game. The marble skin in Tiger gives the clearest pieces.

I'm no chess player, and my 8 yo is even worse, so we play it in 'fastest' (dumbest mode). Only it seems to behave differently in Tiger and Panther.

On my G3 iBook running Panther it tends to beat us fairly handily -- even in 'fastest' mode and even when we cheat and 'take back' dumb moves. On my far more powerful G5 iMac, however, I can beat it fairly easily in that mode.

So what's the story?

Does it learn? (God, I hope not.) Is there a bug in the 10.3.9 version so it behaves as though it were in mid-range smarts? Did Apple dumb it down for Tiger (thank you)? I'm curious.

Update 9/14/05: I'm convinced there are a few bugs. I think in 10.3.9 the prefs don't always work -- sometimes Chess.app works at its default setting despite what the gui shows. In 10.4.2 Chess.app at its lowest setting is very beatable (it looks one move ahead, so it will quickly trade a pawn for a queen). On the other hand in 10.4.2 we saved a game with a bishop that couldn't be moved. He was stuck!

The sad story of Palm Desktop -- OS X version

I use Missing Sync on my OS X machine and sync my wife's Palm to Apple's (feeble) calendaring and contact applications. Even ePocrates works, thanks to the bundled AvantGo conduit. So I'm far away from Palm Desktop for OS X. Still, I think it's worth mentioning just how bad this software is.

MacInTouch: timely news and tips about the Apple Macintosh

Art McGee raised a red flag about more file-permission abuse by bad installers:

I have just examined the contents of the Palm Desktop 4.2.1 Revision C package installer, and I have come to the conclusion that either PalmOne is intentionally trying to damage our computers, or the software is a trojan horse that someone uploaded in place of the real software.

After the program files are installed, the installer runs a shell script called "postflight" that attempts to "fix" any permissions issues which may prevent the program from running properly. Unfortunately, the script violates the most basic programming principle in the universe - thou shalt not alter the files of programs other than thyself - and it does it so blatantly that I can only assume malicious intent. At the end of the script, it runs a final set of commands to change permissions (The "$2" variable is replaced at runtime by "/"):..

While any bad changes to the "/", "/Applications", or "/Library" directories can be easily fixed by repairing permissions or issuing another single command, the most OUTRAGEOUS and potentially damaging change is the last one:

sudo chmod -R 775 "$2Library/Application Support"
sudo chown -R :admin "$2Library/Application Support"

The "/Library/Application Support" directory is where many programs place critical system-wide configuration and program files that are referenced on an as-needed basis. This is a directory whose permissions should NEVER be changed or altered, lest you end up breaking many of your installed apps. In particular, all sorts of system-level programs such as Anti-Virus and Disk Utilities place parts of themselves there, and any changes to their permissions will prevent them from loading at boot time. Even more dangerous, some programs place symbolic links from that directory to "/System/Library", and running a chmod command that recursively drills down that directory could end up completely trashing your entire system...

Art is apoplectic, but those who've followed Palm's swan dive into misery [1] know that that their "doers and visionaries" abandoned ship long ago. They're running on fumes now.

Things are no better on the XP platform. It's been about 5 years since Microsoft implemented a user-specific security model, and Palm still expects all conduits to be shared and all user accounts to be in a single directory.

Palm is a dead company. Shame.

[1] Matched only by Intuit, which lately claims it will fix US healthcare. Perhaps they follow the philosophy of bringing on the apocalypse to accelerate change.

OS X Open With list a bit crazed -- restart with shift key down (safe start)

I'd had a lockup (old Classic game) in OS X. Next time I accessed the 'open with' dialog I got a long list of options, with multiple versions of older applications appearing (ghost apps).

Safe start fixed it, one of the most basic troubleshooting tips: Gordon's Tech: Mac OS X Update troubleshooting. I held down shift and restarted. Takes a long time (it's the easiest way to run fsck in Tiger). Then restarted again. Problem fixed, drop down list repaired.

PublicVPN.com

How Does It Work

$60 a year for more secure WiFi use on unencrypted lans. Can two users form a network?

FlickrExport: iPhoto Plug-In to upload to Flickr

FlickrExport

Now if only I could order prints from Flickr ...

The old freezing a stuck hard drive trick still works

Macintouch: Reviving Macintosh Computers

This is an old tip. I'd forgotten about it. It still works:

Reviving Failing Drive

MacInTouch Reader

I recently managed to recover data from a failing hard disk using a rather unusual technique, which has come to be known as "the freezer trick".

The symptoms exhibited by my failing 80GB IBM DeskStar seemed quite odd when you think of hard disk failures. Usually failures are sudden and complete. However, in my case, a week ago I noticed strange pauses in operation (most obvious in iTunes playback, as my music was stored on that drive) that lasted up to 30 seconds at a time. I suspected maybe some background operation such as Spotlight had taken excessive CPU and/or disk time, but Activity Monitor didn't provide any clues. I then checked Console, and eventually I started seeing I/O errors referring to my IBM drive. At this point, I suspected a directory error and repaired the disk using Disk Utility. The intermittent access problems persisted but running Disk Utility actually turned up nothing wrong with the drive. Furthermore, SMART status always showed "Verified". I started backing up data from the drive.

Still, I had intermittent problems accessing the drive. Eventually, the disk would disappear and become unmounted. Disk Utility would actually not list the drive anymore. This also resulted in the Slave drive on the same bus disappearing at the same time. The only remedy was to restart, and it would operate normally for a while again. I then thought perhaps something was wrong with the Ultra ATA bus. So, I tested the IBM drive on the IDE/ATA bus by swapping it with the DVD-ROM drive on that bus. The slave disk worked fine, but the IBM drive still showed problems. I therefore suspected the IBM drive as having the problem.

At this point, following another failure, it would no longer spin up on restart. I left the drive overnight and figured it would be OK the next day. It wasn't. At this point the drive was inoperable, but I still needed to back up some of its data. Time for last resorts.

I remembered the recent posting of a tip on MacInTouch about whacking the drive with a wooden mallet or screwdriver handle. I tried this, and it didn't work. I suspected "sticktion" as the drive appeared to make noises, but wouldn't spin up. I then searched the Internet for ways to revive an IBM DeskStar (aka "DeathStar" on many forums). I soon came across mentions of "the freezer trick", which was actually also mentioned on MacInTouch as well. Several people reported limited success in reviving "stuck" disks (from IBM and others) by using this method.

Essentially, in "sticktion" cases, the mechanical parts seize up, and a couple of methods may work to free them again (if only temporarily). "The freezer trick" is to put the drive in a sealed ziploc bag or wrap it in plastic food wrap, and put that in your freezer for a couple of hours. (I also put that inside a plastic case so that it wouldn't stick to the freezer.) This causes the mechanical parts to contract, hopefully freeing whatever is stuck. To my astonishment, it actually worked! I was able to backup all of the remaining data from the drive. The key is to keep the drive spinning. Once it spun down or went to sleep, it would not spin up again. I re-froze the drive for an hour and it worked again on reconnection. Obviously, people should only try this method as a last resort, and only in "sticktion" cases.

Additionally, I remember from a very long time ago (maybe 15 years) I had ongoing sticktion problems with an external SCSI hard drive that could be remedied by placing it in front of a dehumidifier for a couple of hours.

Cheap wireless USB adapter: CompUSA

Macintouch Wireless Networking (Part 31): "I purchased the Hawking Wireless-g USB 2 adapter last week from CompUSA, $9.99 after rebates. I was intended to use it in a desktop PC. In PC, it was identified as a Zydas ZD1211 device. I went to the Zydas website and found that they have drivers for Mac OSX 10.2, 10.3, and 10.4. So I downloaded it and installed in my eMac, it works on my eMac with Mac OSX 10.4.."