Macha

Paul Irish believes that by 2020, web designers will be forced to support 76 variations of Internet Explorer between the nearly annual release schedule IE is on lately and the compatibility modes each of these IEs will have for previous versions of Internet Explorer. ¹

IE6's entrenched position came from the fact that (a) it was the latest version of Internet Explorer for a huge amount of time and (b) its status as the IE dead end for Win2k and below.

When IE7 came out, any company that still had any Win2k machines had to keep designing with IE6 in mind if they wanted their new apps to work on all their computers. (I'm making the assumption that if they were relying on IE previously, they couldn't just switch to Firefox or something).

Now, IE8 I think most people can accept is going to end up in IE6's current place. It's the IE dead end for XP, a hugely popular OS. But IE7? None of those companies that don't upgrade upgraded to IE7. Home users that upgrade will also have installed the IE8 upgrade. So you're left with what? Unpatched Vista installations. These are much rarer than unpatched XP installations simply because Vista had a shorter lifespan, and Windows Vista to 7 is sufficiently undramatic an upgrade for the types of people who would take years to go from XP to Vista.

So so far we have:

• IE6 will drag on as long as XP does.
• IE7 won't last particularly long. While it's popular now, earlier Vista computers will be replaced in the close future (2-3 years), causing it to lose market share to IE8.
• IE8 will have a long lifespan, although probably not as long as IE6.

IE9? IE9 has never been shipped by default with any version of Windows. That means anyone who installed it did decide to upgrade. These users will likely upgrade away, meaning in the future, IE9 will be even more of a non-issue than IE7.

IE10 will likely also go the way of IE7. While it will be installed by default on Windows 8, the amount of dramatic changes in W8 will scare off many of the companies that are slow to upgrade.

So in 5 years time, what versions of IE will realistically you need to support?

• IE6 (maybe - probably, hopefully, enterprise only at this stage)
• IE8
• IE10 (enterprise will never use it because Win8 is scary and different to them so for home users only)
• IElatest-1 So IE13 or something?
• IElatest IE14 or something.

Needing to support IE6 and IE10 will likely be mutually exclusive, so that's 4 versions for sites targeted at home users and 5 for sites aimed at both enterprise and home users. Still ugly, but far from 76. And all those versions will be dead in the timescale that the article is using. Insofar as IE6 will ever die, anyway.

IE6 for home users will be dead at that point. Most of those old early XP computers will be "broken" and replaced, even if "broken" is just slow and annoying. Using XP in five years will be like using Win98/Win2k. Yes, people do use them. No, they aren't a large enough group for most to worry about. I even have a small amount of hits from Netscape 6. I haven't a clue what my page looked like for them, and don't care.

In theory, if even IE is aiming for at least yearly releases from now on, no future IE will end up in the position that IE6 is in, and that IE8 will find itself in, as upgrading your browser frequently becomes a fact of life. The compatibility modes will be much less important too, as the shorter lived the browser, the less likely that the compatibility mode for it will ever be used.

Ubuntu 10.04 Netbook Edition (2010)¹

Mac OS X Lion (presumably 2011)

Windows 3.1 (1992)

While working on my Haskell IRC bot, I needed some information on the actual IRC protocol. Much of this information sadly isn't available in any centralised format, and much of the information that is there is just a copy/paste of the RFC. There are two formal descriptions of the IRC protocol, an older one (RFC 1459) and a newer one (RFC 2812), though the actual protocol as used by most servers doesn't adhere exactly to either of these. So, here is a short summary of the information that I have gathered in my research. This is by no means a comprehensive tutorial, but it is sufficient to write a basic IRC bot.

The first part of the IRC protocol is the rough layout of messages. The first, optional part, is the source (username and hostmask, or server) preceded by a colon, as in :holmes.freenode.net . Because they only deal with one other part of the network, the server, clients will rarely, if ever send this part, while servers nearly always will.

