Fixing Broken Things

For me, the Things in the title refers mostly to software, but it could be anything. Today there are two broken things, one which I’ve already fixed.

The first thing that was broken was this blog. I’m not sure how long the problem lasted, but if you attempted to access it sometime between just a bit ago and whenever it broke, it didn’t work. You would’ve gotten an error.

My method of fixing it was roughly:

1. Notice it’s broken.
2. Confirm it’s actually broken (eg, that it wasn’t a connection problem or browser-related problem).
3. See how broken it is.
4. Fix it.

The first step came for free, as it usually does, except when things break in very subtle/spooky ways. This actually ties in with the third step as much as the second step.

The second step entailed opening the site in a different browser and trying a few other things like making a request with curl -I <domain>. Again, this also ties in with step three.

The third step was getting on the server itself and really finding the root of the problem. In this case, the problem was that the version of PHP the server runs changed, making something that was probably a warning before into a full error.

The fix wasn’t hard once I had that direct, small, known problem.

But the key point here is that the first three steps and step four are basically two steps, and that they’re both essentially the same process.

Part one is getting the problem understood, modeled. Part two is getting a solution understood, modeled.

Both are scientific in their best case: forming a hypothesis, testing it, and observing the results.

Either can block. Sometimes you can’t find the problem, and sometimes a solution is elusive. Sometimes to find the problem would require access or tools that aren’t available. Same for finding or implementing a solution.

The other problem giving me a rash today is my Firefox profile. This profile has been with me for a long time. It’s from at least 2005, as it came with me when I switched to GNU/Linux in 2006. It’s only recently had some problems:

1. A particular website which I don’t frequent causes a complete and utterly bad situation: it eats all my memory and then starts eating my swap.
2. Firebug just won’t work.

For reference, I’ve got six gibibytes of RAM, which never get filled. Within a minute of visiting the website in question, swap begins to be flooded, my RAM being completely filled.

In both cases, using a different profile fixes the problem, but even in safe mode on this profile the problem persists (can’t check Firebug from safe mode, but some console errors reinforce the fact that it wouldn’t work there).

The question is whether it’s worth it to try to track down the problem with the profile. It’s probably not. Recently Firefox introduced a feature (available in Firefox 13, currently beta) that will reset my profile, but it’s currently disabled for me in Iceweasel. That’s seems to be due to Iceweasel being dependent upon XUL runner on Debian, in order to not install the same support libraries for all Mozilla applications.

Using the web console, one can see that the following migrators are available:

• browser/chrome
• browser/firefox
• browser/ie
• browser/safari

While I could force the issue, without knowing what would happen, this would be risky. An alternative would be to create a new profile, throw some data in, and try it there first, to see if it’s safe.

There are other ways to achieve the equivalent of a reset, the most useful being to use the Firefox Sync service to store the data, then attach a new profile to Sync and let it handle the rest.

If I decide to go for a new profile, this will fit the bill nicely. But it remains to be seen if I can still figure out what the problem with this profile is.

And here’s where we depart. Next week, I’ll leave a note about the outcome. I’ll probably replace the profile either way, but it would be neat to know what the problem is.