Or uses a malloc implementation that never gives back null pointers (calling abort() instead). That's basically what large parts of WebKit and Gecko do at this point.
For Firefox and Safari, part of the difference is that they're 64-bit applications on Mac and 32-bit applications on Windows.
For Chrome and Opera, that's not an issue, since they're 32-bit both places.
Past that, Windows and Mac use different font and graphics subsystems. That's a pretty large chunk of memory usage right there that'll be very different. There might also be differences in allocations in various other system libraries.
I agree the result is interesting though, and having an idea of how much of it is attributable to which factor would be good. An apples-to-apples (so to say) comparison using a recent Firefox nightly with jemalloc on both Windows and Mac, running in 32-bit mode on Mac, might be interesting.
You should read the article, which actually touches on this. One issue is that a "memory leak" can include memory that does in fact get released at shutdown, especially in garbage-collected systems (not a problem in C, of course).
So you can have situations where you close a tab but its memory is kept alive for a while because an extension is referencing it. Not a leak in the C sense, but a leak in the sense the user cares about.
Little IDE support is helped by building IDEs, not coming up with a new language that has even less IDE support.
Dart doesn't do type safety by default. There have been proposals to add optional type annotations of the sort Dart _does_ have to JS... and they were shot down by certain members of the JS standards committee, last I checked. Don't recall what the stance of Google's representatives on it was, but they weren't the ones pushing it.
As far as a compile phase goes, Dart doesn't have one either unless you're cross-compiling it to JavaScript. You just load your Dart code directly in the browser, which then compiles it. That's what browsers do with JS too.
So ignoring for the moment whether these things are good or not, I don't see Dart making much of an improvement over JS here, except in the type-safety department, where Google didn't exactly try to improve JS in the first place.
I was talking about the rate at which changes are made to the codebase. The frequency at which you tag, branch, and release is somewhat independent of that.
One more note. Chrome doesn't do any sort of extended support. MSIE does extended support, but only for critical security bugs. They don't backport security features and infrastructure improvements to old releases. So IE9 is in fact more secure than IE8, which is more secure than IE7, which is more secure than IE6, even though all four are supported and all get security fixes.
Is there a reason you think Mozilla should be held to some sort of higher standard here? Do you hold yourself to such a standard for the software you ship?
The ESR will almost certainly not get new security _features_. Especially because these often break some websites, and the whole reason for the ESR is so large organizations have a way to deploy something that won't break their intranet sites.
I'd hope the difference would be clear. But apparently it's easier to call people names than to think.
I think you underestimate the number of components a web browser has. Most Mozilla code has 1-3 people who actually deal with it on a regular basis, as far as I can tell.
There are lots of parts to "the architecture". New GC algorithm? Arch change. Changes to how selector matching works, another arch change.
Browsers implement a several dozen specifications and in-progress specifications. If you figure there are major improvements to support for each one once every two years or so, that comes out to 2-3 such improvements per month.
Supported software doesn't get all bug fixes. Certainly not if it's supposed to not change outward behavior. For example, the ESR would pretty much by definition not get HTML/JS/CSS/etc spec compliance bug fixes.
It would also not get memory leak fixes if those affect extension compat or involve a new GC architecture or anything else major... Simple self-contained memory leak fixes might get backported, of course.
Oh, I understand perfectly why a managed deployment environment might want an LTS release, both to ease deployment and for the practical "well, we tested it against the things we knew about" bit.
My point was that not updating your browser for 2 years right now will leave you with a browser that's considered hopelessly insecure by the standards of the day (not preventing entire new classes of attacks, etc), even if you patch actual exploitable security holes that come up.
The LTS would include critical security fixes. It wouldn't include all minor security fixes or general architectural improvements that improve security-in-depth, because typically those have visible effects and the whole point of the LTS is to avoid such effects. Or put another way, "does not make changes to the Web or Firefox Add-ons platform" excludes a wide range of security improvements.
To be more specific, fixing an exploitable crash is LTS material. Adding JIT hardening or process separation or something like HTTP Strict Transport security or UI changes to improve the ability of users to make informed security decisions are all not LTS material.
Then you would be hurting those regular users, since the ESR will almost certainly be less secure than the regular version; the longer into its year of life you get the more this will be true.
> Shouldn't Firefox instead concentrate on not > invalidating Addons for EVERYONE?
That change is in Firefox 10, shipping in less than 3 weeks.
But "enterprises" (which includes schools and libraries, not just corporations) care about things other than extensions; they have all these intranet apps to worry about too, which normal users do not have to deal with. And intranet apps have a tendency to be coded like it's 1999 (heavy dependence on browser bugs and nonstandard features, targeting only one browser version, etc, etc)
I agree that for the general web this is suboptimal; that's why Mozilla didn't want to do it initially...
On the other hand, it's hard to say which is better for the general web: libraries and schools being able to use Firefox ESR or there being no ESR version of Firefox but libraries and schools being stuck on IE8.
This would be somewhat bad, because the ESR will almost certainly be less secure than regular releases. It'll get fixes for critical security bugs, but will _not_ get architecture changes designed to improve security in depth, pretty much by definition.
Er... Browsers are adding security improvements and features at a much much faster rate now than in the 2002-2009 timeframe. This is true at least for Microsoft, Mozilla, and Google.
In the specific case of Mozilla, it has about 60x more employees now than in 2002 (and 3x what it had in 2009). It would be _really_ odd if improvement rate were actually slower as a result, since the codebase was already quite mature in 2002.
I believe the 3.6 requirements just hadn't been updated in a few years and were more or less totally bogus. When 4 shipped, the requirements were updated to reflect reality.
> Because the Pepper API is a much more achievable > target than the entirety of Win32.
That's not saying much.
The Pepper API is tied to various details of how V8 and WebKit interact, from what I've seen, and has no sane definition other than the implementation. Attempting to actually duplicate it would require enormous resources. Probably less than duplicating win32, but the latter is actually a semi-solved problem (see Wine project).
Which are not so much documented; the only documentation is the implementation. How is that different from Win32?
> and runs under Windows, OS X, and Linux.
That's not all that interesting a metric. More interesting to me is that it only runs on certain hardware platforms, by design, so if it takes off that means no new hardware platforms can arise that can use the web.
Or put another way, if this had happened in 1998, ARM-based phones would have been a non-starter.
> Work is underway to make Native Client work > across multiple architectures
Google's interest is in tying users to their services (search, gmail, Google docs, etc) so they can deliver advertising.
This may or may not coincide with moving the web forward as a whole. In the past it often has. Right now, a lot of the things Google is doing are harmful to the future of the web but good for Google services.
> Google has long experimented with non-standard > APIs in order to stimulate progress.
"progress" is not a single thing. Google is only interested in the forms of "progress" that benefit them. As long as those forms also benefit their competitors, things are not too bad. But I don't expect that to continue for much longer...
The whole issue with Native Client is that it is NOT independent of platform. You have to specifically compile for particular hardware architectures; whichever ones your server doesn't have binaries for won't work.
The patent is about inferring the religion of person B based on the wrapping paper person A uses for a gift he buys for person B.
It doesn't matter whether person A in the above scenario is Jewish, unless you think he would use Hanukkah-themed wrapping paper for Christmas gifts for his Christian friends.
> they make general internet usage--and by extension > ALL Google sites--work better.
That's where they started.
Now they are specifically trying to make Google sites work particularly well with Chrome (and in some cases only with WebKit), even if that has to happen at the expense of other browsers. They are also trying to make Chrome work particularly well with their own sites, even if that comes at the expense of other sites, of course.
> Microsoft thought it could control the web to lock > people into proprietary software.
And Google thinks they can lock users into their websites and their app store, and if it takes switching them to their browser first, that just means they should try to stealth-install that browser on as many computers as possible.
People who don't want to waste the time to load google.com. It's a lot faster to have one server round-trip than two, esp. on high-latency (e.g. mobile) networks.
Slashdot Mirror
Or uses a malloc implementation that never gives back null pointers (calling abort() instead). That's basically what large parts of WebKit and Gecko do at this point.
For Firefox and Safari, part of the difference is that they're 64-bit applications on Mac and 32-bit applications on Windows.
For Chrome and Opera, that's not an issue, since they're 32-bit both places.
Past that, Windows and Mac use different font and graphics subsystems. That's a pretty large chunk of memory usage right there that'll be very different. There might also be differences in allocations in various other system libraries.
Further, "the same memory allocations" can lead to very different results when different allocators are used. See http://pavlovdotnet.wordpress.com/2007/12/06/more-allocator-data-tcmalloc-edition/ and http://pavlovdotnet.wordpress.com/2007/12/04/vlad-and-analysis-of-dtrace-was-used/ for some data from a few years ago using different allocators for Firefox on Windows. At least for the Firefox version tested there the allocators are different on Windows and Mac: the Mac version uses the system allocator while the Windows version uses jemalloc. Newer versions use jemalloc on Mac as well.
I agree the result is interesting though, and having an idea of how much of it is attributable to which factor would be good. An apples-to-apples (so to say) comparison using a recent Firefox nightly with jemalloc on both Windows and Mac, running in 32-bit mode on Mac, might be interesting.
You should read the article, which actually touches on this. One issue is that a "memory leak" can include memory that does in fact get released at shutdown, especially in garbage-collected systems (not a problem in C, of course).
So you can have situations where you close a tab but its memory is kept alive for a while because an extension is referencing it. Not a leak in the C sense, but a leak in the sense the user cares about.
Little IDE support is helped by building IDEs, not coming up with a new language that has even less IDE support.
Dart doesn't do type safety by default. There have been proposals to add optional type annotations of the sort Dart _does_ have to JS... and they were shot down by certain members of the JS standards committee, last I checked. Don't recall what the stance of Google's representatives on it was, but they weren't the ones pushing it.
As far as a compile phase goes, Dart doesn't have one either unless you're cross-compiling it to JavaScript. You just load your Dart code directly in the browser, which then compiles it. That's what browsers do with JS too.
So ignoring for the moment whether these things are good or not, I don't see Dart making much of an improvement over JS here, except in the type-safety department, where Google didn't exactly try to improve JS in the first place.
I was talking about the rate at which changes are made to the codebase. The frequency at which you tag, branch, and release is somewhat independent of that.
One more note. Chrome doesn't do any sort of extended support. MSIE does extended support, but only for critical security bugs. They don't backport security features and infrastructure improvements to old releases. So IE9 is in fact more secure than IE8, which is more secure than IE7, which is more secure than IE6, even though all four are supported and all get security fixes.
Is there a reason you think Mozilla should be held to some sort of higher standard here? Do you hold yourself to such a standard for the software you ship?
The ESR will get security patches.
The ESR will almost certainly not get new security _features_. Especially because these often break some websites, and the whole reason for the ESR is so large organizations have a way to deploy something that won't break their intranet sites.
I'd hope the difference would be clear. But apparently it's easier to call people names than to think.
I think you underestimate the number of components a web browser has. Most Mozilla code has 1-3 people who actually deal with it on a regular basis, as far as I can tell.
There are lots of parts to "the architecture". New GC algorithm? Arch change. Changes to how selector matching works, another arch change.
Browsers implement a several dozen specifications and in-progress specifications. If you figure there are major improvements to support for each one once every two years or so, that comes out to 2-3 such improvements per month.
Supported software doesn't get all bug fixes. Certainly not if it's supposed to not change outward behavior. For example, the ESR would pretty much by definition not get HTML/JS/CSS/etc spec compliance bug fixes.
It would also not get memory leak fixes if those affect extension compat or involve a new GC architecture or anything else major... Simple self-contained memory leak fixes might get backported, of course.
Oh, I understand perfectly why a managed deployment environment might want an LTS release, both to ease deployment and for the practical "well, we tested it against the things we knew about" bit.
My point was that not updating your browser for 2 years right now will leave you with a browser that's considered hopelessly insecure by the standards of the day (not preventing entire new classes of attacks, etc), even if you patch actual exploitable security holes that come up.
The LTS would include critical security fixes. It wouldn't include all minor security fixes or general architectural improvements that improve security-in-depth, because typically those have visible effects and the whole point of the LTS is to avoid such effects. Or put another way, "does not make changes to the Web or Firefox Add-ons platform" excludes a wide range of security improvements.
To be more specific, fixing an exploitable crash is LTS material. Adding JIT hardening or process separation or something like HTTP Strict Transport security or UI changes to improve the ability of users to make informed security decisions are all not LTS material.
Then you would be hurting those regular users, since the ESR will almost certainly be less secure than the regular version; the longer into its year of life you get the more this will be true.
> Shouldn't Firefox instead concentrate on not
> invalidating Addons for EVERYONE?
That change is in Firefox 10, shipping in less than 3 weeks.
But "enterprises" (which includes schools and libraries, not just corporations) care about things other than extensions; they have all these intranet apps to worry about too, which normal users do not have to deal with. And intranet apps have a tendency to be coded like it's 1999 (heavy dependence on browser bugs and nonstandard features, targeting only one browser version, etc, etc)
I agree that for the general web this is suboptimal; that's why Mozilla didn't want to do it initially...
On the other hand, it's hard to say which is better for the general web: libraries and schools being able to use Firefox ESR or there being no ESR version of Firefox but libraries and schools being stuck on IE8.
This would be somewhat bad, because the ESR will almost certainly be less secure than regular releases. It'll get fixes for critical security bugs, but will _not_ get architecture changes designed to improve security in depth, pretty much by definition.
Er... Browsers are adding security improvements and features at a much much faster rate now than in the 2002-2009 timeframe. This is true at least for Microsoft, Mozilla, and Google.
In the specific case of Mozilla, it has about 60x more employees now than in 2002 (and 3x what it had in 2009). It would be _really_ odd if improvement rate were actually slower as a result, since the codebase was already quite mature in 2002.
I believe the 3.6 requirements just hadn't been updated in a few years and were more or less totally bogus. When 4 shipped, the requirements were updated to reflect reality.
As long as you're willing to tie your app to particular hardware platforms.
Which is terrible for the future of the web, of course.
> Because the Pepper API is a much more achievable
> target than the entirety of Win32.
That's not saying much.
The Pepper API is tied to various details of how V8 and WebKit interact, from what I've seen, and has no sane definition other than the implementation. Attempting to actually duplicate it would require enormous resources. Probably less than duplicating win32, but the latter is actually a semi-solved problem (see Wine project).
> Native Client now uses the new Pepper APIs
Which are not so much documented; the only documentation is the implementation. How is that different from Win32?
> and runs under Windows, OS X, and Linux.
That's not all that interesting a metric. More interesting to me is that it only runs on certain hardware platforms, by design, so if it takes off that means no new hardware platforms can arise that can use the web.
Or put another way, if this had happened in 1998, ARM-based phones would have been a non-starter.
> Work is underway to make Native Client work
> across multiple architectures
If that actually happens, we can revisit the discussion. So far, a number of the LLVM folks are pretty doubtful. See http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html for example.
> Google's interest is in moving the web forward.
Google's interest is in tying users to their services (search, gmail, Google docs, etc) so they can deliver advertising.
This may or may not coincide with moving the web forward as a whole. In the past it often has. Right now, a lot of the things Google is doing are harmful to the future of the web but good for Google services.
> Google has long experimented with non-standard
> APIs in order to stimulate progress.
"progress" is not a single thing. Google is only interested in the forms of "progress" that benefit them. As long as those forms also benefit their competitors, things are not too bad. But I don't expect that to continue for much longer...
The whole issue with Native Client is that it is NOT independent of platform. You have to specifically compile for particular hardware architectures; whichever ones your server doesn't have binaries for won't work.
The patent is about inferring the religion of person B based on the wrapping paper person A uses for a gift he buys for person B.
It doesn't matter whether person A in the above scenario is Jewish, unless you think he would use Hanukkah-themed wrapping paper for Christmas gifts for his Christian friends.
> they make general internet usage--and by extension
> ALL Google sites--work better.
That's where they started.
Now they are specifically trying to make Google sites work particularly well with Chrome (and in some cases only with WebKit), even if that has to happen at the expense of other browsers. They are also trying to make Chrome work particularly well with their own sites, even if that comes at the expense of other sites, of course.
> Microsoft thought it could control the web to lock
> people into proprietary software.
And Google thinks they can lock users into their websites and their app store, and if it takes switching them to their browser first, that just means they should try to stealth-install that browser on as many computers as possible.
> How do you make apps for Boot 2 Gecko?
Just like you make websites.
There will be some sort of APIs for doing things that need expanded privileged, but those will be proposed for standardization just like any web API.
People who don't want to waste the time to load google.com. It's a lot faster to have one server round-trip than two, esp. on high-latency (e.g. mobile) networks.