> Nobody is stopping you from installing anything else.
This is true for their desktop products, but iOS makes anything Microsoft ever did seem pretty tame by comparison. Compare the differences between trying to use a non-Trident browser on Windows at any point in time and trying to use a non-mobile-Safari browser (in terms of the rendering engine, not the user interface; the mobile Safari rendering engine is no a vanilla WebKit).
> it has gained so much share in a far far shorter time > than Mozilla took.
There are two important differences:
1) Chrome is operating in an environment where websites are NOT just authoring to IE anymore; site compat is somewhat easier to come by and hence user adoption is easier.
2) Chrome has had a huge marketing campaign going for it starting the monent it was released. It's advertised in huge and expensive ad campaigns on subways. It's advertised on Google's web properties. It's advertised via banner ads all over the internet. Mozilla back when it started just didn't have the financial resources for an ad campaign like that. Heck, I don't think it has them now. I'd be interested in comparing the amount of money it would take to purchase the various Chrome yearly advertising (including the Google property placements, which are being provided in-kind and not for cash, of course) on the market to Mozilla's total yearly budget. Based on what I've seen, I would not be surprised if the first number is higher. So Mozilla had to depend on word-of-mouth, which depends on how many users you have, which was small at the time.
> Even nontechs/nonnerds are downloading and > installing Google Chrome
Right, but how did they find out that it even exists to go download? This was the major problem Mozilla and Firefox faced initially, and that's where the huge marketing campaign really helps.
Spent fuel is an interesting discussion topic; I'll believe in people in the US taking it seriously when they take the already-available mitigation steps that other countries take routinely: reprocessing.
As it is, the spent fuel situation is that we're told that the obvious thing that will reduce the amount of waste significantly is off the table, and then we suddenly have large amounts of waste to deal with, surprisingly.
Well, of course! That's always the question. Pretty much anything we do means more people will die. More people flying on airplanes means higher levels of radiation exposure and more cancer deaths. More people driving cars means more accidents and more deaths. More people walking outside (or on stairs, as I said) means more falls and more deaths; several thousand per year just in the over-65 demographic in the US. More people getting CT scans leads to more cancer. The real question is one of risks and benefits. For the record, I think our use of CT scans is pretty suspect, and a good bit worse than what I've been able to find so far in terms of contamination from this accident outside the evacuation zone, but maybe you have other numbers?
In case it's not clear, I think that just saying "it increases risk" without quantifying that is fear-mongering. Of course it increases risk.
> Also, the explosion most certainly distributed > plutonium and uranium into the local area.
Maybe I missed part of the news here. Which explosion are we talking about? The one hydrogen explosion that blew away the outer reactor building, or some other explosion?
If you have a reference for this, I would be very interested.
> short half-life elements tend to be more dangerous.
Simply because ipso facto they have higher radioactivity levels per atom (they're decaying faster, after all).
For a given activity level, what matters is the kind of decay, not the half-life, since all the half-life does is affect the activity level. Alpha decays are easy to handle; gamma decays are the hard kind to deal with.
Cs-137, which I presume is the major cesium isotope we're worried about here, is bad stuff because it's _medium_ half-life (30 years or so), and the decay chain includes gamma rays very soon after the cesium itself decays. I agree that significant quantities of cesium-137 release is a serious problem.
I-131, which is again presumably the iodine you're talking about, is not nearly as bad as long as you don't eat it. Japan _has_ been testing food outside the quarantine area for iodine, as well as testing children, and things are looking ok so far from the articles I've read. Again, maybe you have references to specific issues that I've missed here? Note that I-131 has a half-life of only 8 days, so the concentration drops rapidly on a timescale of several months. As long as the quantities released are not huge and it doesn't disperse widely, this problem will solve itself.
> Somehow I doubt thousands have died from a > damn
If you meant "dam", then you should have read the article I linked to. 90,000--230,000 dead (no one actually bothered to count for sure) dead from one single dam accident.
> Because the coal plant doesn't explode so > violently that a plume of radioactive material > (including cesium and radioactive iodine) into the > atmosphere.
Uh... Coal plants put radioctive material into the atmosphere all the time. It's a lower level per plant than a Chernobyl-style explosion, but we have a _lot_ of coal plants. And Fukushima is nothing like Chernobyl, again unless I missed a major piece of news here. If you haven't before, you may want to read http://en.wikipedia.org/wiki/Radioactive_waste#Coal (it's a very short read).
> Industrial accidents which are far easier to > mitigate
Are they, now? Data, please? Or is this a gut feeling?
> and only affect a small area around the factory.
So in other words, deaths are ok as long as they're not in your backyard and preferably not in your country? C'mon now.
> From the mining of the ore, to the processing, > power production, reprocessing and eventual > disposal.
Except for disposal, those are all "production and operation".
Disposal is a problem, but since we're not even takin
> The increase in background radiation will > absolutely cause a raise in cancers
Increase in background radiation where? Do you have numbers to cite here?
> there's the matter of radioactive material put into > environment
Details? Which isotopes are we talking about? Is it worse than your typical coal plant operating for a month?
> Radioactive elements can never be made safe.
That's just not true. For example, oxygen-15 makes itself safe in a matter of hours (half-life of 120s with decay to a stable nitrogen isotope). A large fraction of the radioactive release from Fukushima has been elements like that.
Now maybe what you mean is that long-half-life isotopes can't really be made safe. I agree; the goal would be to prevent them escaping the containment vessel.
> Solar, wind, and hydrothermal are much safer.
I'd _love_ to see numbers for this, on comparable scales.
That is, how safe or unsafe is your typical solar plant generating 0.8GW (which is what each of the reactors at Fukushima was generating)? How safe is your typical wind plant of that capacity? Whole-life numbers (i.e. including construction and maintenance) would be good. Problem is, no one actually tracks that stuff, so we don't have those numbers....
> that would otherwise plague a small area around > the plant
Uh... you can't have it both ways. If pollution from coal plants (including the radioactive elements they put in the air) is localized to a "small area", how is that not the case for nuclear?
> But since the deaths from nuclear are primarily > cancers
Citation please?
> The best you can do is mitigate the risks.
This is true for all power-generation setups. The only question is when in the life cycle the highest risks are. For photovoltaic solar, for example, it seems to me that they are primarily at the solar cell production stage and the related industrial accidents. For hydroelectric they're when your dam is operating (http://en.wikipedia.org/wiki/Banqiao_Dam is a good read). For nuclear there's the initial uranium purification or plutonium production and operating risks. But yes, risk-mitigation is the name of the game. That's how life in general works: walking down stairs is unsafe. People die from it all the time. We do it all the time, but we put in handrails and people who're particularly susceptible to the risk get single-floor houses...
You estimate for the number of CS graduates per year from CMU is about right (the school of computer science is 500-600 undergrads from the numbers I can find, but they have a computation biology major, and a music and technology one, and an a "computer science and arts" one in addition to straight computer science).
But yes, I would fully expect that a majority of CMU's CS graduates go into engineering (perhaps after doing a masters degree), not pure CS.
If they all die, then there will be no computer scientists to fill the few positions where they _are_ needed, so there will be demand for some computer science programs.
Or did you mean that _most_ of them would die? Maybe all but the very best two or three? If so, seems like CMU might have a good chance of staying around as a computer science program. If this were some random state school making the change, your argument would carry more weight.... (I think it would still be somewhat off, but it's _definitely_ off for CMU.)
The problem is that OCSP as currently implemented doesn't really work, precisely because of the two problems you describe (vulnerability if OCSP checks are nonfatal, failure to connect if they are). In fact, there are places where all OCSP is effectively blocked (airport wireless networks before you've paid, say, and paying requires SSL, so if OCSP is fatal then you can't pay). As a result, browsers default to non-fatal OCSP checks (with Chrome having a small unobtrusive warning if the check fails, which I fully expect that users ignore).
The warning approach would work for you, but not for most people, who have no idea what OCSP is or what to do with a warning about it, unfortunately. Either the warning would be unobtrusive and missed or look like an error page kinda thing, and confuse people...
The problem is that there is no system API for low-level accelerated 2d graphics on OS X. So the only way to do it is to roll your own. The plan is to do just that on top of OpenGL, but that's a big project.
The only way to issue a cert with the same private key as another cert is to know that private key. If you know the private key and you know the certificate the server sends in response to an SSL request, then you can simply impersonate the server's existing certificate right now. In other words, a "certificate" is a pair consisting of a private key and the public bits that the SSL server puts on the wire when you connect to it. Everyone knows the latter, so "all" you need to MITM is to know the former.
Right now, if someone creates a fake cert for a domain it'll have the right domain name but a different key pair from the real cert for that domain. Again, being able to issue a fake cert with the same key pair means you don't need a "fake" cert; you just have the real one!
You're right that if this proposal were implemented, then the "new certificate" alert would need to only happen in cases when the key pair for a hostname changes. But that seems eminently doable.
Actually, the author does address that. They key is that the private key would not change when the certificate changes. Unless the MiM has cracked the old cert (in which case you're screwed no matter what), they couldn't impersonate an update that keeps the same private key.
> Do you really think MS has tried their best with IE?
I have no idea what "their best" is. I do think that over the last 4 years or so they've clearly written a large amount of high-quality code. That takes a good bit of effort.
Of course for the 5 years before that they did absolutely nothing.
> but browser standards just happen to be > their weak point
In none of the things you list have they recently had to enter a mature market and build a team from scratch, except game consoles. And how long did it take them to ship a good one?
> The PNG transparency bug in IE6 could have > been fixed overnight. The CSS bugs could have > been fixed in a week.
I find it very hard to take you seriously if you really think that. Have you ever tried implementing CSS? (I have, for what it's worth; it's not that easy even in a clean implementation, much less in a legacy codebase.)
> And Konqueror was ahead of IE in the area of > browser standards for years
Sure, the years when IE wasn't being developed at all. What bearing does that have on the changes from IE8 to IE9, which are the topic of discussion here?
Note also that IE6 was way ahead of Konqueror in _functionality_. It happened that a lot of it was non-standard, but that doesn't mean it didn't exist.
I think you'd have to look hard to find someone who thinks that the IE7 schedule was the best Microsoft could do. But either you haven't been paying any attention at all in the last 2 years, or you're rather mis-informed if you think that what's currently going on with IE is anything like what was happening in 2003.
1) Money does not translate immediately into a working team. See The Mythical Man-Month. Getting together a team that can effectively develop a large system just takes time. Especially if you have a legacy codebase to deal with.
2) I think you overestimate how easy it is to make use of some other rendering engine without just using it in its entirety. And IE can't just use webkit or Gecko wholesale because of compatibility issues: sites sniff for IE and do various crazy IE-specific stuff that they therefore need to keep supporting but isn't supported in Webkit or Gecko. There's also the fact that Trident does some things that are important to some of Microsoft's markets (e.g. vertical text, in East Asia) that neither Webkit nor Gecko do at the moment.
All that you're seeing is that it's been a while since the last Safari release. Webkit has kept being developed, and Chrome has been using those newer Webkit versions, but there has been no Safari released with the newer Webkit.
On Linux, Chrome does almost all of its painting itself, in software. Firefox, on the other hand, tries to play nice and hand of painting to the X server, using XRender.
Sometimes this works really well, XRender is able to hand the painting off to the graphics card, and you get performance comparable to what you see with IE9/Fx4 on Windows.
But sometimes the graphics driver decides to do the work in software anyway. And they tend to have pretty slow software fallback paths; much slower than Chrome's software renderer.
It sounds like you're hitting one of those situations.
Using a different video driver may help. But the only options for Firefox here are to either do what Chrome does and do it all in software (slower for some people, faster for others), hope driver manufacturers get their act together, or stop using XRender (and try to do everything in GL, say). At the moment that third plan is being followed, but it'll take some work to get there.
The stats show 108,749 downloads to date for Australia. The population of Australia is about 22.5 million according to . So figure one in 200 people has downloaded in Australia.
The same states show 2 million downloads for the US, with a population of about 300 million people; one in 150 has downloaded.
This is over one Australian day and 1.5 nights, and 1.5 US days and one night.
Seems like pretty similar download rates to me.
I suspect people seriously overestimate how many people live in Australia. For comparison, the population of the Netherlands is 16 million, and that of Belgium is 10 million, so between them they have almost 20% more people than Australia does.
Now Japan, I agree; there are 339,157 downloads for a population of 130 million or so. That's about half the US rate.
You're using testing builds. Nothing wrong with that, but they don't guarantee the same stability that the release does. On the other hand, you get new features sooner. Some of us like that.;)
> I can't believe it is due to a lack of talent or resources
Why not? They had a _lot_ of catching up to do, and just throwing more people at the problem if they're not already experts on it doesn't help.
I think the fact that MS hasn't caught up yet is all due to resource constraints on the IE team. They're working on it, but they had a good long way to go.
Africa for the most part has no internet connections.
Japan and Australia are in the middle of the night right now. As of when you posted your comment, it's 1:39am in Tokyo and 3:39am in Sydney. There was quite a bit of downloading going on in Japan 10 hours ago or so.
> Firefox probably popped up and said 4 is available
That hasn't happened yet; the offer to update typically lags a new release by a bit for Mozilla.
The download count in the article is just people who went to the mozilla website and downloaded the browser from there.
> As a web developer and a web surfer Firefox gives me nothing new.
Just as a note, Firefox has various web-facing features Chrome doesn't have (e.g. CSS calc()), has better graphics performance on many computers, and doesn't send every url you load to Google by default. There are plenty of other things it can do that Chrome can't.
No you may or may not care about these things, of course.
"UI animation" doesn't mean animated icons. It means things like what happens in Firefox 4 or Chrome when you open a new tab: it doesn't just spring into existence but rather animates into place (from below in Chrome, from the left in Firefox). The idea is to give the user better feedback about what they just did by showing how you go from A to B instead of just replacing A with B.
Slashdot Mirror
> Nobody is stopping you from installing anything else.
This is true for their desktop products, but iOS makes anything Microsoft ever did seem pretty tame by comparison. Compare the differences between trying to use a non-Trident browser on Windows at any point in time and trying to use a non-mobile-Safari browser (in terms of the rendering engine, not the user interface; the mobile Safari rendering engine is no a vanilla WebKit).
> it has gained so much share in a far far shorter time
> than Mozilla took.
There are two important differences:
1) Chrome is operating in an environment where websites are NOT just authoring to IE anymore; site compat is somewhat easier to come by and hence user adoption is easier.
2) Chrome has had a huge marketing campaign going for it starting the monent it was released. It's advertised in huge and expensive ad campaigns on subways. It's advertised on Google's web properties. It's advertised via banner ads all over the internet. Mozilla back when it started just didn't have the financial resources for an ad campaign like that. Heck, I don't think it has them now. I'd be interested in comparing the amount of money it would take to purchase the various Chrome yearly advertising (including the Google property placements, which are being provided in-kind and not for cash, of course) on the market to Mozilla's total yearly budget. Based on what I've seen, I would not be surprised if the first number is higher. So Mozilla had to depend on word-of-mouth, which depends on how many users you have, which was small at the time.
> Even nontechs/nonnerds are downloading and
> installing Google Chrome
Right, but how did they find out that it even exists to go download? This was the major problem Mozilla and Firefox faced initially, and that's where the huge marketing campaign really helps.
Spent fuel is an interesting discussion topic; I'll believe in people in the US taking it seriously when they take the already-available mitigation steps that other countries take routinely: reprocessing.
As it is, the spent fuel situation is that we're told that the obvious thing that will reduce the amount of waste significantly is off the table, and then we suddenly have large amounts of waste to deal with, surprisingly.
> only to show how many can be expected
Well, of course! That's always the question. Pretty much anything we do means more people will die. More people flying on airplanes means higher levels of radiation exposure and more cancer deaths. More people driving cars means more accidents and more deaths. More people walking outside (or on stairs, as I said) means more falls and more deaths; several thousand per year just in the over-65 demographic in the US. More people getting CT scans leads to more cancer. The real question is one of risks and benefits. For the record, I think our use of CT scans is pretty suspect, and a good bit worse than what I've been able to find so far in terms of contamination from this accident outside the evacuation zone, but maybe you have other numbers?
In case it's not clear, I think that just saying "it increases risk" without quantifying that is fear-mongering. Of course it increases risk.
> Also, the explosion most certainly distributed
> plutonium and uranium into the local area.
Maybe I missed part of the news here. Which explosion are we talking about? The one hydrogen explosion that blew away the outer reactor building, or some other explosion?
If you have a reference for this, I would be very interested.
> short half-life elements tend to be more dangerous.
Simply because ipso facto they have higher radioactivity levels per atom (they're decaying faster, after all).
For a given activity level, what matters is the kind of decay, not the half-life, since all the half-life does is affect the activity level. Alpha decays are easy to handle; gamma decays are the hard kind to deal with.
Cs-137, which I presume is the major cesium isotope we're worried about here, is bad stuff because it's _medium_ half-life (30 years or so), and the decay chain includes gamma rays very soon after the cesium itself decays. I agree that significant quantities of cesium-137 release is a serious problem.
I-131, which is again presumably the iodine you're talking about, is not nearly as bad as long as you don't eat it. Japan _has_ been testing food outside the quarantine area for iodine, as well as testing children, and things are looking ok so far from the articles I've read. Again, maybe you have references to specific issues that I've missed here? Note that I-131 has a half-life of only 8 days, so the concentration drops rapidly on a timescale of several months. As long as the quantities released are not huge and it doesn't disperse widely, this problem will solve itself.
> Somehow I doubt thousands have died from a
> damn
If you meant "dam", then you should have read the article I linked to. 90,000--230,000 dead (no one actually bothered to count for sure) dead from one single dam accident.
> Because the coal plant doesn't explode so
> violently that a plume of radioactive material
> (including cesium and radioactive iodine) into the
> atmosphere.
Uh... Coal plants put radioctive material into the atmosphere all the time. It's a lower level per plant than a Chernobyl-style explosion, but we have a _lot_ of coal plants. And Fukushima is nothing like Chernobyl, again unless I missed a major piece of news here. If you haven't before, you may want to read http://en.wikipedia.org/wiki/Radioactive_waste#Coal (it's a very short read).
> Industrial accidents which are far easier to
> mitigate
Are they, now? Data, please? Or is this a gut feeling?
> and only affect a small area around the factory.
So in other words, deaths are ok as long as they're not in your backyard and preferably not in your country? C'mon now.
> From the mining of the ore, to the processing,
> power production, reprocessing and eventual
> disposal.
Except for disposal, those are all "production and operation".
Disposal is a problem, but since we're not even takin
> The increase in background radiation will
> absolutely cause a raise in cancers
Increase in background radiation where? Do you have numbers to cite here?
> there's the matter of radioactive material put into
> environment
Details? Which isotopes are we talking about? Is it worse than your typical coal plant operating for a month?
> Radioactive elements can never be made safe.
That's just not true. For example, oxygen-15 makes itself safe in a matter of hours (half-life of 120s with decay to a stable nitrogen isotope). A large fraction of the radioactive release from Fukushima has been elements like that.
Now maybe what you mean is that long-half-life isotopes can't really be made safe. I agree; the goal would be to prevent them escaping the containment vessel.
> Solar, wind, and hydrothermal are much safer.
I'd _love_ to see numbers for this, on comparable scales.
That is, how safe or unsafe is your typical solar plant generating 0.8GW (which is what each of the reactors at Fukushima was generating)? How safe is your typical wind plant of that capacity? Whole-life numbers (i.e. including construction and maintenance) would be good. Problem is, no one actually tracks that stuff, so we don't have those numbers....
> that would otherwise plague a small area around
> the plant
Uh... you can't have it both ways. If pollution from coal plants (including the radioactive elements they put in the air) is localized to a "small area", how is that not the case for nuclear?
> But since the deaths from nuclear are primarily
> cancers
Citation please?
> The best you can do is mitigate the risks.
This is true for all power-generation setups. The only question is when in the life cycle the highest risks are. For photovoltaic solar, for example, it seems to me that they are primarily at the solar cell production stage and the related industrial accidents. For hydroelectric they're when your dam is operating (http://en.wikipedia.org/wiki/Banqiao_Dam is a good read). For nuclear there's the initial uranium purification or plutonium production and operating risks. But yes, risk-mitigation is the name of the game. That's how life in general works: walking down stairs is unsafe. People die from it all the time. We do it all the time, but we put in handrails and people who're particularly susceptible to the risk get single-floor houses...
> The number of PhDs in computer science per year
> in the US is probably less than 100
http://www.nsf.gov/statistics/infbrief/nsf10308/ says 1786 computer science PhDs awarded in the US in 2008.
You estimate for the number of CS graduates per year from CMU is about right (the school of computer science is 500-600 undergrads from the numbers I can find, but they have a computation biology major, and a music and technology one, and an a "computer science and arts" one in addition to straight computer science).
But yes, I would fully expect that a majority of CMU's CS graduates go into engineering (perhaps after doing a masters degree), not pure CS.
If they all die, then there will be no computer scientists to fill the few positions where they _are_ needed, so there will be demand for some computer science programs.
Or did you mean that _most_ of them would die? Maybe all but the very best two or three? If so, seems like CMU might have a good chance of staying around as a computer science program. If this were some random state school making the change, your argument would carry more weight.... (I think it would still be somewhat off, but it's _definitely_ off for CMU.)
The problem is that OCSP as currently implemented doesn't really work, precisely because of the two problems you describe (vulnerability if OCSP checks are nonfatal, failure to connect if they are). In fact, there are places where all OCSP is effectively blocked (airport wireless networks before you've paid, say, and paying requires SSL, so if OCSP is fatal then you can't pay). As a result, browsers default to non-fatal OCSP checks (with Chrome having a small unobtrusive warning if the check fails, which I fully expect that users ignore).
The warning approach would work for you, but not for most people, who have no idea what OCSP is or what to do with a warning about it, unfortunately. Either the warning would be unobtrusive and missed or look like an error page kinda thing, and confuse people...
Not an ETA yet; just a plan.
The problem is that there is no system API for low-level accelerated 2d graphics on OS X. So the only way to do it is to roll your own. The plan is to do just that on top of OpenGL, but that's a big project.
https://wiki.mozilla.org/Gecko:2DGraphicsSketch has some details.
The only way to issue a cert with the same private key as another cert is to know that private key. If you know the private key and you know the certificate the server sends in response to an SSL request, then you can simply impersonate the server's existing certificate right now. In other words, a "certificate" is a pair consisting of a private key and the public bits that the SSL server puts on the wire when you connect to it. Everyone knows the latter, so "all" you need to MITM is to know the former.
Right now, if someone creates a fake cert for a domain it'll have the right domain name but a different key pair from the real cert for that domain. Again, being able to issue a fake cert with the same key pair means you don't need a "fake" cert; you just have the real one!
You're right that if this proposal were implemented, then the "new certificate" alert would need to only happen in cases when the key pair for a hostname changes. But that seems eminently doable.
Actually, the author does address that. They key is that the private key would not change when the certificate changes. Unless the MiM has cracked the old cert (in which case you're screwed no matter what), they couldn't impersonate an update that keeps the same private key.
> Do you really think MS has tried their best with IE?
I have no idea what "their best" is. I do think that over the last 4 years or so they've clearly written a large amount of high-quality code. That takes a good bit of effort.
Of course for the 5 years before that they did absolutely nothing.
> but browser standards just happen to be
> their weak point
In none of the things you list have they recently had to enter a mature market and build a team from scratch, except game consoles. And how long did it take them to ship a good one?
> The PNG transparency bug in IE6 could have
> been fixed overnight. The CSS bugs could have
> been fixed in a week.
I find it very hard to take you seriously if you really think that. Have you ever tried implementing CSS? (I have, for what it's worth; it's not that easy even in a clean implementation, much less in a legacy codebase.)
> And Konqueror was ahead of IE in the area of
> browser standards for years
Sure, the years when IE wasn't being developed at all. What bearing does that have on the changes from IE8 to IE9, which are the topic of discussion here?
Note also that IE6 was way ahead of Konqueror in _functionality_. It happened that a lot of it was non-standard, but that doesn't mean it didn't exist.
I think you'd have to look hard to find someone who thinks that the IE7 schedule was the best Microsoft could do. But either you haven't been paying any attention at all in the last 2 years, or you're rather mis-informed if you think that what's currently going on with IE is anything like what was happening in 2003.
> Yes it does if you have enough of it.
Seriously, read the Mythical Man-Month.
> Additional components like Asian fonts
I think you're pretty confused about what doing vertical text entails. It's not a "fonts" issue.
> There are plenty of browsers like Konqueror that
> have small teams
And were never anywhere close to offering the features even IE6 offers, much less any of the modern browsers.
1) Money does not translate immediately into a working team. See The Mythical Man-Month. Getting together a team that can effectively develop a large system just takes time. Especially if you have a legacy codebase to deal with.
2) I think you overestimate how easy it is to make use of some other rendering engine without just using it in its entirety. And IE can't just use webkit or Gecko wholesale because of compatibility issues: sites sniff for IE and do various crazy IE-specific stuff that they therefore need to keep supporting but isn't supported in Webkit or Gecko. There's also the fact that Trident does some things that are important to some of Microsoft's markets (e.g. vertical text, in East Asia) that neither Webkit nor Gecko do at the moment.
You may want to read http://www.imperialviolet.org/2011/03/18/revocation.html
All that you're seeing is that it's been a while since the last Safari release. Webkit has kept being developed, and Chrome has been using those newer Webkit versions, but there has been no Safari released with the newer Webkit.
Yeah, I was afraid of that.
On Linux, Chrome does almost all of its painting itself, in software. Firefox, on the other hand, tries to play nice and hand of painting to the X server, using XRender.
Sometimes this works really well, XRender is able to hand the painting off to the graphics card, and you get performance comparable to what you see with IE9/Fx4 on Windows.
But sometimes the graphics driver decides to do the work in software anyway. And they tend to have pretty slow software fallback paths; much slower than Chrome's software renderer.
It sounds like you're hitting one of those situations.
Using a different video driver may help. But the only options for Firefox here are to either do what Chrome does and do it all in software (slower for some people, faster for others), hope driver manufacturers get their act together, or stop using XRender (and try to do everything in GL, say). At the moment that third plan is being followed, but it'll take some work to get there.
The stats show 108,749 downloads to date for Australia. The population of Australia is about 22.5 million according to . So figure one in 200 people has downloaded in Australia.
The same states show 2 million downloads for the US, with a population of about 300 million people; one in 150 has downloaded.
This is over one Australian day and 1.5 nights, and 1.5 US days and one night.
Seems like pretty similar download rates to me.
I suspect people seriously overestimate how many people live in Australia. For comparison, the population of the Netherlands is 16 million, and that of Belgium is 10 million, so between them they have almost 20% more people than Australia does.
Now Japan, I agree; there are 339,157 downloads for a population of 130 million or so. That's about half the US rate.
You're using testing builds. Nothing wrong with that, but they don't guarantee the same stability that the release does. On the other hand, you get new features sooner. Some of us like that. ;)
What's using the CPU time in your case? Is it Firefox, or Xorg?
> I can't believe it is due to a lack of talent or resources
Why not? They had a _lot_ of catching up to do, and just throwing more people at the problem if they're not already experts on it doesn't help.
I think the fact that MS hasn't caught up yet is all due to resource constraints on the IE team. They're working on it, but they had a good long way to go.
Africa for the most part has no internet connections.
Japan and Australia are in the middle of the night right now. As of when you posted your comment, it's 1:39am in Tokyo and 3:39am in Sydney. There was quite a bit of downloading going on in Japan 10 hours ago or so.
> Firefox probably popped up and said 4 is available
That hasn't happened yet; the offer to update typically lags a new release by a bit for Mozilla.
The download count in the article is just people who went to the mozilla website and downloaded the browser from there.
> As a web developer and a web surfer Firefox gives me nothing new.
Just as a note, Firefox has various web-facing features Chrome doesn't have (e.g. CSS calc()), has better graphics performance on many computers, and doesn't send every url you load to Google by default. There are plenty of other things it can do that Chrome can't.
No you may or may not care about these things, of course.
"UI animation" doesn't mean animated icons. It means things like what happens in Firefox 4 or Chrome when you open a new tab: it doesn't just spring into existence but rather animates into place (from below in Chrome, from the left in Firefox). The idea is to give the user better feedback about what they just did by showing how you go from A to B instead of just replacing A with B.
The thing I see people printing most often is boarding passes.