Wednesday, May 06, 2009

Why I'm downloading Windows 7 RC tonight ...

It works on VMWare -- and it's free ...

VMware: Team Fusion: Windows 7 on Mac with VMware Fusion: A Practical Guide Revisited

... More important, I am excited that the Windows 7 Release Candidate is the easiest way for you to try out Windows on your Mac for FREE (at least until the beta expires). That’s right, you can download Windows 7 Release Candidate through July 1st and it’s free to use until it expires on June 1, 2010...

The VMWare post has more details, but basically the RC works fine with some trivial and standard configuration options.

A very nice surprise for me. I've been tracking Windows 7 from a distance, but primarily as my way to avoid Vista (Windows 7 is Vista 2.0 of course, but I'm good with that). In the meantime I've had Parallels 1.x and Windows 2000 (!) running on my MacBook for about 2 years (man, does Win2K ever boot fast on that machine.) This setup worked for the handful of times I've needed it, and the two take up very little CPU or disk space. Windows 2000, of course, is essentially immune to modern viruses.

That's a good setup and it cost me nothing but Parallels 1.x since I have several unused Win2K licenses. It probably won't work on 10.6 though, and I'm about due for a new iMac.

So I'll put my unused VMWare license on the new machine, install Windows 7 RC, and be good for a year or so. Then I can decide if I want to buy Win 7 or regress to Win2K ...

(I wonder if I need to get more than one copy of Win 7 RC, in case I put it on two Macs ...)

5/26/09: Updated to remove a stupid mistake where I confused 2009 with 2010. The RC1 download is good for one year. That's just fine.

Tuesday, May 05, 2009

iPhone incompatible with old auto adapter? Salvation from Griffin

I like Griffin stuff, so I was willing to take a gamble on the just released Griffin Firewire to USB Charge Converter for iPod and iPhone 3G.

In short, it works. One of the truly infuriating iPhone aggravations has been ameliorated.

The $20 device is a bit bigger than the proverbial postage stamp, about an inch square. It's quite light. The standard iPhone/iPod adapter is the modern friction-only style, no lock feature. (I'd prefer the positive lock for this use, but Apple has moved away from them.)

I plugged one end into my SONY car stereo with iPod adapter cable and the other end into my 3G iPhone. The iPhone began charging. More importantly, the kludgy but useful iPod control software works, and the sound quality really is better through that cable than through the AUX in mini-jack connector.

I did get an error message from my iPhone saying the device was not compatible with the iPhone and offering to reduce audio interference by putting my phone into airplane mode. This is not related to the Griffin converter, I get this message without it. It's different from the "can't charge" message -- it's saying that the radios built into the iPhone can cause interference with many devices not built for the 3G iPhone. In my case there's no hum or other problem in standard mode.

The adapter does make the cable to iPhone connection long and somewhat fragile. It would be easy to whack the end of this longish lever and injure a connector. It would be best used when the iPhone is securely mounted.

It's probably not worth buying this device to extend the utility of a firewire charger -- it costs almost as much as a Griffin USB charger and cable. It's really made for an automotive head unit, and it works on mine.

Note that Griffin makes no claims that the automotive head unit controls and audio inputs will work -- only that charging will work. I took a chance that everything would work, and it did.

Lost phones: advice for everyone

Although this article is written about a lost iPhone, it's really applicable to all phones: Six things I learned from losing my iPhone 3G.

Be sure to read the comments as well. I'd already followed most of the recommended practices, but I hadn't checked with my home owner's insurance to ask what it would cost to insure the phone against loss. One comment mentioned their policy increase was only $10 a year, another said the deductible was prohibitive. Note that most high end phones cost about $500 to replace unless your contract is nearing its two year renewal date. (I think for AT&T in Minnesota they'll provide the new phone subsidy if the renewal date is less than 4 months away).

I didn't realize that under some conditions AT&T will mark a phone as stolen, and may be able to retrieve it if someone tries to use it with a new account.

I photographed a business card and turned it into my wall paper. Dull, but effective. I also implemented the "delete data on 10 password retries", but some of us have young children who may try to hack a phone. If you implement this be sure to have sync regularly.

Monday, May 04, 2009

Apple's iPhoto and MobileMe photo blunder: when full quality isn't.

Adam Engst is far too kind to Apple in this article (emphases mine) ...

TidBITS Media Creation: How to Share Full-Quality Photos via iPhoto

A reader recently sent me email asking why sending a photo via email using the "Actual Size (Full Quality)" option in iPhoto resulted in a photo that was significantly smaller than the size of the photo within iPhoto...

A quick test on my system confirmed his results. My Canon PowerShot SD870IS's test photo started out at 3.1 MB and 180 dpi before dropping to 1.7 MB and 72 dpi. When I opened both the original and the reprocessed photos, Preview's inspector window showed the change in dpi and file size, though the dimensions of the photos were indeed identical.

... iPhoto always compresses photos sent via email to reduce the file size...

... posting the photo to your MobileMe Gallery won't help either, since iPhoto compresses uploaded photos there as well, even when you use the Actual Size option in the Advanced preferences for a MobileMe Gallery album...

... is an EmailCompressionQuality key in the com.apple.iPhoto.plist file that's set to 0.75 ... When I bumped it up, the size of photos sent via email did increase, but when I set it to 1.0, the file size nearly doubled from the original....

Arggghhhh.

Adam is glossing over some key points in an understandable effort to be sweet to Apple.

The problem is not that "iPhoto [always] compresses photos", it's that iPhoto is decompressing the original JPEG (SD870 is JPEG, not RAW), then recompressing it at a severe .75 JPEG compression factor. The decompression/recompression factor is why, when Adam moved the quality index to 1, the resulting JPEG was twice as big as the original. (You'll see the same thing with any image managed this way.)

