We'll see | Matt Zimmerman

This afternoon, I decided to take the plunge and replace the OS on my G1. I had been having problems with the factory software for a while (including extreme slowness and a recurring crash in the calendar sync code) which finally outweighed the risk and inconvenience of flashing it. It looked like I was going to have to wipe it, and if I have to suffer that inconvenience anyway, I might as well go for broke.

“Rooting” the phone to enable the use of an alternative OS was very easy, thanks to the excellent Recovery Flasher application. I installed it by pointing the phone’s browser at the .apk download, though in retrospect it should be even easier to use adb. Recovery Flasher installs an alternative system recovery application, used when you hold down the magic buttons while the phone is starting up. The one which comes with the phone only allowed me to perform a few simple operations, while Recovery Flasher offers more features and doesn’t limit me to OS images blessed by Google.

Next, I downloaded the latest version of the highly recommended Cyanogen build. Thanks to Recovery Flasher, I didn’t even need to rename the file, as it lets me select any .zip file from the SD card to install. This is particularly convenient when experimenting with multiple OS images. On the first try, it failed to verify the .zip, so I copied it again, and it worked. I think the microSD card which was included with the phone is a bit flaky.

I decided to try without wiping my settings, to see if I could preserve them. The Cyanogen installation instructions warned that the first boot would take a long time, but after several minutes, I started to worry. adb logcat gave me some bad news:

I/SystemServer(  631): Starting Content Manager.
I/SystemServer(  631): Starting System Content Providers.
I/SystemServer(  631): Starting Battery Service.
I/SystemServer(  631): Starting Hardware Service.
W/HAL     (  631): load: module=/system/lib/hw/lights.trout.so error=Cannot find library
W/HAL     (  631): load: module=/system/lib/hw/lights.trout.so error=Cannot find library
E/ActivityThread(  631): Failed to find provider info for settings
W/dalvikvm(  631): threadid=31: thread exiting with uncaught exception (group=0x40019a68)
E/AndroidRuntime(  631): Uncaught handler: thread PowerManagerService exiting due to uncaught exception
E/AndroidRuntime(  631): *** EXCEPTION IN SYSTEM PROCESS.  System will crash.
E/AndroidRuntime(  631): java.lang.NullPointerException
E/AndroidRuntime(  631): 	at android.content.ContentQueryMap.(ContentQueryMap.java:65)
E/AndroidRuntime(  631): 	at com.android.server.PowerManagerService.initInThread(PowerManagerService.java:414)
E/AndroidRuntime(  631): 	at com.android.server.PowerManagerService$1.onLooperPrepared(PowerManagerService.java:374)
E/AndroidRuntime(  631): 	at android.os.HandlerThread.run(HandlerThread.java:59)
E/AndroidRuntime(  631): Crash logging skipped, no checkin service
I/Process (  631): Sending signal. PID: 631 SIG: 9

It was stuck in an infinite loop due to this crash. I searched Google for the error and found no help, and after some experimentation (including clearing out the dalvik-cache directory), I resigned myself to wiping my settings. I copied off the /data directory from the phone and rebooted, and the crash disappeared. Since I have a copy, I can restore the settings individually as I need them (and may be able to identify which one triggered the crash).

adb push makes it easy to copy files back onto the device from a backup. It was easy to restore my list of WiFi networks and keys: just restore /data/misc/wifi/wpa_supplicant.conf. It looks like Bluetooth pairings are stored in /data/misc/hcid, and I’ve copied that as well, though I haven’t tested whether it worked.

Restoring applications was also straightforward: adb push some.app.apk /data/app

I didn’t bother trying to figure out how to restore my Google account settings, Twidroid settings or Twitta settings. I just re-entered my account details. Twitta doesn’t seem to be working, though. It gets a timeout trying to contact Twitter and verify my credentials (but I can ping twitter.com fine).

The phone is much snappier now, though whether it’s due to the fresh start or the Cyanogen build, I’m not sure.

I’ve lived in many different places in my life, and spent a lot of time online. As a result, my friends are dispersed around the world. We see one another rarely, and stay in touch through short letters, text conversations and phone calls. Through these occasional communications, we learn about what is going on in each other’s lives. We share anecdotes about where we’ve been, what we’re thinking about, what we’ve done, read, heard and watched.

At least, that’s how it used to work.

Now, when I travel, it appears in my Facebook feed. When I do something interesting, I mention it on identi.ca and Twitter. When I read something I like, I share it on Google Reader. If I watch a video which reminds me of a friend, I send them a link. If I have an idea I think is worth sharing, I write about it on my blog.

The end result of all this is that when I catch up with friends who use social media, I don’t have much to say. They’ve already heard it all, and there is very little “catching up” to do. It’s awkward when I start to tell them about something which has happened to me, and they remind me that they’ve already heard about it.

I would have expected this to make me feel closer to people, but it doesn’t. It makes the relationship feel less intimate. Reading something on a feed is not the same as hearing about it first-hand, but even so, the first-hand account feels a bit redundant because it’s not new.

Is anyone else having the same experience?

On the heels of the excellent geekfeminism wiki comes the geekfeminism blog. Kirrily Robert, Liz Henry, yatima, Mary Gardiner, Sumana Harihareswara, Mackenzie Morgan, Terri Oda and Valerie Aurora are listed as contributors so far.

The about page reads:

The Geek Feminism blog exists to highlight and discuss issues facing women in geek communities, including the tech industry, open source, gaming, science fiction fandom, and more.

It’s only just getting started, but if you’re interested in reading about and discussing this subject, head on over and subscribe to their feed.

