1) JS JITs. These optimize for speed of compilation and speed of generated code; small size of generated code is not really something being optimized for except insofar as it helps one of the other two metrics. In the case of Firefox, just deciding to JIT a little less aggressively late in the 4.0 cycle saved a good bit of memory when JS-heavy pages are open.
2) Images. Sites are using more and more bigger images, in addition to larger and larger scripts. With images you have the options of decompressing on draw (slow, typically) or storing decompressed images in memory (uses lots of memory). Guess which one browsers are typically doing?
3) Leaks in webpages. By this I mean web pages that allocate more and more JS objects and have them all reachable (e.g. by sticking things in an array that's hanging off the Window) so the web page uses more and more memory. gmail did this until recently; they were working on fixing it last I checked. This means that if one of your "few tabs" is gmail and you've had it open for a while a lot of that memory could be actually being used by gmail.
about:memory in Firefox is being improved to make it easier to answer the "what's using the memory" question, at least....
Several hundred, I'd think. Even the small players in the market (Opera and Mozilla) have teams in the 100-200 range (not counting volunteer contributors).
Are we? The "intangible assets" stuff for the Fortune 500 that this discussion sub-thread is about was "patented technology, proprietary data, and market plans". That's not art.
The original article is about art, of course. But most of the Fortune 500 don't make their living off art-related IP.
Think of them more as arbitrators whose job is to get the community to agree on something even when different parts of it want different things to happen.
The reason that CSS is so complex and such a pain to implement is the combinatorial explosion when you have multiple interacting features. The standard has to define how they interact, and UAs have to implement the interactions. Any standard that focuses on features but not their interactions with each other will simply mean that browsers handle interaction of the features differently.... and any standard that actually tries to standardize behavior will be just as complicated as CSS by the time it reaches feature parity.
Note that print layout is much simpler than web layout because you don't have to deal with size changes and because some features are missing in print but present on the web. Something as simple as the interaction of:first-line with a in the first line that changes font size on hover is not an issue print has to deal with, but _is_ an issue that CSS and implementations have to deal with.
Now you're right that CSS was initially designed for document layout and that its facilities for laying out a user interface are pretty much nonexistent. That's being worked on with various CSS3 proposals; we'll see how that goes. And document layout is still needed on the web, of course; not every web page all user interface (many are user interface wrapped around a document).
I actually do think that good music is quite a bit harder to come by than people usually claim. But I think that other sorts of IP are even harder to come by.
The number of Firefox users has gone up quite a bit in the last year.
The percentage of Firefox users has been stable.
The key insight is that the total number of browser users has gone up a lot in the past year...
As for Chrome's market share gains, some of that is because it has some good points and some is because Google is spending insane amount of money on advertizing it.
Oh, IE has its share of bugs. I'm just surprised you haven't run into more problems with Chrome... I mean this is the browser that can't draw a non-opaque border correctly.
The thing to keep in mind is that Firefox 4 is EOL once Firefox 5 ships in June (just like 3.6.0 was EOL once 3.6.1 shipped, and with the same UI interaction: the update just happens, if you have automated updates turned on at all). So yes, when Firefox 6 comes out, Firefox 4 support gets dropped, but by that point Firefox 4 is not getting any more security updates so people shouldn't be using it anyway.
We're talking about correctness here, not feature checklists. Last I checked, there wasn't even an agreed-on syntax for linear gradients. WebKit and Gecko use different syntax for them.
My point being that if you assume that any given browser's rendering of something it claims to support is "correct" you will get burned more with Chrome than with IE. If you have such an expectation for anything from CSS3, you will naturally be doubly burned, because often there is no "correct" for it yet.
I'm glad you prefer the approach of shipping buggy things just so you can list them on your feature checklist. But is it a better approach for web developers? Hard to say.
For what it's worth, IE9 is a better benchmark of "how it should look" than Chrome in many ways. Of the four major rendering engines, WebKit has the buggiest CSS 2.1 support, for example...
Hamas _is_ the de-facto government of Gaza, and is the group that the largest number of Palestinians actually voted for.
The government charter per se means nothing much, since negotiations don't happen with "the Palestinian Government" in practice but with various groups that seize control of it..
Glad you asked for a citation, but you did not say which part... Taking them one at a time:
Murder of all jews: Hamas charter Article 7, last paragraph and following Hadith.
Blames them for being behind wars and revolutions: Hamas charter Article 22 (which explicitly blames "the French Revolution, the Communist revolution and most of the revolutions we heard and hear about, here and there" on the Jews, as well as World War I and World War II).
Protocols of the Elders of Zion: Hamas charter article 32, which says: Their plan is embodied in the "Protocols of the Elders of Zion", and their present conduct is the best proof of what we are saying.
You can get the full text of the Hamas charter at several of the References on http://en.wikipedia.org/wiki/Hamas_Charter but here are two of those just for your convenience:
Or were you talking about some other charter? There are several different charters around in Gaza and the West Bank; the Hamas one is the one for the group that had a plurality (though not majority) of the votes in the one election held so far and the group that is the government of Gaza at the moment.
You're confusing "Mozilla" (like the people who are shipping the Firefox browser) and "Mozilla Labs" (the people whose job it is to brainstorm and come up with ideas, prototype them, and see if they work).
Some Labs ideas end up in the browser after they've been prototyped and the like. Most don't.
The only difference between that and what Apple and Google do is that they keep their prototyping work hidden for the most part, so you don't get articles about all the things they're thinking of trying that then don't pan out.
For what it's worth, the bored teenage prodigy effect has certainly come up at least in Mozilla's case, and 2-3 bug bounties is indeed pretty good money for a teenager!
> I also think it's the esoteric platforms which stand to > gain the most from platform neutrality
Yes, but the point is that NaCl and PNaCl are both less platform-neutral than JavaScript. So it seems like time is better invested in JavaScript performance than trying to make PNaCl be more popular if you're actually interested in platform neutrality.
It's actually really easy to accidentally write C that works on x86 but not ARM. And even easier to write C that works on x86 but not, say ia64. Especially if multiple threads or any sort of type punning are involved.
> and after all, if you have an x86 library, it's probably > portable to x86_64, ppc, arm, etc
I feel like I'm missing something. What makes you think random x86 code is probably portable to arm? My experience is that it's not, unless you put in a LOT of work....
Except that LLVM is generally not hardware agnostic (or more precisely, there's a more or less hardware-agnostic subset, but you can't really compile C to it). So what you end up having to do is compile to something hardware-dependent and then if the actual hardware doesn't match deal somehow (the PNaCl plan). That "somehow" is the bad part...
In brief, NaCl seems like a good way to try to lock the web into a particular set of allowed client hardware. That's NOT a good thing.
Note that even if you just stick to reporting "known facts" your choice of which exact facts to report will nearly always bias the reporting. And you can't report "all the facts", because you have limited time.
Slashdot Mirror
There are several things going on here:
1) JS JITs. These optimize for speed of compilation and speed of generated code; small size of generated code is not really something being optimized for except insofar as it helps one of the other two metrics. In the case of Firefox, just deciding to JIT a little less aggressively late in the 4.0 cycle saved a good bit of memory when JS-heavy pages are open.
2) Images. Sites are using more and more bigger images, in addition to larger and larger scripts. With images you have the options of decompressing on draw (slow, typically) or storing decompressed images in memory (uses lots of memory). Guess which one browsers are typically doing?
3) Leaks in webpages. By this I mean web pages that allocate more and more JS objects and have them all reachable (e.g. by sticking things in an array that's hanging off the Window) so the web page uses more and more memory. gmail did this until recently; they were working on fixing it last I checked. This means that if one of your "few tabs" is gmail and you've had it open for a while a lot of that memory could be actually being used by gmail.
about:memory in Firefox is being improved to make it easier to answer the "what's using the memory" question, at least....
If I go to print a page and just print it, it's pretty common to get 3 pages of print out, with my content on the first page and ads on the other two.
Preview lets me see that and decide to print only the first page, or some other range of pages.
Several hundred, I'd think. Even the small players in the market (Opera and Mozilla) have teams in the 100-200 range (not counting volunteer contributors).
Are we? The "intangible assets" stuff for the Fortune 500 that this discussion sub-thread is about was "patented technology, proprietary data, and market plans". That's not art.
The original article is about art, of course. But most of the Fortune 500 don't make their living off art-related IP.
Think of them more as arbitrators whose job is to get the community to agree on something even when different parts of it want different things to happen.
Have you ever tried writing a standard?
It took so long to finalize CSS 2.1 for two reasons:
1) There's a lot of complicated behavior the standard had to describe.
2) One of the criteria for a W3C REC nowadays is that there are two independent correct implementations of every part of the standard.
BASIC from the 80s is dead-simple in comparison, and probably still fails the criterion above. ;)
The reason that CSS is so complex and such a pain to implement is the combinatorial explosion when you have multiple interacting features. The standard has to define how they interact, and UAs have to implement the interactions. Any standard that focuses on features but not their interactions with each other will simply mean that browsers handle interaction of the features differently.... and any standard that actually tries to standardize behavior will be just as complicated as CSS by the time it reaches feature parity.
Note that print layout is much simpler than web layout because you don't have to deal with size changes and because some features are missing in print but present on the web. Something as simple as the interaction of :first-line with a in the first line that changes font size on hover is not an issue print has to deal with, but _is_ an issue that CSS and implementations have to deal with.
Now you're right that CSS was initially designed for document layout and that its facilities for laying out a user interface are pretty much nonexistent. That's being worked on with various CSS3 proposals; we'll see how that goes. And document layout is still needed on the web, of course; not every web page all user interface (many are user interface wrapped around a document).
I actually do think that good music is quite a bit harder to come by than people usually claim. But I think that other sorts of IP are even harder to come by.
There are different kinds of intangibles.
There's no scarcity of people capable of creating music.
There's a comparative scarcity of people capable of designing a new lithography process or new device architecture or new algorithm.
The number of Firefox users has gone up quite a bit in the last year.
The percentage of Firefox users has been stable.
The key insight is that the total number of browser users has gone up a lot in the past year...
As for Chrome's market share gains, some of that is because it has some good points and some is because Google is spending insane amount of money on advertizing it.
Oh, IE has its share of bugs. I'm just surprised you haven't run into more problems with Chrome... I mean this is the browser that can't draw a non-opaque border correctly.
The thing to keep in mind is that Firefox 4 is EOL once Firefox 5 ships in June (just like 3.6.0 was EOL once 3.6.1 shipped, and with the same UI interaction: the update just happens, if you have automated updates turned on at all). So yes, when Firefox 6 comes out, Firefox 4 support gets dropped, but by that point Firefox 4 is not getting any more security updates so people shouldn't be using it anyway.
Or they could switch to a release of Firefox from sometime after the flood...
We're talking about correctness here, not feature checklists. Last I checked, there wasn't even an agreed-on syntax for linear gradients. WebKit and Gecko use different syntax for them.
My point being that if you assume that any given browser's rendering of something it claims to support is "correct" you will get burned more with Chrome than with IE. If you have such an expectation for anything from CSS3, you will naturally be doubly burned, because often there is no "correct" for it yet.
I'm glad you prefer the approach of shipping buggy things just so you can list them on your feature checklist. But is it a better approach for web developers? Hard to say.
For what it's worth, IE9 is a better benchmark of "how it should look" than Chrome in many ways. Of the four major rendering engines, WebKit has the buggiest CSS 2.1 support, for example...
JS VMs are far from state of the art compared to, say, Java VMs. They're working on it, though...
Hamas _is_ the de-facto government of Gaza, and is the group that the largest number of Palestinians actually voted for.
The government charter per se means nothing much, since negotiations don't happen with "the Palestinian Government" in practice but with various groups that seize control of it..
Glad you asked for a citation, but you did not say which part... Taking them one at a time:
Murder of all jews: Hamas charter Article 7, last paragraph and following Hadith.
Blames them for being behind wars and revolutions: Hamas charter Article 22 (which explicitly blames "the French Revolution, the Communist revolution and most of the revolutions we heard and hear about, here and there" on the Jews, as well as World War I and World War II).
Protocols of the Elders of Zion: Hamas charter article 32, which says: Their plan is embodied in the "Protocols of the Elders of Zion", and their present conduct is the best proof of what we are saying.
You can get the full text of the Hamas charter at several of the References on http://en.wikipedia.org/wiki/Hamas_Charter but here are two of those just for your convenience:
http://www.fas.org/irp/world/para/docs/880818a.htm
http://www.mideastweb.org/hamas.htm
http://avalon.law.yale.edu/20th_century/hamas.asp
Or were you talking about some other charter? There are several different charters around in Gaza and the West Bank; the Hamas one is the one for the group that had a plurality (though not majority) of the votes in the one election held so far and the group that is the government of Gaza at the moment.
You're confusing "Mozilla" (like the people who are shipping the Firefox browser) and "Mozilla Labs" (the people whose job it is to brainstorm and come up with ideas, prototype them, and see if they work).
Some Labs ideas end up in the browser after they've been prototyped and the like. Most don't.
The only difference between that and what Apple and Google do is that they keep their prototyping work hidden for the most part, so you don't get articles about all the things they're thinking of trying that then don't pan out.
For what it's worth, the bored teenage prodigy effect has certainly come up at least in Mozilla's case, and 2-3 bug bounties is indeed pretty good money for a teenager!
> LLVM would not preclude anything over any modern
> processor
http://llvm.org/docs/FAQ.html#platformindependent and the references to "not supported by all targets" in http://llvm.org/docs/LangRef.html seem to beg to differ.
> I also think it's the esoteric platforms which stand to
> gain the most from platform neutrality
Yes, but the point is that NaCl and PNaCl are both less platform-neutral than JavaScript. So it seems like time is better invested in JavaScript performance than trying to make PNaCl be more popular if you're actually interested in platform neutrality.
It's actually really easy to accidentally write C that works on x86 but not ARM. And even easier to write C that works on x86 but not, say ia64. Especially if multiple threads or any sort of type punning are involved.
> and after all, if you have an x86 library, it's probably
> portable to x86_64, ppc, arm, etc
I feel like I'm missing something. What makes you think random x86 code is probably portable to arm? My experience is that it's not, unless you put in a LOT of work....
Except that LLVM is generally not hardware agnostic (or more precisely, there's a more or less hardware-agnostic subset, but you can't really compile C to it). So what you end up having to do is compile to something hardware-dependent and then if the actual hardware doesn't match deal somehow (the PNaCl plan). That "somehow" is the bad part...
In brief, NaCl seems like a good way to try to lock the web into a particular set of allowed client hardware. That's NOT a good thing.
Note that even if you just stick to reporting "known facts" your choice of which exact facts to report will nearly always bias the reporting. And you can't report "all the facts", because you have limited time.