Yesterday’s project was to back up, reset & restore the iPhone: this, according to AT&T, is the final step in unlocking the iPhone. Alas, there were…distractions.

When I docked the iPhone (for the first time since January), iPhoto popped up with an offer to upload the 159 new pictures – new vs. last January, that is – that it found.

Sure, go ahead, thought I.

Alas, the upload process did not include any of the titles, descriptions, tags, etc., etc., that I had set in iPhoto on the iPhone. iPhoto for iOS is off in its own little world, and will not give up any of the data entrusted to it.

There’s a word for that sort of behavior, but it isn’t a very nice word. I imagine I won’t be using iPhoto on the iPhone any more.

iTunes also offered to download available updates for sixty-three apps. Never mind that most of those are tried-once/didn’t-like, or apps I bought for the iPad & don’t want on the iPhone; never mind also that the iPhone has been happily downloading its own updates for the last six months; the bandwidth gods must have their offering.

With resignation bordering on despair, I clicked the Download all updates button, and watched the blue progress bars crawl slowly across the screen.

(It turns out Jake had his own download running, so my completely-pointless download included a bonus starved-for-bandwidth waste of time.)

After a while, I gave up & went out to watch television with Jennifer. I never did get the iPhone backed up. Maybe tonight….

A few weeks ago, the Wii’s message light started blinking. I wonder what that’s for, thought I. A message from Cousin Ryan? An available software update?

The Wii has been sadly neglected, ever since the Xbox arrived. All those games, all those controllers & their goofy accessories – they sit in baskets near the television, gathering dust.

So the Wii’s efforts to gain our attention met with little success, until last Sunday evening. The kids were in bed, Jennifer was elsewhere in the house; it was time to solve the mystery of the pulsating blue glow.

It turned out to be nothing exciting, nor even very interesting: just an advertisement for the Wii U. Nintendo must be desperate to boost sales, if they’re nagging Wii users.

Once the Wii home screen came up, I noticed that somebody had left a Call of Duty: Black Ops disc in the drive. (I hate it when the kids do that. Alas, my attempts at teaching proper CD handling to the next generation have failed.) After ejecting the CD & returning it to its case, I brought up the Wii calendar thingy, to see when Blacks Ops had last been played.

The answer: somebody played Black Ops for five hours on February 3rd. And that’s the only time all year anyone has used the Wii.

Suppose you have a MySQL table, that contains a field like this:

start_time datetime default NULL

As it turns out, the start_time field is never null: it always contains a value. Every record in the table has a value, and new records are never created without one. So, in the interest of good data hygiene, you do this:

alter table …
modify start_time datetime not null default ’0000-00-00 00:00:00′;

This should be a very fast operation: the data type isn’t changing, the current values are all valid under the new schema. MySQL could just update the schema, and leave the data alone.

Alas, it does not. It insists on making a copy of the entire table. If the table is large – say, because it contains thirteen years of data – this can take a rather long time.

Annoyance, I have it now.

I’ve been thinking about passwords.

Long ago, passwords were short & simple, usually a single all-lowercase word: cabbage, turkey. Those turned out to be easily guessed, since most people chose from a fairly small set of words.

Then everybody started mangling their passwords, replacing letters with vaguely-similar digits: ca66ag3, turk3y, that sort of thing. They were harder to guess, but also harder to remember.

The bad guys responded with rainbow tables: tables of pre-computed password hashes. They’re huge – 8GB or more – but disk space is cheap.

The latest (proposed) solution is to string together several words: supposedly, an easy-to-remember password like “correct horse battery staple” has 44 bits of entropy, and at 1,000 guesses/second would take 550 years to crack.

A few thoughts:

Some web sites won’t accept a twenty-five-character password, or one that’s all lowercase letters.

There are already storage systems large enough to hold a 44-bit rainbow table. They’re insanely expensive, for now; but soon enough they’ll cost $100 at Best Buy. What then?

As passwords get larger, is there a risk of hash collisions – two passwords with the same hash? (I know very little about cryptography. Maybe there is no risk.)

Passwords are obsolete. (No, I’m not the first person to think that. Thanks for asking!) I hope clever people are working on a replacement.

