Mac OS X

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

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.

Full cart

Wow, I must be shopping too much — but not buying enough — at the iTunes Store. I’ve filled it up!


I had used the shopping cart feature since my first visit to the iTMS years ago. It has become my wish list. There is no other good wish list feature I’ve found that lets me save references to what I want to buy from any computer so that I can see them on any computer where I access my account.

I could, instead, build one or more playlists for this purpose — it is perhaps little-known that you can drag items from the iTMS to playlists in the iTunes software’s source list area. The playlists, however, are per-computer; they are not saved with my iTMS account the way the shopping cart is.

I could send each playlist I’ve saved in the iTunes software to the iTMS as an iMix. iMixes are intended for community sharing, however. Creating an iMix would mean that others could see what I’m intending to buy, so it’s not entirely satisfactory, either.

So, I stick with the shopping cart and I’ve simply got too much in mine for the iTMS to handle. I don’t know if it’s related to the number of objects or the total cost of what’s in my shopping cart or some other limitation, but it’s full. Now, I have to buy or remove items.

Syndicate content