This is an advanced setting that we don't expect users to tweak. The default value should work for most people. Here's a decent test: if you have to go to about:config to change a setting, it's not something we want normal users to touch, so talking about usability at that point is a bit silly. The most usable software just does the right thing and doesn't require users to change setttings.

Conveniently Mike is also the Debian Firefox package maintainer, so I'd expect him to apply as much of his work as possible to those packages. That's not to say that Debian's Firefox builds will be as fast as the official Mozilla builds, since Debian has other priorities that may conflict.

Intel does have ICC, but it's kind of expensive, and it's picky in different ways than GCC/VC++, so it means fixing up things across the entire codebase to even get it to work. I was able to build our JavaScript library on OS X with ICC at one point without a huge amount of hassle, and it was a decent speedup back then (but Apple's GCC is ancient). Using it on Windows would probably be a PITA in terms of amount of work to even compare performance.

There were actually several GCC bugs that had to be fixed in order for us to use PGO. Thankfully Mike has a good working relationship with GCC maintainers, and he upstreamed all necessary patches, so everybody wins.

Not really true, we actually built our Linux builds with -Os (optimize for space) up until this change, where we switched to -O3 (optimize for speed) + changed from GCC 4.3 to GCC 4.5 and also enabled profile-guided optimization at the same time. The end result is a pretty nice performance win and not much disk space change.

Windows builds of Firefox didn't get profile-guided optimization until Firefox 3 (2008), so it's only about 3 years behind. Actually I think Firefox 1.0 might have been shipped with PGO on Linux, but I wasn't directly involved in that release so I can't recall. Mike had to chase down a number of bugs in GCC in order to make it work again, which is nice because it benefits all GCC users. GCC developers are using Firefox as a testcase for further optimizations in GCC 4.6 (like LTO), so we should hopefully be able to use those when it's released.

Please feel free to use a competing browser, all of which already include this root cert, to my knowledge.

http://en.wikipedia.org/wiki/Lorentz_National_Park

Firefox codenames are always park names nowadays. This park happens to be in Indonesia, which (AFAIK) is the first country to pass 50% Firefox marketshare.

It's certainly possible, but we do have an extensive set of unit tests and performance tests these days, and we don't land new features without a test suite. Combined with our crash reporting infrastructure, I have pretty high confidence that the quality of the software is improving.

That's great, but there are lots of extensions that do in fact break. If users update to a new version of Firefox and their extensions don't work, or cause their browser to crash or otherwise malfunction (not a theoretical problem), they are not happy users.

The Jetpack project is working to create a stable (but admittedly more limited) API for extensions to use to make it possible to sidestep this problem.

Uh, the primary goal of the Lorentz branch is to merge the out-of-process plugins architecture back to the stable 1.9.2 branch that Firefox 3.6 was released from.

Uh, you can disable the blacklist, if you really want to. It's just enabled by default because we think it's the right thing to do. The vast majority of people do not know they even have these things installed, nevertheless how they would update them or otherwise mitigate their risk.

Also, if you read the original blog post, Mike Shaver spoke to Microsoft before making this decision. Mozilla does not employ the blacklist without consulting with the vendor in question first.

As for Firefox, you are basically running a series of stovepipes where it makes sense for each tab to have a separate process... why it has taken so freakin' long for this I don't know, but it's not a new idea

Because it's a large existing codebase and will require invasive changes to work in this model. Also, multi-core processors are a fairly new development, having been around for only a few years. Do you think that back in 2000 anyone would have predicted consumer-grade quad-core CPUs? Would anyone have thought that building a multi-process architecture (ala Chrome) was the right course of action at that time? Software is hard, and retrofitting large codebases to do things they weren't designed for takes a lot of time and engineering effort.

I would question whether "execute the JavaScript in this HTML page your server provided to me" really constitutes "decrypt without authorization".