Fans drive me crazy

No, not that type of fan. The Canonical folks updated the Ubuntu 9.04 kernels and now my Aspire One started blowing its fan all the time again. After a bit of tinketing in ~/tmp and /etc/modules I remembered that the acerhdf module is _not_ included, so has to be reinstalled every time a new kernel shows up. So grab that and sudo make install.

xrandr to the rescue

Just got a new Samsung 22" 1080p monitor and plugged it into an Acer Aspire One. I have 3 OSes in this machine, so decided to configure all 3 for the new monitor. Windows XP did a decent job at setting it up (there's an "Advanced" tab in the video preferences that has lots of cool options -- video card specific). MacOS X 10.5.5 was even better, it came up with a bogus config but as soon as I pulled the new monitors plug, it reverted to the main netbook screen and recognized the new monitor after plugging it back in. All very easy.

Unfortunately Ubuntu 9.04 was not as friendly. Although Xorg did recognize all valid modelines at boot, for whatever reason the intel driver refused to show any of the higher ones. The same thing happened when I configured other monitors in the past, but I forgot what I had done to fix it, and didn't want to hard code the xorg.conf file because I will be using different external monitors on a regular basis.

Anyway the solution is quite simple. Just force xrandr to recognize the modeline you want (xrandr --newmode and copy/paste the modeline from Xorg.0.log, then xrandr --addmode). Now go to the display preferences and your shinny new display mode will be available. Logout and login and all is done. Yay!

Swim on boot

I've got my Nokia E71 syncing with Google (contacts, calendar) and Ovi (those and more). As you probably know the S60 platform doesn't sync by itself on a regular basis so most people use Swim for that task. According to the Swim page it should run at boot time but on my E71 it doesn't seem to. I use Powerboot to run a few apps at boot time, but couldn't find the Swim process by name to add it. Turns out that ("use the source, Luke!") it's called SyncServer.

Alexa cleaning up interfaces

Now that Alexa's thumbnails are no longer supported via AWS (breaking their own site for a while :P) it seems that they decided to also revamp their remaining services and do so cleaning up. This broke a script of mine used to fetch per-country stats. It's a simple change, the UrlInfo call with RankByCountry now returns a Code property in the XML instead of the old code property (note the case change). So if you're using HPricot (like I am), you'll use a line like:

(h/"aws:country[@Code='#{countryCode}']"/"aws:rank").innerHTML.sub(/\s*$/, '')

to filter out the resulting rank.

jdresolve on GitHub

I'm trying to force myself to switch to Git from Subversion for my current projects. The safest way to do it seems to be using an older project as a guinea pig :) So I just pushed jdresolve over to GitHub. I'll scavenge for the uncommitted patches and the unanswered emails regarding jdresolve and will commit to the Git repository soon (enough).

Google geocoding charset encoding currently broken

Update (2008-09-09): Google seems to have finally fixed this.

About 2 weeks ago I started seeing weird characters when geocoding addresses via Google using the YM4R gem. The addresses are outside the US and so contain plenty of accented characters that used to be properly encoded in UTF8. Although Google's XML claims to return UTF8, it currently doesn't, sending what looks like ISO-8859-1 encoded characters in some fields instead. This is more than likely a problem with their outsourced partners not having properly setup UTF8 environments and updating GIS information using local encodings.

I search for the issue and found if mentioned in ep's blog. He ended up seeing the same error message:

#<REXML::ParseException: Missing end tag for 'DependentLocalityName' (got "DependentLocality")

That'll usually result in a nice 500 error in your Rails app (if that's what you use) because it raises an exception.

His solution (forcing further charset translations to occur) worked quite well, except that I had to mention the origin charset in my case. So instead of calling to_utf8 plainly, I pass it the charset with to_utf8('iso-8859-1'). This is a very ugly hack in all so I hope that Google fixes the issue soon. I personally didn't report the bug 'cause I never got any feedback from any information I ever sent their way or any requests that I've made in the past.

Fixing mint tables after a 32bit to 64bit migration

I just migrated a web site from a regular 32bit processor (Intel(R) Xeon(TM) CPU 2.40GHz) to a 64bit slice (Dual Core AMD Opteron(tm) Processor 265). This made mint v2.14 (or actually the underlying MySQL database) start showing the visitor IPs as mostly 127.255.255.255. A little searching got me to here and here and here. I don't run PhpMyAdmin so here are the raw SQL command for you to run on your console:

alter table mint_visit modify ip_long int(10) unsigned;
alter table mint_visit modify referer_checksum int(10) unsigned;
alter table mint_visit modify domain_checksum int(10) unsigned;
alter table mint_visit modify resource_checksum int(10) unsigned;
alter table mint_visit modify session_checksum int(10) unsigned;

After running these a show columns from mint_visit should return the following:

+--------------------+---------------------+------+-----+---------+----------------+
| Field              | Type                | Null | Key | Default | Extra          |
+--------------------+---------------------+------+-----+---------+----------------+
| id                 | int(11) unsigned    | NO   | PRI | NULL    | auto_increment |
| dt                 | int(10) unsigned    | NO   | MUL | 0       |                |
| referer            | varchar(255)        | NO   |     | NULL    |                |
| referer_checksum   | int(10) unsigned    | YES  | MUL | NULL    |                |
| domain_checksum    | int(10) unsigned    | YES  | MUL | NULL    |                |
| referer_is_local   | tinyint(1)          | NO   | MUL | -1      |                |
| resource           | varchar(255)        | NO   |     | NULL    |                |
| resource_checksum  | int(10) unsigned    | YES  | MUL | NULL    |                |
| resource_title     | varchar(255)        | NO   |     | NULL    |                |
| search_terms       | varchar(255)        | NO   |     | NULL    |                |
| img_search_found   | tinyint(1) unsigned | NO   | MUL | 0       |                |
| browser_family     | varchar(255)        | NO   |     | NULL    |                |
| browser_version    | varchar(15)         | NO   |     | NULL    |                |
| platform           | varchar(255)        | NO   |     | NULL    |                |
| resolution         | varchar(13)         | NO   |     | NULL    |                |
| flash_version      | tinyint(2)          | NO   | MUL | NULL    |                |
| local_search_terms | varchar(255)        | NO   |     | NULL    |                |
| local_search_found | tinyint(1) unsigned | NO   | MUL | 0       |                |
| window_width       | smallint(5)         | NO   | MUL | -1      |                |
| window_height      | smallint(5)         | NO   | MUL | -1      |                |
| ip_long            | int(10) unsigned    | YES  | MUL | NULL    |                |
| session_checksum   | int(10) unsigned    | YES  | MUL | NULL    |                |
| visitor_name       | varchar(255)        | NO   |     | NULL    |                |
+--------------------+---------------------+------+-----+---------+----------------+
23 rows in set (0.00 sec)

The sooner you fix your database the less info you'll lose. Took me a couple of hours to realize this was happening...