This is one of my favorite bugs of all time: Ubuntu bug #248619, where OpenOffice.org won’t print to Brother printers on Tuesdays (but works on other days of the week).

Read some of the duplicate reports to follow the analysis and developer/user cooperation which isolated the bug.

It’s a great example of a Bohrbug, where the circumstances which trigger the problem can be very difficult to isolate. It’s likely that many such bugs exist in Ubuntu and other software today, but have not yet been isolated, as bug 248619 has been.

We’ve all observed a complex software stack misbehaving in ways we would never expect. It’s just as confusing when things suddenly start working again, for no apparent reason. We start to doubt our senses, or the person who is reporting their observations.

In The Psychology of Computer Programming (chapter 5), Jerry Weinberg presents a case where two identical systems, physically isolated from each other but running the same software, exhibited precisely the same error at the same time. This obviously pointed to a software bug, but after two weeks of searching, the problem could not be replicated and the root cause was not found. The team gave up on finding it, and the system went into production, only to have the bug recur and cause a serious operational outage.

Bugs which occur very rarely may not always be worth investigating, but they are real, and can be explained. When it really matters, we should remember not to disregard them.

While on holiday for the weekend, I have been browsing RSS feeds using NewsRob, a convenient offline RSS reader which synchronizes with Google Reader. I came across an article on Kirrily Robert’s blog on the use of the word “offense” in the context of sexism. The RSS content indicated that there were several comments on this post, and so I clicked through to check it out. The result was this:

My phone was connected to the hotel’s WiFi, which apparently has a SonicWALL content filter installed. This filter seems to think that Kirrily’s blog is “Adult/Mature Content”. I’m not sure why this is. Perhaps because the word “sexism” has “sex” in it?

SonicWALL has a web site where one can view their ratings for arbitrary web sites, and it confirms that infotrope.net (apparently the whole site) is classified as Category 6: Adult/Mature Content and Category 41: Society and Lifestyle. There is no explanation of what these categories mean, or how the classification process works.

They provide a form to request that they reevaluate their rating of a particular site, so I did that. Without knowing why they classified this site the way they did, I don’t see how a reevaluation will help, though. They asked me to suggest better categories for it, but none of them made sense. They can’t be serious about using a list of a few dozen static categories for all of the content on the web. Can they?

I wrote them a short note explaining that I did not think the site merited an “Adult/Mature” content rating, a euphemism usually reserved for pornography. I have very little hope that this action will ever elicit a response, and it certainly won’t restore my access to the site this weekend while I’m here. I am not a customer of SonicWALL, and don’t expect ever to be.

I will mention to the hotel that their system caused this problem for me, but I don’t expect them to act on this complaint either. Companies which install content filtering systems don’t plan to spend time maintaining them to make sure that they provide a good quality of service, and this is sure to seem like an unnecessary hassle to them.

This is why I hate content filtering systems. They disenfranchise end users by making content decisions on their behalf, and make it their responsibility to work through the bureaucracy when it goes wrong.

The Ubuntu kernel team receives an extraordinary number of bug reports, about 1000 in the past week. Yesterday, Leann Ogasawara, our Ubuntu kernel QA lead, addressed a roomful of Ubuntu developers. She shared how the kernel team is handling this situation, and asked for ideas and suggestions from the crowd.

To try to help out, I reviewed the most recent screenful of kernel bug reports (75) to see if there were any patterns we could take advantage of. I discussed with the kernel team some ways in which we could improve our approach, and implemented some of the changes.

Altogether, this was only a few hours of work, but should eliminate a large number of invalid reports, and significantly increase the quality of many more.

A quick back-of-the-envelope count revealed the following categories:

Suspend or hibernate failures (36%)

A majority of these are automated reports from apport. This is good, because we have the opportunity to collect relevant information from the system when the problem happened, but it also means that there are a lot of reports.

Although some new logging was added in 9.04, these reports still often do not contain enough information to diagnose the problem.

One bit of data which the kernel team has said would be useful is the frequency of the failure: does it fail every time, or only sometimes? We can improve the logging to keep track of successful resumes as well as failures, and then include this data in the report.

Networking problems, both wired and wireless (13%)

The kernel team has a partial specification for some improvements to make here.

Package installation and upgrade failures (10%)

The kernel tends to be a trigger point for a variety of problems in this area which are not its fault. For example, if the system is very low on disk space, upgrading the kernel can fail because it is a large package, so we automatically suppress those reports. In my sample, none of the failures being reported against the kernel actually belonged there.

To help address this, we can suppress bogus reports, and redirect valid reports to the appropriate package. I committed fixes to apport which will file the problem reports against grub or initramfs-tools if they were caused by failures in update-grub or update-initramfs respectively. I also added an apport bug pattern to suppress bug reports against the kernel which contained certain dpkg unpacking errors, and added a patch to apt to try to detect this case as well.

Audio-related problems (9%)

Currently, the first step for most of these bug reports is to ask the user to complete the report by running apport-collect -p alsa-base to collect audio-related debugging data.

Because they account for a significant proportion of all kernel bugs, I committed an apport patch to simply attach this information by default for all kernel bugs.

Kernel panics, oopses, lockups etc. (8%)

These bugs are notoriously tricky to file properly, because the system is often non-functional or severely impaired.

In Karmic, we now have a kernel crash dump facility which is very easy to use. Rather than reporting a bug saying “my computer locks up”, you can throw a switch which will enable the problem to be automatically detected, recorded and analyzed. By the time the bug report reaches the kernel developers, it should have detailed information about where the problem occurred, rather than requiring the reporter to use things like digital cameras to capture panic messages.

We’ve also wired up kerneloops to apport, so that oopses are reported through an automatic facility which can produce a more complete bug report.