But a few people don’t respect or value the contributions that Jobs made. Richard Stallman, the famously anti-Apple, GPL protagonist, comes off borderline celebratory in his reaction:

Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died. As Chicago Mayor Harold Washington said of the corrupt former Mayor Daley, “I’m not glad he’s dead, but I’m glad he’s gone.”

It’s dumbfounding to me that anybody who lives to any degree in the public’s eye could be this emotionally callous about the death of another person. He paints Jobs as a robber of freedoms, first and foremost, while neglecting to acknowledge the many liberties he brought, for example to those of us who can’t, or don’t want to build our own computing infrastructures.

I find it laughably easy to poke holes in the philosophy of “freedom” that Stallman and his acolytes passionately pursue. In this particular case, his metaphor of the computer as a jail brings to mind the beauty of constraints. Freedom from choice can be as liberating and empowering as freedom of choice.

Imagine a Steinway piano: each string is perfectly tuned so as to cast a unique, beautiful tone into the air with the gentle press of a key. I respect and value this instrument as a liberator of artistic expression. Many people find a lifetime’s pursuit of study in this device, extracting no end of joy from the limitless possibilities it offers.

But to Richard Stallman the piano must appear no less than “musical jail.” After all, the sound spectrum is made up of an infinite number of tuneable pitches, and this … instrument … this villainous oppressor of choice, limits its users to a paltry 88 tones.

I’m really excited about sandboxing and also really terrified. Apple has given us, thus far, a limiting set of entitlements that don’t quite cover everything that reasonable apps want to do, or even everything that Apple itself has approved as acceptable behavior in the Mac App Store. Yet Apple has made it clear that it wants to see all apps adopt sandboxing, and the writing is on the wall that in particular, participants in the Mac App Store should be prepared for the day when non-sandboxed apps may not be approved for sale in the store.

For us developers looking into sandboxing our own apps, it can be tough to wrap one’s head around exactly what privileges need to be requested. One way to go about it is to sandbox your application with the strictest of controls (basically disallow everything disallowable), and see what breaks. Then you could add back whatever entitlements are necessary to get things working again.

On the other hand, it would be handier to have the system simply tell us what kinds of behaviors our app is engaging in, and what the corresponding entitlements would be to allow it to work even while sandboxed. Thanks to a tracing mechanism in the sandbox, this is in fact possible. Furthermore, you can use a command-line tool to apply arbitrary sandbox profiles to an application without having to modify the application itself.

I defined a handy shortcut in zsh for running an arbitrary app with the “trace” mechanism enabled, to show exactly what the app is accessing, simplify the output, and open it in my default text editor:

function sbx()
{
        echo '(version 1)\n(trace "/tmp/traceout.sb")' > /tmp/tracein.sb
        sandbox-exec -f /tmp/tracein.sb $1
        sandbox-simplify /tmp/traceout.sb > /tmp/tracesimple.sb
        open -t /tmp/tracesimple.sb
}

After you’ve defined this in your .zshrc (other shells, you are on your own!), you can do something like:

sbx /Applications/FastScripts.app/Contents/MacOS/FastScripts

Then you use whatever features in your app you are concerned about, and quit the app. A text file will open with exquisite details about all the privileged actions your app was permitted to do, which would otherwise be forbidden by the sandbox.  Great, just copy that list of permissions into your sandbox entitlements plist, and we’re done. Right? Not quite.

The rules generated by the trace are very precise and may not be sufficient to cover your app’s behavior in practice. For example, if I open FastScripts, my scripting utility, and run a single AppleScript that controls the terminal, the resulting permissions trace reveals a sandbox rule that would allow that behavior to happen:

(allow appleevent-send
       (appleevent-destination "com.apple.terminal"))

That’s well and good for a utility that only ever needs to send events to the Terminal, but of course FastScripts is a general purpose scripting application that needs to send events “wherever the heck the user wants to send them.” Currently, Apple doesn’t offer a sandbox entitlement for this broad behavior, so it is not possible to sandbox FastScripts.

I think that Apple would have a lot more developer enthusiasm for this feature if it wasn’t so clear to many of us that our apps will be forced to lose features in order to adopt sandboxing. And while users may be happy about the prospects of improved security with the sandbox, I think there will be less excitement about the diminished functionality of apps whose features don’t fit nicely into the sandbox confines.

