Wow. So the other day, my LaCie d2 Triple-interface drive that I use for backup died. Bad noises (although not the terrible head chunk noise, just a weird clicking), wouldn't mount; the usual story. I figured I'd be sending it back. I opened a case on their website, and they first said they were shipping a replacement power supply (external) just in case. They also included an RMA number in case that didn't work, I could ship 'em the drive.
Now, I would have never guessed that a power supply would have been the problem; I almost just shipped 'em the drive anyway. But the supply arrived today, and on a whim I swapped it out and boom, no ugly noise, the drive mounts fine. I had to A/B test with the new and old power supplies three times to convince myself.
Competent tech support, who knew. Makes me wish I had picked up another LaCie instead of the WD 500GB that I got at Costco in the interim (it was cheap, and I've been wanting redundant backups anyway).
So now I have a time machine drive on the WD, and I'll continue to use the LaCie with Super-Duper to give me a bootable, identical clone (that I'll probably move back and forth between my parent's house and home). Sound paranoid? Never forget that the universe tends towards maximum irony.
I was all excited to use the google provided project for accessing google stuff via Objective C. Except for this tidbit: The Google Data APIs Objective-C Client Library requires Mac OS X 10.4 due to dependencies on NSXMLDocument.
As far as I know, a certain mobile device SDK doesn't support NSXML, just libxml directly. I bet it works on the simulator because the dependencies are there, but I have a feeling that the real device is left out in the cold. Given the heavy use of that API in this code, I wouldn't expect it to be ported to libxml2 anytime soon. Although that would be a useful fork.
When the Segway was in it's pre-announcement stage, it had a lot of hype. It was going to change the world.
Someone is driving through my suburban neighborhood on a Segway right now, and they just delivered some flyers to my doorstep.
Segway: Helping more efficient junkmail leaflet delivery since 2008.
Consider the world a changed place.
For the most part I think applications obeying the "launch fast/quit fast" protocol implied by the lack of background tasks will do just fine. There's plenty you can do.
I can think of one major stumbling block though, and that's tasks that you can't just quit and suspend. Like, say uploading a file. Unlike mail on the phone, where you can send a mail, lock the phone, and hear the satisfying swoosh that lets you know your mail was delivered, if you lock, get a call, or accidentally hit home, good bye file upload. I can see ways to handle it sort of with UI, but noting jumps out as being as good as Mail's solution.
Computers are not perfect. Everyone, even Mac users (arguably the system that spends the most time thinking through ways to make the system run without a lot of administrative overhead), spends some time troubleshooting problems.
John Gruber hits on the relation of this to Apple disallowing background apps on the iPhone.
Imagine a scenario where background apps are allowed on the iPhone this summer. Some typical user buys and installs 10 apps from the App Store. Three of them are background-capable apps, and two of those three are so resource hungry that they have a noticeable drag on battery life. How are typical users ... supposed to know which apps are causing the problem? How are they even going to know which apps do continue to run in the background? They won’t. A likely reaction would simply be to regret ever having junked up their iPhone with any third-party apps at all.
I'd go even further. Us nerds are all debuggers at heart, and I personally still don't want to spend too much time fixing my phone. "Oh sorry Joe, I missed your call 'cause I had to reinstall iPhone OS on my phone." The iPhone's claim to fame is it's usability not it's features. If the administrative overhead of owning one (meaning the average user has to spend any time worrying about which apps hurt performance and which don't) starts to cut into it's usage, the usability advantage evaporates.
People (and by people I mean average users) are willing to accept (or more likely have been conditioned to accept) administrative overhead on their computers. OS reinstalls, re-installing applications, fixing registry settings, calling support, etc.. They are not so tolerant of their phones. Phones out there may have terrible, terrible user interfaces, but no one spends any time worrying about administering them. If Apple wants to make the iPhone as ubiquitous as the iPod (which I believe they do), they'll need to keep that overhead low.
Apple would be lucky if a user that junked up their phone and caused system/performance problems blamed the applications they installed. More likely the thoughts on people (meaning regular, non-nerd people) would be "this thing crashes all the time," or "man battery life sucks." And they either return it, or leave the platform when the phone wears out, thinking to themselves "that's no better than any other phone."
I was given hope by the docs that said that "not all functionality will work on PPC' macs.
Installing on a Mac gets you XCode 3.1 beta, but no iPhone SDK at all (docs, sample code, projects, etc.). You do get a bit of the cool iPhone Dashcode features for building iPhone web apps, but that's it.
Guess I'll be writing iPhone software on Cyndie's MacBook.
Update: It can be made to work. When/if I get my cert will I have the stones to try and upload to my phone from a non-supported environment? That seems...unlikely, but at the basics can be done via simulator.
John Gruber from Daringfireball asksif members of the developer's program can run other user's apps.
It's a good question, but I think there's an implication in there that's not true right off the bat. I don't think the iPhone will run unsigned apps, period. In the "iPhone OS Programming Guide" it has instructions for obtaining and using a developer certificate, complete with CSR generation and sending that CSR to apple for signing. That gives you a cert that you must build with in Xcode to code-sign your binary.
So it seems like developers should be able exchange source code and test their apps if you build it locally. Can you run other developer's signed apps? Seems like as long as they are signed that should be okay.
But, the kicker on that link is the whole "designate a device for development" and "provisioning profile," which apparently specifies the actions you can perform on that device, "such as whether or not you can make calls." You have to get the profile from Apple, so presumably it's crypto-signed somehow with your cert.
So perhaps the process of designating a device for development then -potentially- (depending on your approval level from Apple) could disable the normal, ATT network access functions (phone and data). That could be a major downer if there's no way to use an app in real world situations without a dedicated developer device.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: