*scottstuff*

Apparently Tiger’s iCal is more strict then Panther’s, because the .ics files created by my author readings page won’t import into iCal anymore. There are a handful of other issues with the author readings code that need fixed, too, so I’ll see what I can do with it later this afternoon.

Wow: Tiger no longer includes Internet Explorer. (from John Gruber’s Tiger details page)

It never worked very well, but it’s still surprising to see it go. If you upgrade from a previous version of OS X, then the Tiger installer won’t delete it, but new Macs won’t have it from now on.

According to Apple, Spotlight is supposed to be able to index EXIF data. Unfortunately, none of my JPEGs’ EXIF data has been indexed. Even worse, some of the Spotlight metadata fields are obviously bogus, showing obvious bugs in Spotlight’s implementation.

To test Spotlight’s EXIF abilities, I used a JPEG from my D60 that I had annotated with EXIF and IPTC data using iView Media Pro. Using the mdls command-line tool, I asked for details on one of my images, and saw something like this:

halloween-2004-173.JPG -------------
kMDItemAttributeChangeDate = 1970-01-02 17:40:06 -0800
kMDItemFSContentChangeDate = 2004-10-30 22:43:23 -0700
kMDItemFSCreationDate  = 2004-10-30 22:43:23 -0700
kMDItemFSCreatorCode   = 0
kMDItemFSFinderFlags   = 0
kMDItemFSInvisible     = 0
kMDItemFSLabel         = 0
kMDItemFSName          = "halloween-2004-173.JPG"
kMDItemFSNodeCount     = 0
kMDItemFSOwnerGroupID  = 20
kMDItemFSOwnerUserID   = 501
kMDItemFSSize          = 1712816
kMDItemFSTypeCode      = 0
kMDItemID              = 3341125
kMDItemLastUsedDate    = 2004-10-30 21:43:23 -0700
kMDItemUsedDates       = (2004-10-30 21:43:23 -0700)

Notice that all of the metadata provided is simply generic file data–none of this is image-specific. There is no EXIF data, and no indication that Spotlight knows that this is an image. Also, the kMDItemAttributeChangeDate is weird–it’s not impossible that I’d lost my clock and not noticed for two days, but it’s unlikely.

Worse, after making a minor change to the JPEG and then waiting for the re-indexer to run, the Attribute Change Date became completely bogus, changing nearly every time I ran mdls. Here are a few sample values:

kMDItemAttributeChangeDate = 1969-12-31 16:00:06 -0800
kMDItemAttributeChangeDate = 125748-10-16 05:23:09 -0800
kMDItemAttributeChangeDate = 1976-10-14 07:29:24 -0700

I particularly like the way that it jumps from 6 seconds after the Unix epoch to 123000 years into the future and then back into the 70’s again.

Even after telling iView Media Pro to re-write all of the EXIF and IPTC data in the file, mdls still doesn’t show any EXIF details. This is disappointing–I’d hoped to be able use Spotlight to locate images in my photo collection, possibly searching by date, time, focal length, lens, location, subject, and so on.

As I see it, one of two things can be happening here. Either this is a bug in 10.4.0 or Spotlight’s indexing system works in two passes–first indexing files’ existence, and then looping back around to index the data inside the file. It looks like mdimport is still running on something on my box, even though the Spotlight dropdown claims to be finished.

Update: I think it’s running in two passes. If I manually run mdimport on my JPEG, then a bunch of EXIF data shows up in mdls:

