Standards compliance is indeed the best way to interoperability. And the standard needs to specify handling of all possible inputs. Now not all inputs are considered correct, but that doesn't affect the interoperability situation.
In other words, it's the old "be liberal in what you accept and strict in what you send" approach. Except now people have realized that the standard needs to specify exactly how to be liberal, because otherwise you get problems when people are not in fact strict in what they send.
And given that the senders are by and large not actually aware of the standard in practice on the Web, the best way forward is to specify what to do with all possible byte input streams.
Note that people _did_ test various compile options. Assuming you're building a generic i386 binary with gcc (which you're not, of course), -Os produces a faster Gecko and Firefox than -O3 does (almost certainly because of a better instruction cache hit rate). For a program small enough to fit completely in i-cache, -O3 would of course be faster.
> But when people can't or can just barely afford food and heat, does it really > matter how affordable cell phones and cable are?
Of course not. That was my point originally, if you look: lack of possessions is a bad criterion of poverty in the modern world, no matter how the dictionary defines "poverty". Pretty much everyone, even people who are in poverty by any sane measure, can have all sorts of stuff. That doesn't necessarily mean they live well.
Note the "wants" part. It's all a matter of priorities, as far as I can tell from observation of poor people right here in Chicago. I agree that given _my_ spending priorities if I earned $7 an hour I wouldn't have a cell phone. Or cable. Or a TV. But a lot of people do.
That said, rent includes heat here, and rents in the bad neighborhoods are kept down because they're bad neighborhoods. I agree that in places where heat or hot water is not included in the rent, or where rents have more elasticity, things have gotten bad recently.
So perhaps I should qualify what I said above. It's easy to have material possessions at the expense of a decent location to live. If you're willing to live in a crappy location (which a lot of people either are, or feel they have no choice about), it turns out that "stuff" is really cheap, comparatively. Energy, as you point out, is not. Food is not. But stuff is.
> Upgrading a desktop is so much easier (approx one hour)
Actually, that I disagree with. Perhaps if you never change any configuration on the desktop, but if you have various local configuration changes... it takes a while to update it and make it work again. My experience with RedHat/Fedora has been that between changes to X and updated versions of _all_ the applications, a dozen or so things would break and need about a week's worth of time to fix (if they could be fixed at all).
For example, there is a history of ld being broken (in the sense of 2 orders of magnitude performance regression linking gklayout) in the several.0 releases of Fedora in a row... then they fix it in an update, and rebreak it with the next major release.
There is also a legal definition in the US, to whit the federal poverty line. This is a measure of income, not possessions, and doesn't include all income sources (e.g. excludes all public assistance, for obvious reasons, as well as cash income, etc).
At this point, in the US, no one without serious mental problems is really "lacking in material possessions". It's hard to find people who want a television but don't have one, say. Or a cell phone.
I agree that the original poster's 10% thing doesn't make much sense at least in the U.S. context, since the poverty line is set based on a fuzzy "have enough income to make ends meet" thing (or more precisely based on the cost of a particular food-weighted basket of goods).
> Your severe lack of imagination doesn't mean that there is only > one option, just that you're unable to think of more than one.
His point was that this is the EXACT reasoning process people go through every day, particularly in the context of this discussion (school achievement). We all agree it's a stupid process, but the problem is that it's what actually happens.
> After all, we are physically indistinguishable from our ancestors 3000 > years ago, but any engineer or doctor of today would seem to be a > genius by classical Greek standards.
A lot of this might have to do with better (especially childhood) nutrition in addition to the education factor you mention.
> What hope is there for Linux taking over the desktop when the main > application has no install instructions online for easy reference?
Almost all Linux users install things like this as distro packages, and get them from their distro... Firefox is no different: very few Linux users download if from Mozilla.org (compared to the number that actually use it).
For what it's worth, that sort of stuff was in fact in place (which is why things recovered in about an hour).
People had made some pretty conservative estimates of expected traffic based on current usage, etc to estimate what sort of traffic needed to be handled. Then the actual traffic was 12x as big. The peak download rate was more than 10x what it was with Firefox 2. The _lowest_ download rate seen so far is 3x the Firefox 2 peak rate....
But what really killed the website at first was the 2Gb/s of HTTP it was pushing out...
South Korea has the minor issue that they started doing internet banking very early, before SSL got standardized. So they came up with their own encryption setup.
They use it to this day, with an ActiveX control to handle the encryption. Which means you can't use any serious bank site (and can't use a lot of e-commerce sites) in South Korea unless you're using IE on Windows. There is basically no marketshare for Macs or non-IE browsers as a result.
Between the start of Gecko 1.9 development and now (effectively the end of Gecko 1.9 development), 389 bugs with the "perf" keyword got fixed. That's not counting the UI-only performance bugs (e.g. the Firefox UI took up about 15% of the pageload time in Firefox 2; in Firefox 3 that number is much smaller).
People care, I can assure you. On the other hand there are a _lot_ of performance bugs. At least in part because any algorithm that's not O(N) or faster amortized is automatically a performance bug on the web: people throw up multi-tens-of-megabytes HTML files all the time.
"The environment" is part of the performance problem in a lot of cases. For example, GTK2 is a lot slower than GTK1 (affecting things like Window opening performance, for example). Using pango for text layout will let you get more things (e.g. Thai) correct, but is a good bit slower than other options that don't try to handle as many situations... RENDER and XOrg have all sorts of performance issues. There are graphics testcases where Firefox 2 on Linux beats Firefox 3 hands-down because the software rendering in Firefox 2 is faster than the "accelerated" rendering done through RENDER in Firefox 3.
So depending on the tradeoffs you want to make, the way to be fast might in fact be to NOT integrate with "the environment". At least on Linux. On operating systems with a better graphics and widget layer story, things may be different.
Slashdot Mirror
Of course the record is for number of manually initiated downloads...
Standards compliance is indeed the best way to interoperability. And the standard needs to specify handling of all possible inputs. Now not all inputs are considered correct, but that doesn't affect the interoperability situation.
In other words, it's the old "be liberal in what you accept and strict in what you send" approach. Except now people have realized that the standard needs to specify exactly how to be liberal, because otherwise you get problems when people are not in fact strict in what they send.
And given that the senders are by and large not actually aware of the standard in practice on the Web, the best way forward is to specify what to do with all possible byte input streams.
> What's the point of rendering incorrect code correctly?
Most code on the web is "incorrect". The point of rendering it correctly is interoperability.
Also, ACID3 is not exactly testing "incorrect" code. Have you ever read the test?
Firefox 3 has been downloaded 20-some million times during that time.
So 70,000 is about 0.35% of the people who downloaded Firefox 3.
Definitions of "trivial" may vary of course.
A typical "commercial" website is a good bit bigger than 10,000 DOM and script objects. Most are bigger than 10,000 DOM nodes, for a start.
Note that people _did_ test various compile options. Assuming you're building a generic i386 binary with gcc (which you're not, of course), -Os produces a faster Gecko and Firefox than -O3 does (almost certainly because of a better instruction cache hit rate). For a program small enough to fit completely in i-cache, -O3 would of course be faster.
Did you let your favorite site authors know that they're driving away business by restricting he browsers people can use to access their sites?
> But when people can't or can just barely afford food and heat, does it really
> matter how affordable cell phones and cable are?
Of course not. That was my point originally, if you look: lack of possessions is a bad criterion of poverty in the modern world, no matter how the dictionary defines "poverty". Pretty much everyone, even people who are in poverty by any sane measure, can have all sorts of stuff. That doesn't necessarily mean they live well.
Note the "wants" part. It's all a matter of priorities, as far as I can tell from observation of poor people right here in Chicago. I agree that given _my_ spending priorities if I earned $7 an hour I wouldn't have a cell phone. Or cable. Or a TV. But a lot of people do.
That said, rent includes heat here, and rents in the bad neighborhoods are kept down because they're bad neighborhoods. I agree that in places where heat or hot water is not included in the rent, or where rents have more elasticity, things have gotten bad recently.
So perhaps I should qualify what I said above. It's easy to have material possessions at the expense of a decent location to live. If you're willing to live in a crappy location (which a lot of people either are, or feel they have no choice about), it turns out that "stuff" is really cheap, comparatively. Energy, as you point out, is not. Food is not. But stuff is.
> Upgrading a desktop is so much easier (approx one hour)
.0 releases of Fedora in a row... then they fix it in an update, and rebreak it with the next major release.
Actually, that I disagree with. Perhaps if you never change any configuration on the desktop, but if you have various local configuration changes... it takes a while to update it and make it work again. My experience with RedHat/Fedora has been that between changes to X and updated versions of _all_ the applications, a dozen or so things would break and need about a week's worth of time to fix (if they could be fixed at all).
For example, there is a history of ld being broken (in the sense of 2 orders of magnitude performance regression linking gklayout) in the several
> Poor: "lacking material possessions".
That's the dictionary definition.
There is also a legal definition in the US, to whit the federal poverty line. This is a measure of income, not possessions, and doesn't include all income sources (e.g. excludes all public assistance, for obvious reasons, as well as cash income, etc).
At this point, in the US, no one without serious mental problems is really "lacking in material possessions". It's hard to find people who want a television but don't have one, say. Or a cell phone.
I agree that the original poster's 10% thing doesn't make much sense at least in the U.S. context, since the poverty line is set based on a fuzzy "have enough income to make ends meet" thing (or more precisely based on the cost of a particular food-weighted basket of goods).
> Your severe lack of imagination doesn't mean that there is only
> one option, just that you're unable to think of more than one.
His point was that this is the EXACT reasoning process people go through every day, particularly in the context of this discussion (school achievement). We all agree it's a stupid process, but the problem is that it's what actually happens.
> After all, we are physically indistinguishable from our ancestors 3000
> years ago, but any engineer or doctor of today would seem to be a
> genius by classical Greek standards.
A lot of this might have to do with better (especially childhood) nutrition in addition to the education factor you mention.
The record is for number of human-initiated, non-automated downloads.
> What hope is there for Linux taking over the desktop when the main
> application has no install instructions online for easy reference?
Almost all Linux users install things like this as distro packages, and get them from their distro... Firefox is no different: very few Linux users download if from Mozilla.org (compared to the number that actually use it).
The vulnerability in question is present in Firefox 2 as well.
Last I checked no more than 2-3% of Linux users get Firefox from Mozilla directly. The rest get it through their distro.
Distros do in fact plan to create versions that statically link in not just libpangocairo but also GTK (because of the 2.10 dependency).
Redhat will be backporting the relevant libraries and Firefox 3 to EL4.
The reason for the new dependencies is basically better system integration, which both Linux distros and Linux users kept crying for...
Peak (right after release) was about 14Gb/s.
Which matches the likely 8m download count.
For what it's worth, that sort of stuff was in fact in place (which is why things recovered in about an hour).
People had made some pretty conservative estimates of expected traffic based on current usage, etc to estimate what sort of traffic needed to be handled. Then the actual traffic was 12x as big. The peak download rate was more than 10x what it was with Firefox 2. The _lowest_ download rate seen so far is 3x the Firefox 2 peak rate....
But what really killed the website at first was the 2Gb/s of HTTP it was pushing out...
The confusion is judged worth avoiding the risk of introducing regressions by making changes between test and ship.
South Korea has the minor issue that they started doing internet banking very early, before SSL got standardized. So they came up with their own encryption setup.
They use it to this day, with an ActiveX control to handle the encryption. Which means you can't use any serious bank site (and can't use a lot of e-commerce sites) in South Korea unless you're using IE on Windows. There is basically no marketshare for Macs or non-IE browsers as a result.
An RC is an RC. If no stop-ship bugs come up, those exact bits on disk become final, with no more changes. That includes changing text in about boxes.
Hence every RC for Firefox 3 has said "3.0" in the about box.
Between the start of Gecko 1.9 development and now (effectively the end of Gecko 1.9 development), 389 bugs with the "perf" keyword got fixed. That's not counting the UI-only performance bugs (e.g. the Firefox UI took up about 15% of the pageload time in Firefox 2; in Firefox 3 that number is much smaller).
People care, I can assure you. On the other hand there are a _lot_ of performance bugs. At least in part because any algorithm that's not O(N) or faster amortized is automatically a performance bug on the web: people throw up multi-tens-of-megabytes HTML files all the time.
"The environment" is part of the performance problem in a lot of cases. For example, GTK2 is a lot slower than GTK1 (affecting things like Window opening performance, for example). Using pango for text layout will let you get more things (e.g. Thai) correct, but is a good bit slower than other options that don't try to handle as many situations... RENDER and XOrg have all sorts of performance issues. There are graphics testcases where Firefox 2 on Linux beats Firefox 3 hands-down because the software rendering in Firefox 2 is faster than the "accelerated" rendering done through RENDER in Firefox 3.
So depending on the tradeoffs you want to make, the way to be fast might in fact be to NOT integrate with "the environment". At least on Linux. On operating systems with a better graphics and widget layer story, things may be different.