Shebanator

iPhones and Third Party Applications

•19Apr07 • Comments Off

A while back I wrote about the problem I had with the iPhone being closed to 3rd party developers. Blackfriars Marketing has an interesting theory on why the iPhone won’t support 3rd party applications, at least at launch. They claim that the problem is battery life – naively written applications will be too big a drain on the system. I’m not sure whether to be happy or sad if this theory turns out to be true. It certainly isn’t a vote of confidence in 3rd party developers if true, but at least it means the situation may get fixed.

The problem is that the iPhone is a blend of a phone and a full-fledged Mac OS X computer. Most developers don’t give a whit about how much power their software consumes. After all, the processor is running anyway; why not use it? The result: most developers are happy to burn processor cycles to get their jobs done, since they view them as having no cost. You can see that in Dashboard widgets available for the Mac today that poll endlessly for everything from the weather to updates of YouTube and Facebook pages. Yes, they are useful, but they both burn processor cycles and require an open Internet connection to work.

But unlike full-fledged Macs, phones don’t really have a sleep mode. As long as they are on, they need to be able to do routine housekeeping matters like beaconing, cell handoffs, and listening for incoming calls. So any software that runs on the iPhone has to do what it needs to as quickly as possible, and then retreat into a low-power-consumption mode. Think of it like the type of cooperative multi-tasking that was done in the Mac OS before version X, and you have the idea. This is made even more important by the inclusion of power-hungry WiFi networking in the iPhone. No matter how clever you are, keeping up a 100 Mbit/sec WiFi link is going to drain a phone battery in hours, not days, unless there’s careful management of its use.

Now Apple can enforce this type of behavior easily in its own user-driven programs like Safari and Mail. Cooperative, well-power-managed software should yield an iPhone battery life similar to other smart phones on the market. But without control over what the software does and how it does it, all bets on battery life would be off. With arbitrary software, the iPhone could easily get a reputation as a power-hungry beast that just doesn’t have enough battery power to succeed. After all, John Dvorak has already claimed as much in a podcast earlier this month; Apple has too much invested in the iPhone and its success to allow such unintended consequences to spoil the launch of this flagship product.

Posted in Openness
Tags: Apple

More on Twitter, Rails, and Scaling

•19Apr07 • 2 Comments

Just a brief update to point to some more good discussion on the issues with scaling Twitter to handle its load better, as discussed in my earlier post on Friction(less) Rails. The first thing I wanted to point out is that a lot of people have called Twitter’s purported load into question. The original source for the 11,000 requests/second number was DHH’s original post as far as I can tell. That’s a heck of a lot of load, and as others have pointed out, its a nice problem to have. Jens Alfke of Apple has written a nice post describing the problem and ways to handle it that do not involve databases. Its an interesting read, and the comments are worth a look as well.

Another article worth reading is by Peter Bell. In it, he reflects on the tone of the conversation to date and thinks about the appropriateness of Rails for the applications it is being used for. I don’t actually agree with him but its an interesting point of view:

Simple apps with huge traffic requirements needs different engineering choices that complex enterprise apps that may have lower loads but higher complexities and maintenance burdens. When I look at an app like twitter (which is when it comes down to it, a submit form, a list display and an API along with some really interesting scaling challenges) I’m not sure Ruby or Rails would be the ideal tools. I’m not sure what language has the very best support for the highest and most robust levels of performance and scalability, but I’m guessing whatever it is would be the perfect choice – even if it meant it took you a week instead of a day to code the form, the API and the list (I know it is a little more than that, but I think we all know it doesn’t need to be TOO much more than that – it isn’t exactly an insurance quoting app or something).

As with anything cool and new (remember when Java was the *it* language?!) Ruby and Rails are being widely misused. I am not convinced that all of the Web 2.0 start ups selecting Ruby have picked the bet tool – they’ve picked the coolest one. However, cool tools bring the smartest programmers so it still may be a smart decision – even if the language and framework has problems, at least choosing them means you can more easily get the most innovative programmers to work on your problems, and just like in Venture Capital where a good team trumps a good idea, in programming a good coder trumps a good language.