Developers and power-users can use the sandbox command-line tools now to get a good sense for what will or will not work down the road if sandboxing, with the current set of entitlements, is enforced by Apple for a large number of 3rd party applications. There is some documentation for these tools in e.g. “man sandbox-exec”, but the documentation is pretty minimal. If you want to read more, check out this useful document, which aims to give a better understanding of the sandbox, entitlement profiles, and how to use the command-line tools.

• Çingleton. October 14-15. Montreal, Québec. My friends Guy English, Scott Morrison, and Luc Vandal teamed up to put on a very small, very focused “symposium.” I love the small scale and single-tracked nature, but it comes with one huge drawback: low capacity. Just as the similarly formatted C4 conferences sold out quickly every year, I expect Çingleton will do the same.
• MacTech. November 2-4, Los Angeles, California. This year’s show features a keynote from Guy Kawasaki, which will be exciting for me, since I’ve corresponded with Guy over the years: he’s provided a ton of valuable feedback about MarsEdit. Also exciting is the addition to the organization team of Scotty from iDeveloperTV, who will be running the developer side of the conference.
• Voices That Matter. November 12-13. Boston, Massachusetts. The floating conference moves back to Boston, the site of its first show, at which I also had the pleasure of speaking. They have just posted the schedule, revealing that Aaron Hillegass will be delivering the opening keynote. Definitely wake up for this!

The Voices That Matter folks are offering a coupon code with a twist: $150 off for the purchaser, with a $50 bonus for me as the speaker. I am not paid for the speaking itself, so if you are looking for a discount, consider using “BSTSPK5“. When combined with the early-bird pricing, it brings the cost of the conference down to $395.

With such a busy speaking lineup, I have once again had to pass on some other conferences where I would have enjoyed the less demanding experience of simply attending. In particular, I am bummed to be missing:

• 360iDev. September 11-14. Denver, Colorado. Another show I haven’t had the pleasure of attending yet, but that is celebrated by many of my peers. The schedule a more conventional, multi-track affair, which is great for those who prefer to pick a favorite topic from a variety of choices. The keynote address will be delivered by my friend Matt Drance, whose work you may also know from his past life as an Apple evangelist.
• SecondConf. September 23-25. Chicago, Illinois. Seen by many as the organic successor to C4, I have been hoping to attend for the past two years. This year’s roster of speakers is outstanding, featuring some well-known developers and … Andy Ihnatko! But it’s also notable for featuring some folks who don’t do as much public speaking, including Mike Rohde, the designer of Red Sweater’s logo!

Suffice to say, there is a lot going on this fall. If you are looking  for something to do, take a click-through to some of these great shows and see if any of them sounds like the right place for you.

I had grown up using mostly non-Apple products. My dad bought me a Timex Sinclair when I was six. I moved on to a Commodore 64, an Amiga 1000, and finally a Unix-based Sun 3/50 before I caught Mac fever in 1994. Two years later, I was working full-time at Apple as a software engineer at Apple.

When I signed on, Jobs was long gone, but his legacy was strong. Ten years after his departure from the company, bumpers in the parking lot remained plastered with the aspirational “The Journey is the Reward” proverbs that he had famously reiterated. Jobs made his mark, and the pursuit of excellence was alive and well inside Apple.

In late 1996, Apple announced that it would acquire Steve Jobs’s NeXT computing. Steve Jobs, in one role or another, was returning to Apple. I was overwhelmed, but excited. Although I had never worked for Steve Jobs, I felt that I had been working on his vision.

When I left Apple in 2002, it seemed that Jobs had won. He proved himself to critics by rescuing Apple from the throes of bankruptcy and restoring it to a company of huge successes. The iMac, iPod, and Mac OS X were all new testaments to his enduring legacy at Apple.

But he was just getting started. Still to come were not only the obvious iPhone and iPad, but dozens of less obvious successes ranging from the ever-improving Mac OS X, to the incredible Airport Express, to the fact that every damn thing Apple makes just works so damned well together.

Pixar Animation Studios is another of Jobs’s great successes. My three-year old, Henry, has lately been obsessed with everything Pixar. This includes “Cars,” which I have seen more times than I care to admit. It’s actually a pretty great film, and I’m fond of the romantic interlude where the protagonist Lightning McQueen is led on a carefree drive through the desert by his love interest, Sally. Their ride is set to an upbeat Randy Newman tune, which helps to pack an emotional punch in the scene.

