This is certainly a skewed sample, but I just ran a quick test, and it looks like over half of the Safari users that have visited this site today are using Safari 2.0. Most the the rest are using Safari 1.3. Considering that Safari 2.0 is only available on Tiger, and Safari 1.3 arrived about two weeks ago as part of the 10.3.9 upgrade, it looks like most of my readers are quick upgraders.
If time permits, I’ll build a little graph later showing the version percentage by day; that should be entertaining.
I’ve been thinking a bit about what Apple’s going to do as a followup for Tiger. Assuming that Apple sticks with an 18-month cycle for 10.5 (“Lion”?), then we’ll be getting our hands on it slightly before Longhorn’s release date. Given that, it’s pretty clear that Apple is already thinking about what they want in 10.5 so they can trump Microsoft’s Longhorn offerings in the media. More then any previous release of OS X, I expect this one to be flashy; if Tiger was really an attempt to revamp the developer core of OS X, then I expect 10.5 to focus on the user experience.
A few things that I expect to see:
Improved metadata support. Just like Jon Siracusa has been saying, metadata is important. With Spotlight, we now have a framework for searching and storing file metadata. With 10.5, I expect to see the ability to tag files with specific metadata tags, like project name, priority, status, and so on. This is a feature that was pulled from Longhorn because of time constraints; Apple should be able to jump way ahead of Windows without a lot of work in this area.
Networkable Spotlight. Right now, Spotlight only works on local filesystems. Adding network support for Spotlight searching (and all of the other metadata that goes with it) will finally give people a decent reason to buy OS X servers.
A Finder replacement. Once we have the new metadata engine, we’re going to need a UI for managing it. I’m not sure if Apple will simply provide us with “Finder 2.0,” or if they’ll produce a radical new file manager and then provide users with the ability to revert to the old finder if they don’t want to upgrade. Either way, if Apple finishes their metadata back-end, then the Finder really needs to be updated to match. Since Apple hasn’t really put much work into the Finder since 10.0, and there are boatloads of customer complaints about the current Finder, I think it’s time for it to get re-written from the ground up, with the new version centered around metadata and searching.
More syncing and disconnected support. Windows has supported disconnected operation on network shares for years. That way, you can have a network share for some project, but have Windows maintain a local cache so you can still edit documents while you’re on a plane or otherwise unable to connect to the network. It’s a great feature, and Apple doesn’t have anything even vaguely like this right now.
Full 64-bit support. With Tiger, Apple has some support building 64-bit applications, but you can’t use any of the UI frameworks from 64-bit apps. I fully expect 10.5 to provide equal support for all current APIs from 32- or 64-bit code, and I expect that Xcode will have simple support for building “fat” 32/64 applications. If Apple leaves 64-bit apps out in the cold, then they’re giving Microsoft a big opening, and we’ll see claims that OS X isn’t “a real 64-bit operating system.” By 2007, at least 80% of new PCs and Macs will come with 64-bit CPUs; even if most apps won’t need to support 64-bit address spaces, it’d be a major mistake not to give developers the tools that they need to build 64-bit apps.
Resolution-independant displays. Right now, most UI elements are sized in pixels; that works great when all monitors have roughly the same DPI, but it falls down horribly when displays range from 72 to 300 DPI. Switching from a 100 DPI display to a 200 DPI display currently means that all of your UI elements (menu bar, window decorations, icons) shrink to half of their current size. Tiger has the ability to change this hidden inside the developer tools, but most apps have a hard time dealing with it right now; by the time 10.5 rolls around, I expect the OS to automatically adjust the UI size based on the DPI of the output device; this will let us have HD-resolution displays on 15-inch PowerBooks without needing to ship a magnifying glass with every new laptop.
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
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.