Mac OS X

The Macintosh operating system “for the next twenty years.”

Thoughts about the Leopard line

I got together with some folks to stand in line for the Leopard release on Friday evening; we went camping in Victor outside the Apple Store Eastview. I wanted to jot down a few observations of the outing, and I’ll do so in no particular order.

It was fun, both for the event itself and to spend time outside the home with friends. (Unfortunately — or perhaps fortunately — Christen was stuck at home with Elijah.)

It’s perhaps not the best advertising in the world to have a line 200-some odd deep waiting to get into your store. It becomes a curiosity for others in the mall and a hassle for patrons who just wanted to saunter in but are turned away. Amplify this with a line that is predominantly composed of white males, aged 20 to 60 — and the store suddenly looks a lot less hip.

Those of you who’ve stood in lines for Apple conference or trade show keynote addresses know of what I speak. Though this crowd was less like WWDC’s and a little more eclectic like Macworld’s, it was still a turn-off for the teenage girl iPod demographic.

Speaking of which, some young girls walked up to others in the line behind us, asked what the line was for, and then rolled their eyes and stalked off in revulsion.

Unlike any other retailer I can think of in this situation — a captive audience of 200 people waiting to rush through your doors — Apple didn’t have any other promotions in force. Just a new operating system. They didn’t give anyone 5 or 10% off a new computer, or a discount on an iPod, or any other kind of bundling incentive, as far as I could tell.

Frankly, most of the people I saw walking in played with a computer for a few moments and walked out again with only their free t-shirts. And then a few jumped back at the end of the line for another t-shirt.

Did Apple even make any money on this, after staffing up, closing the store to prep, and then giving out the freebies? It looked like they wanted you to go in and out immediately … preferably with your copy of Leopard, sure, but they weren’t exactly encouraging anyone to get more than that.

The Eastview store has been totally reconfigured. I haven’t been there since its remodelling, but the Genius Bar is in the back now, where the checkout used to be. Now, there’s no obvious checkout so I assume they’ll be heavily using those hand scanners from now on. Overall, it was hard to get a feel for the changes since the Leopard checkout line was roped off through the center of the floor.

The iPod touch, which I saw in person for the first time, is really thin. The outer ring on its face is beveled in a black material, maybe metal, that appears similar in style to the sloping edges on the new iPod classics and nanos.

The store employee I chatted with about the Mac Pro didn’t have much help to offer me about the optional BTO RAID card. In fact, he was just looking up the details on the Apple Store Web site, thankyouverymuch. But, he was pleasant while he was performing that admirable service, and I’ll give him credit that he was genuinely trying to be helpful.

Non-universal libraries and more in Leopard

Dave Dribin notes a non-fat library file in the shipping version of Leopard. I whipped up a quick test to see if there were other libraries that were PowerPC-only, at least based on my understanding of lipo (see also Compiled for ppc7400). There is one other I found:

