The Mozilla Plugin Check page was released today, so I loaded it up to see the latest changes. “Looks good,” I thought, and skimmed the list of plugins it displayed for me. Quicktime, Silverlight, Flash, and… Woah, wait.
On my OS X box? How the fuck did that get there? I sure don’t remember installing it. Grrrr!
A little web searching later, and I found my answer. It’s silently installed with Flip4Mac (a set of Quicktime components to allow playing Microsoft proprietary media formats on OS X), which I had installed a week or two ago to try something, and then promptly forgot about. The installer doesn’t have a word to say about it, unless you click a little “Customize” button on the 5th screen on the install:
That really annoys me. Silent, sneaky software installs are evil, evil, evil.
At least Flip4Mac includes an uninstaller, so I ran that. It’s actually a package, so you’re confusingly prompted to “Select the disk where you want to install the uninstaller software.”, but it was otherwise painless. Now to just restart my browser, check about:plugins, and…
GAHHHH! It’s still there. Their uninstaller uninstalls the Flip4Mac bits, but not the Silverlight plug. Solution:
rm -rf /Library/Internet Plug-Ins/Silverlight.plugin/
It’s finally dead, Jim.
If you’re running nightly builds of trunk or Firefox 3.6, you may notice a smoother progress bar while installing the nightly updates…
The old progress bar behavior had always seemed a bit odd to me — it would do nothing for a bit, move to about 15% point, and then suddenly finish. I didn’t get around to looking at why it did that until I used the updater on a Windows CE netbook. The device is a lot slower than a normal system, so the unusual progress bar movement could appear frozen for over a minute! That’s really poor UI feedback, so I set about fixing it.
You can read the gory details in bug 517102, but the end result is that the progress bar now tracks progress more accurately, and the updater runs 3 times faster too!
While sheriffing yesterday, I was a bit confused when dbaron asked if I was looking into all the orange. The tree (http://tinderbox.mozilla.org/Firefox/) looked mostly green, except for a handful of earlier Talos oranges. So, yadda yadda, it turns out that most of the test boxes report to a separate tinderbox tree now — http://tinderbox.mozilla.org/Firefox-Unittest/. There are similar splits for the 3.6 and 3.5 trees.
This was probably announced somewhere, but 3 other developers also didn’t know this was the case. So, I figured a blog post was in order.
Tinderboxpushlog already includes both sets of data, and I’ve just updated isTheTreeGreen.com to use both sets as well.
I got a new Windows desktop last week, and was curious if enabling disk compression would have any effect on build times… The theory being that source code compresses well (binaries too, to a lesser degree), so less disk IO should result. The price is more CPU usage, but this is a Core i7 box, so that’s basically free.
Result: Theory Busted.
Without disk compression, a full build took 23 minutes. With disk compression, 24 minutes. [Drive formatted between tests.] I’d guess some combination of not being IO bound plus disk seeks dominate, so compression doesn’t really help and just adds overhead. I also tried disabling “write-cache buffer flushing” to no effect, although I’m curious if splitting my build across two drives will help at all [src on one, objdir on the other; currently it’s in a RAID-0 config].
One thing that would be nice is if parallel make worked correctly with Mozilla on Windows. If I build with anything higher than MOZ_MAKE_FLAGS=”-j1″, the build hangs at random (?) places. Seeing as this is a quad-core box (8-core, if you count HT), that makes me all sad and frowny.
Update: Mitch on IRC pointed out bsmedberg’s pymake work. With -j1 it’s about 30 seconds slower, but with -j10 it did a full build in 11 minutes (without hanging like a gmake build did!). Yay! I should also note that until now I’ve been doing Windows builds in a VM, which can take well over an hour to finish.