CNN says: At long last, Microsoft has an Apple-beating vision:

But Microsoft’s plan may be even better than anything Apple or Google currently have to offer. If – and it’s still a lofty if – there’s a shred of validity to rumors that Microsoft will merge the Windows and Windows Phone platforms, “Blue” could end up being a huge deal. Dissolving the barrier between mobile and desktop would be nothing short of impressive.

My first thought on reading this was that if Microsoft does merge Windows and Windows Phone, all existing Windows Phone devices will be orphaned. Users won’t be able to update their devices to the new OS; and the old OS won’t work with the new apps, app store, etc., etc.

I don’t think screwing over your existing users counts as an ‘Apple-beating vision’….

Consider the following Python code:

import MySQLdb
conn = MySQLdb.connect(...)
cursor = conn.cursor()
sql = "create temporary table t1 (a datetime, b integer)"
cursor.execute(sql)
sql = "insert into t1 (a,b) values (ifnull(%s,now()),%s)"
args = [(None,0),]
cursor.executemany(sql, args)
cursor.close()

If you run it against MySQLdb 1.2.4, you get this error:

TypeError: not all arguments converted during string formatting

…even though there’s nothing wrong with the insert query. Any of the following changes will make the error go away:

• Replace now() with ’2013-01-01′;
• Reverse the field order, e.g.: insert into t1 (b,a) …;
• Use an earlier version of MySQLdb (I tried 1.2.1b4).

I found a comment on the ever-helpful StackOverflow that says this is a bug in MySQLdb  (unfixed, despite the developer’s claims to the contrary), and even offers the specific regex that’s broken.

(I’d say using a regex to parse sql, when all you really need to do is find & replace instances of “%s”, is the real breakage….)

The end result of all this is that I get to waste my time looking at every single instance of executemany in my code, to make sure my queries won’t confuse the easily-bewildered MySQLdb.

I’ve seen a few news items, and read a bit of online chatter, regarding Amazon’s recent (imminent? intended?) purchase of Goodreads. Everybody’s excited – what a wonderful world it will be, with Amazon’s vast resources placed in service of Goodreads’ mission to get everyone reading & discussing online what they have read.

I’m thinking I might delete my Goodreads account.

These acquisitions are usually about the data, occasionally about the developers, and never about the site or what the site’s users might want. Goodreads will become an adjunct to the Amazon marketing machine, if it survives at all. Sorry, not interested.

Rummaging around in my stack of old genealogy research notes, I found a marginal annotation:

size 61496 cyls 7476 head 255 sector 63
precomp 0 landz 16382

…i.e., disk-configuration settings from long ago.

Remember the brief but weird time in which disk capacities had exceeded the limits assumed (and/or imposed) by the IDE interface? For the disk to work, it had to lie to the controller about its geometry: e.g., a four- or six-platter disk pretending to be a 255-platter disk, to keep the cylinder count low enough not to choke IDE.

I can’t remember the last time I had to do that. These days, disks are a thousand times larger, but no foolery is required: plug them in, and they just work.

I’ve been setting up a new Windows 8 laptop (for work), these last few days. The press coverage for Windows 8 has been less than enthusiastic, but my own reaction so far has been…

…meh.

The software I used with Windows 7 works pretty much the same in Windows 8. (So Microsoft got that much right.)

But it’s hard to get excited by the new features. The Start screen is just a cumbersome way to launch programs. The included don’t-call-them-Metro apps are ugly & useless.

Perhaps the next version of Windows will be better.

The download page for Apache Tomcat says:

You must verify the integrity of the downloaded files. We provide OpenPGP signatures for every release file. This signature should be matched against the KEYS file which contains the OpenPGP keys of Tomcat’s Release Managers. We also provide an MD5 checksum for every release file. After you download the file, you should calculate a checksum for your download, and make sure it is the same as ours.

Well, yes, that’s very secure…except the .zip file and its checksums are stored on the same server.

If I’ve compromised the server, and replaced the .zip file with my own (malware-contaminated) version, what’s to stop me from replacing the .md5 file with a recalculated one?