All right, all right! ) Happy now?

Fake Science diagrams the Types of Plugs. I’m going to have to hang on to this one for the “shameless” variety.

Nmap has a nice visualization of the Internet’s top websites: Icons of the Web

Leverage has put up a set of short video clips from their Comic-Con presentation. Let’s go steal a Comic-Con. (Interestingly enough, they picked some of the same bits I did for my own write-up of the event.)

Hilarious. People working on viruses are actually sending their crash reports to Microsoft — including the malicious code!

The Bad Astronomer presents: Top 5 Ways the Universe Could Wipe Out Humankind. He goes into these threats (some likely, some unlikely, and some certain — but not for millions of years) in a lot more detail in his book, Death from the Skies!, which is a fascinating read.

It’s a trending topic, but there’s a lot of misunderstanding about the Twitpocalypse. Here’s what’s going on, in layman’s terms (I hope).

What’s happening?

  1. Every Twitter post has an ID number that goes up by 1 each time.
  2. When a computer program stores a number, it sets aside a certain amount of space for it. Bigger numbers take more space because they have more digits.
  3. One common format is called a “signed integer.” It has 32 binary digits (1 or 0 only) with one digit set aside to indicate a minus sign. The biggest number it can store is 2,147,483,647.
  4. Twitter’s status IDs are approaching that number.

So what’s the likely impact?

  • Twitter itself can handle bigger numbers and will be fine.
  • Third-party apps that store the ID in a bigger format will be fine.
  • Third-party apps that store the ID as text instead of a number will be fine.
  • Third-party apps that store the ID in this particular format will end up with bad IDs as they try to cram a big number into a small space.

If I were to guess, the most likely breakage would be that replies might be attached to the wrong previous post — but again, only with apps that use this particular format for numbers.

Twitter itself will probably sail through cleanly (and has been planning to move up the schedule so that affected app developers don’t have to fix things in the middle of the night), so don’t expect any fail whales. Unless so many clients have problems that lots of people switch to the website.

Update: Not surprisingly, most Twitter clients are unaffected by the Twitpocalypse. I’ve used both Twidroid and Twhirl with no problems since Twitter passed the mark. I figured a few would get tripped up, but the real surprise is that it hit Twitterrific. One of the most popular clients on the iPhone? They do have an update, but a lot of people are unable to connect.

The IEBlog recently posted about their efforts to improve reliability in Internet Explorer 8, particularly the idea of “loosely-coupled IE” (or LCIE). The short explanation is that each tab runs in its own process, so if a web page causes the browser to crash, only that tab crashes — not the whole thing. (It is a bit more complicated, but that’s the principle.) Combine that with session recovery (load with the same set of web pages, if possible with the form data you hadn’t quite finished typing in), and you massively reduce the pain of browser crashes.

I’d like to see something like this picked up by Firefox and Opera as well. They both have crash recovery already, but it still means restoring the entire session. If you have 20 tabs open, it’s great that you don’t have to hunt them down again. But it also means you have to wait for 20 pages to load simultaneously. It would be much nicer to only have to wait for one (or, if I read the IE8 article correctly, three).

Edited to add:

On a related note, I’ve run into an interesting conflict between crash recovery and WordPress’ auto-save feature. If you start a new post, WordPress will automatically save it as a draft. If the browser crashes, it will bring up the new-post page, but restore most of the form data you filled in. So the title, the text of your post, etc will all be there. But WordPress will see it as a new post, and you’ll end up with a duplicate.

This wasn’t a major problem when I encountered it — I had to reset the categories, tags, and post slug after I hit publish (since I hadn’t noticed that they’d been reset to defaults), and I just deleted the older, partial version of the post — but I can imagine if I’d uploaded an image gallery, I would have been rather annoyed, since there’s no way (that I’ve noticed) to move images from one post to another. Reuse them, sure, but not such that the gallery feature would work.