Today I was driving in my own car, and heard an old Bob Dylan song that I realized the Randy Newman score reminds me of.  Steve Jobs is known to be a huge Bob Dylan fan, so it’s especially poignant that on the day of his retirement as CEO of Apple, I may have found myself listening to one of his favorite songs. Buckets of Rain also includes a concise proverb of its own, which serves as an appropriate comment on Jobs’s career:

“Life is sad, and life is a bust, all you can do is do what you must. You do what you must do, and you do it well.” — Bob Dylan, “Buckets of Rain”

Well said, Bob. Well done, Steve. For the rest of us: let us do what we must do, and do it well.

Now you can grab any edge of a window and grow or shrink it to suit your wants. What I didn’t notice until today, however, are a few interesting variations on window resizing that are facilitated by pressing a modifier key while resizing.

Hold the option key while resizing to cause changes in the  window’s width or height to be made in equal measure on each side of the window. For example, clicking and dragging the right edge of a window with option depressed will cause the left side to grow or shrink in mirrored fashion. For lack of a better term, I’ll call this balanced resizing.

Hold the shift key while resizing to impose constrained resizing. Whatever direction you grow or shrink the window, adjustments will be made so that the ratio of height to width remains the same.

These are some pretty geeky resizing modes. I don’t foresee using them particularly often, but it’s interesting to know they are there.

(I did some preliminary Googling before sharing this, and didn’t see any documentation come up. I’ve since noticed that Matt Gemmell already shared this tip in a Twitter update.)

When I first saw the Lion version of iCal, my eyes were drawn to the obnoxious bits of paper that cling to the top of the window, artificially and pointlessly leaving the debris that you might find on a real-life calendar with removable paper sheets:

As Cathy Shive pointed out in her NSConference talk on user interface metaphors, the presence of junk like this in an application is at best useless, at worst distracting and detrimental to the usability of the application. I remember her saying in her talk, before Lion’s iCal had even been presented in a private developer beta, that little things like paper scraps in an application are particularly annoying because she always wants to try to pick them off just as she would with a physical object.

Lion has given me the opportunity to empathize deeply with that concern. I hate those cruddy paper bits, and I can’t pick them off! Or can’t I?

To clean up your copy of iCal on Lion:

1. Select the iCal application in the Finder and press cmd-D to duplicate (make a backup, for safe keeping).
2. Control click the application icon and select “Show Package Contents.”
3. Navigate to Contents/Resources/
4. Select “CanvasTopTile.png” and open it up in Acorn or another, less attractive image editor. Or download my edited version and replace the original file.
5. Select the paper bits and “clean them up” by deleting them.
6. Reopen iCal, and bask in the glow of your clean white calendar:

Granted, this only fixes the paper bits. You’re still stuck with that horrendous tan leather toolbar. But at least that doesn’t beg to be picked at. It’s worth noting that the tan leather can also be tweaked by editing a variety of other image resources in the bundle. It’s trickier because many of the graphical components of the toolbar are designed to blend with the leather background, so you’ll end up having to change quite a few of the images.

I’m reminded of another great observation Cathy made in her talk: when you make very stylistic choices like this for a user interface, you dramatically increase the variety of reasons that the customer can be repulsed by the design. What if I don’t like leather? What if I don’t like tan leather? What if I prefer a running stitch to an outline stitch? You can argue that matte grays and subdued color gradients may invite the same controversy, but there’s a reason they are so common in user interfaces: because they’re far less likely to distract from the form and function of the application itself.

Addendum: Updating the iCal code signature. Thanks to rentzsch and daagaak on Twitter for pointing out that editing the resource will break the “code signature” on the application, put there by Apple to assure users that the application 1. Was developed by Apple, and 2. Has not been modified by anybody but Apple. You can re-sign the application after tweaking it, to put it back into a  ”signed” state, albeit not by Apple. Hopefully this will prevent it from prompting you all the time about approving connections to services like MobileMe. From the Terminal:

 codesign -f -s - /Applications/iCal.app

This reveals how little things like tweaking an application’s resources have wider-reaching consequences than they used to. I’m pretty sure you won’t miss any functionality in iCal by using a self-signed copy of the app vs. an Apple-signed version. But I could be wrong!

