As I went down the lines counting, I could not believe the amount of stress that I induced in those being counted.  People quickly began to worry about whether they were too far back in line to get a phone, or even if they were in the right line.  I was stopped about every 25 people asking what their number in line was. I had to explain over and over that I wasn’t counting for any purpose.

For the record, by the time 7 AM rolled around there were 700 total people in the two lines.  During that time I’m sure the line grew, because I started with the no-reservation line first, and then proceeded to the reserved line, which wound around the building in a different direction.  Between 7AM and 7:20, another 82 people showed up in the reserved line behind me.

Either I’m missing something, the initial iPad apps are going to suck, or we haven’t yet been told that iPad-native apps won’t be available for some period of time after the iPad’s launch.

You are missing something.

The problem, of course, is that before day one, we won’t have iPads ourselves for development and testing. This wasn’t a problem for iPhone development: by the time the SDK was released, we had all been using iPhones for many months. We knew how iPhone apps should look and behave, and we could test our apps on our iPhones during development for three months before anyone could sell apps to customers.

No, we didn’t. You might have, but thousands of others were left out in the cold, unwelcome to develop for the iPhone. Apple tightly controlled who they allowed in, and many didn’t get developer keys until months after the App Store was opened for business. Yes, we could develop on the simulator, but not on the phone itself. This preferential treatment continued with the release of later beta SDKs and Firmwares. The entire time this was going on Apple was very coy about what they were doing.

You have based your 3 possibilities on a bed of false assumptions.

You have assumed that you can go to the local Apple Retail store, buy an iPad and install software.

This is not supported in the current SDK. At this point you can’t even compile code to the A4.

Apple hasn’t said when it will be supported.

Most importantly there is no guarantee that your current developer certificate will allow you to cryptographically sign and install software on the iPad at all.

Your certificate may work for iPhone and iPod touch only.

Apple may require a separate enrollment fee to get a iPad certificate.

Apple may limit iPad certificates to a select few developers. This limitation may be temporary or permanent.

You have assumed that Apple will accept iPad apps from you sometime on or before “day 1″.

Apple has made no such commitment.

They have committed to their future iPad users that iPad specific apps will be ready on day 1, but they haven’t committed to any developers (AFAIK) that they can submit them.

When it comes to the AppStore, Apple is not a matchmaker helping developers connect to users in a frictionless manner. It sure seems that way and as an indie developer I like the AppStore, but it is what it is, which is Apples playground.

You have assumed that there is a submission queue.

Developers like data structures like FIFO, and lots of them refer to the “submission queue” but I have never seen documentation from Apple that submissions are handled in a first come first served manner. Anecdotal evidence seems to indicate that the are several submission piles, and they are serviced at different rates.

This has been driving me crazy for awhile now, so I looked into the problem and found a “solution”. While I can’t vouch that it will work for everyone, I wanted to share it in the hopes that it might work for some.

This is going to be long so that everyone can understand the cause and possible soutions.

The problem firsrt showed up when I started using SVN 1.5. I upgraded all my repositories on my linux and mac servers, and the mac server was working well, but the linux server would ocassionally just hang in Versions. As part of the 1.5 upgrade there are some caches that you can either prebuild or build as needed, so I assumed the slowness was just those caches slowly being updated.

That was until this morning when I had the problem with a brand new empty repository. I found that when Versions was running, access to the repository was slow even from the command line. But if I wasn’t running Versions, performance was lightning fast from the command line.

It turns our the problem is related to the way SVN 1.5 uses random numbers. On linux (and OS X), there are two sources of random numbers. One is /dev/random, and the other is /dev/urandom. /dev/random produces true cryptographically secure random numbers. If there isn’t enough entropy available it will hang waiting for secure random numbers to become available. urandom on the other hand will sacrafice cyrptographica quality and always produce random numbers.

Svnserve on my linux box uses /dev/random, and if the random numbers aren’t available it blocks until they are. This in turn leads to Versions blocking waiting for svnserve to respond, which will happen eventually as sources of entropy like network traffic occur.

The problem is compounded when you turn on “Show Updates from Repository”. For me this is the entire reason for having a program like Versions, so that I can keep track of what repositories I’m working with have experienced changes, so I can make sure my source stays up to date and that I’m aware of who is making what changes to the source.

The problem is that the SVN server doesn’t do much besides serve svn connections. So there isn’t much entropy available. Eventually /dev/random runs out of random numbers and svnserve will hang, causing Versions to hang. Versions should be a bit smarter about realizing that if a request isn’t critical (like say a commit or update) that it can just terminate the connection on quit.

The solution is to either rebuild the Apache Portable Runtime library that svnserve from source and change it to use /dev/random instead of /dev/urandom. This would need to be done on the server.

The other choice is to simply remove /dev/random and replace it with the equivalent of urandom. This will affect all programs running on the server.

The commands are not for the faint of heart and can easily render the box unusable if done improperly. These are for a Fedora Core 9 box, and won’t work on OSX or other platforms. The commands must be run as root.

rm /dev/random
mknod /dev/random c 1 9
chmod 666 /dev/random

For me, this has completely solved the problem of Versions hanging on quit, and I’m back to mostly happy with the product.

At some point I need to have some trust that the data it holds is secure, and Apple can’t possibly guarantee the long term security of the data and access. In the end the most they can do when a screw up occurs is shrug and say sorry.

If on the other hand there was a set of tools that came with OSX Server that allowed my iDisk and related mobile syncing to be on a server I or my organization control I would feel a lot more comfortable.

The zip file (7.3MB) contains a high-rez image of the newton (1276×2074) from scanning the face on a flat bed scanner. The original newton was very beat up, an the photshop file is from after airbrusing some of the junk and scratches off.

This was then used to make a much smaller skin for POSE.

Included in the zip is also a 1200×1920 version that I just created to use as a background for a 23″ monitor in portrait style.

http://www.hulu.com/embed/1734

The number at the end is the primary key in the database of the video. They start at 1 and go up from there.