RIM doesn’t really have any lock-in other than user habits. The BlackBerry gimmick is that it works with the email system your company bought from Microsoft.

Which is not really true. I don't know what % of RIM's revenues come from their server products, but I do know the Blackberry -> Exchange integration is more complicated that just the user buying their own phone and hooking it up themselves.

The blackberry solution offers an "internet free" solution. Your exchange servers don't need to talk to the internet, they live buried in your firewall, passing messages to RIM's network, that sends them via the proper mobile carrier. That might not be the perfect description, but point is, there's network connections, server products, and support costs. I don't think the iPhone will be a drop-in replacement in large companies. Enterprises have built-in lock in. With the blackberry solution, the IT department is in charge of provisioning all the phones, and if I don't get the blessed, provisioned phone from them I can't even have a blackberry.

It remains to be seen exactly what the iPhone's solution is going to take to deploy. Or whether it will without a server be able to offer all the ticky-tacky big-brother things that enterprises love (disabling the web browser, or the camera, or the iPod, keeping logs on all calls, etc.). We'll know more once it's released.

So the way we want to configure things is such that the RG is the router; it will do all the DHCP stuff; get its IP from ATT, and then act as an internal DHCP server so things on your home network get IP addresses. Luckily, this is the immutable default configuration. :-) We'll probably also want to disable it's wireless network, just to avoid interference with your existing network, or your neighbors, etc. since we we prefer the Airport's wireless network.

For the Airport, we'll need to configure it in bridge mode. This disables its DHCP server, router and firewall. Now it's essentially just a dumb switch; it's just passing traffic between it's ethernet ports and the wireless network. So when a computer connects to the airport network, it will ask for an IP via DCHP. The airport will no longer answer that request from it's own pool, but instead pass it onto it's ethernet, where it will get to the ATT provided gateway. Then the gateway will give the wireless computer it's IP address and route traffic to it. We'll also want to set the Airport to get its IP via DHCP from the ATT gateway as well, so it can have an IP for printing or disk use, etc..

A word of caution before we begin, you will likely lose connectivity briefly during this procedure, so be prepared. Don't be 99% way through a 20GB download when you do this.

So let's get started. First the airport. Run "/Applications/Airport/Airport Utility". You should a screen showing all airports (I have an express and extreme). Select your desired Airport, and you should see this:

