This is an utterly content-free rant in which I express my anger at recent Internet Explorer preview releases requiring installation of what is effectively an entirely new operating system. I would like to know how new IE behaves on various testcases. But I don’t want to potentially hose my primary functioning Windows system to do it, especially if I then lose access to a working IE9 installation. And I am really not interested in wasting a bunch of time to spin up a virtual machine just so I can waste a bunch more time to “upgrade” it to test a new version of IE.

Here’s a novel concept: what about shipping a browser that doesn’t have to insert itself deep into operating system guts? Maybe you could even install and uninstall it distinct from the OS. But that’s crazytalk, nobody would ever do that, right?

So, yeah, whatever the latest IE10 does, meh. Someone who cares can be the sacrificial lamb and find that out, if it actually matters.

(“Content-free rant”, indeed. Future posts will return to substantive form.)

Two weeks ago changes landed in Mozilla to reduce the locations searched for a mozconfig to just $MOZCONFIG and $topsrcdir/.mozconfig. Previously a bunch of other weird places were searched, like $topsrcdir/mozconfig.sh and $topsrcdir/myconfig.sh and even some files in $HOME (!). This change made specifying build options more explicit, in line with build system policy to be “as explicit as possible”. Reducing complexity by killing off a bunch of truly odd configuration option locations was good. But I thought it went too far.

The changes also removed $topsrcdir/mozconfig. This location wasn’t nearly as bizarre as the others, and it was more explicit than $topsrcdir/.mozconfig: it appeared in directory listings and folder views. I wasn’t the only person who thought $topsrcdir/mozconfig should stay: the bug which reduced the mozconfig guesswork included rumblings from others wanting to keep support for $topsrcdir/mozconfig, and the blog post announcing the change included yet more.

I filed a bug to re-support $topsrcdir/mozconfig, and the patch has landed. $topsrcdir/.mozconfig and $topsrcdir/mozconfig (either but not both) now work again: use whichever name you like.