Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

Last week, I found and installed the Drupal Bad Behavior module. It’s been remarkable to see it working; in only one week of operation, it’s already logged 98 pages of events — at 23 items per page. That’s 2254 likely bots blocked!

In order to install the module, I had to find the latest patch/version — one that would work with the current Bad Behavior library — on the Drupal site and install it in my modules directory. I then had to install the Bad Behavior PHP library inside the the new module’s folder. Although this was a little tricky, it certainly feels worth it.

In reading the man page for the updated installer utility in Leopard, it looks like it offers the equivalent of “answer files” on Windows. This sounds like a big improvement, especially for systems administrators who want to automate the installation of packages on Mac OS X.

The “install choice change XML file” can be used to apply changes to the default option in an installer package. This uses the -applyChoiceChangesXML flag.

The installer can also show the defaults as well as the result after applying a choice changes XML file to them. Use the -showChoicesXML to find the choices and -showChoicesAfterApplyingChangesXML to see the outcome of choice changes, respectively.

For what it’s worth, the -dominfo and -query flags are also new and have functions that I don’t recognize from Tiger, comparing the two man pages.

Anyway, the install choices sound like a “win” — even just to get reliable, reproducible Radmind transcripts, if you’re into that sort of thing. Imagine creating an installer choice change file for a package you install/update all the time — the system software itself, and the Apple Xcode Developer Tools, both spring to mind. Whether you’re creating install choice change files for bulk installation or just automation of your build process, it sounds as if this new capability should be really helpful.

TidBITS: Apple to Allow Virtualization of Leopard — Mac OS X Server, not the workstation version.

This is pretty big news, even though it’s really only the change in EULA right now. It would solve a great many problems in hosting Mac OS X Server if VMWare ESX could run on Apple hardware. If you could make Xserves part of an ESX cluster, and you could limit the Mac OS X Server to running on just the Apple hardware in that cluster … that would be very good. But this is all wishful thinking and speculation on my part.

I checked on the version of xar that ships with Mac OS X 10.5 Leopard, and I was dismayed to find it’s 1.4. Xar is new to Leopard, but it’s got a much older version that dates back to January 10, 2007.

$ xar --version
xar 1.4

The latest version, 1.5.1, is from June 10. Version 1.5 is from May 14. The benefit of the newer versions is that they have fixed flaws and passed the Backup Bouncer test. Leopard’s bundled version is apparently too old to incorporate the fixes that put xar over the top on the test. That’s too bad. I was — and am — looking forward to its possible use for backups of all the kinds of data that can sit in the Leopard filesystem.

I also found the man pages for process sandboxing in Leopard; it’s found under “sandbox”:

$ man sandbox

I found the man page for code signing in Leopard; it’s found under “codesign”:

$ man codesign

Update: It’s worth noting that Apple has released the Code Signing Guide to document this feature further, from a developer perspective.

I came across a kernel extension for SoftRAID 3.6.5, from SoftRAID LLC in Leopard’s /System/Library/Extensions folder. I found the version in the SoftRAID.kext’s Info.plist file, and it really truly does appear to be SoftRAID, based on the copyright and the bundle identifier and so on.

This is notable simply because it’s included (although I don’t know how it’s being used, if at all) and it is also a newer version than I’ve seen press releases for.

One thing I find incredibly neat is that screenshots I’ve taken of Quick Look windows in Leopard are actually transparent — I can layer them on top of other graphics in applications such as Keynote, and the backgrounds show through.

I’m sure this sort of thing happened if you took screenshots of transparent windows in Tiger, but I never bothered. The windows weren’t everywhere. Quick Look is everywhere in the Finder, and as a Big New Feature With A Marketing Name, having screenshots when you’re explaining it to others is really handy.

For reference, I’m using a Python script to take the screenshots. It’s basically calling the built-in screencapture tool and then adding a drop shadow to it with the Python Core Graphics bindings. I got+the+script+from+Lankhmart+on+the+Mac+OS+X+Hints+forums — I found it after trying to write my own, since I’d been wanting such a script for a long time.

In this video, Pamela Fox and Ryan Boyd talk about the Blogger JavaScript client library. Ryan used to have an office around the corner from mine, and now he’s got videos posted to the Blogger Developers Network. Neat!

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.