Click on manual setup at the bottom (circled in the above shot, then click "Internet" up at the top. You should see this:

On "configure IPv4", set it to "Using DHCP". This will give your airport an IP you can connect to. Then under connection sharing (highlighted), choose "Off (Bridge Mode)". Now click update. If I remember, I think it reboots, or does something that takes a few seconds. You'll probably lose your connection to it initially.

So now you might be a bit stuck, you may/may not be a bit stuck, since your computer probably has an IP that your airport gave you, but now you're talking straight to the RG for routing. No worries, you can either reboot your computer, or follow Apple's procedure for getting a new IP. Skip to the "Solution->Mac OS X instructions -> 1. Force reconfiguration of IP Settings" section. Or just reboot. Any other network hardware that got it's IP from the airport will need to be rebooted as well.

Now, any computers plugged into the Airport extreme ethernet ports or wireless networks should be getting their IP from the RG and using it properly. Before you started, if you looked at your RG configuration screen in the Home Network section, you would have just seen the airport extreme. Now you should see all your devices showing up.

You can get to this screen by trying this configuration URL (which is pointing at your router), or manually visiting http://192.168.1.254/ in your browser.

Now the final step if you don't want to use the RG's wireless networking at all, is to disable it. From the screen above, click Home Network and you should go here:

Notice the circled button on the right; "Disable" next to the wireless network. Click that. You'll get prompted for confirmation, and the device password. Once done, the button changes to "Enable", which you can click to re-enable the wireless should you ever choose to.

That's it; with the Apple acting in bridge mode, the RG is in charge. Seems to work fine for me so far, no complaints. Note you can still have the Airport participate in a WDS network even in bridge mode; I'm using it with my Airport Express that way.

Update 4:00PM PST Fixed broken image

This could mean big, big things for Apple if it's true. I think this strategy makes the 10 million phones by the end of the year goal look like a drop in the bucket. Apple's not in the habit of selling anything at a loss though, but that's okay here since it's ATT that would pick up the tab.

The question is, why would they? And why wouldn't they at launch? Was it so calculated that ATT knew demand would drive 5-6 million phone sales that they could rake in bucks for, in return for taking the risk on the iPhone, and then after a year and version 2.0 they'd announce the subsidy, to go deeper into the market?

Brilliant strategy if true. For one it's obvious; it's just pricing things like the market will bear. Second, this makes the iPhone like an iPod; it puts it into kids' price ranges. Can you say "ubiquitous"? I knew you could.

So at the expense of some cash, ATT gets to own the market for what could be an iPhone-like domination of the phone market for the next 5-10 years. Bold.

Imagine a video camera, shooting 30 frames per second. You walk into the frame, and your actions are very accurately recorded. Now slow down the camera to 1 frame every 60 seconds. The camera takes a picture, then you run through the frame in 2 seconds. 60 seconds later, it takes a picture and it's like you were never there, even though you were. You were faster than the sampling rate of the camera, so it didn't capture you at all. It -can't- if you continue to move that fast. You have to slow down, or speed up the camera. That's why the hard limit.

Now, you if you vary your speed, you can play with the frequency of how often you show up. So let's say the camera it still running at 1 frame a minute, and your pacing back and forth, spending 5 seconds in the frame out of every 45 seconds. So your real rate of passing the camera is once every 45 seconds. So the camera starts, as do you, and your first pass comes at 45 seconds and you're gone. The camera fires, and there's no you. You pass by again at 1m:30s...then 2m:15s...then at 3m. The camera is firing then because it fires at 0s, 1m, 2m, etc...So you're caught on film. You're next pass is 3m:45s, then 4m:30s, then 5m:15s, and 6m, and you're caught on film again at the 6 minute mark.

So you're real rate of passing by is every 45 seconds. But according to the film, you're only passing by every 3 minutes. That's aliasing. Because the sampling rate isn't fast enough to capture your frequency, you are "aliasing" to a different frequency. From 45s to 3m. You can imagine when capturing music with samples that this would do baaaad things to the soundwaves, which is why digital audio systems filter out high-frequency sounds somewhere around the Nyquist limit, so they don't alias to the wrong frequencies and destroy everything.

This explanation isn't perfect of course, but I have found it useful to explain the concept.

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.

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.

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.

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.

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."

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.

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.

Not that he says this is a guaranteed failure, but I think the comparison is off. While there is still an adoption problem with getting people to install the software, there's a much bigger value proposition for the customer.

Joel's claim that "Some things are still the same: typing URLs is not hard" is biggest misstep Yes, if you're sitting near your computer, it makes zero sense to pick up your cue cat or phone and scan an interesting ad because it's easier to type the URL. Always.

But have you ever typed a url into 99% of the world's mobile phones? Sort of a time consuming, incredibly painful, makes-me-want-to-slash-my-wrists sort of experience. Being able to just point my phone at an ad (or an article, or lots of other possibilities) and grab the url and visit the page is by itself tremendously more valuable than the cue cat ever was. Especially since Google can give it away for free, and the advertisers themselves don't have to worry about it.

As more mobile apps pop up, that will actually do things like process payments, the potential grows even further. This could become, "scan this bar-code to order tickets for this movie." Or stores could have the barcode on their signs, and you scan it to visit their website. Or info about a construction project. Or a flyer on a signpost for an interesting band could take you to their website, and you could see if there were tickets for tonight's show available. Or buy their CD and have it shipped to you.

Could be very cool, and it's simpler than trying to rig up wireless, or rfid, or bluetooth, or whatever other mobile communication schemes are out there.

This idea doesn't deserve to be lumped in the with CueCat.