This is a big deal for photo geeks. Try putting an image through four sequential JPEG 0.75 save/edit cycles and you'll get a mess. When I put "full quality" images on Picasa Web Albums or SmugMug one of the things I get is a high quality backup of my image. We now know that's not true of MobileMe -- it only looks that way.

The discovery that "full quality" images posted on MobileMe are being put through the same decompress/recompress cycle, while being sold as "full quality", ought to be red meat for a lawyer. Anyone know of a hungry lawyer taking charitable contributions for yet another Apple lawsuit? I don't care about winnings, I just want them to suffer.

For my part I'm going to give this a try with Google's Picasa Web uploader and see what I get back. I don't use MobileMe, and I'm not likely to start now.

Incidentally, a more subtle version of this stupidity occurs in Aperture. If you import a JPEG image into Aperture, don't apply any edits, then export it from Aperture using a standard JPEG setting with quality 1 you'll see the same (pointless) decompression/recompression at work.

Update 5/26/09: Apple doesn't apologize, but it effectively confesses to the blunder. No promises of a fix, however.

Sunday, May 03, 2009

Yikes! Disastrous iTunes 8.1.1 AppleScript bug!

Wow.

This iTunes 8.1.1 bug is probably the nastiest bug that's bitten me in years.

I have long used an AppleScript to delete the first 'n' characters from an iTunes column string for all selected columns.

In iTunes 8.1.1 it ignores the selection, it processes all the items in a playlist.

So about 300 items have lost the first few characters of their name.

I'll have to restore from backup.

Update: Well, isn't that sweet. My backups appear to be good, but my restores are failing with a Retrospect error code of "-519", which means network error. I have reason to suspect this is actually a hardware error on the old Windows XP machine that runs my Retrospect Professional backup server.

Looks like this is going to be one of those days.

Update b: I dropped the XP to 10mbps and rebooted the XP box and the iMac. The backup is now crawling along; it will take about 12 hours (!) to complete if it continues. I'll delete all the AppleScripts associated with iTunes and see if can figure out if this is a known bug.

As for the networking issue -- it's not the first odd networking problem I've seen lately. Sad thing is this is just as likely to be hardware (switch, XP box, iMac) as software! If Retrospect 8 were in better shape (still no PPC version!) I'd probably buy a modern iMac and get rid of the XP box.

Update 5/4/09: The 45GB restore at 10 mbps took about 12 hours, but it worked. Interesting lesson about modern apps -- the script bug only knocked out a few bytes of data distributed across about 300 MB of music, but I had to restore all 45GB.

So now I have to address the network problem that blocked restores at 100 mbps. In the past I'd have been confident this was a software bug in either the iMac or the XP box. Nowadays nothing's so simple. It could be an emergent bug. It could be an XP BIOS problem triggered by the 1 TB external USB drive, a drive that's far out of spec for that old system. It could be a subtle motherboard problem on the iMac -- the G5 iMac line is notorious for mb failures (one of Apple's crappiest products).

I've already ruled out switch or cable problems.

I'm going to take a semi-informed gamble and install a new 1 gbps Intel NIC in the XP box and retest. If that doesn't work I'll have to start testing the iMac for a motherboard failure.

Update 5/6/09: New NIC worked, but not exactly sure why.

Thursday, April 30, 2009

Testing Firefox 3.5b4

Firefox 3 has been very slow on a single CPU PPC G5 iMac. It quickly pegs my CPU.

Happily Safari 4beta has been a great improvement over Safari 3, and Google's Safari (4) support is finally respectable. So I've been using Safari -- really for the first time. (Camino runs into too many Google oddities, otherwise I'd use it over FF 3. We do use Camino on an ancient G3 iBook running 10.3 -- and it's marvelous there.)

Now, however, James Fallows reminds me that FF 3.5b4 is a real option. I've started testing ...
Welcome to Firefox 3.5 Beta 4

... This release is being made available for testing purposes only. You should read the release notes before getting started.

We want to hear all of your thoughts about this beta, especially if you encounter broken sites or other web weirdness. Drag this feedback button onto your bookmarks toolbar and click on it when you have something to tell us...
I know how to test it.

First impressions? It's fast and responsive so far, and my CPU is running at about 35-50% -- which is about the same as Safari. The mouse wheel scrolling is particularly smooth, and Macintosh copy/cut shortcuts work in the rich text editor (not sure that's new, I switch platforms so often it's all a bit automatic).

The release notes mention ...
  • There are Gmail oddities, fix by refresh
  • Uses Tracemonkey - so faster Javascript, maybe fewer memory leaks
  • Location aware browsing (I'll turn it on of course)
  • HTML 5 offline storage (like webkit and chrome)
Updates to come, but this feels like a good one.

Update: Google Gears is not compatible with the beta (unsurprisingly). So you'll lose offline Gmail if you install. Also I found one bug. In a multi-user OS X machine the install reports a privileges error if another user is active, even if FF is not in use in the the other session.

Tuesday, April 28, 2009

OS X parental controls - bug?

Yes, my eldest is of that age.

So I'm checking out the Parental Controls ... and I discover they only go back a month. When I change the date range to anything over a month no information is displayed at all!

Since you can't export or otherwise analyze the logs they're not terribly useful anyway -- but they also don't work.

Apple really doesn't take children seriously -- I'm not sure they believe in them! This didn't used to be true -- parental features in Classic were excellent, as was Simple Finder.

None of that survived OS X, and it's clear Apple doesn't really test this stuff. I figure they put it in to keep regulators of their backs.