a life of coding

Thursday, January 28, 2010

Skirt the AppStore: Run Unsigned Code on a Stock iPhone / iPad

Another iPhone OS product, another flame-war over Apple's "iron fisted control". I think the whole argument is pretty silly, and to hammer it home I gave this post a title that's sure to anger lots of people. Why? Because what I'm about to say is (a) obvious, (b) correct, and (c) still not what people want to hear.

You can run arbitrary code on an unmodified iPhone, and the same will be true of the iPad. You will still have certain restrictions (only one app at a time, no access to the data in other apps, and limited access to hardware), but rarely do people complain about those. What people do say is that "Apple will stop me from doing X, because X interferes with their business model, or angers the carriers." Examples are Skype over 3G, Google Voice... really, there aren't that may reasonable apps that have been turned down on the AppStore, but as I said, this is a flame-war and "reasonable" isn't part of the vocabulary.

You can run whatever your little heart desires on your iPhone/iPad, and it only costs you $99 more. This product "upgrade" is called the Developer Program, and has been available for quite some time. After paying the fee, Apple lets you download a piece of software that lets you run almost anything that you like (I already listed the restrictions) on your iPhone. Done!

Whats truly amazing is that this is always how desktop development has always been done, except on Linux and Mac OS X. Pay your money, get your compiler, write your software, run your software. The Linux and Mac OS X crowd is up in arms because they have had GCC for at least 9 years, and $99 seems like a lot compared to free. Where things differ is what happens after you have written a piece of software that you like and runs correctly. Traditionally, you make the binary available and people can click it and have it run (insecurely) on their computer. With the iPhone OS, you send it to Apple, they make sure that it fits some minimum criteria, and now you can require people to pay you to use this software. The end user even gets a convenient update mechanism, and a way to re-acquire your application without re-paying should it be deleted.

Want to be a revolutionary? Here's some advice: stop complaining, join the developer program, and make something people want.

Thursday, January 21, 2010

The Most Amazing Error Condition

I stumbled on a dumbfounding message today. It said: "The application Preview can't be opened -10810." I saw another one later that said: "The application TextEdit can't be opened -10810." I have seen strange errors when upgrading (I assume due to pieces of libraries cached in memory differing from the remaining code on disk), but I had not upgraded recently. Thinking that I may have run out of disk space, I decided to check "df -h". Opening a new Terminal window just said: "Could not open a new pseudo-tty."

"Huh. Thats odd..." A search brought up some old Linux threads mentioning a maximum number of processes-per-user. I couldn't think of any reason why I would have too many processes, so I went to an existing shell, typed "ps -ax" and got "fork: Resource temporarily unavailable." Further adding to the awesomeness of the situation. But, I had a possible out - if there were indeed too many processes running, I could sacrifice some and the problem would (temporarily) go away.

I did manage to run a "ps -ax", and I saw a large number of:

  502  4344 ??         0:00.00 (Google Chrome He)
502 4432 ?? 0:00.00 (Google Chrome He)
502 4433 ?? 0:00.00 (Google Chrome He)

... zombie Google Chrome processes! Hah! I have been running Chrome for long periods of time, and its process management system is not functioning correctly. Close Chrome, problem solved.

Man, that was a weird one.

Thursday, November 19, 2009

Paul's Mistake (Be Strong, Not Whiny)

Paul Graham recently commented on the state of Apple's AppStore and their treatment of developers. The comment seemed uncharacteristic of him, dedicating a lot of time to chastising Apple for their actions and claiming that this will substantially tarnish Apple's reputation. I respect Paul, but feel that his tone is wrong. Only time will judge whether Apple's treatment of developers will keep them from being successful. Instead of complaining, we should be analyzing how Apple has been successful and attempt to reproduce that on our own. Its the longer, harder path, but it will make all the difference.

(continuing with the previously titled "Developers: You Are Whats Wrong With the iPhone AppStore")

You pounded your fists because Apple didn't have a "real" SDK, so Apple created one. Then you pounded your fists because the approval process is too slow, so Apple hired a bunch of noobs. Now you're pounding your fists because the newbies aren't consistent in their execution.

Stop. Stop making iPhone apps. Stop complaining about Apple. Stop using their phone. Stop.

I am a long time Mac user, and I will tell you that nobody cares about your app, least of all Apple. I didn't buy the iPhone because of you, I bought it because of Apple. Apple put a bunch of cool things on it, and they all work (mostly) great. Most AppStore apps sell for a dollar, because thats about all they're worth. (BTW: please disprove this by creating something valuable.)

Since Apple made a great phone, they have become popular. But Apple isn't good at popular. Popular people have to bend to the will of others to stay popular, and that just isn't Jobs, and it isn't me either. Apple wants to be the best, and you have to be a little elitist to do that. You have to somewhat ignore what everyone wants and concentrate on what is best. Personally, I'm okay with this, and so are most of the people who bought an iPhone.

When Apple releases a tablet, will your iPhone app work on that? Of course not. What about Google's Droid? Not there either. Your apps will be rewritten (and re-tested) on every platform there is. The reason that we were all making web apps before the iPhone was that web apps actually work everywhere. JavaScript+HTML is the data interchange format for executable code (delivering what Java was supposed to). Don't like Apple's phone? Get a new one, your email, photos and web applications will continue to work there. Man that sounds nice, doesn't it.

If Apple is pissing off developers, I personally think this is great. Instead of building yet another iPhone app that Apple has to test and only your friends will ever use, you'll think about building your own hardware, or an app for another phone, or a web app that will be usable on any device for decades. Better yet, build a WebAppStore that works exactly like the AppStore, but for web applications.

You can pound your fists all you want, but only a couple of your peers are even listening.

[Discuss at Hacker News]

Wednesday, September 02, 2009

Cleaning MacPorts Dependencies

Sometimes MacPorts gets a little carried away with dependencies. I recently tried installing mercurial on 10.6, and found MacPorts yak shaving various X11 libraries. After deciding that this yak didn't need to be shaved, I cancelled the install and downloaded the Mac OS X mercurial installer (index).

Unfortunately, canceling a port install leaves behind extra packages. Which packages? Good question. I knew that I had asked for some packages (libidl, graphviz, bash-completion), but I didn't know which packages were only installed as dependencies of my half completed mercurial request. Given a package, port can find the packages that are dependent on it. Hmm, this sounds like some programming homework...

Given a map of package names to a list of packages dependent on that package:
  1. find packages with no dependencies, which were not explicitly installed by the user
  2. if there are none, you are done
    1. add them to a list of packages to remove
    2. remove their map entry
    3. remove them wherever they appear as dependent on another package
  3. recurse!