A cursory look at Mozillazine shows that large fraction of posts serve a heavy dose of misinformation. Pointing out the erroneous statements inevitably results in locked threads and name calling, so I have no option but to write and respond to the the regulars here.
(For future reference: at the time of this writing, both the versions of Pale Moon and Firefox ESR are 24.5.0 and the latest stable version of Firefox is 29.0.1.)
There are some posts claiming that the compiler optimisations in Pale Moon have no benefit, for example:
There are two things to consider:
- Optimisation for specific instruction sets does work, regardless of whatever someone claims. In fact, starting from Firefox 4, even Mozilla optimises some parts of the code for the SSE2 instruction set (e.g. [font=courier]/gfx/2d/BlurSSE2.cpp[/font]); however, the approach is different: code for both SSE2 and non-SSE2 processors are written to maintain compatibility with old processors. Pale Moon resorts to compiler optimisations to optimise all parts of the browser: it does not intend to serve people with museum-grade computers.
- The reasons why the so called "browser benchmarks" are not accurate/effective has been already stated. A few things to note:
- People are probably correct in stating that benchmarks don't prove it's faster; but neither do they prove it's slower. Benchmarks, in short, don't prove anything. That's because benchmarks are a very poor measuring tool since they only measure a very limited subset, they measure in tight loops (something that's never used in a normal website), and often are poorly calibrated or subject to bias - not to mention measuring performance of JS using JS (the very language one is trying to benchmark) instead of an external measuring tool is not scientifically sound. These are the reasons why benchmarks, in general, are considered useful only to spot regressions after implementing new features (in a 1:1 before/after scenario with exactly the same build parameters) and not useful for anything else.
- Pale Moon doesn't necessarily score higher in benchmarks since benchmarks are measuring, almost without fail, JS instructions only - and JS is really not the speed limiting factor any more with modern JIT compilers in browsers and the likes (the only thing measured is how fast a single library can spit out machine code). Also, it depends very much on which benchmarks they use. For example, Pale Moon fares better than Firefox in real-world browser benchmarks, like the MSIE chalkboard benchmark (panning/zooming large canvases).
And some others want to compare Pale Moon as just another Firefox rebuild with extensions slapped onto it:
Pale Moon actually entails in-house development, and incorporates a number of features not present in Firefox ESR. Pale Moon is not a simple rebuild any more; it includes a number of UI changes and additional features (such as TLS 1.2 and OCSP stapling); these are not present in Firefox ESR. Pale Moon is not just about removing features arbitrarily: features are removed if they are not used widely and if they give a sufficient performance advantage.
A full list of differences between Pale Moon and Firefox is listed here.
In fact, the development of Pale Moon and Firefox are completely independent. While Pale Moon bases itself on the Firefox codebase, it will evolve according to its own development roadmap. Some people keep claiming that Pale Moon will jump on to whatever (ESR) version that is released:
This conception enforced by some of the regulars is completely wrong: as stated above, Pale Moon will take its own development road. The regulars will find this hard to swallow, and complain about man power and required work, but work is required to maintain anything. It may be relatively more work than has been handled by the developers of Pale Moon till now; but the modular nature of the Mozilla codebase comes to the rescue in this. However, that does not prevent some of the extension developers (who should really know better) from commenting:
Pale Moon intends to become a real fork, in fact, already has a number of major changes. Pale Moon will retain the old UI, no matter what. Work may be involved to keep it free from the Australis UI, but it can be done. Moaning "it'll require work" is only an absurd statement, since nothing can be done without putting in work.
To answer the only real question (not presented as such) asked: Pale Moon will have a dual-GUID system; allowing Pale Moon specific extensions, while keeping Firefox compatibility. This may or may not be changed in the future.
Also, when nothing really works, just mention anything, anything; people flocking to Pale Moon must be stopped at any cost, right? Who the fuck cares about actual knowledge of the Mozilla codebase or of Pale Moon's optimisations, when mud slinging is easily done without it:
Accessibility features are something that is not considered important at this point of time, but if becomes in demand later, it can be easily turned on by removing --disable-accessibility from .mozconfig. However, I'm aware that nothing works like making a mountain out of a molehill. (Guessing by the nature of these posts, the Pale Moon developers may also expect a "won't someone think of the children" post.)
Also, such posts only go on to show how idiotic the regulars at Mozillazine are. Maybe "LoudNoise" thinks that features are removed by deleting folders; even it were so, a grep -Ev '^./accessible' will fix things. But I'm talking about "LoudNoise", now.
There are a number of things that I will simply not choose to respond to, for example, wild allegations like this: these people have turned Mozillazine into a ground for pissing contents; I'm not sufficiently masochistic to participate in these.
A small piece of advice to the regulars spreading misinformation: if discussion regarding third party builds are not encouraged, then please state this clearly in Mozillazine; if it is encouraged, then please stop acting like fanboys and douchebags and get the facts straight. Please redirect users of Pale Moon to <http://forum.palemoon.org/> for support.
Thank you for your consideration, if you've actually read this far.