Asides
Broken phone screen – data rescue
Last weekend I broke my Nokia 6120’s screen. I have a military phone, which is far cheaper, so I’ve decided to keep it offline. However, being the sentimental guy that I am, I did want to save all of my contacts and SMS messages (in addition to the photos, which presented less of a problem). This proved to be a bit of a challenge without the screen working.
Usually, when you connect the phone via USB, it asks if you want “PC Suite mode” or “Data Transfer mode”. The “Data Transfer” mode has the phone show up as a standard USB storage device, which allows for easy transfer of MP3 files, photos and videos to and from the phone, without any nokia-specific software. However, it only works for the external SD card, so you can’t use that to access SMS messages or contacts.
I usually only need “Data Transfer” mode, so I changed the default to that. Today I regret that decision, as it cost me a couple of hours’ work. I called the Orange hotline, and they did their best to help me, including trying to blind-guide me through the menus, which failed because the menus are actually dynamic and I didn’t have the default setup. They actually got me 90% of the way there – here’s the solution I found: Hit the red (disconnect) button, and type the Soft Reset GSM code: *#7780#. Now press the “left menu” key (not the left key, nor the menu key – the left of the two “dynamic” keys) – this part was what the Orange hotline missed, because it seemed so obvious. Then hit 12345 (this is the default “secret code”), and the left menu key again. I found this by watching a demo of the soft reset on YouTube.
At this point I used VirtualBox and the Nokia PC suite (both are free-as-in-beer) to do the heavy lifting. I now have a text file with all of my contacts, a CSV file with all of my SMS messages, and all of my images saved both to my computer and a DR site. Now I just need to upgrade my military phone (Mirs)…
Loving the new Totem
Totem is Gnome’s built-in media player, and it really annoyed me in previous versions, and had me switching to VLC. However, the version included in the Ubuntu 9.10 release candidate has two features which are very important, in my opinion. The first feature is smooth graphical integration with compositing managers (such as compiz). In previous versions, as well as VLC, once you fullscreen the window, moving the mouse (which causes the cursor and the partial interface to appear) causes a very annoying flicker. This has been fixed (at least on my box, using an NVidia card).
The second, more important feature, is the exact one I’ve been missing and talked about in the previous post – hit Edit->Preferences->Start playing files from last position, and Totem will keep track of your last playback position when you close the video. Reading the implementation patch shows that there is a certain threshold for this – the position won’t be saved if you’re too close to the beginning or end of the video. So there, my show downloading stack now has every feature I’d want from Miro, without the downsides I’ve mentioned.
Timezones are fickle
I’ve been trying to work out a system to be able to cleanly switch between IST (Israel Standard Time, GMT+2:00) and IDT (Israel Daylight savings Time, GMT+3:00) on command. The logical way to do this, in my opinion, is to have two separate files in /usr/share/zoneinfo, say IsraelIST and IsraelIDT, and copy (or link) the relevant one as /etc/localtime. The trick is creating the IsraelIDT file:
My first guess was the following zic source-file:
# Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone IsraelIDT 2:00 01:00 IDT
Now, this almost works. The problem is that both is_dst is set and timezone = -10800 (3 hours – should be 2, as it should represent local standard time), so some software double-compensates here for a grand total of GMT+4:00. After some research (walking through __tzfile_read gave the biggest hint), it turns out that timezone is set according to the minimal local time type which is transitioned into. So I came up with this file:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ZionIDT min 1939 - Jan 1 00:00 1:00 D Rule ZionIDT 1939 only - Jan 1 00:00 0:00 S Rule ZionIDT 1940 max - Jan 1 00:00 1:00 D # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone IsraelIDT 2:00 ZionIDT I%sT
Sounds about right, nay? Even my handy little pyzdump confirms that it looks about how I want it to:
./pyzdump.py /usr/share/zoneinfo/IsraelIDT Transitions: ['At Sat Dec 31 23:00:00 1938, switch to IST', 'At Sun Dec 31 22:00:00 1939, switch to IDT'] Types: [<TZType IDT: UTC+10800 dst=True>, <TZType IST: UTC+7200 dst=False>]
(pardon the lack of syntax highlighting – my prettyprinter fails me)
However, it still doesn’t work. A test program:
int main() {
tzset();
time_t t = time(NULL);
printf("Timezone name is %s, timezone=%ld\n", __tzname[1], timezone);
printf("The time is %s", ctime(&t));
printf("Timezone name is %s, timezone=%ld\n", __tzname[1], timezone);
return 0;
}
And its results, as run at 14:42:17 UTC, which is 19:42:17 IDT:
Timezone name is IDT, timezone=-7200 The time is Sat Apr 18 14:42:17 2009 Timezone name is UTC, timezone=0
Or, as I described it to a friend:
Me: Hi computer, do you know what timezone are we in?
Computer: Yeah, it’s Israel Daylight Savings time, GMT+2:00 for standard time.
Me: OK, and what time is it?
Computer: 14:42
Me: No, that’s 3 hours late. What timezone are we in?
Computer: Umm… UTC?
Me: You just said IDT.
Computer: Nuh-uh.
I’ll get to the bottom of this eventually :/
Addendum: It seems that the problem is even more complicated. For the following timezone file, C programs seem to work fine:
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ZionIDT min 1939 - Jan 1 00:00 1:00 D Rule ZionIDT 1939 only - Jan 1 00:00 0:00 S Rule ZionIDT 1940 2030 - Jan 1 00:00 1:00 D Rule ZionIDT 2030 max - Jan 1 00:00 0:00 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone IsraelIDT 2:00 ZionIDT I%sT
However, Python programs still show timezone = -10800. Examining Python’s code, I found this:
if( janzone < julyzone ) {
/* DST is reversed in the southern hemisphere */
PyModule_AddIntConstant(m, "timezone", julyzone);
PyModule_AddIntConstant(m, "altzone", janzone);
PyModule_AddIntConstant(m, "daylight",
janzone != julyzone);
PyModule_AddObject(m, "tzname",
Py_BuildValue("(zz)",
julyname, janname));
} else {
PyModule_AddIntConstant(m, "timezone", janzone);
PyModule_AddIntConstant(m, "altzone", julyzone);
PyModule_AddIntConstant(m, "daylight",
janzone != julyzone);
PyModule_AddObject(m, "tzname",
Py_BuildValue("(zz)",
janname, julyname));
}
And since June and July have the same timezone in our case, there's a good chance that this is what's going wrong.
The moral of the story seems to be this - I should go with the first, simplest "always-DST" solution. Programs should ignore the timezone variable, as in our context it isn't reliable. In general, all internal time handling should be done in UTC; when reading times from the outside world, if they are in local time - use mktime. If they are in a specified timezone, use timegm and compensate manually. I'd love to hear better ideas in the comments.
Using git for code review
At my workplace, I’ve recently been using git for code review purposes. I work on code in my own git clone, and ask a peer to review it. It works somewhat like this:
masterbranch is same code as currently in upstream.- Working to resolve issue #1234 pertaining to “Performance for gizmo”, I work on a branch
1234-gizmo-performance. - I mail a peer, John, with this information, as well as my repository location.
- John adds my repository as a remote, lutzky. Then he branches
review1(orreview2if that is taken, and so on) atlutzky/1234-gizmo-performance. - John adds comments with nice big “
FIXME” tags, which are highlighted in any decent editor. He commits this, the commit-message stating that it was code review. - John tags his final review commit (or, if he had no comments –
lutzky/1234-gizmo-performance) with a “reviewed1” (orreviewed2, etc.) annotated tag. Since the annotated tag includes all the necessary information (who tagged, when, and what), the number doesn’t really matter. - I merge
john/review1, incorporate the changes (or reject them) and remove the comments. If no further review is necessary, I submit this – and once submitted, I merge this back into master.
It’s a nice system. I wonder what other methods there are of doing this.
Hardware doesn’t like me
I’m a software kind of guy. Here’s proof.
Today I went to visit my grandparents, and it turned out their computer wouldn’t boot. BIOS would load up fine, and I could browse the menus fine – but once it tried to go on from there, it would simply blink what looked like half a cursor (that is, half of a “_”-style cursor). I figured it might be the HDD – so I took it home, and decided to connect it to my own box. Upon disconnecting my DVD drive, I destroyed the SATA cord – it had an annoying little metal tab which had to be pushed in before it would release, and it just wouldn’t give, and the connector just broke, exposing and bending the wires.
Checking if the computer still boots, the BIOS took much longer to display hard drive status, and while Ubuntu would start booting, it would fail in the process and tell me that my root hard drive (by UUID) isn’t available. Looking at dmesg, the ata2 module was indeed reporting that the hard drive was too slow – but a few seconds later it would finally access the drive, and mount properly. This problem, however, disappeared once I connected my grandparents’ drive! (Mounting it would fail, telling me that I either have a hardware error or need to connect it to a Windows machine, which I don’t have, and run some diagnostic commands). Sure enough, when the HDD is connected by itself, it gets quite flaky, but once I connect a second drive (back to the DVD, eventually), everything works properly. This probably has to do with the fact that both drives are connected on continuations of the same power cord – but I’ve never experienced such a problem, where you must connect devices to both connectors on the power cord. A hardware guy I know says he’s never heard of such a problem either.
Naturally, these things never happen when I mess with hardware at work, where there are plenty of spare parts…