halloween-2004-173.JPG -------------
kMDItemAcquisitionMake     = "Canon"
kMDItemAcquisitionModel    = "Canon EOS D60"
kMDItemAperture            = 6
kMDItemAttributeChangeDate = 2005-04-29 18:49:35 -0700
kMDItemBitsPerSample       = 32
kMDItemCity                = "Woodinville"
kMDItemColorSpace          = "RGB"
kMDItemContentCreationDate = 1903-12-31 16:00:00 -0800
kMDItemContentModificationDate = 2004-10-30 22:43:23 -0700
kMDItemContentType         = "public.jpeg"
kMDItemContentTypeTree     = ("public.jpeg", "public.image", "public.data", "public.item", "public.content")
kMDItemCopyright           = "2004 Scott Laird"
kMDItemCountry             = "USA"
kMDItemDisplayName         = "halloween-2004-173.JPG"
kMDItemEXIFVersion         = "2.2"
kMDItemExposureMode        = 1
kMDItemExposureTimeSeconds = 0.005
kMDItemFlashOnOff          = 1
kMDItemFocalLength         = 23
kMDItemFSContentChangeDate = 2004-10-30 22:43:23 -0700
kMDItemFSCreationDate      = 2004-10-30 22:43:23 -0700
kMDItemFSCreatorCode       = 0
kMDItemFSFinderFlags       = 0
kMDItemFSInvisible         = 0
kMDItemFSLabel             = 0
kMDItemFSName              = "halloween-2004-173.JPG"
kMDItemFSNodeCount         = 0
kMDItemFSOwnerGroupID      = 20
kMDItemFSOwnerUserID       = 501
kMDItemFSSize              = 1712816
kMDItemFSTypeCode          = 0
kMDItemHasAlphaChannel     = 0
kMDItemID                  = 3341125
kMDItemISOSpeed            = 7.64386
kMDItemKind                = "JPEG Image"
kMDItemLastUsedDate        = 2004-10-30 22:43:23 -0700
kMDItemPixelHeight         = 3072
kMDItemPixelWidth          = 2048
kMDItemRedEyeOnOff         = 0
kMDItemResolutionHeightDPI = 180
kMDItemResolutionWidthDPI  = 180
kMDItemStateOrProvince     = "WA"
kMDItemUsedDates           = (2004-10-30 22:43:23 -0700)
kMDItemWhiteBalance        = 1

This still isn’t perfect, though–I’m not quite sure where kMDItemISOSpeed = 7.64386 came from–it’s really ISO 100. Similarly, mdls reports the Aperture as 6 when it should be f/8. On the other hand, the focal length and shutter speed are correct, although it’s sort of weird to see shutter speed expressed as decimal seconds.

Update 2: It’s definitely a two-pass thing. After leaving my laptop running overnight, all of my JPEGs now have a full set of metadata associated with them. The ISO numbers and apertures are still wrong, but the rest of the data’s all there. So, it looks like Spotlight tries really hard to get basic data into the DB, and then makes a second pass filling in more details as time permits. Good to know–I haven’t seen this documented anywhere.

I installed Tiger over lunch today. I’ll have more to say later, but for now, I just wanted to share this:

I guess that explains why Mail was so slow in Panther–138,000 messages will do that to you. Right now, my poor PowerBook is converting mail, installing the developer tools, and indexing for Spotlight. Hopefully it’ll return to a usable speed once that all finishes.

Ars Technica’s John Siracusa has posted his writeup on Tiger. I haven’t had time to read all of it yet, but the first half is an amazing piece of work. There’s a ton of content in there that is entirely new to me, like the writeup on launchd, Apple’s new open-source daemon-launching code. As usual, he goes to great lengths tracking down all of the metadata changes in Tiger, and for once he likes what he sees, although there’s still a lot of work left to do in 10.5. This is a really technical guide to what has changed under the hood in Tiger; it’s not a “the shortcut for doing Foo in the Finder changed; Apple Sucks” sort of write-up.

One thing that I’m wondering that I haven’t seen anyone address: if Apple is currently on a 18-month OS X release cycle, and 10.4 is out in April 2005, then the next release will be in October 2006, or slightly before Longhorn’s current release timeframe (“before Christmas 2006”). This should be fun.

