Turing's work focuses on feasibility of computation, not on the time needed for the computation. In particular, given Turing-complete languages A and B it's quite possible for an algorithm to be implementable in A in a way that takes O(N) time and impossible to implement in B in faster than O(N^2) time. And that doesn't even start in on the constant factors.
Since the thing being discussed here is not a change in functionality but a performance optimization, Turing's work doesn't tell us much about its feasibility in the different environments under discussion.
Actually, Korea ended up using their own crypto standards because their deployment of strong crypto predated the finalization of the 128-bit SSL standards.
And switching to SSL is apparently hard because government regulations for financial institutions in Korea require the use of the current setup.
> There are plenty of people willing to test the code.
Are there? The number of people testing your typical Firefox minor release is about an order of magnitude lower than the number of people testing bleeding-edge Firefox trunk last I checked. And it's at least two orders of magnitude lower than the number of people testing a major release beta.
If you talk to the Mozilla QA and release folks, one of their big problems is in fact the lack of minor release testers...
Yes. The typical monthly Firefox minor update ships on the order of 30-100 fixes depending on the month (security problems, stability problems, compat problems, etc). Micro-patching would involve 1-3 upgrades a day.
If the upgrade could happen silently and without any user notification (which is what Chrome is working and and what Mozilla would like to get to), that may be acceptable. But even just telling the user three times a day "hey, I just updated" is a deal-breaker.
> The mozilla project isn't so immature they need lots of people testing their new > experimental code.
As a matter of fact, the only way to find out whether you broke some intranet site somewhere is to have someone on that particular intranet testing your "experimental code" (which 3.6 is not, by any means).
Typically betas of Firefox end up with several hundred thousand users.... and that still doesn't catch bugs on little-known sites like Hotmail (which apparently thinks Firefox 3.6 is Firefox 2 and therefore breaks in some cases).
> It would do us all no good if Mozilla did implement H.264 and then got hooked for > megabucks when the H.264 licensing agreement suddenly requires dollars per instance of > software decoding H.264.
The thing is.... IE8 claims to support CSS2.1 and actually supports it well, at least in my testing. Webkit's support, on the other hand, is pretty buggy (complete fail on handling many sorts of dynamic changes, for example).
If by "innovation" you mean "making things up while not implementing the existing standards very well", then webkit is indeed innovating. Just like IE as in the late 1990s, right?
Seamonkey was not included because only one browser per "vendor" is allowed, and technically Seamonkey and Firefox come from the same "vendor" (Mozilla).
Seamonkey wasn't included because it's technically from the same "vendor" as Firefox (Mozilla, to be precise) and the screen can only include one browser per vendor. Seamonkey most definitely has enough market share in Europe to be on the screen otherwise.
Yes, it really is that difficult. Consider this classic example in English:
Time flies like an arrow.
Fruit flies like a banana.
There happen to be two ways to read the latter sentence. One is in a way analogous to the former one: the subject is "Fruit", the intransitive verb is "flies", and "like a banana" is an adverb phrase. The other way to read it is that the subject is the noun phrase "Fruit flies" , the transitice verb is "like" and the direct object is "a banana". Heck, this case is difficult for _humans_ to get "right" at times.
There are various situations like that in which the meaning is ambiguous, but even worse are situations in which the concepts used are just nonexistent in one of the languages/cultures. For example, English names are made up of three parts, typically: first, middle, last. Russian names are also made up of three parts: given, patronymic, family. Russian family name is a good match for English last name. Russian given name is a good match for English first name. Russian patronymic is... not really a match for English middle name (in that for example it's not up to the parents to choose it), but occupies a similar position in names, obviously.
So when translating a phrase containing (patronymic) into English, what word you use to translate it really needs to depend on what's being said. If it's a technical discussion about the concept, translate as "patronymic". If it's a casual discussion about names, "middle name" may be appropriate. If the Russian text says that X addressed Y by name and patronymic then that _is_ what they did, but that happens to be the standard polite form of address. The equivalent English form is a Mr/Mrs/whatever followed by the last name, and the translation should reflect that.
There are also often situations in which two phrases are technically the same in terms of denotation but have different connotations (or heck, just different emphasis on which words are important; compare "I saw him" to "I saw him/em" and note that such emphasis differences can be expressed with word order in many languages). Getting that right can be very difficult unless you really understand what's being said. Pattern matching might work if you've seen that exact pattern before (which is Google's approach), but even small differences in the surrounding sentence structure can totally change the meaning of the part you're trying to translate.
I leave you with this short story (or rather stories):
Jack was walking across the meadow when he saw a spring. The spring glinted in the
sunlight, and he thought that he'd never seen something quite so beautiful. He bent
down and...
1)... put it in his pocket.
2)... had a drink.
How much lookahead in the translation is needed to translate the first sentence correctly? If the rest of the story is option 2 above, how do you know that he didn't just take a swig from his flask before picking up the bit of metal?
At the time when FDR was creating the entitlements, immigration to the US was at historic lows because there were no jobs to be had (so not much reason to immigrate). If you look at you will see that in the 1920s (which saw immigration restrictions passed in 1921 and 1924) immigration averaged 400k a year (as compared to 900k a year in the 1900-1914 timeframe; 1915-1919 is partially showing the effects of WWI). In 1931-1946, immigration averaged 50k a year. If you assume that none of this happened during WWII, then we're talking 75k a year averages for the 1930s. Immigration quotas as set in 1924 were about 150k from Europe, nothing from Asia, no limits on Latin America.
I doubt those immigration numbers would have looked much different without the quotas in the 30s.... again, no point immigrating to a country where you then won't be able to find a job.
Note that the entitlements put in place at the time were not nearly as generous as what we have now. For example Social Security didn't cover jobs in agriculture, domestic service, government, teaching, nurses, hospitals, anyone who worked intermittently. The upshot was that about half the workers in the US were not covered by it; I would expect that fraction to have been even higher amongst recent immigrants. See http://en.wikipedia.org/wiki/Social_Security_(United_States)#Controversy for some details and links to references.
I don't have data offhand on the public employment projects and unemployment benefits, but the WPA jobs were restricted to "Any American citizen, or other person owing allegiance to the United States" (see http://www.gjenvick.com/WPA/1939-04-17-Questions-Answers-WPA-Employment-WagesAndHours.html ). It's not clear to me whether that latter part covers immigrants prior to naturalization or only residents of US territories....
> no coincidence that the US transitioned from an open immigration society to a closed > society in the 20s and 30s
Uh.... The Emergency Quota Act was passed in 1921. What entitlements were being doled out in 1921? Note that the act didn't place any limits on immigration from Latin America and placed the limit on Northern/Western Europe higher than actual immigration levels; it was basically targeted at limiting immigration from Eastern/Southern Europe. And that had more to do with "those people aren't like us" than with entitlements. http://en.wikipedia.org/wiki/History_of_Immigration_to_the_United_States#New_Immigration has a good summary.
Of course the Chinese Exclusion Act of 1882 can hardly be explained by entitlements as well.
The truth is that immigration restrictions in the US have always had more to do with the existing population feeling that the ethnic balance is threatened than with anything else. That's exactly what's going on now too.
Now I agree that entitlements make it more appealing for people to immigrate to the US. But the country was pretty appealing in the early 20th century too.
The XHTML2 standard was designed in such a way that there was no good way to tell whether content was supposed to be XHTML2 or XHTML1, but required quite different treatment of the same content.
So the only way to handle this in the browser would be on a page-by-page whitelist or blacklist basis. IE8 did in fact do this, but most other browser authors don't quite have unlimited resources to audit the entire web like that. Nor can you argue that this is in any way a "simplification" for the browser.
In general, it's hard to argue that XHTML2 was in any way a simplification for browsers given that not a single browser implemented it. Had they thought it would be worth it, I'm fairly certain they would have.
Different types of vulnerabilities are likely, yes. Some security risks will become smaller (e.g. no more disagreement between browser and plug-in as to what the security context of a given piece of script is, due to there being only one piece of code enforcing security policy).
But more importantly, there won't be a monoculture of vulnerabilities (modulo vulnerabilities required by the spec and not caught in review), and vulnerability patching would happen when browsers patch their stuff and push the security fixes (how successful that is varies by browser) and not when users install updated versions of the Flash plug-in (which is never, to a first approximation).
I think you underestimate the "without breaking backwards compatibility" part of this.
XHTML2 was pretty much designed to not work with any existing web infrastructure (either existing content or existing browsers). If you think a parallel web built from the ground up is the way to go, feel free to work on it, but the network effects involved make it a pretty risky prospect.
Of course the new benchmark still does things like "run this test for 100ms, take the number of runs, multiply by some magic number (different for each test), then add up all the results and declare it the total score". Which means that while the individual test results might mean something the total score doesn't, much. It's possible to be fast on one thing, really slow on everything else, and trivially win on total score, since it's a straight sum.
Ah, interesting. The source has actually changed significantly from the last time I looked at this. Or the article author is on crack about what benchmark it is.
I assume they ran http://jsbenchmark.celtickane.com/Run.aspx which actually looks like a legitimate benchmark. Celtic Kane used to push a dom/css/etc benchmark which basically did things like "measure speed of CSS animation" by setting style.x and style.y and the like.
It's not biased. Just incompetent. You can tell by the fact that they think the JSBenchmark numbers actually mean anything (which implies they've never read the source for that benchmark), for example.
Did you look at the "Mozilla" benchmark? It's basically V8 + Sunspider + some other stuff. Very heavily weighted towards the V8 + Sunspider scores. So that number is basically just the average of the Sunspider and V8 numbers.
And the Opera number there is due to the fact that the tester stopped and restarted the test, which resets the timers involved... Over here Opera does well on that test, but nowhere close to that far ahead of the others.
In all, this is about par for the course for benchmarking articles out there: someone who doesn't understand the (not particularly good and hard to use well) tools misusing them badly, then reporting the results.
Turns out, there are no good independent benchmarks, because writing a decent browser benchmark is _hard_. The two sets of independent tests actually used in the article are broken beyond belief (don't measure what they think they're measuring, are easily gamed, etc).
In practice, even the dependent benchmarks aren't very good (Dromaeo measures its harness overhead more than anything else in a lot of cases, V8 tests are designed around the V8 engine, Sunspider has known bugs that cause some tests to produce random results and cause others to do different amounts of work in different browsers, that sort of thing). But they're somewhat better than the independent ones....
> And the naive solution to a shuffling an array is similar to bubblesort, traverse through > the array and generate a random number up to array size to swap the element with.
While this is not in fact perfectly random (the right way would be to generate a number up to remaining elements, then add the offset), it's a lot more random than what Microsoft did here. Did you read the article?
Note that the article author is 40 years old. Dunno whether you consider that "young".
> given the size/age/complexity of the Firefox codebase compared to Chrome
The Firefox codebase was comparable to the Chrome one or smaller, last I checked. Age is an interesting question and hard to measure as parts of a codebase get rewritten. Complexity... a tossup.
Seriously, take a look at both carefully instead of just reading the hype.
Slashdot Mirror
Turing's work focuses on feasibility of computation, not on the time needed for the computation. In particular, given Turing-complete languages A and B it's quite possible for an algorithm to be implementable in A in a way that takes O(N) time and impossible to implement in B in faster than O(N^2) time. And that doesn't even start in on the constant factors.
Since the thing being discussed here is not a change in functionality but a performance optimization, Turing's work doesn't tell us much about its feasibility in the different environments under discussion.
Actually, Korea ended up using their own crypto standards because their deployment of strong crypto predated the finalization of the 128-bit SSL standards.
And switching to SSL is apparently hard because government regulations for financial institutions in Korea require the use of the current setup.
> There are plenty of people willing to test the code.
Are there? The number of people testing your typical Firefox minor release is about an order of magnitude lower than the number of people testing bleeding-edge Firefox trunk last I checked. And it's at least two orders of magnitude lower than the number of people testing a major release beta.
If you talk to the Mozilla QA and release folks, one of their big problems is in fact the lack of minor release testers...
> Just to avoid making users upgrade too often?
Yes. The typical monthly Firefox minor update ships on the order of 30-100 fixes depending on the month (security problems, stability problems, compat problems, etc). Micro-patching would involve 1-3 upgrades a day.
If the upgrade could happen silently and without any user notification (which is what Chrome is working and and what Mozilla would like to get to), that may be acceptable. But even just telling the user three times a day "hey, I just updated" is a deal-breaker.
> The mozilla project isn't so immature they need lots of people testing their new
> experimental code.
As a matter of fact, the only way to find out whether you broke some intranet site somewhere is to have someone on that particular intranet testing your "experimental code" (which 3.6 is not, by any means).
Typically betas of Firefox end up with several hundred thousand users.... and that still doesn't catch bugs on little-known sites like Hotmail (which apparently thinks Firefox 3.6 is Firefox 2 and therefore breaks in some cases).
> It would do us all no good if Mozilla did implement H.264 and then got hooked for
> megabucks when the H.264 licensing agreement suddenly requires dollars per instance of
> software decoding H.264.
That licensing agreement already requires such. If Mozilla were to ship an H.264 decoder themselves, they would need to pay $5 million per year (see http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf for the terms).
The thing is .... IE8 claims to support CSS2.1 and actually supports it well, at least in my testing. Webkit's support, on the other hand, is pretty buggy (complete fail on handling many sorts of dynamic changes, for example).
If by "innovation" you mean "making things up while not implementing the existing standards very well", then webkit is indeed innovating. Just like IE as in the late 1990s, right?
Seamonkey was not included because only one browser per "vendor" is allowed, and technically Seamonkey and Firefox come from the same "vendor" (Mozilla).
> Not to mention that certain browsers (*cough* IE) take way longer to give you a usable
> browser than they do to just display the window.
Safari (at least on Mac) does the exact same thing too...
Seamonkey wasn't included because it's technically from the same "vendor" as Firefox (Mozilla, to be precise) and the screen can only include one browser per vendor. Seamonkey most definitely has enough market share in Europe to be on the screen otherwise.
Yes, it really is that difficult. Consider this classic example in English:
Time flies like an arrow.
Fruit flies like a banana.
There happen to be two ways to read the latter sentence. One is in a way analogous to the former one: the subject is "Fruit", the intransitive verb is "flies", and "like a banana" is an adverb phrase. The other way to read it is that the subject is the noun phrase "Fruit flies" , the transitice verb is "like" and the direct object is "a banana". Heck, this case is difficult for _humans_ to get "right" at times.
There are various situations like that in which the meaning is ambiguous, but even worse are situations in which the concepts used are just nonexistent in one of the languages/cultures. For example, English names are made up of three parts, typically: first, middle, last. Russian names are also made up of three parts: given, patronymic, family. Russian family name is a good match for English last name. Russian given name is a good match for English first name. Russian patronymic is ... not really a match for English middle name (in that for example it's not up to the parents to choose it), but occupies a similar position in names, obviously.
So when translating a phrase containing (patronymic) into English, what word you use to translate it really needs to depend on what's being said. If it's a technical discussion about the concept, translate as "patronymic". If it's a casual discussion about names, "middle name" may be appropriate. If the Russian text says that X addressed Y by name and patronymic then that _is_ what they did, but that happens to be the standard polite form of address. The equivalent English form is a Mr/Mrs/whatever followed by the last name, and the translation should reflect that.
There are also often situations in which two phrases are technically the same in terms of denotation but have different connotations (or heck, just different emphasis on which words are important; compare "I saw him" to "I saw him/em" and note that such emphasis differences can be expressed with word order in many languages). Getting that right can be very difficult unless you really understand what's being said. Pattern matching might work if you've seen that exact pattern before (which is Google's approach), but even small differences in the surrounding sentence structure can totally change the meaning of the part you're trying to translate.
I leave you with this short story (or rather stories):
Jack was walking across the meadow when he saw a spring. The spring glinted in the
sunlight, and he thought that he'd never seen something quite so beautiful. He bent
down and...
1) ... put it in his pocket. ... had a drink.
2)
How much lookahead in the translation is needed to translate the first sentence correctly? If the rest of the story is option 2 above, how do you know that he didn't just take a swig from his flask before picking up the bit of metal?
At the time when FDR was creating the entitlements, immigration to the US was at historic lows because there were no jobs to be had (so not much reason to immigrate). If you look at you will see that in the 1920s (which saw immigration restrictions passed in 1921 and 1924) immigration averaged 400k a year (as compared to 900k a year in the 1900-1914 timeframe; 1915-1919 is partially showing the effects of WWI). In 1931-1946, immigration averaged 50k a year. If you assume that none of this happened during WWII, then we're talking 75k a year averages for the 1930s. Immigration quotas as set in 1924 were about 150k from Europe, nothing from Asia, no limits on Latin America.
I doubt those immigration numbers would have looked much different without the quotas in the 30s.... again, no point immigrating to a country where you then won't be able to find a job.
Note that the entitlements put in place at the time were not nearly as generous as what we have now. For example Social Security didn't cover jobs in agriculture, domestic service, government, teaching, nurses, hospitals, anyone who worked intermittently. The upshot was that about half the workers in the US were not covered by it; I would expect that fraction to have been even higher amongst recent immigrants. See http://en.wikipedia.org/wiki/Social_Security_(United_States)#Controversy for some details and links to references.
I don't have data offhand on the public employment projects and unemployment benefits, but the WPA jobs were restricted to "Any American citizen, or other person owing allegiance to the United States" (see http://www.gjenvick.com/WPA/1939-04-17-Questions-Answers-WPA-Employment-WagesAndHours.html ). It's not clear to me whether that latter part covers immigrants prior to naturalization or only residents of US territories....
> no coincidence that the US transitioned from an open immigration society to a closed
> society in the 20s and 30s
Uh.... The Emergency Quota Act was passed in 1921. What entitlements were being doled out in 1921? Note that the act didn't place any limits on immigration from Latin America and placed the limit on Northern/Western Europe higher than actual immigration levels; it was basically targeted at limiting immigration from Eastern/Southern Europe. And that had more to do with "those people aren't like us" than with entitlements. http://en.wikipedia.org/wiki/History_of_Immigration_to_the_United_States#New_Immigration has a good summary.
Of course the Chinese Exclusion Act of 1882 can hardly be explained by entitlements as well.
The truth is that immigration restrictions in the US have always had more to do with the existing population feeling that the ethnic balance is threatened than with anything else. That's exactly what's going on now too.
Now I agree that entitlements make it more appealing for people to immigrate to the US. But the country was pretty appealing in the early 20th century too.
> It has worked for millennia, and will continue to do so.
Worked in what sense? Preventing wars? Didn't really work that well for WWI or any of a whole bunch of other wars....
The XHTML2 standard was designed in such a way that there was no good way to tell whether content was supposed to be XHTML2 or XHTML1, but required quite different treatment of the same content.
So the only way to handle this in the browser would be on a page-by-page whitelist or blacklist basis. IE8 did in fact do this, but most other browser authors don't quite have unlimited resources to audit the entire web like that. Nor can you argue that this is in any way a "simplification" for the browser.
In general, it's hard to argue that XHTML2 was in any way a simplification for browsers given that not a single browser implemented it. Had they thought it would be worth it, I'm fairly certain they would have.
Different types of vulnerabilities are likely, yes. Some security risks will become smaller (e.g. no more disagreement between browser and plug-in as to what the security context of a given piece of script is, due to there being only one piece of code enforcing security policy).
But more importantly, there won't be a monoculture of vulnerabilities (modulo vulnerabilities required by the spec and not caught in review), and vulnerability patching would happen when browsers patch their stuff and push the security fixes (how successful that is varies by browser) and not when users install updated versions of the Flash plug-in (which is never, to a first approximation).
I think you underestimate the "without breaking backwards compatibility" part of this.
XHTML2 was pretty much designed to not work with any existing web infrastructure (either existing content or existing browsers). If you think a parallel web built from the ground up is the way to go, feel free to work on it, but the network effects involved make it a pretty risky prospect.
Of course the new benchmark still does things like "run this test for 100ms, take the number of runs, multiply by some magic number (different for each test), then add up all the results and declare it the total score". Which means that while the individual test results might mean something the total score doesn't, much. It's possible to be fast on one thing, really slow on everything else, and trivially win on total score, since it's a straight sum.
Ah, interesting. The source has actually changed significantly from the last time I looked at this. Or the article author is on crack about what benchmark it is.
I assume they ran http://jsbenchmark.celtickane.com/Run.aspx which actually looks like a legitimate benchmark. Celtic Kane used to push a dom/css/etc benchmark which basically did things like "measure speed of CSS animation" by setting style.x and style.y and the like.
> I can't help to find the testing biased.
It's not biased. Just incompetent. You can tell by the fact that they think the JSBenchmark numbers actually mean anything (which implies they've never read the source for that benchmark), for example.
Did you look at the "Mozilla" benchmark? It's basically V8 + Sunspider + some other stuff. Very heavily weighted towards the V8 + Sunspider scores. So that number is basically just the average of the Sunspider and V8 numbers.
And the Opera number there is due to the fact that the tester stopped and restarted the test, which resets the timers involved... Over here Opera does well on that test, but nowhere close to that far ahead of the others.
In all, this is about par for the course for benchmarking articles out there: someone who doesn't understand the (not particularly good and hard to use well) tools misusing them badly, then reporting the results.
Turns out, there are no good independent benchmarks, because writing a decent browser benchmark is _hard_. The two sets of independent tests actually used in the article are broken beyond belief (don't measure what they think they're measuring, are easily gamed, etc).
In practice, even the dependent benchmarks aren't very good (Dromaeo measures its harness overhead more than anything else in a lot of cases, V8 tests are designed around the V8 engine, Sunspider has known bugs that cause some tests to produce random results and cause others to do different amounts of work in different browsers, that sort of thing). But they're somewhat better than the independent ones....
Might help if the "real OSes" provided more useful 3d apis to build on instead of having to do things from scratch, no? ;)
> And the naive solution to a shuffling an array is similar to bubblesort, traverse through
> the array and generate a random number up to array size to swap the element with.
While this is not in fact perfectly random (the right way would be to generate a number up to remaining elements, then add the offset), it's a lot more random than what Microsoft did here. Did you read the article?
Note that the article author is 40 years old. Dunno whether you consider that "young".
> given the size/age/complexity of the Firefox codebase compared to Chrome
The Firefox codebase was comparable to the Chrome one or smaller, last I checked. Age is an interesting question and hard to measure as parts of a codebase get rewritten. Complexity... a tossup.
Seriously, take a look at both carefully instead of just reading the hype.