The installation was extremely simple, with no remote activation or anything like that. This is because the GM is essentially the very same that will be pushed to the masses in a week. I simply pressed the option key while clicking on ‘update’ in iTunes and I got a dialog window to choose the .ipsw file from the disk. After that, it took its sweet updating time and lo and behold, my two-year-old device was running the latest incarnation of iOS.

I am extremely pleased to report that my iPhone 3G has come back to life. After using it extensively, to the extent of purposefully opening all sorts of apps in rapid succession to make it crumble, it stood strong. I can assure you that this is not placebo: it’s pleasant to use again. Most importantly, it doesn’t randomly freeze for a random amount of time in a random fashion in random apps. Sometimes it does take its time when the lock screen comes up (perhaps it does some cleaning when it automatically locks, and it reloads something?), but other than that, it’s completely different from 4.0.x.

Mind you, this is still a two-year-old phone and there have been two major revisions since it came out, so do not expect The Flash in your iPhone (hey! that’s a geeky double-entendre! neat!), but it’s definitely a major improvement. One disappointment stands, though: 3G units just don’t have the hardware to run the Epic Citadel demo, but — once again — is anybody really surprised by that?

The real irony is that my iPhone 3G was such a pain to use in the past couple of months (especially with the annoying freezes) that I honestly can’t even say whether 4.1 makes it as fast as 3.1.2, or if it’s still slower than that. All I know is that it’s faster than 4.0.2, and that’s all I care about.

The ident check timeout depends on how the IRC server is configured. Freenode takes a very conservative approach, using a timeout of 15 seconds. This is what happens:
[08:43:08] --- Looking up irc.freenode.net..
[08:43:08] --- Connecting to chat.freenode.net (2001:6b0:e:2018::172) port 6667..
[08:43:08] --- Connected. Now logging in..
[08:43:08] --- *** Looking up your hostname...
[08:43:08] --- *** Checking Ident
[08:43:08] --- *** Couldn't look up your hostname
[08:43:23] --- *** No Ident response
[08:43:23] --- Welcome to the freenode Internet Relay Chat Network Jollino
...etc...

Not exactly the fastest thing. The problem here is not that I lack an ident daemon; it’s that my router filters all ports by default. A filtered port is neither open or closed, so a remote party trying to connect to it is left waiting indefinitely. After all, the lack of an immediate response might be due to a congested network. Indeed, when I tried connecting to port 113 (ident) from a remote shell, here is what happened:
[cyclops]$ time telnet 151.64.126.29 113
Trying 151.64.126.29...
telnet: Unable to connect to remote host: Connection timed out

real 0m21.003s
user 0m0.000s
sys 0m0.000s

Linux’s telnet in this case seems to have a timeout of 21 seconds. Freenode’s IRC deamon waits 15. It’s still too much. Compare to what happens with a closed port:
[cyclops]$ time telnet 151.64.126.29 6870
Trying 151.64.126.29...
telnet: Unable to connect to remote host: Connection refused

real 0m0.266s
user 0m0.000s
sys 0m0.004s

Much better, isn’t it? The solution is straightforward: unfiltering port 113. My router however only does that by forwarding a port to an internal machine (that is, I have to selectively pierce the NAT so that incoming connections to port X are forwarded to internal machine a.b.c.d on port Y — X and Y can be the same, of course). Is that a problem? Not really, but the recipient machine has to be active, otherwise you will incur into another connection timeout and you’re back to square one. Interestingly enough, it turns out that my router is perfectly fine with redirecting ports to itself, so I simply had connections to (external) port 113 to port 113 on itself. Here is the result from the shell:
[cyclops]$ time telnet 151.64.126.29 113
Trying 151.64.126.29...
telnet: Unable to connect to remote host: Connection refused

real 0m0.234s
user 0m0.000s
sys 0m0.000s

And here is how it works when connecting to IRC:
[10:59:03] --- Looking up irc.freenode.net..
[10:59:03] --- Connecting to chat.freenode.net (2001:6b0:5:1688::10) port 6667..
[10:59:03] --- Connected. Now logging in..
[10:59:03] --- *** Looking up your hostname...
[10:59:04] --- *** Checking Ident
[10:59:04] --- *** Couldn't look up your hostname
[10:59:04] --- *** No Ident response
[10:59:04] --- Jollino already in use. Retrying with Jollino_..
[10:59:04] --- Welcome to the freenode Internet Relay Chat Network Jollino_
...etc...

Much better, isn’t it?

As for DCC, the situation is more complex. The protocol works with the recipient connecting to the sender, so opening up specific ports on the router (and redirecting them to the machine where the IRC client is running) and telling the client to use such ports should work. That’s how I used to work it around years ago. However, it’s not working anymore. I can connect to myself from a remote shell, but the actual recipient won’t. In this time and age, though, it‘s much faster to just upload things to Dropbox and share the link, so I’m not going to investigate that further.