1) The article's first paragraph is taking a proposal for a possible future plan of action
and claiming that it is the plan of action. 2) Right now (Firefox 3.0 and Firefox 3.5) there are no features shipped as minor updates;
all features are "withheld" as you put it until the next major version.
The only firm current plan here is that one particular feature, namely out-of-process plug-ins, is currently planned to be backported to Firefox 3.6 and shipped in some form in one of the minor updates. Once it's judged ready and so forth. Since minor updates are all about security and stability, this particular feature fits well in their scope (for example, a significant fraction of Firefox crashes are actually Flash crashes).
There is also talk of possibly backporting some other small features (mostly performance-related) to the stable branch as they become ready. This may or may not happen. There is also discussion about what and when the next Firefox major update will be, and discussion about what and when the next Gecko release will be. These may not happen at the same time. None of that is decided.
The smaller instructions are still worth it, not so much because of main RAM size constraints but because of cache size constraints. Staying in L1 is great if you can swing it; falling out of L2 blows your performance out of the water.
Most recently, just iterating over an array and doing a simple op on each entry became about 2x faster on my machine by going from an array of ints to an array of unsigned chars (all the entries are guaranteed in unsigned char range). Reason was, the array of ints was just about the total size of my L2... and the new array is 1/4 the size, which means there's space for other things too (like the code).
Firefox 3.5 is slower when built 64-bit instead of 32-bit, because the jit shipped in that doesn't generate 64-bit instructions yet. It doesn't really make sense to ship a 64-bit build it if has worse user experience than a 32-bit one.
Firefox 3.6 will have a 64-bit-capable jit. So at that point all that's needed to make 64-bit a tier1 platform is setting up the test infrastructure for it, hiring more people to do the QA for it (or finding more volunteers willing to do it, of course), and so forth. It'll probably happen (especially as some other platforms, like Mac OS X 10.4 are dropped), but it's not quite as simple as compiling and then tossing the binaries up on the FTP server. That last _can_ be done, but they're likely to have bugs that the 32-bit binaries don't have, just by virtue of having gotten less testing....
For a soft-block, the user is prompted whether to disable the known-vulnerable plug-in.
There are also provisions for a hard-block. This would be _very_ unlikely to happen unless a plug-in had an announced security vulnerability being actively exploited and disabling it doesn't break too much, so not likely at all for Flash. If it did happen, there is no user-facing UI to turn off the block. That said, you could edit blocklist.xml in the Firefox install to remove the relevant entry. Or edit nsBlocklistService.js in said install, of course...
There are two main differences between this and the old way IE did its IE-specific features:
1) This implementation is based on a public draft of a W3C REC-track document, which is worked on in public in collaboration with other browser vendors, web developers, and anyone else who cares to join the public www-style@w3.org mailing list. In fact, the gradient syntax was changed radically between beta 1 and beta 2 of Gecko 1.9.2 based on feedback and discussion on said mailing list.
2) The feature is clearly marked as Gecko-specific, so it doesn't pollute the namespace for future standardization (e.g. the properties are not called "linear-gradient" and "radial-gradient") and makes it clear to anyone using it that it will only work in Gecko and break in other browsers. This last property makes it less likely that someone will just use it, test only in Gecko, and accidentally break other browsers by just failing to think about testing in them.
But yes, using it as an _author_ for things outside progressive enhancement is of course bad. But even the progressive enhancement uses are a start: they can give valuable feedback on that www-style mailing list I mention if there are serious problems with the current spec draft.
Yep. That is exactly how they do it. They update the renderer executable on-disk, then switch to the updated version it the next time they need to start a renderer process.
Thanks for the pointer; I'll try to get that bug bumped up in priority.
In the meantime, if you control the mount options for the NFS mount (I know, a big if) you should be able to mount it nolocks to trigger sqlite to fall back to dotfile locking... The caveat is somewhat worse sqlite performance, of course.
> I'm curious as to where you find your connections to me buying a "foreign" brand car made > in a US plant by US workers has anything to do with funding terrorists?
It's not the buying. It's the fueling. For practical purposes, one can assume that a certain fraction of every dollar used to buy Saudi oil is used to fund terrorists. The same could be said for Iran, possibly.
Since we have no particular import limits on Saudi Arabia, and since oil is close to fungible, that means that some fraction of every dollar you or I spend on gas is going directly into terrorist funding.
The main attacks on second-amendment issues are not in fact aimed at people who "own enough firepower to liberate a small country" (who tend to be somewhat wealthy and hence not affected by most gun laws we have around).
The gun-control regulations in various cities are certainly not aimed at that demographic (though neither are they aimed at hunting weapons... yet they don't bother to exclude those from the ban).
Are there particular Linux issues that are bothering you? "Pay some attention to Linux" isn't nearly as useful as "please fix X, Y, and Z" in terms of getting things to happen.
I would dearly love to know the actual issues Linux users have, as opposed to generic "it sucks, but I won't tell you why I think that" grumbling.
Why? V8 is slower than SpiderMonkey in a number of cases; Spidermonkey is working on addressing the cases when it's not (and vice versa, I'd hope). WebKit is significantly buggier than Gecko's layout layer in a number of cases (and vice versa in other cases, of course, but the attempt to shoehorn XUL into Webkit is unlikely to help the situation).
Porting XUL to run on top of Webkit would be a huge project distracting from other desperately-needed work.
So given all that, what exactly should the motivation be for spending the time to run on top of Webkit instead of sticking with existing code and not reinventing wheels?
Just to be clear, the idea of maybe using Webkit _was_ in fact considered at one point. It was judged to not be worth the effort.
> In ways kinda like what happened with KHTML and WebKit.
At that time, Apple didn't have a layout engine of its own, so the situation is quite different.
That might have something to do with the fact that MSVC++ generates 30% faster code (on the particular codebase in question) than g++ does...
Not that this is the only source of Linux performance issues (pango, I'm looking at _you_), but lack of a usable pgo mode in gcc (what it does have falls down on keeping track of its own profiling information and errors out when applied to Gecko), is a quite noticeable.
Just as a note, vimperator is an excellent example of how not to write extensions in a number of ways. Leaks all over the place, assertions firing due to it doing things that are explicitly forbidden by various contracts, etc.
Running it against a debug build is pretty horrifying.
> that involves raising the level of education and the quality of life in > all parts of the globe to the point where there are no large groups of > people who are still so poor that they have nothing to lose,
This is an interesting theory, but runs into the slight problem that a significant proportion of people involved in planning terrorist acts are reasonably wealthy, that all such planners are in fact well-educated, and that even the people who actually carry out the terrorist act tend to be well-educated (and in particular tend to disproportionately have engineering degrees or science degrees)... This is true for both domestic terrorism in the US (the Unabomber, for example) and for various other terrorist organizations.
You're right that having poor people with nothing to lose makes it somewhat easier to recruit people to do the dirty work, but the 9/11 hijackers didn't exactly fit the "poor and downtrodden" demographic (largely educated, some had pilot's licenses before they ever got involved, some were already living in the West, etc).
Fully agreed with your second paragraph; I just don't think there's a good way to void such small groups: people will see grievances everywhere, and make some up if there aren't any.:(
Note that the way Dromaeo is scored its scoring is dominated by Sunspider and V8 (which it includes as very high-weight subtests; total weight about 50%-60% of the test or so). So if you're looking for a somewhat independent number from Dromaeo you want to restrict to tests NOT including the Sunspider/V8 ones. I'm not sure Dromaeo makes this easy, though...
Giving the sub-test scores will make it a little clearer what's going on, I agree.
> Why is Spidermonkey implementing non-standard Javascript extensions?
Uh... every single JS impl has implemented these for years; different extensions in different impls. Some of these are making their way into standards; some are not; some are going to end up in standards in a modified form. That's how the standards get written.
In this case, the non-standard extension is the 'g' option for the replace() call on strings. Try this in your favorite web browsers:
javascript:alert("aba".replace('a', 'x', 'g'));
Sunspider uses this flag on some of its replace calls; in Sunspider the string happens to have only one instance of the substring being replaced, so behavior is the same whether the 'g' flag is honored or not. Honoring it obviously takes more work. The particular test using this flag became about 3x faster in Gecko when the flag was removed. See details at http://blog.mozilla.com/dmandelin/2008/10/06/squirrelfishing-in-regexp-dnajs/
The best part is that Apple has removed the flag from their Sunspider core repository, but is refusing to actually update the public test...
> Do they use these extensions on every sub-test, or just some of them?
Only some; I thought I was pretty clear on that.
> It looked like Chrome beat Firefox on all of them.
I never claimed that Chrome isn't very fast on Sunspider. It absolutely is! That just doesn't mean they aren't slow in other cases not covered by popular benchmarks. The same is true in general, of course.
But yes, you're right that the multi-process parts of electrolysis (which this guy didn't enable and hence wasn't testing) have nothing to do with JS performance.
Lags behind Chrome on a particular benchmark (Sunspider). Ignoring for the moment the Sunspider tests that are purposefully slower in SpiderMonkey than in other JS engines (by using extension features that only SpiderMonkey implements and that slow the test down if implemented), that leaves the question of how relevant Sunspider is.
In my testing, Chrome is anywhere from 4x faster to 4x slower than Firefox on various JavaScript/DOM/canvas tasks. It really depends on the task, as expected: if nothing else different jit heuristics will lead to better or worse performance on the same code even if all else is identical.
In fact, Electrolysis aims to have tabs in a separate process from the browser UI as a first cut, then work on separate tabs in separate processes. That's not enabled by default, though, so the guy who wrote this blog post wasn't testing it...
Slashdot Mirror
I think you're missing two things:
1) The article's first paragraph is taking a proposal for a possible future plan of action
and claiming that it is the plan of action.
2) Right now (Firefox 3.0 and Firefox 3.5) there are no features shipped as minor updates;
all features are "withheld" as you put it until the next major version.
The only firm current plan here is that one particular feature, namely out-of-process plug-ins, is currently planned to be backported to Firefox 3.6 and shipped in some form in one of the minor updates. Once it's judged ready and so forth. Since minor updates are all about security and stability, this particular feature fits well in their scope (for example, a significant fraction of Firefox crashes are actually Flash crashes).
There is also talk of possibly backporting some other small features (mostly performance-related) to the stable branch as they become ready. This may or may not happen. There is also discussion about what and when the next Firefox major update will be, and discussion about what and when the next Gecko release will be. These may not happen at the same time. None of that is decided.
What exact problems are you seeing with the 1.1 test suite? Last I checked, Gecko passed a pretty big chunk of that (SVG fonts and SMIL excluded).
The smaller instructions are still worth it, not so much because of main RAM size constraints but because of cache size constraints. Staying in L1 is great if you can swing it; falling out of L2 blows your performance out of the water.
Most recently, just iterating over an array and doing a simple op on each entry became about 2x faster on my machine by going from an array of ints to an array of unsigned chars (all the entries are guaranteed in unsigned char range). Reason was, the array of ints was just about the total size of my L2... and the new array is 1/4 the size, which means there's space for other things too (like the code).
> Does the Kindle to text to speech for the nav menus also?
No, which is the whole point of TFA.
> Firefox 3.6 will have a 64-bit-capable jit
Er, apparently not quite. It's there, but still not working well enough, so not enabled by default. Or so I'm told.
Firefox 3.5 is slower when built 64-bit instead of 32-bit, because the jit shipped in that doesn't generate 64-bit instructions yet. It doesn't really make sense to ship a 64-bit build it if has worse user experience than a 32-bit one.
Firefox 3.6 will have a 64-bit-capable jit. So at that point all that's needed to make 64-bit a tier1 platform is setting up the test infrastructure for it, hiring more people to do the QA for it (or finding more volunteers willing to do it, of course), and so forth. It'll probably happen (especially as some other platforms, like Mac OS X 10.4 are dropped), but it's not quite as simple as compiling and then tossing the binaries up on the FTP server. That last _can_ be done, but they're likely to have bugs that the 32-bit binaries don't have, just by virtue of having gotten less testing....
For a soft-block, the user is prompted whether to disable the known-vulnerable plug-in.
There are also provisions for a hard-block. This would be _very_ unlikely to happen unless a plug-in had an announced security vulnerability being actively exploited and disabling it doesn't break too much, so not likely at all for Flash. If it did happen, there is no user-facing UI to turn off the block. That said, you could edit blocklist.xml in the Firefox install to remove the relevant entry. Or edit nsBlocklistService.js in said install, of course...
There are two main differences between this and the old way IE did its IE-specific features:
1) This implementation is based on a public draft of a W3C REC-track document, which is worked on in public in collaboration with other browser vendors, web developers, and anyone else who cares to join the public www-style@w3.org mailing list. In fact, the gradient syntax was changed radically between beta 1 and beta 2 of Gecko 1.9.2 based on feedback and discussion on said mailing list.
2) The feature is clearly marked as Gecko-specific, so it doesn't pollute the namespace for future standardization (e.g. the properties are not called "linear-gradient" and "radial-gradient") and makes it clear to anyone using it that it will only work in Gecko and break in other browsers. This last property makes it less likely that someone will just use it, test only in Gecko, and accidentally break other browsers by just failing to think about testing in them.
But yes, using it as an _author_ for things outside progressive enhancement is of course bad. But even the progressive enhancement uses are a start: they can give valuable feedback on that www-style mailing list I mention if there are serious problems with the current spec draft.
The former.
There's no web socket support in a shipping Chrome either, last I checked, just in the developer channel builds (the equivalent of Firefox nightlies).
Do you want a list of things Firefox has that Chrome doesn't in terms of web capabilities? ;)
Yep. That is exactly how they do it. They update the renderer executable on-disk, then switch to the updated version it the next time they need to start a renderer process.
Thanks for the pointer; I'll try to get that bug bumped up in priority.
In the meantime, if you control the mount options for the NFS mount (I know, a big if) you should be able to mount it nolocks to trigger sqlite to fall back to dotfile locking... The caveat is somewhat worse sqlite performance, of course.
Do you happen to know whether there's a bug filed on this already or whether I should file a new one?
> I'm curious as to where you find your connections to me buying a "foreign" brand car made
> in a US plant by US workers has anything to do with funding terrorists?
It's not the buying. It's the fueling. For practical purposes, one can assume that a certain fraction of every dollar used to buy Saudi oil is used to fund terrorists. The same could be said for Iran, possibly.
Since we have no particular import limits on Saudi Arabia, and since oil is close to fungible, that means that some fraction of every dollar you or I spend on gas is going directly into terrorist funding.
The main attacks on second-amendment issues are not in fact aimed at people who "own enough firepower to liberate a small country" (who tend to be somewhat wealthy and hence not affected by most gun laws we have around).
The gun-control regulations in various cities are certainly not aimed at that demographic (though neither are they aimed at hunting weapons... yet they don't bother to exclude those from the ban).
Are there particular Linux issues that are bothering you? "Pay some attention to Linux" isn't nearly as useful as "please fix X, Y, and Z" in terms of getting things to happen.
I would dearly love to know the actual issues Linux users have, as opposed to generic "it sucks, but I won't tell you why I think that" grumbling.
> port XUL to run on top of WebKit and V8
Why? V8 is slower than SpiderMonkey in a number of cases; Spidermonkey is working on addressing the cases when it's not (and vice versa, I'd hope). WebKit is significantly buggier than Gecko's layout layer in a number of cases (and vice versa in other cases, of course, but the attempt to shoehorn XUL into Webkit is unlikely to help the situation).
Porting XUL to run on top of Webkit would be a huge project distracting from other desperately-needed work.
So given all that, what exactly should the motivation be for spending the time to run on top of Webkit instead of sticking with existing code and not reinventing wheels?
Just to be clear, the idea of maybe using Webkit _was_ in fact considered at one point. It was judged to not be worth the effort.
> In ways kinda like what happened with KHTML and WebKit.
At that time, Apple didn't have a layout engine of its own, so the situation is quite different.
That might have something to do with the fact that MSVC++ generates 30% faster code (on the particular codebase in question) than g++ does...
Not that this is the only source of Linux performance issues (pango, I'm looking at _you_), but lack of a usable pgo mode in gcc (what it does have falls down on keeping track of its own profiling information and errors out when applied to Gecko), is a quite noticeable.
Just as a note, vimperator is an excellent example of how not to write extensions in a number of ways. Leaks all over the place, assertions firing due to it doing things that are explicitly forbidden by various contracts, etc.
Running it against a debug build is pretty horrifying.
> that involves raising the level of education and the quality of life in
> all parts of the globe to the point where there are no large groups of
> people who are still so poor that they have nothing to lose,
This is an interesting theory, but runs into the slight problem that a significant proportion of people involved in planning terrorist acts are reasonably wealthy, that all such planners are in fact well-educated, and that even the people who actually carry out the terrorist act tend to be well-educated (and in particular tend to disproportionately have engineering degrees or science degrees)... This is true for both domestic terrorism in the US (the Unabomber, for example) and for various other terrorist organizations.
You're right that having poor people with nothing to lose makes it somewhat easier to recruit people to do the dirty work, but the 9/11 hijackers didn't exactly fit the "poor and downtrodden" demographic (largely educated, some had pilot's licenses before they ever got involved, some were already living in the West, etc).
Fully agreed with your second paragraph; I just don't think there's a good way to void such small groups: people will see grievances everywhere, and make some up if there aren't any. :(
Note that the way Dromaeo is scored its scoring is dominated by Sunspider and V8 (which it includes as very high-weight subtests; total weight about 50%-60% of the test or so). So if you're looking for a somewhat independent number from Dromaeo you want to restrict to tests NOT including the Sunspider/V8 ones. I'm not sure Dromaeo makes this easy, though...
Giving the sub-test scores will make it a little clearer what's going on, I agree.
> Why is Spidermonkey implementing non-standard Javascript extensions?
Uh... every single JS impl has implemented these for years; different extensions in different impls. Some of these are making their way into standards; some are not; some are going to end up in standards in a modified form. That's how the standards get written.
In this case, the non-standard extension is the 'g' option for the replace() call on strings. Try this in your favorite web browsers:
javascript:alert("aba".replace('a', 'x', 'g'));
Sunspider uses this flag on some of its replace calls; in Sunspider the string happens to have only one instance of the substring being replaced, so behavior is the same whether the 'g' flag is honored or not. Honoring it obviously takes more work. The particular test using this flag became about 3x faster in Gecko when the flag was removed. See details at http://blog.mozilla.com/dmandelin/2008/10/06/squirrelfishing-in-regexp-dnajs/
The best part is that Apple has removed the flag from their Sunspider core repository, but is refusing to actually update the public test...
> Do they use these extensions on every sub-test, or just some of them?
Only some; I thought I was pretty clear on that.
> It looked like Chrome beat Firefox on all of them.
I never claimed that Chrome isn't very fast on Sunspider. It absolutely is! That just doesn't mean they aren't slow in other cases not covered by popular benchmarks. The same is true in general, of course.
But yes, you're right that the multi-process parts of electrolysis (which this guy didn't enable and hence wasn't testing) have nothing to do with JS performance.
Lags behind Chrome on a particular benchmark (Sunspider). Ignoring for the moment the Sunspider tests that are purposefully slower in SpiderMonkey than in other JS engines (by using extension features that only SpiderMonkey implements and that slow the test down if implemented), that leaves the question of how relevant Sunspider is.
In my testing, Chrome is anywhere from 4x faster to 4x slower than Firefox on various JavaScript/DOM/canvas tasks. It really depends on the task, as expected: if nothing else different jit heuristics will lead to better or worse performance on the same code even if all else is identical.
In fact, Electrolysis aims to have tabs in a separate process from the browser UI as a first cut, then work on separate tabs in separate processes. That's not enabled by default, though, so the guy who wrote this blog post wasn't testing it...