Once again, I want to commend people for turning the conversation in a more positive direction. Its been a great read.

Posted in Dynamic Languages
Tags: Scalability

Hello new world!

•17Apr07 • 2 Comments

Welcome to my new blog hosted on WordPress.com… The transition went pretty smoothly – everyone’s comments should be here, and the new blog has some nifty features.

Still to come: updating the blog look and feel to something that is more “me”. Right now I’m using a standard WordPress template. Not sure when I’ll get the time to do this work, though, so bear with me.

Posted in Administrative

Joyent fires their Slingshot at me…

•17Apr07 • 2 Comments

So the folks over at Joyent have announced that Slingshot will be released under a dual licensing model: GPL and a commercial paid license. The surprising thing about their announcement is that they went out of their way to call me out over the licensing issues:

When we announced Slingshot, Andrew Shebanow at Adobe posted about Apollo, Competition, and Openness.

Next is SlingShot from Joyent and Magnetk. I love Ruby on Rails, so this product is very interesting to me. They basically have taken the all-in-one desktop server approach of Locomotive and turned it into an application runtime. Its a great idea, and one that opens up a lot more power to the local application than Apollo. Downsides are a lot of potential security issues (no sandbox?), the fact that the entire source of your application is distributed to the world whether you like it or not, and the fact that it is limited to Ruby on Rails applications. More disturbing, though, is that it sounds like Joyent will be charging a royalty for distributing applications based on their runtime unless you are a customer for their hosting service. Maybe they just plan on charging a flat fee for the SDK. Either way, this is much less open than the Apollo model where the SDK and runtime are both free of charge.

We are charging a license fee to people using Slingshot for commercial purposes. I believe Adobe does this for content producing tools, too. Joyent would like to invite Adobe to open source Apollo and the ecosystem around it (Flex, Flash). Don’t just make it free, free it.

And by way of response. Sandbox? What’s the sandbox Adobe Photoshop runs in? Entire source? More on that, later. Limited to Rails? Yes. Focus.

I have to admit that I’m a little mystified by their hostility. I thought I was pretty evenhanded and positive about their product. David Young, the CEO of Joyent did respond to the post accusing me of FUD, we had some back and forth on it, and I thought it was resolved. Heck, when I posted a while later about DHH’s post, David commented again to thank me. Why the change in attitude now? Beats me.

Anyhow, I tried to respond to the post on Joyent’s blog, but my post disappeared shortly after I submitted it. I thought it might have been a glitch so I posted the comment again. Again it disappeared. This might be a server problem on their end, but it also might be outright censorship, and it feels more like the latter to me since other people’s comments show up. In any event, the net has a way of routing around that sort of thing. Here’s my comment as I wrote it in their blog, unedited. I think my comments were critical but not inflammatory so I’m again at a loss to explain why they’d delete what I said, if that is in fact what happened. Are they really that incapable of dealing with criticism? I hope not.

Wow, holding a grudge, are we?

I addressed your sandbox comment on my original post, but you clearly don’t appreciate the trust model differences between small apps that are downloaded from the internet and large-scale traditional desktop applications. Or maybe you do appreciate the difference but are only targeting the latter. Or you just don’t care. I personally think you are making a big mistake ignoring the security issue but its certainly your right to do so.

I’m happy you’re releasing source under GPL. Duel licensing is an interesting choice, and I look forward to seeing how it works out for you business-wise. There is no question that monetizing a runtime framework is a tricky business.

Can’t really speak to the whole “free vs. free” thing. I’d certainly welcome such a thing but it isn’t something I have any control over. I do want to point out that even though Apollo isn’t fully open source, pieces of it are, like WebKit and Tamarin. That obviously won’t be enough to satisfy everyone, but we expect great things.

Bottom line is I wish you all the success in the world, and I hope you get over your hard feelings.

Posted in Rich Internet Applications