It looks like the Seattle Fry’s store will be selling Tiger for $99 this weekend. I suspect that other Fry’s locations will have similar prices, but it’s not at all uncommon for Fry’s to run different promotions in different regions. Take a look at frys-electronics-ads.com; they’ll probably have details within a day or two.

Apple finally announced a ship date for Tiger: April 29th. They’ve kept the same pricing that they’ve used for earlier releases, $129 per copy or $199 for a 5-system “family pack.” Apparently they’ve added a Tiger/iLife/iWork bundle at $249 as well.

Think Secret is also reporting that new PowerMac G5 systems will show up at the NAB conference this weekend. They’re unsure if Apple will use IBM’s dual-core CPUs yet, or just stick with faster single-core processors. There’s some evidence that Apple is getting ready to release 4-processor sysetms, so systems with 2 dual-core CPUs wouldn’t be surprising.

On the PowerBook G5 front, ThinkSecret says that they don’t expect to see them any time in 2005. It’s unclear what Apple will do with their PowerBook lineup if the G5 is still most of a year away. Their current CPU is bus-starved, and cranking up the clock rate (or even using Freestyle’s dual-core G4) probably won’t give them a lot of extra performance.

It seems like every month, Safari runs just a little bit slower on my PowerBook. Some sites are worse then others–I can’t visit cnn.com or newegg.com without staring at the spinning beachball of death for 5 or 10 seconds. Even worse, whenever this happens, Mail or NetNewsWire tend to go away as well, rendering my system effectively useless. Clearly something was eating a bunch of CPU time, but there was no obvious way to tell what it was.

So, this afternoon I decided that I’d bite the bullet and find the problem. I downloaded Apple’s CHUD toolset, installed it, and fired up Shark, Apple’s system-wide profiling tool. I left it running in the background, collecting performance data, while I loaded up a bunch of slow websites, and then took a look at the profile that it generated. The single biggest block of time was spent running CFStringFindWithOptions (9.1%). Drilling down a bit, it looks like most of those calls came from NSHTTPCookieDiskStorage (8.8% of the total). So I fired up Safari’s cookie editor and realized that I hadn’t cleared out my cookie cache since I first installed Safari–there were several thousand cookies sitting there. From looking at the profile, I’d guess that OS X’s cookie system does a linear search through the whole cookie jar every time it hits a page. Since the same basic code is used by every native OS X application, that’d explain why both Safari and NetNewsWire were slow.

I spent a few minutes cleaning out the cookie jar, and–amazingly enough–Safari’s a lot faster. I haven’t seen the beachball of death since I cleaned up the cookies; before I was seeing it every minute or so. I don’t have any hard benchmark numbers, but subjectively it feels a lot better.

So, if Safari’s running slow, try cleaning out your cookies.

Update: Thinking about it a bit more, it seems obvious what’s happening–every single HTTP request does a linear read of the cookie database. With some sites, a decent percentage of the HTTP requests also result in a write to the cookie database. Most likely, this triggers a reader-writer lock of the cookie DB, so the write stalls waiting for a bunch of slow reads, and then a handful of writes back up one after the other, so even if the cookie handling is only eating 9% of the CPU, the total wall-clock time lost due to locking could easily be really substantial. Even worse, this effectively serializes HTTP requests, limiting the system to one cookie-invoking request at a time. That’d explain a lot of the weird behavior that I’ve seen in Safari, where one slow website will block a dozen tabs from loading. Does anyone know if Tiger has a new cookie implementation? Any decent database system will solve all of these problems.

Tiger Update: It still uses ~/Library/Cookies/Cookies.plist–no SQLite. So it’s this is probably still a problem with Tiger.

Last week, a co-worker stopped by my office to ask me what cool new Mac software I’d seen recently. I had to stop and think for a while–I mean, it seemed like I was seeing cool new Mac stuff show up once or twice per month for a while, but recently it’s slowed to a trickle. I can’t think of anything really exciting that I’ve seen since NetNewsWire 2.0 betas started showing up months ago.

