So, I spent first five months of this year on a grueling, panic-driven-development project on Mac OS X. As my longest single Mac engagement, I’m afraid this can’t help but wear down my enthusiasm for the platform.
It doesn’t help that what I was working on was well into the edge-case realm: our stuff needed to silently update itself in the background, which gets into the management of daemons, starting and stopping them at will. This isn’t bad in theory, but getting it to work consistently across 10.4 through 10.6 is grueling. An always-on daemon sets a RunAtLoad property in its /Library/LaunchDaemons plist in order to come up immediately and stay up. Uninstalling and/or replacing such a daemon is tricky, as launchd keeps track of what daemons it has loaded and thinks are still running. The worst thing to do is to just kill the process… instead, you need to use launchctl to load or unload the daemon as needed. And, as a root-owned process, you need to perform this launchctl as root. Oh, and you’d better not delete the plist before you unload the daemon, since launchctl takes the path to the plist, so doing things in the wrong order can leave you with rogue daemons you can’t unload. And if you don’t unload the old daemon, a new launchctl load does nothing, as launchd thinks the original daemon is still running.
Now throw in some user agents. These are like daemons, except that they run for each user at login, and are owned by the user. So to uninstall or update, you need to launchctl unload as each user. Which is possible with sudo -u username in a shell script, unless you’re on 10.4 and you get the user list from /usr/bin/users, as the 10.4 version truncates user names to 8 characters, breaking the sudo.
Oh, and who’s doing these unloads? A script in an .mpkg installer. Which is a whole ‘nother bundle of fun, given how fabulously broken is Package Maker, Apple’s utility for creating .pkg and .mpkg installers. Package Maker crashes frequently, doesn’t consistently persist (especially when source-controlled) settings for file ownership, and creates broken installers when invoked by the command-line utility /usr/bin/packagemaker, making it utterly unsuitable for use in Makefiles or other automated build processes. IMHO, Package Maker is as big an ass-muffin as I’ve ever seen come out of Cupertino, at least since that quickly-pulled iTunes 2 release that reformatted the host drive.
Working with all these taped-together technologies — desperately trying shell script voodoo in an .mpkg post-install step to make things right — eventually wore me out. And granted, this is an edge case: most Mac apps can be distributed as app bundles without installers, and most installers can require the user to restart if it’s making radical changes like installing or updating daemons (not an option for me because the installer runs in the background, called by another daemon). Still, it’s enough to make you long for the “curated”, locked-down walled garden of the App Store, whose distribution and update system really does work remarkably well.
With the Mac all but expelled from this week’s WWDC, some pundits are happy to declare the death of the Mac. That’s a silly overstatement, but it is sensible to accept that after a decade of improvement and marketing, the Mac is a mature platform, likely secure at its 10%-or-so market share. What else would we want Apple to do with the Mac? I’d like to see things fixed and cleaned up, dubious legacies cleared out and things set right. And Apple has done that. Problem is, the result is not Mac OS X 10.7, it’s iOS 4.
But then again, if the iPad replaces the laptop for some number of users, this is a brilliant way to grow Apple’s share — nibbling away at traditional computers cannibalizes the Mac somewhat, but chows away mostly at Windows.
Suffice to say I’m very happy to be re-orienting myself to iPhone/iPad/iPod-touch development. It’s got the feel of a somewhat clean start, based on proven technology, but not burdened by old breakage. Now I’ve got some catching up to do to adapt to all the changes in iOS 4.
In addition to other arbitrary changes on my system (ruining file-app association, losing the ability to stay asleep), Snow Leopard changed the default gamma, which made the white-on-black text on this blog significantly less readable at its default (small) point size. So I’ve increased the body font size slightly.
Snow Leopard also adds a new monospaced font, Menlo, which I’ve swapped in as the default font for code tags, ahead of Panic Sans, DejaVu Sans, Inconsolata, and a few other programmer favorites. If you’re getting Courier (or, heaven forbid, Courier New), you’re either not a programmer, not on a Mac, or both. FWIW, if you’re on a Mac, you should be getting Lucida Sans as the body font.
And if you read the blog with RSS, then none of this applies to you. Thanks for playing.
One-time self-described “World’s Greatest Compressionist” Ben Waggoner posts a pointed question to the quicktime-api list:
http://www.apple.com/macosx/what-is-macosx/quicktime.html
What I’d like to know is if QuickTime X is going to be available for Windows and older versions of Mac OS X.
It’s an important issue, because despite iTunes’ insistence on installing QuickTime on Windows, the future of that product seems completely unknown. For years, every question I’ve seen about the future of QuickTime on Windows has been met with absolute silence from Apple. Yeah, I know, “Apple does not comment on unannounced products,” and all… Still, Apple has left this technology in limbo for a remarkably long time. I recall asking ADC reps about QuickTime for Windows back at Leopard Tech Day Atlanta in 2006, as I was considering calling it from Java with JNI, and (as previously noted), I got no reply at all. And every other public question I’ve seen about the future of QuickTime on Windows has gone similarly unanswered, for years.
Smell that? That’s the scent of Abandoned Code Rot. We got that from QuickTime for Java for a few years before they managed to finally deprecate it (though they apparently haven’t gotten the message out).
It wouldn’t be too surprising to see QT for Windows fall by the wayside… Apple probably cares more about the popularity of its favorite formats and codecs (AAC and H.264) than of the QuickTime APIs and QuickTime’s interactive features like Wired Sprites that have been clearly and unequivocally beaten by Flash.
But if that’s true of Windows, is it also true on the Mac? QuickTime developers are right to be a little worried. The old C-based QuickTime API remains a 32-bit only option, intended to be replaced by the Objective-C QTKit. But in the four years since its introduction in Tiger, QTKit has only taken on part of the capabilities of the old QuickTime API. With Leopard, you could finally do capture and some significant editing (e.g., inserting segments at the movie or track levels), but raw sample level data was unavailable for any track type other than video, and some of the more interesting track types (like effects and especially tweens, useful for fading an audio track’s volume between specific times) are effectively useless in QTKit.
With Snow Leopard, the big news isn’t a more capable QTKit API, it’s QuickTime X. And as Apple’s QuickTime X page points out, QTX is all about a highly-optimized playback path (using decode hardware if available) and polished presentation. Great news if you’re playing 1080p movies on your computer or living room PC, not so much if you want to edit them: if you want to edit anything, you’re back in the old 32-bit QuickTime (and the code is probably still written in C against the old APIs, given QTKit’s numerous limitations). You don’t see a 64-bit Final Cut Pro, now do you? (BTW, here’s a nice blog on that topic.)
When you all install Snow Leopard tomorrow and run the QTX-based QuickTime Player, you’ll immediately understand why the $30 QuickTime Pro (which bought you editing and exporting from the Player app and the plug-in) is gone. Follow up in the comments tomorrow (after the NDA drops) and we’ll discuss further.
If I were starting a major new multimedia project that wasn’t solely playback-based — imagine, say, a podcast studio that would combine the editing, exporting, and publishing tasks that you might currently perform with Garage Band, iTunes, and FTP — I would be very confused as to which technology to adopt. QuickTime’s cross-platform story seems to be finished (QTJ deprecated, QTW rotting away), and everything we hear on the Mac side is about playback. Would it be safer to assume that QuickTime doesn’t have a future as a media creation framework, and drop down to the engine level (Core Audio and Core Video)? And if not QuickTime… then what?
Oh, and as for the first question from the quicktime-api thread:
… How about Apple throwing us a bone as to what QuickTime X will offer those of us that use QT and QTSS?
From what I can tell, Apple has all but ditched QTSS in favor of HTTP Live Streaming, supported by QuickTime X and iPhone 3.0.
I’ve brought this up before, but now that it’s official, I just want this noted for the record:
In October 2005, I said that it might make sense to wait for the then-announced Intel transition, rather than buy PowerPC hardware. Check out the comments — the Mac zealots were seriously pissed at me for suggesting that buying into PowerPC was a dead-end. It was called “ridiculous advice”, “dumb advice”, and “flat wrong”.
In part, my blog was based on my estimate of when Apple would ditch PPC support:
So, I suspect that Leopard is the end of the line for PowerPC, and that 10.6 will be Intel-only. That means you are buying into a four-year dead-end on PowerPC.
This was based on a rough calculation that 10.6 would come out in 2010. Yet we know from yesterday’s keynote that it will actually arrive in September, 2009. And we also know from yesterday’s keynote, confirmed on the Snow Leopard tech specs page, that it is Intel-only.
Yeah, you’re welcome.
I’m leaving for WWDC on Sunday afternoon, getting in Sunday night which means I get my pass Monday morning and therefore can’t be in line early enough to get in the main room and will instead be in the overflow. Don’t mind actually; my time is worth something, and waiting more than six hours in line at Moscone West is just not worth it. For me, the appeal of WWDC is the knowledge, not the spectacle.
I’m not in the mood for predictions (I didn’t do well last year, predicting the deprecation of Carbon), though there are little things that are obvious: we’ll get major new beta builds of both iPhone OS 3.0 and Snow Leopard, hopefully at least one of which will be provided on DVD so we don’t paralyze the wifi with a thousand simultaneous downloads. Last year, working through an iPhone OS build that had botched app-signing, I spent four hours Tuesday morning with a group of developers trying to download a fixed build, and when I was the first to get it, I burned a DVD and shared via Bonjour so the rest of the group could get it.
I don’t think there will be an iPhone OS-based tablet for two reasons. First: tablets, thusfar, have sucked, and the case for them hasn’t been made. Secondly, a tablet would have different dimensions than an iPhone, and for third party apps to run on it, I would expect the iPhone SDK to be pushing us towards resolution independence. But instead, the opposite seems to be happening: we were told two years ago to start getting Leopard apps ready for resolution-independence, and that at some point Apple would “flip the switch” and make Leopard resolution-independent in the field. Yet I don’t think that ever happened, and the iPhone SDK continues to dictate explicit pixel sizes for things like icons and badges, just the opposite of the guidance I’d expect if we were being set up for running under varying screen dimensions.
Similarly, the SDK makes an argument against the rumor of video recording with editing. I originally thought the idea of QTKit as an API was a migration strategy on the Mac to get developers off the legacy QuickTime code (a 20-year-old code base!) and on to something modern: while QTKit largely calls into the old QuickTime code, if the underlying implementation changed to a new code base, developers would be none the wiser, and you could retire the old code (this might be what QuickTime X is doing, but Apple continues to call it “the streamlined path for efficient playback of modern standards-based media”, and playback represents only a tiny fraction of QuickTime/QTKit functionality). Now, what if QTKit weren’t just hiding a migration of underlying code, but migration of platforms: if you were going to support video editing on the iPhone, it would make sense to at least try to reuse the work that’s already been done on the desktop (as they’ve done with Core Audio, for example). But arguing against this hypothesis is the existence of the iPhone’s AVFramework, a high-level framework for the simplest of audio tasks, like playing a file. It doesn’t exist on the desktop, because QTKit makes it unnecessary: to play an MP3, just open it as a QTMovie and call play. So the fact that there still is an iPhone-only AVFramework makes me think that QTKit is not coming to the iPhone anytime soon, which in turn argues against video editing.
Of course, I’ve been wrong before. Like, last year.
As for WWDC wishes? I’d actually like to see AppleTV get some love. With the explosion of Flash-based video streaming sites, AppleTV is starting to seem irrelevant when it can’t play video from Hulu, Crunchyroll, or any of the network sites. For AppleTV to get relevant again, it would presumably have to either get Safari and Flash into the box (and thereby cave on the consistent user experience), or Apple would have to make deals with the major content providers for them to make their stuff available to AppleTV (similar to the way the iPhone offers a non-Flash YouTube). But how many providers would they have to work with? And would this cut too deeply into iTunes if the same box offers you a streaming show with commercials that you’d otherwise have to pay for? (counter-argument: doesn’t seem to hurt iTunes on the desktop.) At some point, I’d like to move into something like an AppleTV, but the streaming anime I want to watch is on a bunch of websites that it doesn’t support; more likely that I’d use the Mac Mini as a super-AppleTV, even though its output options don’t agree with the analog-only inputs on my HDTV.
A small thing I’m hoping for is a genuine D-pad accessory for the iPhone. Touch games are great, but we can see from the sales of titles like Ms Pac Man and Galaga that old-school joystick games are still desirable. The touch screen is awful for these, because you don’t have a tactile sense of whether your thumb is on the correct button. I’m hoping for a control that wraps around the iPhone, putting D-pad on one side, and a set of buttons on the other, making it a de-facto PSP (hopefully, software would support flipping for lefties, like the old Atari Lynx did). The key for this would be that the hardware manufacturer would set a standard for developers to use the External Accessory API to determine if the D-pad is present and poll the button status. If we had 10 different D-pad accessories that worked differently, there’d be no software support. We really need one strong hardware maker (Pelican, Belkin, whoever) to set a standard and open it up to the developer community. Not counting on this happening, but there’s no way we’re getting Street Fighter or Soul Calibur on the iPhone until it does.
One more wish: I hope putting out the session videos doesn’t take four months again. That’s too long to wait for needed information from sessions you missed due to schedule conflicts. Hell, would it be so wrong to just get the slides out right away?
About 10 minutes into Java Posse 241, an unconference session on design, Joe Nuxoll almost pulls the usual “developers talking design” chat into a breathtakingly new perspective. Really close. Picking up on an anecdote about 37signals’ creation of Rails as a tool for what they wanted to do, he points out the idea of going back to first principles:
- What do I want to accomplish?
- What can I do that will accomplish that?
- How do I do that?
He points out that not everything has to be a webapp or a library; that there could be a human process that’s more practical (cheaper, effective, etc.) than building something electronic.
And then the conversation goes another direction. But this so reminded me of Scott McCloud’s exceptional metaphor and discussion of “The Six Steps” of the creative process, in Understanding Comics. McCloud presents a linear progression of choices and concerns:
- Idea/purpose – What am I trying to accomplish?
- Form – What form will my effort take (a comic book, a website, etc.)
- Idiom/genre – How do I address the recipient (fiction vs. nonfiction, online community vs. news site). McCloud says this is “the ‘school’ of art, the vocabulary of styles or gestuers or subject matter.”
- Structure – How the work is arranged and composed, “what to include, what to leave out” (the latter being a far more important choice than is often realized).
- Craft – The actual work of getting the thing done: problem solving, use of skills, etc.
- Surface – The immediately-perceivable traits, like polish or production values.
What’s perhaps most breathtaking the first time you read Understanding Comics is McCloud’s narrative which portrays the reality that almost nobody starts with step 1 and proceeds to step 6. In fact, it’s far more common to go backwards: to see just the surface gloss of something and try to mimic that, with no understanding at all of the decisions that inform the rest of the work, and how they depend on each other.
In our realm, this pathology is highly obvious. If McCloud’s version is a kid tracing Wolverine onto lined notebook paper and declaring “I can draw as well as a professional!”, then surely our equivalent is the UI “skin”, like the hackery that can make a Windows or Linux desktop look like Mac OS X, but can’t change the fact that everything below the surface is built up with the respective ideas of those operating systems.
This is why I’m convinced Linux can never succeed as a desktop OS. When I used GNOME as my desktop for a year back in 2001, I commonly complained that the desktop gave me at least a dozen places to set my visual theme, but setting the damned clock still required me to jump into xterm and do sudo date -s ... I haven’t used it since then, but I wonder if they’ve even gotten inter-application copy-and-paste working (to say nothing of drag-and-drop). McCloud’s narrative shows genuine artists eventually working all the way back to step 1 or 2, asking “why am I doing this”, and proceeding forward, making informed and purposeful decisions about idiom, structure, and craft. It’s hard to imagine the Linux community having the wherewithal and discipline to see through such a process, when they’ve proven themselves willing to fork their code at the drop of a hat (or, more accurately, the outbreak of a Kirk-versus-Picard flamewar). The result is something that’s so baroque and self-contradictory it isn’t even necessarily ideal for hackers, and there’s little hope of this community ever deciding to build something their moms can use.
A lot of projects make bad choices of “form”, and doom themselves from the start. In the 90′s, there seemed to be people who believed that every activity worth undertaking should be done in the form of a startup company. As it turned out, fairly few endeavors are well-suited to that approach.
Today, we see people falling over themselves to make everything into an iPhone app, even when it’s not appropriate. If most of the value of your project comes from data provided via servers you own or operate, it’s likely that a webapp is more appropriate than a genuine iPhone app. Clever use of iPhone CSS can produce webapps that behave much like native apps (the Facebook webapp is still as good as its App Store equivalent), can be updated for all users at any time, and can be adapted to other devices without starting over at square one (compare to the challenge of rewriting your iPhone app for Android, Blackberry, Windows Mobile, etc.).
If anything, many of the great iPhone apps are heralding a resurgence of the “productivity app”, which Broderbund founder Doug Carlston defined to Tim O’Reilly as “any application where the user’s own data matters more to him than the data we provide.” Any iPhone app worth writing is going to involve some significant user data, whether that’s classic user data like their mail, their files, audio they’ve recorded… but also data as simple as where the user is when they run the app. After all, the hundreds of thousands of records in the the restaurant-finder app’s database is useless to me; what matters is finding what I like that’s close to where I am. In other words, the data has no value until it gets those crucial inputs: where I am and what I want to eat.
Now here’s an interesting mental exercise: where would what we consider to be “design” fall in McCloud’s six steps? At first, I made a cursory decision that it was just part of step 5 (craft), as it was part of the doing of the work. That’s clearly wrong, as what we think of as design (and I’m mentally considering varying creative exercises I understand, like book writing, screenwriting, TV production, podcasting, software development, etc.) clearly encompasses the step 4 (structure) decisions of how to arrange the content. And it probably touches on step 6 too: deciding whether to use the brushed metal or plain UI look, whether to shoot in SD, HD, or on film, is a design decision as well. But would we consider step 3 (genre/idiom) to be part of design? I think not. I think that’s a decision that precedes design, one that informs just what it is we’re going to be designing (a educational game versus an electronic series of lessons, historical fiction versus documentary, etc.).
Still, I think it’s important not to make too early, too easy assumptions about the major decisions at the front of the process. “Why am I doing this” is the most important question to ask yourself: it shouldn’t be skipped.