$ for a in /usr/lib/*.dylib ; do if [ -f "$a" ] ; then lipo -info "$a" ; fi ; done | grep -v "i386" | grep -v "x86_64"
Non-fat file: /usr/lib/libcrypto.0.9.dylib is architecture: ppc7400
Non-fat file: /usr/lib/libssl.0.9.dylib is architecture: ppc7400

Duplicating that with grep "Non-fat", which I settled on in my next step, produces the same results.

I figured I'd widen the scope a little bit — and wondered if any non-universal files would be Intel-only — so I experimented until I came up with the following search. It turned up some interesting results, including non-universal files that were ppc, some ppc7400, some i386 … and "veo."

$ find / -type f -perm +u=x,g=x,o=x -exec lipo -info {} \; 2>/dev/null | grep "Non-fat"
… 64 lines of non-universal executables omitted but attached as a file to this story …

I'm surprised that there were 64 non-universal executables. Some of them didn't necessarily need to be universal, as they appeared to be architecture-specific drivers. Others, I'm not so sure.

What the heck is veo? I guess it might+be+related+to+PowerPC, but that still doesn't explain to me why its architecture type shows up in Leopard.

64nonuniversal.txt7.71 KB

Compiled for ppc7400

I noticed that in the shipping version of Mac OS X Leopard, universal binary executables are compiled as "ppc7400" rather than simply "ppc."

For example, the lipo output on zsh:

$ lipo -info /bin/zsh
Architectures in the fat file: /bin/zsh are: i386 ppc7400

Compare that to Tiger on PowerPC:

$ lipo -info /bin/zsh
Non-fat file: /bin/zsh is architecture: ppc

… and Tiger on Intel:

$ lipo -info /bin/zsh
Architectures in the fat file: /bin/zsh are: i386 ppc

When I’ve tried to compile Universal Binaries myself in the past, I came across various architecture types in documentation. I’ve personally compiled Apache 2.2 as Universal with support for both “ppc” and “i386” architectures. Because I used lipo to verify the results, I’m going to presume that its output matches up with the compiler targets.

I presume that this change means that even a PowerPC 750-ish ("G3") processor — to say nothing of older PowerPCs, like the 604 — wouldn't be able to run those binaries. I hope I’m not misinterpreting the output of lipo, and I’m certainly open to correction. If indeed the binaries are PowerPC 7400-only, it appears doubtful that even something like XPostFacto would enable Leopard to run on those older Macs that lack G4 CPUs.

Since even launchd — the executable behind PID 1 on a running Leopard system — exhibits this, I wouldn't expect the OS to boot on anything less than a PowerPC 7400.

$ lipo -info which launchd
Architectures in the fat file: /sbin/launchd are: i386 ppc7400

I'm wondering if greater-than-867 MHz G4 CPU upgrades for older Power Mac G4 models will allow them to run Leopard, since the floor on the G4 system requirements was also raised. Or, does Apple's 867 MHz minimum mean that they are really looking for something else on the system? Was 867 MHz the breakpoint between generations or models of PowerPC 7400s?

[See also: Non-universal libraries and more in Leopard.]

Camping in Victor

It looks like I’ll finally be making a camping trip to Victor today. I’ve never camped in line outside an Apple Store for anything, but I thought it would be fun to try it once. I missed doing it for the iPhone and I don’t need Leopard right away, but today, I’ll see what the line is like at the Apple Store Eastview.

Mostly, I just want to soak in the atmosphere.

An OS for the next twenty years, a year or so at a time

MacNN notes Apple’s CEO in Decade of Mac OS upgrades likely (it’s easier to link to MacNN than the+original+NYT+article), commenting that Mac OS X Leopard will form the basis for the next ten years of operating systems upgrade. I remember Mac OS X being announced — not sure if this was at a WWDC or Macworld keynote — as “the next twenty years” of Apple operating systems. We’re basically ten years out from the NeXT acquisition of Apple acquisition of NeXT.

He says "I’m quite pleased with the pace of new operating systems every 12 to 18 months for the foreseeable future," wherein we see again that Apple considers the Intel version of Mac OS X to be a major release of Mac OS X. That’s fine, I’m sure it took a lot of effort and it has definitely had an impact. Otherwise, accounting for the 910 days between the debuts of Leopard and Tiger would mean that Apple isn’t sticking to a 12- to 18-month release schedule.

I think, by this logic, it’s entirely reasonable for Microsoft to consider Windows XP SP2, XP 64-bit, XP Tablet Edition, XP Media Center Edition, and all of Windows Vista to be major releases. It’s only fair. Sure, it took them a long time to release an upgrade to the original Windows XP, but it’s not like they’ve sat idle without releasing anything new at all between 2002 and 2007.

Interesting week of Apple news

Let’s summarize the week in Apple news so far:

  • Declared October 26, 2007, as the ship date for Mac OS X 10.5 Leopard, and updated all sorts of marketing material about it — including a list of its 300+ new features (an almost unheard-of summary, and the closest I’ve seen to the old TechNotes covering each new Mac OS release).
  • Increased the catalog of DRM-free music on the iTunes Store to 2 million tracks, and dropped the price to 99¢ from $1.29.
  • Announced an SDK for developing native software for the iPhone and iPod touch, due in February 2008.

Sync Services swarming behavior

I got to mention the Sync Services truth database on MacInTouch. Any day that you get to talk about the truth database is a good one.

Adam must have been looking around for more references, because he sent me the link to this+Apple+knowledgebase+article+about+the+SyncServices+folders+in+Mac+OS+X. It contains the best line I’ve ever seen in a knowledgebase article. And I read these articles for fun.

“As if it were a swarm of bees, you should stay away from the SyncServices folder in Mac OS X 10.4.”


Adam’s friend Matt wants to put a Folder Action on that folder, so that as it is opened, it’ll say “CAUTION: Swarm of Bees!” ROFL!

Oh, and I can vouch for Sync Services sometimes causing “unexpected results.” And apparently, silly behavior in all of us. Ahem.

Pixelmator versus Twitterific windows

I got a little confused when I opened the new Pixelmator 1.0 in demo mode, and had Twitterific running in the background. Pixelmator’s palettes and windows are all in the same “HUD” style as Twitterific’s main window. There was a lot of dark transparency floating around …

Determine the USB protocol used by a camera or card reader in Mac OS X

Apple’s iPod+Camera+Connector:+Supported+Devices support article has an interesting tidbit about how to find out what USB protocol Mac OS X is using with your camera or card reader or similar device. The protocols they list for the iPod Camera Connector are PTP, Type 4, and Mass Storage; these correspond to protocols Mac OS X itself supports.

While the device is connected (and in my experience, has a card inserted or other storage available), open Image Capture. Click “Options” and then choose the “Information” tab. In Tiger, the “Device Module” line will tell you which protocol module is being used with the camera or card reader. It seems as if this is a useful tidbit of information, especially if troubleshooting is required.

By the way, I had to make sure that iPhoto wasn’t launched when I checked my SanDisk reader — otherwise, iPhoto tended to exert control over my card reader and it disappeared from Image Capture’s list. I assume the same could be true of Aperture or other applications which use the Image Capture framework.

Hashing with splash in Python

Every time I do hashing in Python, I have to look it up. I forget how to do it. That's probably a bad thing, at least compared to the shell. The shell way isn't exactly simple, but I find it something I can do by rote.

I'm going to write down how I got MD5 and SHA-1 hashes for a file — which is something I occasionally have to do when posting a download, for example — thereby making it possible to find my own perfectly-tailored how-to next time:

>>> import hashlib # hashlib is new in Python 2.5
>>> file_reference=open('/path/to/file', 'rb').read() # open the file for reading, in binary mode
>>> hashlib.md5(file_reference).hexdigest()
>>> hashlib.sha1(file_reference).hexdigest()

There, that wasn't so bad. I just have to remember the name of the built-in hashlib module and how to call for a hash of some data with it. You're missing the twenty other lines I tried which didn't work, of course, but you don't really need to see that. Sigh.

Without specifying hexdigest(), the result is a hash object rather than the hash value.

>>> hashlib.md5(file_reference)
<md5 HASH object @ 0x639c0>

I compared the Python hashlib results above with the following output from OpenSSL, and they are the same:

$ openssl md5 /path/to/file
MD5(/path/to/file)= 11fb57ba7927ad04534d0a341dd9c943
$ openssl sha1 /path/to/file
SHA1(/path/to/file)= bff8e8bcd74662ee52dde369e9387cb10d5a5ece

On balance, I think I'd still like comparing that hash against another string better in Python, but getting the hashes was quite a bit more confusing to me. It was enough to interrupt my flow.

Syndicate content