Apple has apparently taken advantage of the 64-bit runtime in Lion by optimizing the Objective C runtime itself to use some of these extra bits for, shall we say, clever purposes. Bavarious describes an optimization through which Apple is able to replace previously full-fledged opaque objects such as NSNumber with an object-placeholder that exists entirely as the 64-bit “object address” itself. This means that, for a wide range of “simple” objects, no additional memory allocation is required, and no retain/release memory management is required for the “object.”

The trick relies on a implementation detail of the system, that allocated blocks of memory will always be aligned at 16-byte offsets into the address space. This leaves a bunch of numbers that can be represented in 64-bits, that cannot reasonably be assigned to any other object. To understand this practically, imagine that your neighborhood’s postal addresses are all assigned at offsets of 10: 30, 40, 50, etc. A clever postal service could institute an addressing system that uses an “invalid” address such as “31,” to perhaps mean “deliver to 30 with expedited afternoon delivery.”

Cleverness like this with encoding extra information in memory addresses is a time-honored tradition. I recall the days of 24-bit addressing on classic Mac OS, where Apple, and many 3rd party developers, observed that the high 8 bits of a typical memory address could be tweaked and used to store additional information, because the system would never reference those bits when resolving a particular address.

In those days, using those extra bits turned out to be a pretty significant headache when 32-bit addressing ultimately came along, and lots of code had this “crufty” treatment of addresses to clean up. Perhaps it is a memory of situations like this that caused Jon “Wolf” Rentzsch to comment in his bookmarking of the above-referenced blog post:

“Every tagged pointer has its lowest bit set, hence tagged pointers are odd integers” Strikes me as a really bad idea. [Emphasis Mine]

But the difference now, in this scenario, is the “cute hacking” is all being done by a central power, with and in terms of opaque objects that only Apple has the authority to change. I think this is a really clever hack that will undoubtedly lead to some serious performance gains in Lion and beyond. It’s hard to imagine specific outcomes that will make Apple regret adopting this strategy. In the worst case scenario, an addressing system of future Macs will not leave any “spare” bits to be exploited, so the runtime will simply revert to its previous behavior.

In Mac OS X 10.6 and earlier, FileVault was a feature that only affected your home directory. In OS X Lion, it applies encryption at a very low-level, encrypting an entire volume of your disk at a time, and keeping it encrypted as you use it.

I was able to enable FileVault for my boot volume with relative ease, using the Security & Privacy preference pane in System Preferences. However, the UI for this is pretty limited, and notably, it only allows you to protect the computer’s startup disk.

The way I have my Mac configured, most of my sensitive data is not on the startup volume, but is instead on a second partition called “Data” where I keep my home directory, media files, etc.  Apple’s Disk Utility allows you to erase and reformat a volume as encrypted from scratch, but what if you want to migrate a volume in-place, the way the system does the boot volume? You’re not completely out of luck.

OS X Lion ships with a low-level technology called “core storage,” which is used to facilitate a wide variety of disk-maintenance functionality, including whole-disk encryption. To get a quick look at what core storage supports, type “diskutil cs” at the Terminal command line. For a more in-depth look, type “man diskutil” and search for the core storage command documentation.

Important: This is the part of the blog article where I warn you to be very careful before proceeding. The diskutil command is capable of doing incredibly destructive things to your disk and to your data, so you should feel confident before doing anything that you have a 100% reliable backup of your data.

To convert an arbitrary volume to Lion’s whole-disk encryption, you use diskutil’s core storage “convert” command, and provide a passphrase. For example, if you have a volume called “Data” attached to your Mac, you would run something like this from the command line:

% diskutil cs convert /Volumes/Data -passphrase [yourPasswordHere]

What this does is kicks off a conversion process similar to what the System Preferences panel does when allowing you to convert your main startup volume to core storage with encryption. At any time during the conversion, you can use the diskutil command again to see status of your volumes, whether they are encrypted, not encrypted, or in-progress while converting.

% diskutil cs list

You’ll see a bunch of information, but search carefully for the named volume (e.g. “Data”) that you just started the conversion process on. You’ll find a line starting with something like:

Size (Converted):

This shows you what the progress in the conversion is. From time to time, check this manually, to see how far along things have progressed.

Caveats

In addition to the major admonition above to backup your data carefully, you should also know that after you have converted a volume, it seems to be in a sort of provisionally encrypted state where it’s still being treated by the running OS as a “native volume” although it’s been converted and is ready to be treated as a “core storage” volume. I have to confess I don’t really understand it 100%, but it seemed like a really good idea to me to restart as soon as possible after the conversion is complete.

