I’ve been looking at smartphones for a while, although not quite seriously up until now. In fact, I’m quite surprised with myself that I actually took the plunge and bought something.

Actually, the main push for me to get an Android phone was Dad, who wants me to get into app development. I initially held back because I like the concept and hackability of the Nokia N900 and the Maemo OS. Maemo uses a normal X11+GTK/Qt kind of stack, and is generally hacker friendly.

However, I don’t just want to hack for myself; I want to be able to release stuff, and if I do, I want people to be able to use it. Not only that, but with the merger of Maemo and Moblin becoming MeeGo, and the fact that MeeGo won’t be officially supported on the N900 creates furher turbulence and fractures where Android is still going strong.

The main selling point for me on the Milestone was the massive screen size, and the positive reviews of its screen size; both of which, in practice, have been fabulous. I was holding out for a glimpse of the HTC Wildfire pricing, but I decided I didn’t want a tiny 240×320 screen no matter how cheap it was.

The version I got was a UMTS 900/2100, which means it is not Next G compatible (which needs UMTS 850/2100). As I’m a Telstra user, that consequently means my coverage is not too crash hot. However, I could fix that simply by moving to Optus.

I’m not going to write a full-on review of the phone — there are plenty out there already. Any more you hear from me about this phone will be something I’ve hacked up for, hopefully, you to try.

Case in point:

The “no caching” bit is what it’s been running like for 8 months, using this config in /etc/collectd/collectd.conf:

<Plugin rrdtool>
        DataDir "/var/lib/collectd/rrd"
</Plugin>

To more than half my idle CPU usage, and get my load averages back down to near 0.00, all I had to do was add:

<Plugin rrdtool>
        DataDir "/var/lib/collectd/rrd"
       CacheTimeout 120
       CacheFlush 900
</Plugin>

I don’t get why they don’t ship it like that by default. Enable caching. Your server will thank you. Thanks to the folks on #slug who held my hand while fixing this.

The old site didn’t look bad (in particular, I liked the penguin header image), but was getting a little long in the tooth, had a few issues (such as broken category styles, and images being linked to the wrong domain), and didn’t really reflect much about Wollongong, which is where we are based.

So a little Inkscaping later, I came up with this:

Check it out. No, like, seriously. Check it out. A bit more polish to come, but the idea is there.

My server, glenstorm, is the IPv6 router, which contains the ppp0 interface that connects it to the IPv6 Internet. I am also running irssi on the same machine. It’s a router, so /proc/sys/net/ipv6/conf/all/forwarding is 1.

So, basically, when I fire up irssi, and type “/connect irc.ipv6.freenode.net“, it hangs when connecting. And for good reason: here’s the (edited for clarity) tcpdump output:

IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667
IP6 ::1.34823 > 2001:19f0:feee::dead:beef:cafe.6667

So obviously that’s wrong. And in violation of RFC 4291, I might add (“The loopback address must not be used as the source address in IPv6 packets that are sent outside of a single node.”).

I can hack around it by typing “/connect -host 2001:44b8:7df3:b970::14 irc.ipv6.freenode.net” into irssi, which forces it to use the source IP that I specified. But that’s just a hack — I’d like to get to the bottom of what actually causes it.

Update: Finally solved this. It’s because in my irssi config, I had the following directive:

core = {
    host = "glenstorm";
};

It was being told to use “glenstorm” as the “host”, which translates to “resolve the IP address of glenstorm and use that as the source IP address” (I think I misunderstood the meaning of the directive when I put that configuration flag in).

Of course, in /etc/hosts, I had the following entry:

::1 glenstorm

So, naturally, irssi decided to use ::1 as the source IP address. So removing the “host” line from the irssi config fixed the problem. While I’m sure that because of the aforementioned RFC, that shouldn’t have resulted in the subsequent symptoms, at the end of the day, it was simply Unix allowing me to shoot myself in the foot.

(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable

So it had fallen back to a software 3D renderer, which is pretty crap. So to make a long story short, it was because my ‘Virtual’ screen size was too big. I typed xrandr, and got the following:

$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 960, maximum 2048 x 2048

Because of various technical reasons, when the Virtual size is too big (which, evidently, 2048×2048 is), DRI gets disabled. So, to re-enable it, I put this into my xorg.conf:

Section "Screen"
        Identifier "Main Screen"
        Device "Radeon 7500"
        Monitor "eMac CRT"
        SubSection "Display"
                Virtual 1280 960 # put the highest resolution you intend to use here
        EndSubSection
EndSection

Obviously, edit the values to suit.