I’m not sure if this is all in my head or not, or if there’s some underlying reason (waiting for Tiger? Economy recovered and programmers went back to desk jobs?). Hopefully things will pick up again soon.

For what it’s worth, here are the last few Mac apps that I’ve looked at. Only one of these is really new, the rest have been sitting around for a while but only recently found their way onto my desktop.

Seasonality

Seasonality is probably the coolest new program that I’ve seen in a week or two. It’s a desktop weather monitor that knows about forecasts, history, sunrise and sunset, and weather radar. I played with it for a few minutes yesterday, and it seems to be an improvement over rssWeather.com and NetNewsWire. However, it’s not a $25 improvement, and I don’t care about the weather enough to leave Seasonality running 24x7. So, while it’s cool, I don’t really feel any desire to actually use it.

TextMate

I keep hearing people rave about TextMate; a lot of people really love using it for their text editor. I spend half of my life in Emacs, but I’d love to switch to something more Mac-centric–I’ve used Emacs for 15 years, but I don’t really feel like I understand it any better now then I did a decade ago. It can do anything, but the barrier for learning each new feature is high enough that I only rarely bother to learn anything new about it. On the plus side, though, Emacs works pretty well out of the box for me, and it’s available everywhere.

So, every 6 months or so, I download a new copy of TextMate to see if it’s the right editor for me, and end up deleting it about 30 minutes into the trial. It looks really cool, and they seem to be adding some really nice Subversion integration into it, but I can’t stand the way it handles indenting. My brain seems to have fused with XEmacs’s indent handling–when editing languages like C, Ruby, XML, or HTML, XEmacs changes the meaning of the Tab key from ‘insert a tab’ to ‘indent this line correctly.’ Obviously, this requires a level of syntax-awareness that most editors don’t posess. TextMate knows enough about syntax to do color highlighting and folding, but that’s about it. While the function folding UI is cool, it’s just not enough for me to justify paying $50 or so for the program.

SubEthaEdit

SubEthaEdit is kind of the epitome of “cool OS X editor,” largely because it’s designed from the ground up to use Rendezvous to allow collaborative editing over the network. On the other hand, it doesn’t seem to have any native support for traditional version control tools, and its indentation support isn’t any better then TextMate. Since SubEthaEdit is free for non-commercial use, I’ll keep a copy around, but I just can’t see myself using it for writing code.

Growl / GrowlMail

Growl is a tool for displaying asynchronous notification messages on OS X. People have used it for a number of different uses, but the one the most interests me is GrowlMail, which sends Growl pop-ups every time new mail arrives. I’ve been using Mail.appetizer for a while now, but it seems to cause more problems then it fixes–since it runs inside of the main Mail process, it’s prone to blocking whenever Mail gets slow, which means that I have notification windows hanging around that I can’t get rid of easily. Also, since I installed it, I’ve noticed that Mail is much more prone to crashing. I don’t have a lot of patience for dead mail clients, so I yanked Mail.appetizer out and replaced it with GrowlMail; hopefully it’ll help a bit.

When ThinkSecret announced last week that OS X 10.4 (”Tiger”) will ship in April, there was a fair amount of skepticism. A number of people suggested that there were too many bugs in the current developer seeds, and Tiger wasn’t ready to ship yet. Since then a few other reports have surfaced, including one from eWeek that seems to confirm at least the timeframe, if not the exact days that ThinkSecret listed.

Today, ThinkSecret followed up with a new report, saying that Tiger development is rapidly winding down and suggesting that many parts of Tiger are already complete and ready to ship:

Multiple sources also report witnessing at least one Tiger “wrap party” at One Infinite Loop earlier this month, and several members of the Tiger development team are presently on vacation, sources say, generally a sure-fire sign that their portion of development has been completed.

Personally, I’ve been drooling over Tiger since it was first announced last year, and can’t wait to get my hands on the new release.