But before you restart, bear in mind that there appears to be a bug in the login process that will prevent a user whose home directory is on an encrypted (“locked”) secondary volume from being able to log in. It seems that whatever logic Apple applies to unlock volumes at login time is not applied early enough to allow the actual login to occur. This means that if you converted your secondary volume like I did, and it contains your home directory, you won’t be able to login.

For this reason, make sure that you have a valid account to log in to whose home directory is located on the main startup volume. In my experience, the process of logging in to this main-volume account will prompt the system to ask for the secondary volume’s password in order to unlock it. Once the secondary volume is unlocked, you can log out and log back in to your regular account, with the home directory on the secondary volume.

This bug is pretty annoying. Hopefully this is something that Apple will get fixed soon, and it may be for bugs like this that they haven’t enabled full-disk encryption as a full-fledged user-facing feature of the operating system. In the mean time, if encrypting your data is important to you, I hope these instructions and caveats will serve you well.

Update: Not surprisingly, this topic is covered in some detail in John Siracusa’s Lion review.

I encourage everybody to upgrade to Lion. I’ve been running it for months in pre-release form, and even while the bugs were being ironed out, I found the experience of using it to be (mostly) superior to running 10.6.

If you want a more detailed analysis of Lion’s features, sit down with a tall glass of your favorite beverage, and read John Siracusa’s famously detailed review. If you’re looking for a quicker overview, check out Jason Snell’s Macworld review, or my developer buddy Matt Gemmell’s guest appearance at the Guardian UK.

Supported Systems

We have known for some time that Mac OS X Lion would drop support for a number of Macs. In particular, all Macs that do not support Intel’s 64-bit memory addressing are not qualified to install the OS. But I was curious to know a bit more about how Apple makes this determination when, say, a user is browsing the Lion “product” in the Mac App Store.

As I described in an an earlier post, you can learn a lot about a product in the App Store by inspecting the HTML that makes up the product page, and by manually loading the references resources. In the case of Lion, the “Buy Now” button contains a number of parameters intended to inform the Mac App Store client about whether a sale should be allowed, and what some of the conditions of sale are. In the case of Lion, here is the raw HTML:

<button is-rental="0" dk-id="30" is-pre-order="0" preflight="http://a5.mzstatic.com/us/r1000/
065/Purple/cd/82/29/mzm.tvvarwmu.pfpkg" item-name="OS X Lion" bundle-id="com.apple.InstallAssistant.Lion" version-string="10.7" buyparams="productType=C&amp;price=0&amp;salableAdamId=444303913&amp; pricingParameters=STDRDL" large-icon="http://a4.mzstatic.com/us/r1000/083/Purple/00/00/00/ lion.170x170-75.png" is-install-button="0" is-update="0" check-is-osx-server="http://r.mzstatic.com/static/isOSXServer.pfpkg" is-free-download="0" adam-id="444303913" metrics-leaf="1" metrics-loc="Buy" class="button-area" aria-label="Install, OS X Lion, Free">    <span class="price">Install</span>    <span class="left-cap"></span>    <div class="inner"><span>Install</span></div>    <span class="right-cap"></span>  </button>

If you load the “preflight” URL content from the command line, and unarchive it with the “xar” tool, you get a few files including a file called “Distribution”:

% mkdir TestFolder; cd TestFolder
% curl -O http://a5.mzstatic.com/us/r1000/065/Purple/cd/82/29/mzm.tvvarwmu.pfpkg
% xar -x -f mzm.tvvarwmu.pfpkg
% more Distribution

Inside you will see a number of constant constraints such as hostArchitectures=”x86_64,i386″, but also more nuanced tests that, for example, test the current computer’s motherboard model ID with a fixed list of allowed values. Presumably this will prevent the App Store from allowing (without some hacking) downloading Lion and installing it, for example, on a Dell PC that happens to meet the ostensive hardware requirement.

Perhaps the most heartwarming bit of code in this relatively complex document is a small function call from the start of the test for whether the install should be allowed on this computer:

function isSupportedPlatform(){

        if( isVirtualMachine() ){
                return true;
        }

It has already been announced that Lion 10.7 will finally support virtualization, e.g. with the use of products such as VMWare or Parallels. This install-time test seems to drive home how true that is.