Reading through http://en.wikipedia.org/wiki/Treaty_Clause it sounds like one major difference is that a Treaty allows something that would otherwise be unconstitutional to be done by the federal government (see the part about "can use treaties to legislate in areas which would otherwise fall within the exclusive authority of the states").
Also note that according to the same article these distinctions are only relevant for internal US purposes; all these agreements are seen as equivalent in international law.
That's pretty likely, and I assume they do; I just haven't seen their code, and they haven't said what they're doing, so I couldn't use them as an example.;)
It will be 64-bit native on Mac OS 10.6, except for the plugin process which will run as 32-bit. The 64-bit OS/library support in 10.5 is broken enough that only 32-bit Firefox will be supported there.
Also, 64-bit will be a supported configuration, on par with 32-bit, on Linux. I would expect that "Linux" in this context includes things like *BSD as well.
I believe that 64-bit has been the "supported" Solaris configuration for a while now.
On Windows, 64-bit will probably compile and run but not be a supported setup for Firefox 4; bugs that only show up on Windows in 64-bit builds are not blocking release at this point.
I expect OS/2 builds will continue to be 32-bit only.;)
For other OSes, it's not clear to me when Fx4 will get ported, nor in which flavor, at this point. I welcome any information on the matter.
The attack surface with WebGL are malicious shaders that try to trigger bugs in graphics drivers. Sadly, graphics drivers trust shaders to not be malicious.
Note that both Gecko and Webkit are shipping shader validators that process the provided shaders; they're not passed through directly to the graphics driver.
For Firefox, "beta" means "get the web developers to test their sites and actually report any issues they find". Sadly, web developers don't do that until you call what you have a beta, and one can sort of understand them: they don't have time to run nightlies.
Predictably, this means that once you release a beta you get a slew of bug reports...
In this case the situation was complicated by the fact that while there were some major changes still pending (e.g. an entirely new JS jit), other major changes that needed website compat testing ASAP (like an entirely new HTML parser) had already landed. So the beta cycle started to get web developers to report bugs in the latter (of which there were plenty, largely due to incomplete reverse engineering of parsing behavior in the HTML5 spec), even though everyone knew that there were more major changes to come.
The 14 bugs are blockers for a beta, not a final release. And yes, they're showstoppers for the beta, at least in part because there are supposed to be no API changes between beta and final.
Looking at the bugs, 7 are crashes that happen far too often, 1 a security bug, 1 a serious rendering regression that makes form controls disappear altogether in some cases, 2 are interface changes that are needed for Firebug to work with Firefox 4 (and have to happen before beta; see above), 1 a problem with rendering Google maps, 1 a regression that breaks execution of scripts inserted via XSLT, but requires nontrivial changes to the script-execution-ordering code to fix. One is an API change needed to make Jetpack actually work; again needs to happen for beta.
> where a good implementation uses simple translation logic for emitted instructions
Actually, no. Not really. That is, you do a translation, but you have to optimize it as you go; else you lose.
> Since Mozilla already had most of the instruction generation logic from their old bytecode > implementation
As a matter of fact, no. That's what JaegerMonkey is: instruction generation logic; takes the bytecode as input, and produces output that the assembler can then assemble...
A regular nightly, or from the tracemonkey branch? The latest batch of JS improvements that the article is about hasn't landed on the main trunk yet.
But yes, under the assumption that this is a mozilla-central nightly the numbers you quote look about as expected.
For your last question, JaegerMonkey uses the same assembler as Nitro to do the final generation of bits in memory from the output of the compiler. It also use the same regular expression engine as Nitro. Those are the only things that are shared with Nitro. It also shares some number-to-string conversion code with V8, as I recall.
To be fair, when Sunspider was created the tests in it took a while to run; in fact at the time they all took about the same amount of time (several seconds each, iirc) in IE7.
> Does this speed-up translate to faster render speed
For some cases, yes. Primarily for cases where the gating factor is computing what to render. Those aren't that common on the web right now (e.g. because they'd not work at all in IE8), but I expect them to become more common once all browsers can do those sorts of computations in real time.
Now you're correct that whole-system performance depends on drawing, CSS, DOM, etc, not just on JavaScript. Unfortunately, benchmarking those in non-dumb ways (i.e. ones that actually make benchmark improvements imply real-life improvements) is even harder than doing that for JavaScript.
1) Spidermonkey still compiles the AST to bytecode. 2) An assembler does just that: assembles. This means a 1-1 mapping of some other sort of
representation of the exact machine instructions you want into actual bits in memory.
There are no smarts here and no optimization going on; the only question is how fast
you generate those bits in memory; an ideal assembler does this as fast as possible
and without using too much memory. Now you have to generate assembly (or whatever
representation the assembler takes as input) for it to assemble. That's the job of
the compiler. JaegerMonkey takes the bytecode generated in step 1 and compiles it,
passing the output to the assembler borrowed from Nitro. This compilation step is
where (some of) the optimization takes place, and this is not code shared with Nitro. 3) Tracemonkey is most certainly useful for Sunspider; just not as useful as for other
things. See, for example, http://arewefastyet.com/?machine=6 where the purple line is
below the black one solely because of Tracemonkey. Alernately, see https://bug580468.bugzilla.mozilla.org/attachment.cgi?id=482609 where you can see the
scores on each sunspider subtest as of a week or so ago; the -m column is JaegerMonkey
without Tracemonkey, -j is Tracemonkey without Jaegermonkey, and -mjp is what's
actually being used now (a combination of the two, with some smarts about deciding
when to use which one). 4) The goal of Kraken is in fact to include anticipated use cases. If you know
anticipated use cases it doesn't include, I'm sure Rob Sayre would love to know what
they are.
The early public betas of Firefox are primarily there for web developers to start testing their sites and for extension developers to update their extensions. Turns out, you need to call it a beta for web developers to see whether their site still works... if you don't, you end up with a slew of last-minute bug reports about sites that you didn't happen test (esp. because a bunch of them are intranets, people's cable-modem config pages, etc).
As you might have noticed, beta7 is going to be the first feature-complete beta of Firefox 4. So it's not that there have been so many bugs that beta after beta has to happen; it's rather that to get people to test websites you have to start releasing betas way before you're "ready" to call your browser feature-complete, even.
That's irrelevant, unfortunately. I turns out that people agree on all sorts of stuff in theory about how others should make decisions, but don't apply it to their own decision-making...
>... except that science produces testable, verifiable, repeatable results.
This is the theory, yes.
It's more true in some sciences than others. For example, in medicine, verifying results (e.g. withholding treatment that a previous study determined to be effective from a test group to see whether it really is effective, or giving a substance a previous study determined is harmful to a test group to see whether it really is harmful) is generally considered unethical and is disallowed by the various ethics boards. Heck, measuring outcomes in a hospital and then adjusting hospital practices based on that has caused hospitals to get in trouble with ethics boards in the US because that's "unauthorized experimentation on humans". Note that the ethics board had a problem with the measuring outcomes bit, not the changing practices bit...
In other sciences, the whole "testable" bit is somewhat suspect, and I say this as someone who's done some astrophysics in the past. Some things we can try to verify using new observations, for example, but it's very easy to overfit your model to your available data and then have no new data coming in for a while that tests the model, and no way to design experiments to test it. Climate science has some similar issues.
OS X doesn't involve reconciling multiple constituencies or implementors with divergent interests. It was also not aiming to create a _specification_; just an implementation. It's often easier to implement than to specify.
> I should infer that the writers of the HTML5 recommendation are creating the documentation > to fit the existing browser implementations of HTML5?
Not quite.
There are two parts to HTML5. There's the "describe how the web works" part. This would be HTML parsing, the Window object, etc. This consists of reverse-engineering the existing browsers and then specifying something preferably sane that, if implemented, gives a working web browser that works with actual web sites.
The other part is the new features part. This consists of writing specifications of new features, fixing them based on implementor feedback, etc.
> What does time to implement have to do with the writing of the recommendation?
A W3C standards-track document doesn't become a Recommendation until there are two interoperable implementations. That means the spec text is written, a test suite is written, and two independent implementations are both passing the test suite.
> W3C writes the recommendation, and browser developers implement the recommendation in > their software
Writing specs without implementor feedback is an excellent way to write specs that can't be implemented in practice (e.g. are self-contradictory, contradict existing de jure or de facto standards, require behavior that any sane application developer is unwilling to impose on his users, etc).
Lots of specs out there like that. They end up being implemented "incorrectly" (e.g. ignoring part of the self-contradictory text, and probably different parts in different implementations, ignoring the parts of the spec that don't work with other specs or with users), and then people bitch and moan about the buggy implementations. That's not really a world that we want all that much.
The fact of the matter is, a 1000 page technical document that precisely defines the behavior of an _existing_ complicated system takes a while to write. And that's before we start thinking about the time to implement (e.g. every browser having to rewrite its HTML parser, every browser having to modify its event loop, that sort of thing).
> Why is it ok for Israel to have nukes, but not Iran?
In terms of international law, as I understand it, because Iran signed a treaty (the Nuclear Non-Proliferation Treaty). This treaty says (just the parts relevant here, quoting wikipedia liberally) that:
1) Iran agrees to not "receive", "manufacture", or "acquire" nuclear weapons, or "seek or
receive any assistance in the manufacture of nuclear weapons". 2) Iran agrees to safeguards and inspections by the IAEA to enforce item 1 above. 3) Iran can have a nuclear energy program as long as it can demonstrate that this is not
being used for the development of nukes. 4) The nuclear-armed signatories of the treaty (US, UK, France, Russia, and China)
promise to not transfer "nuclear weapons or other nuclear explosive devices" to any
other countries and "not in any way to assist, encourage, or induce" any other
countries to acquire nuclear weapons. That would include Iran under "other countries".
The nuclear-armed signatories have also made some nonbinding commitments (as in, NOT part of the treaty) to not attack non-nuclear armed states with nukes unless first attacked with nukes themselves, or attacked by conventional forces of someone allied to someone with nukes.
Israel has never signed this treaty (nor have India and Pakistan). Of course it has also never declared that it has nuclear weapons, even though everyone is pretty convinced it does based on various circumstantial evidence and Mordechai Vanunu's accusations. Israel _has_ publicly said they would not be the first country in the middle east to test a nuclear weapon.
Now there are two possible "legal" (in terms of international law) courses of action for Iran. One is to stick to the NPT and not develop nuclear weapons. This may well be what they're doing; I don't have the information to judge. The other is to withdraw from the NPT (which requires 3 months notice and nothing else) and do whatever they want with regard to nuclear weapons. This is what North Korea ended up doing in 2003.
Of course people might treat Iran withdrawing from the NPT as "a crime", but at that point it's a matter of that being possibly against said people's national interests, not a "crime" per se.
I am not a lawyer; this is not international law advice.;)
Slashdot Mirror
> after H.264 became eternally free for streaming
Except it didn't, except in some limited cases. Please read http://shaver.off.net/diary/2010/08/27/free-as-in-smokescreen/
All I know about it I got at the link I cited. So I can't tell you more than reading it would, sorry.
Would be good to get a decent constitutional lawyer on the line, though...
Reading through http://en.wikipedia.org/wiki/Treaty_Clause it sounds like one major difference is that a Treaty allows something that would otherwise be unconstitutional to be done by the federal government (see the part about "can use treaties to legislate in areas which would otherwise fall within the exclusive authority of the states").
Also note that according to the same article these distinctions are only relevant for internal US purposes; all these agreements are seen as equivalent in international law.
That's pretty likely, and I assume they do; I just haven't seen their code, and they haven't said what they're doing, so I couldn't use them as an example. ;)
It will be 64-bit native on Mac OS 10.6, except for the plugin process which will run as 32-bit. The 64-bit OS/library support in 10.5 is broken enough that only 32-bit Firefox will be supported there.
Also, 64-bit will be a supported configuration, on par with 32-bit, on Linux. I would expect that "Linux" in this context includes things like *BSD as well.
I believe that 64-bit has been the "supported" Solaris configuration for a while now.
On Windows, 64-bit will probably compile and run but not be a supported setup for Firefox 4; bugs that only show up on Windows in 64-bit builds are not blocking release at this point.
I expect OS/2 builds will continue to be 32-bit only. ;)
For other OSes, it's not clear to me when Fx4 will get ported, nor in which flavor, at this point. I welcome any information on the matter.
The attack surface with WebGL are malicious shaders that try to trigger bugs in graphics drivers. Sadly, graphics drivers trust shaders to not be malicious.
Note that both Gecko and Webkit are shipping shader validators that process the provided shaders; they're not passed through directly to the graphics driver.
For Firefox, "beta" means "get the web developers to test their sites and actually report any issues they find". Sadly, web developers don't do that until you call what you have a beta, and one can sort of understand them: they don't have time to run nightlies.
Predictably, this means that once you release a beta you get a slew of bug reports...
In this case the situation was complicated by the fact that while there were some major changes still pending (e.g. an entirely new JS jit), other major changes that needed website compat testing ASAP (like an entirely new HTML parser) had already landed. So the beta cycle started to get web developers to report bugs in the latter (of which there were plenty, largely due to incomplete reverse engineering of parsing behavior in the HTML5 spec), even though everyone knew that there were more major changes to come.
The 14 bugs are blockers for a beta, not a final release. And yes, they're showstoppers for the beta, at least in part because there are supposed to be no API changes between beta and final.
Looking at the bugs, 7 are crashes that happen far too often, 1 a security bug, 1 a serious rendering regression that makes form controls disappear altogether in some cases, 2 are interface changes that are needed for Firebug to work with Firefox 4 (and have to happen before beta; see above), 1 a problem with rendering Google maps, 1 a regression that breaks execution of scripts inserted via XSLT, but requires nontrivial changes to the script-execution-ordering code to fix. One is an API change needed to make Jetpack actually work; again needs to happen for beta.
> where a good implementation uses simple translation logic for emitted instructions
Actually, no. Not really. That is, you do a translation, but you have to optimize it as you go; else you lose.
> Since Mozilla already had most of the instruction generation logic from their old bytecode
> implementation
As a matter of fact, no. That's what JaegerMonkey is: instruction generation logic; takes the bytecode as input, and produces output that the assembler can then assemble...
Firefox 4.0b6 doesn't have JaegerMonkey. This is why the article here is about nightly builds (which is what you're using with Chrome, I will note).
I suggest testing Firefox 4.0b7 when it comes out; you'll see quite different numbers.
> FireFox 4 beta: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101020
> Firefox-4.0/4.0b8pre
A regular nightly, or from the tracemonkey branch? The latest batch of JS improvements that the article is about hasn't landed on the main trunk yet.
But yes, under the assumption that this is a mozilla-central nightly the numbers you quote look about as expected.
For your last question, JaegerMonkey uses the same assembler as Nitro to do the final generation of bits in memory from the output of the compiler. It also use the same regular expression engine as Nitro. Those are the only things that are shared with Nitro. It also shares some number-to-string conversion code with V8, as I recall.
> but it's a pretty pointless benchmark.
To be fair, when Sunspider was created the tests in it took a while to run; in fact at the time they all took about the same amount of time (several seconds each, iirc) in IE7.
> Does this speed-up translate to faster render speed
For some cases, yes. Primarily for cases where the gating factor is computing what to render. Those aren't that common on the web right now (e.g. because they'd not work at all in IE8), but I expect them to become more common once all browsers can do those sorts of computations in real time.
Now you're correct that whole-system performance depends on drawing, CSS, DOM, etc, not just on JavaScript. Unfortunately, benchmarking those in non-dumb ways (i.e. ones that actually make benchmark improvements imply real-life improvements) is even harder than doing that for JavaScript.
There are several things wrong here:
1) Spidermonkey still compiles the AST to bytecode.
2) An assembler does just that: assembles. This means a 1-1 mapping of some other sort of
representation of the exact machine instructions you want into actual bits in memory.
There are no smarts here and no optimization going on; the only question is how fast
you generate those bits in memory; an ideal assembler does this as fast as possible
and without using too much memory. Now you have to generate assembly (or whatever
representation the assembler takes as input) for it to assemble. That's the job of
the compiler. JaegerMonkey takes the bytecode generated in step 1 and compiles it,
passing the output to the assembler borrowed from Nitro. This compilation step is
where (some of) the optimization takes place, and this is not code shared with Nitro.
3) Tracemonkey is most certainly useful for Sunspider; just not as useful as for other
things. See, for example, http://arewefastyet.com/?machine=6 where the purple line is
below the black one solely because of Tracemonkey. Alernately, see
https://bug580468.bugzilla.mozilla.org/attachment.cgi?id=482609 where you can see the
scores on each sunspider subtest as of a week or so ago; the -m column is JaegerMonkey
without Tracemonkey, -j is Tracemonkey without Jaegermonkey, and -mjp is what's
actually being used now (a combination of the two, with some smarts about deciding
when to use which one).
4) The goal of Kraken is in fact to include anticipated use cases. If you know
anticipated use cases it doesn't include, I'm sure Rob Sayre would love to know what
they are.
The early public betas of Firefox are primarily there for web developers to start testing their sites and for extension developers to update their extensions. Turns out, you need to call it a beta for web developers to see whether their site still works... if you don't, you end up with a slew of last-minute bug reports about sites that you didn't happen test (esp. because a bunch of them are intranets, people's cable-modem config pages, etc).
As you might have noticed, beta7 is going to be the first feature-complete beta of Firefox 4. So it's not that there have been so many bugs that beta after beta has to happen; it's rather that to get people to test websites you have to start releasing betas way before you're "ready" to call your browser feature-complete, even.
I don't think anyone's talking about replacing 1TB internal drives with SSDs, though. The drives that are being replaced are the 64-256GB ones.
SSDs cost about 5x what equivalent size hard drives cost right now, from a brief look at newegg.
So your 4-disk raid will be at 80% of the price of the SSD. And has the minor problem of not actually fitting in your laptop.
That's irrelevant, unfortunately. I turns out that people agree on all sorts of stuff in theory about how others should make decisions, but don't apply it to their own decision-making...
> we know we've crossed the line, at least, from there.
Do we? In practice, the 20th century shows that for many people this in fact does NOT cross the line....
> ... except that science produces testable, verifiable, repeatable results.
This is the theory, yes.
It's more true in some sciences than others. For example, in medicine, verifying results (e.g. withholding treatment that a previous study determined to be effective from a test group to see whether it really is effective, or giving a substance a previous study determined is harmful to a test group to see whether it really is harmful) is generally considered unethical and is disallowed by the various ethics boards. Heck, measuring outcomes in a hospital and then adjusting hospital practices based on that has caused hospitals to get in trouble with ethics boards in the US because that's "unauthorized experimentation on humans". Note that the ethics board had a problem with the measuring outcomes bit, not the changing practices bit...
In other sciences, the whole "testable" bit is somewhat suspect, and I say this as someone who's done some astrophysics in the past. Some things we can try to verify using new observations, for example, but it's very easy to overfit your model to your available data and then have no new data coming in for a while that tests the model, and no way to design experiments to test it. Climate science has some similar issues.
OS X doesn't involve reconciling multiple constituencies or implementors with divergent interests. It was also not aiming to create a _specification_; just an implementation. It's often easier to implement than to specify.
> I should infer that the writers of the HTML5 recommendation are creating the documentation
> to fit the existing browser implementations of HTML5?
Not quite.
There are two parts to HTML5. There's the "describe how the web works" part. This would be HTML parsing, the Window object, etc. This consists of reverse-engineering the existing browsers and then specifying something preferably sane that, if implemented, gives a working web browser that works with actual web sites.
The other part is the new features part. This consists of writing specifications of new features, fixing them based on implementor feedback, etc.
> What does time to implement have to do with the writing of the recommendation?
A W3C standards-track document doesn't become a Recommendation until there are two interoperable implementations. That means the spec text is written, a test suite is written, and two independent implementations are both passing the test suite.
> W3C writes the recommendation, and browser developers implement the recommendation in
> their software
Writing specs without implementor feedback is an excellent way to write specs that can't be implemented in practice (e.g. are self-contradictory, contradict existing de jure or de facto standards, require behavior that any sane application developer is unwilling to impose on his users, etc).
Lots of specs out there like that. They end up being implemented "incorrectly" (e.g. ignoring part of the self-contradictory text, and probably different parts in different implementations, ignoring the parts of the spec that don't work with other specs or with users), and then people bitch and moan about the buggy implementations. That's not really a world that we want all that much.
Who do you think is "working out" HTML5 now?
The fact of the matter is, a 1000 page technical document that precisely defines the behavior of an _existing_ complicated system takes a while to write. And that's before we start thinking about the time to implement (e.g. every browser having to rewrite its HTML parser, every browser having to modify its event loop, that sort of thing).
> just on the basis of word-of-mouth.
Uh... Firefox was doing word-of-mouth. Chrome is having serious marketing money poured into it. See http://www.vijayforvictory.com/google/london-is-snowed-with-google-chrome-advertisements/2818/ for example, or http://eu.techcrunch.com/2009/12/14/google-just-advertised-chrome-to-a-million-people-in-the-uk/ (that was around when the European choice screen was coming out, for what it's worth).
So this figure might make sense if it's a reflection of tens to hundreds of millions of dollars poured into advertizing....
> Why is it ok for Israel to have nukes, but not Iran?
In terms of international law, as I understand it, because Iran signed a treaty (the Nuclear Non-Proliferation Treaty). This treaty says (just the parts relevant here, quoting wikipedia liberally) that:
1) Iran agrees to not "receive", "manufacture", or "acquire" nuclear weapons, or "seek or
receive any assistance in the manufacture of nuclear weapons".
2) Iran agrees to safeguards and inspections by the IAEA to enforce item 1 above.
3) Iran can have a nuclear energy program as long as it can demonstrate that this is not
being used for the development of nukes.
4) The nuclear-armed signatories of the treaty (US, UK, France, Russia, and China)
promise to not transfer "nuclear weapons or other nuclear explosive devices" to any
other countries and "not in any way to assist, encourage, or induce" any other
countries to acquire nuclear weapons. That would include Iran under "other countries".
The nuclear-armed signatories have also made some nonbinding commitments (as in, NOT part of the treaty) to not attack non-nuclear armed states with nukes unless first attacked with nukes themselves, or attacked by conventional forces of someone allied to someone with nukes.
Israel has never signed this treaty (nor have India and Pakistan). Of course it has also never declared that it has nuclear weapons, even though everyone is pretty convinced it does based on various circumstantial evidence and Mordechai Vanunu's accusations. Israel _has_ publicly said they would not be the first country in the middle east to test a nuclear weapon.
Now there are two possible "legal" (in terms of international law) courses of action for Iran. One is to stick to the NPT and not develop nuclear weapons. This may well be what they're doing; I don't have the information to judge. The other is to withdraw from the NPT (which requires 3 months notice and nothing else) and do whatever they want with regard to nuclear weapons. This is what North Korea ended up doing in 2003.
Of course people might treat Iran withdrawing from the NPT as "a crime", but at that point it's a matter of that being possibly against said people's national interests, not a "crime" per se.
I am not a lawyer; this is not international law advice. ;)