The next part of the protocol, seperated by a space is the command name, which is in all-caps. Most of these are pretty much the same as what the user types in after the /. For example, the /join command becomes JOIN. The most notable exception is the PRIVMSG command, which is used for sending a message to a user or channel (it's the same command for both).

After this come the arguments for the command, again, space seperated. Most of these are limited to one word values. The one exception is the final argument, which can have more than one word, and is started off by a colon.

There are a few types of channel, but nearly all the channels you will encounter are of the #channel variety, so we will not go into detail on other types.

Finally, the command is terminated by \r\n, not \n according to the spec, though it seems most servers will accept either.

An example of a full message is as such:

:Macha!~macha@unaffiliated/macha PRIVMSG #botwar :Test response

The first part of any IRC connection is sending the NICK and USER messages. The first of these is simple, just NICK name. The next is the USER message.

An example of a USER message is:

USER username 0 * :Real name

The * part is a remnant of earlier days, and will not need to be changed. The 0 is a bitmask for the user's mode, but with just one switch. Change it to 8 to be invisible to those not in a channel with you.

The next part of the protocol we will discuss is the PING message, because some servers need one immediately after these two messages. The server will send you a message in the format PING :message to which it needs a response of PONG :message. This is the most common case of a server not sending a source. Most servers use the server name as the message part, but this isn't consistent.

For all of the rest of these messages,  there is a source on the other messages from the server side. This is a user and hostmask for a user's message, and a server name otherwise. If you are writing a client, do not send the :source part.

The next message to deal with is JOIN. The basic format of this message from most servers I've tested is

:source JOIN :#channel

although the spec says otherwise as regards the need for the colon. This is pretty self explanatory, and works the same as the /join used in an IRC client. The one unintuitive part of this command is that JOIN 0 leaves all channels.

Its counterpart is PART. Its format is

:source PART #channel :reason

The reason part is optional, and some servers (for example Freenode) seem to just cut it off, as it did not exist in earlier versions of the IRC protocol.

Both of these messages can also accept a list of channels separated by commas when sent from the client, for example PART #channel1,#channel2. Don't put spaces between the channels in this list.

The most important command in the IRC protocol is PRIVMSG. This command is used for sending messages both to channels and between users. Its format is

:source PRIVMSG <target> :Message

where the target is either a user's nick, or a channel name. So to send a message to a channel, use PRIVMSG #channel :Hello, World and to send a private message to a user, send PRIVMSG Nick :Hi!.

The final message you will use in basic usage is QUIT. Its format is

:source QUIT :reason

where the reason is optional.

These commands are sufficient to write a basic IRC bot but are by no means the full list. There are also numeric commands, and you can find more detail on these here.

Recently, Linode upped the RAM on all their packages by an average of 42%. My own VPS went from 360mb to 512mb. And yet, the first I heard about it was a RT on Twitter. Considering it's quite a considerable upgrade, almost doubling the RAM, you'd expect them to be shouting it from the rooftops. Most other hosts I have had before this sure would have. Yet I didn't even get emailed about it, so finding out was a pleasant surprise.

This reminds me of a contrasting experience I had on a budget shared host. They were using Apache 1.3.37 and PHP 4.4.7. In early 2010. This host was on a website belonging to a client, and it predated me, so moving them to a new host wasn't an option. "If it ain't broke, don't fix it", was their reasoning. And obviously non-technical people don't quite see the problems with having outdated software.

Looking through the knowledge base for the host, as they made it really hard to talk to a real person, found that there was a process to get PHP5. So I emailed tech support. They said that it may take some time as the client was on a "Legacy Web Hosting" package. They also strongly hinted that new customers get Apache 2 and PHP5. But old customers? They already have those, so why would they upgrade them? The total opposite to Linode's attitude of "Oh, hello, we've just upgraded your RAM for free."

To add insult to injury, that upgrade to PHP5 on the old host took over a month, in which time the ticket was closed incorrectly twice and it was twice hinted that new customers get PHP 5 as standard. Finally, the version of PHP 5 I finally got? 5.1.2. Weren't we all supposed to be using PHP 5.2+ since 2008 anyway?

I guess the old saying of "You get what you pay for" is alive and well and definitely applies here.