> Find me a person that prefers automated customer support so I can punch them repeatedly > in the face.
I have actually encountered one example where the automated system is better than I think a person would be. If you call zipcar while in the middle of your reservation, after punching in your member number the automated system starts with:
You have a car reserved from t1 to t2. If you would like to extend the reservation,
press 1.
I haven't listened past that, since I in fact always want to do this. I press 1, it says:
To add half an hour, press 1. To add one hour, press 2. To add...
I've never needed more than an hour. I press 1 or 2, and it says:
Reservation extended.
And then I hang up. Interacting with a person would almost certainly involve more time than that for me to say what I want and for me to do that.
That said, for anything more complicated than this the automated systems suck. And yes, the voice-recognition ones are particularly sucky.
It's not just a matter of money. It's a matter of Firefox not being able to be redistributed by downstream distributors unless they _also_ buy the license. As in, it would effectively stop being free software in the "can modify and redistribute" sense.
Free in what sense? You can use their code in your code. Your code would then not be able to be distributed to users unless you pay the relevant patent licensing fees. The Mozilla Corporation could do that, but then any other Firefox distributors (e.g. Linux distributions) would not be able to distribute Firefox without either removing this functionality or paying the relevant patent licensing fees. Anyone doing a custom build of Firefox and distributing it could be sued by MPEG-LA to recover the money due them.
Effectively, Firefox stops being "free" for practical intents and purposes. It's still "open source", but the only thing you can really do is contribute patches back to the main repository, unless you pay up the patent fees.
That's not exactly a desirable situation. We might end up there, but as a first cut trying to avoid it is a good thing.
For the vast majority of people, calculus is thoroughly useless. I've never understood the emphasis on teaching it to all high school students if possible...
A course in basic statistics, on the other hand (things like "see the numbers in the paper and understand what they mean"), would be much more helpful, in my opinion.
Sort of. Conservation of energy has only held by redefining what "energy" means to include mass (and the separate law of conservation of mass was summarily dumped). Energy and momentum conservation is obviously only true as long as you work in a particular inertial frame (whereas the whole thing with the speed of light is that it seems to be invariant across all reference frames).
But more importantly, the reason you get things like conservation of momentum is that you make fundamental assumptions like the laws of physics being location-invariant; conservation of momentum follows. It's a good assumption given lack of data otherwise, and has been tested pretty well on scales of hundreds of millions of kilometers or so (Earth's orbit). But I wouldn't rule out theories that take place on much larger scales involving non-conservation of momentum.... of course said theories would need to make some testable predictions about exactly how momentum is non-conserved.
Note that the current HTML5 draft proposes parsing SVG in text/html. At least the html5 parser implementation in Gecko (currently trunk-only and not enabled by default yet) supports this.
In summary, for 2008 and based on http://www.mozilla.org/foundation/documents/mf-2008-audited-financial-statement.pdf , something like $17 million taxes, $12 million set aside for future (e.g. if the Google contract doesn't get renewed, say). About $50 million spent, from a total revenue of $80 million or so. That would presumably include salaries+benefits for those 200-ish people, whatever hardware is needed for the developers, the testing infrastructure (see http://atlee.ca/blog/2009/11/02/what-happens-when-you-push/ for example), infrastructure for the various Mozilla web sites (addons.mozilla.org, www.mozilla.org, update servers, etc). Oh, and office space lease, presumably.
How much do you figure it should take to run an organization with about 200 competent (so not necessarily cheap) staff and a fair amount of necessary infrastructure for a year?
> Put that in the bank and you could easily pay the salary of 10 full time programmers
As of end of 2008, there were about 200 people being paid out of the $66 million, according to the link above. That would include programmers, QA, UI designers, marketing, administration, IT staff.
That's somewhat smaller than the number of people Opera, say, employs, at least last time I checked.
The particular change was that if the server sends "Cache-control: public" the SSL content will be cached on disk (after decrypting it, of course). Otherwise it's memory-cached only.
If you're actually trying to prevent your password being compromised, putting it into an http page is the wrong way to do it. Even if the page normally sent it to an https:/// server, nothing is preventing someone who cares from running mitm on the login page itself and just changing the form action or XHR url to an https:/// server of their choice (theirs, say)....
There's been continuous rearchitecture going on in the 1.9, 1.9.1, 1.9.2 Gecko milestones, and it's ongoing. I mean.... the JS engine is being rewritten from the ground up, in 1.9 CSS layout was rewritten from the ground up, the DOM is about to see some major changes...
Not sure why you decided that there's no rearchitecture going on.;)
If you read the article (or better yet the one it cribbed from), the one feature that's so far being considered for backporting to 3.6.x is in fact out-of-process plug-ins.... So what you want is coming! You can try it right now if you grab a nightly build. At least on Linux and Windows.
Firefox has had an update beta channel for years now (since about Firefox 2, as I recall). If you're on the beta channel, you get updated to the next beta.
Similar for the nightly update channel, where you're updated to the new tip build every day....
The exact colors will depend on your monitor's ICC profile settings, the exact way the png was generated, etc. These tests aren't actually designed to look pixel-identical (or if they are, they totally failed at it).
Yep. Like I said, looks like something is not implemented here.
> feTile:
Works fine for me in Firefox 3.5.7.
> gradient failure:
The tests are both buggy; they're not setting the stop-color on the gradient, and stop-color doesn't inherit by default, and the initial value is black. See . If you care, Opera and Webkit render it exactly the same way as Gecko does, because that's what the spec requires.
> pattern fills:
Works fine for me in Firefox 3.5.7.
> script failure:
The first of these passes for me in Firefox 3.5.7 (you did click on the target, right)? The second fails, due to using events not yet implemented in Gecko (I did mention those earlier in this thread).
> dom traversal:
This is a test of what the browser reports via hasFeature, not a test of what it actually does (and not at all a test of anything SVG related except the last entry). Gecko's hasFeature does not claim support for mutation events or DOM 2 Traversal, since there are some edge cases of both that are not implemented yet and because it's better to claim no support than support if you have partial support.
> grouping:
The switch says to put in the lower-right-hand corner only if the "org.w3c.svg.static" feature is supported by the browser. Gecko will not claim to support this feature until it in fact has a feature-complete implementation (e.g. the feComposite thing above).
> supporting svg in svg (seriously, you can't even do THIS?!):
That's testing support for SVG in an (or ; it's the same thing). This is in fact not supported yet, yes.
> text selection formatting:
The behavior claimed correct on this test in terms of the green color contradicts the CSS specification (since the text does not in fact have focus). The lack of a red underline is certainly a bug.
> text underline strike through... really?:
Yep. Just looks like no text-decoration support on in general. Certainly a bug.
> trefs:
Yep, no tref support.
> no text selection at all:
Yep.
> tspan:
In particular the character positioning part. Sure.
> wrong colors (different shades of green between the two images):
Looks the same to me, but this could easily depend on ICC profile settings for your monitor and the like...
Works for me (the reference assumes a UA which doesn't support BasicText and Gecko does in fact support it).
> Things in a published standard are up for debate?
Indeed. Happens all the time, actually.
> Do you know what a standard is and why they exist?
Yes. Do you know what an ivory-tower standard is?
> fonts in images weren't important
Fonts are important. Defining font data using the SVG language itself (as opposed to, say, using downloadable truetype fonts) may not be so important. No one actually supports SVG Fonts as specified, for example. No one is even trying to (because the spec makes no sense).
> I downloaded, installed, and use Firefox, fresh out of the box, no config changes, no > extensions, nothing added on after install.
In that case, I can't explain why you see tests 3-7 failing when everyone else (I checked with a few more people) sees them passing.
> I didn't bother throwing it at the actual test harness for pixel perfect checking
The vast majority of these tests allow rendering differences on the individual pixel level, actually. So that wouldn't help anyway.
> You're also assuming that EVERYONE is running the latest and greatest version, they > aren't and won't be.
Where did I assume that? The question was about development priorities for future versions, and you claimed that SMIL is the wrong thing t
In fact, if you want to look at tests from back in March 2009 done on 3.5.2 (which has the same SVG support as 3.5.7) by one of the SVG working group folks, take a look at http://www.codedread.com/svg-support.php
Note the big red chunk in the first two lines corresponding to lack of SMIL support. Of the remaining 80% of the tests, Firefox 3.5 passes about 3/4, looks like. That's including the fact that it has no SVG Fonts support.
So SMIL was the biggest single SVG 1.1 compliance bit missing in Gecko... which is why it got worked on.
Interesting. Tests 3 through 7 all match up here in Firefox 3.5.7. On Window, Linux, and Mac, on several different hardware and VM configurations. What's special about your setup?
> I should point out that proper font rendering is required for EVERY test.
Sure. That's not the same thing as SVG Fonts, which are a font format for defining font data in SVG instead of using the fonts installed on your system. Whether SVG fonts are important is up for debate in the working group at the moment, in fact.;)
> the composition test fails, gradient tests fail, fill tests fail, event handling and > scripting is pointless in firefox
If you mean the one feComposite test for "the composition test", I can confirm that this fails. The gradient and fill tests pass fine for me. The event tests that are testing stuff that deals with the Core DOM pass fine. The ones that are testing stuff like onfocusin that SVG made up aren't implemented by pretty much anyone last I checked and are slated to be dropped from the SVG spec. The struct-dom tests pass fine over here.
> structured image placement, text selection doesn't work, inheritance is broken,
Not sure which tests you're looking at here.
> text alignment is broken beyond belief.
A lot of that looks unimplemented, yes.
> Gecko hasn't passed any tests,
Again, I'd like to know what's special about your system (or your profile, or your exact Firefox binary) here. If you're willing to take the time, can you run your Firefox in safe mode and see whether it's still failing tests 3-7? If so, where did you download your Firefox from?
And just to make sure, is "svg.enabled" set to true in your about:config?
If you read the article carefully, the only feature that is planned to ship as part of the security+stability releases so far (note the "stability" part) is out-of-process plugins. And the point there is stability.
Slashdot Mirror
> Such a license would likely require them to not release the patented code openly
That's actually not a problem as long as you avoid GPLv3 (and I'm fairly certain that it's not a problem with MPL in particular). But IANAL, etc.
> Such a license would also not pass to others, so Ubuntu/etc would not be able to
> distribute the licensed firefox.
This, on the other hand, is a much bigger concern.
The chromium code Google wrote is BSD.
However, Chrome depends on Webkit, and parts of Webkit are LGPL-only. Much more restrictive than Chromium or Gecko...
> Find me a person that prefers automated customer support so I can punch them repeatedly
> in the face.
I have actually encountered one example where the automated system is better than I think a person would be. If you call zipcar while in the middle of your reservation, after punching in your member number the automated system starts with:
You have a car reserved from t1 to t2. If you would like to extend the reservation,
press 1.
I haven't listened past that, since I in fact always want to do this. I press 1, it says:
To add half an hour, press 1. To add one hour, press 2. To add ...
I've never needed more than an hour. I press 1 or 2, and it says:
Reservation extended.
And then I hang up. Interacting with a person would almost certainly involve more time than that for me to say what I want and for me to do that.
That said, for anything more complicated than this the automated systems suck. And yes, the voice-recognition ones are particularly sucky.
That's been seriously considered. The reason it's not being done (yet?) is described at http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html
Last I checked, Opera only supports Theora, yes.
It's not just a matter of money. It's a matter of Firefox not being able to be redistributed by downstream distributors unless they _also_ buy the license. As in, it would effectively stop being free software in the "can modify and redistribute" sense.
> and ffmpeg being free and with H.264 support
Free in what sense? You can use their code in your code. Your code would then not be able to be distributed to users unless you pay the relevant patent licensing fees. The Mozilla Corporation could do that, but then any other Firefox distributors (e.g. Linux distributions) would not be able to distribute Firefox without either removing this functionality or paying the relevant patent licensing fees. Anyone doing a custom build of Firefox and distributing it could be sued by MPEG-LA to recover the money due them.
Effectively, Firefox stops being "free" for practical intents and purposes. It's still "open source", but the only thing you can really do is contribute patches back to the main repository, unless you pay up the patent fees.
That's not exactly a desirable situation. We might end up there, but as a first cut trying to avoid it is a good thing.
For the vast majority of people, calculus is thoroughly useless. I've never understood the emphasis on teaching it to all high school students if possible...
A course in basic statistics, on the other hand (things like "see the numbers in the paper and understand what they mean"), would be much more helpful, in my opinion.
> and those conservation laws always held.
Sort of. Conservation of energy has only held by redefining what "energy" means to include mass (and the separate law of conservation of mass was summarily dumped). Energy and momentum conservation is obviously only true as long as you work in a particular inertial frame (whereas the whole thing with the speed of light is that it seems to be invariant across all reference frames).
But more importantly, the reason you get things like conservation of momentum is that you make fundamental assumptions like the laws of physics being location-invariant; conservation of momentum follows. It's a good assumption given lack of data otherwise, and has been tested pretty well on scales of hundreds of millions of kilometers or so (Earth's orbit). But I wouldn't rule out theories that take place on much larger scales involving non-conservation of momentum.... of course said theories would need to make some testable predictions about exactly how momentum is non-conserved.
Note that the current HTML5 draft proposes parsing SVG in text/html. At least the html5 parser implementation in Gecko (currently trunk-only and not enabled by default yet) supports this.
In summary, for 2008 and based on http://www.mozilla.org/foundation/documents/mf-2008-audited-financial-statement.pdf , something like $17 million taxes, $12 million set aside for future (e.g. if the Google contract doesn't get renewed, say). About $50 million spent, from a total revenue of $80 million or so. That would presumably include salaries+benefits for those 200-ish people, whatever hardware is needed for the developers, the testing infrastructure (see http://atlee.ca/blog/2009/11/02/what-happens-when-you-push/ for example), infrastructure for the various Mozilla web sites (addons.mozilla.org, www.mozilla.org, update servers, etc). Oh, and office space lease, presumably.
How much do you figure it should take to run an organization with about 200 competent (so not necessarily cheap) staff and a fair amount of necessary infrastructure for a year?
> Where does the money go?
See http://blog.lizardwrangler.com/2009/11/19/state-of-mozilla-and-2008/ and the documents linked from it for the 2008 data.
> Put that in the bank and you could easily pay the salary of 10 full time programmers
As of end of 2008, there were about 200 people being paid out of the $66 million, according to the link above. That would include programmers, QA, UI designers, marketing, administration, IT staff.
That's somewhat smaller than the number of people Opera, say, employs, at least last time I checked.
For comparison, by the way, FY 2008 revenues for Opera were about $87 million according to http://www.opera.com/media/finance/2009/2Q09.pdf
The particular change was that if the server sends "Cache-control: public" the SSL content will be cached on disk (after decrypting it, of course). Otherwise it's memory-cached only.
If you're actually trying to prevent your password being compromised, putting it into an http page is the wrong way to do it. Even if the page normally sent it to an https:/// server, nothing is preventing someone who cares from running mitm on the login page itself and just changing the form action or XHR url to an https:/// server of their choice (theirs, say)....
There's been continuous rearchitecture going on in the 1.9, 1.9.1, 1.9.2 Gecko milestones, and it's ongoing. I mean.... the JS engine is being rewritten from the ground up, in 1.9 CSS layout was rewritten from the ground up, the DOM is about to see some major changes...
Not sure why you decided that there's no rearchitecture going on. ;)
If you read the article (or better yet the one it cribbed from), the one feature that's so far being considered for backporting to 3.6.x is in fact out-of-process plug-ins.... So what you want is coming! You can try it right now if you grab a nightly build. At least on Linux and Windows.
Firefox has had an update beta channel for years now (since about Firefox 2, as I recall). If you're on the beta channel, you get updated to the next beta.
Similar for the nightly update channel, where you're updated to the new tip build every day....
The exact colors will depend on your monitor's ICC profile settings, the exact way the png was generated, etc. These tests aren't actually designed to look pixel-identical (or if they are, they totally failed at it).
> feComp:
Yep. Like I said, looks like something is not implemented here.
> feTile:
Works fine for me in Firefox 3.5.7.
> gradient failure:
The tests are both buggy; they're not setting the stop-color on the gradient, and stop-color doesn't inherit by default, and the initial value is black. See . If you care, Opera and Webkit render it exactly the same way as Gecko does, because that's what the spec requires.
> pattern fills:
Works fine for me in Firefox 3.5.7.
> script failure:
The first of these passes for me in Firefox 3.5.7 (you did click on the target, right)? The second fails, due to using events not yet implemented in Gecko (I did mention those earlier in this thread).
> dom traversal:
This is a test of what the browser reports via hasFeature, not a test of what it actually does (and not at all a test of anything SVG related except the last entry). Gecko's hasFeature does not claim support for mutation events or DOM 2 Traversal, since there are some edge cases of both that are not implemented yet and because it's better to claim no support than support if you have partial support.
> grouping:
The switch says to put in the lower-right-hand corner only if the "org.w3c.svg.static" feature is supported by the browser. Gecko will not claim to support this feature until it in fact has a feature-complete implementation (e.g. the feComposite thing above).
> supporting svg in svg (seriously, you can't even do THIS?!):
That's testing support for SVG in an (or ; it's the same thing). This is in fact not supported yet, yes.
> text selection formatting:
The behavior claimed correct on this test in terms of the green color contradicts the CSS specification (since the text does not in fact have focus). The lack of a red underline is certainly a bug.
> text underline strike through ... really?:
Yep. Just looks like no text-decoration support on in general. Certainly a bug.
> trefs:
Yep, no tref support.
> no text selection at all:
Yep.
> tspan:
In particular the character positioning part. Sure.
> wrong colors (different shades of green between the two images):
Looks the same to me, but this could easily depend on ICC profile settings for your monitor and the like...
> http://www.w3.org/Graphics/SVG/Test/20061213/htmlEmbedHarness/full-struct-cond-03-t.html
Works for me (the reference assumes a UA which doesn't support BasicText and Gecko does in fact support it).
> Things in a published standard are up for debate?
Indeed. Happens all the time, actually.
> Do you know what a standard is and why they exist?
Yes. Do you know what an ivory-tower standard is?
> fonts in images weren't important
Fonts are important. Defining font data using the SVG language itself (as opposed to, say, using downloadable truetype fonts) may not be so important. No one actually supports SVG Fonts as specified, for example. No one is even trying to (because the spec makes no sense).
> I downloaded, installed, and use Firefox, fresh out of the box, no config changes, no
> extensions, nothing added on after install.
In that case, I can't explain why you see tests 3-7 failing when everyone else (I checked with a few more people) sees them passing.
> I didn't bother throwing it at the actual test harness for pixel perfect checking
The vast majority of these tests allow rendering differences on the individual pixel level, actually. So that wouldn't help anyway.
> You're also assuming that EVERYONE is running the latest and greatest version, they
> aren't and won't be.
Where did I assume that? The question was about development priorities for future versions, and you claimed that SMIL is the wrong thing t
Sure. How about http://www.w3.org/Graphics/SVG/Test/20061213/htmlEmbedHarness/basic-color-prop-01-b.html ?
In fact, if you want to look at tests from back in March 2009 done on 3.5.2 (which has the same SVG support as 3.5.7) by one of the SVG working group folks, take a look at http://www.codedread.com/svg-support.php
Note the big red chunk in the first two lines corresponding to lack of SMIL support. Of the remaining 80% of the tests, Firefox 3.5 passes about 3/4, looks like. That's including the fact that it has no SVG Fonts support.
So SMIL was the biggest single SVG 1.1 compliance bit missing in Gecko... which is why it got worked on.
The fonts will vary based on what's installed on your system, obviously.
But are the gradient/fill tests that he's saying fail failing for you?
> I just tried it using 3.5.7.
> I figured since 3 through 7 didn't match up
Interesting. Tests 3 through 7 all match up here in Firefox 3.5.7. On Window, Linux, and Mac, on several different hardware and VM configurations. What's special about your setup?
> I should point out that proper font rendering is required for EVERY test.
Sure. That's not the same thing as SVG Fonts, which are a font format for defining font data in SVG instead of using the fonts installed on your system. Whether SVG fonts are important is up for debate in the working group at the moment, in fact. ;)
> the composition test fails, gradient tests fail, fill tests fail, event handling and
> scripting is pointless in firefox
If you mean the one feComposite test for "the composition test", I can confirm that this fails. The gradient and fill tests pass fine for me. The event tests that are testing stuff that deals with the Core DOM pass fine. The ones that are testing stuff like onfocusin that SVG made up aren't implemented by pretty much anyone last I checked and are slated to be dropped from the SVG spec. The struct-dom tests pass fine over here.
> structured image placement, text selection doesn't work, inheritance is broken,
Not sure which tests you're looking at here.
> text alignment is broken beyond belief.
A lot of that looks unimplemented, yes.
> Gecko hasn't passed any tests,
Again, I'd like to know what's special about your system (or your profile, or your exact Firefox binary) here. If you're willing to take the time, can you run your Firefox in safe mode and see whether it's still failing tests 3-7? If so, where did you download your Firefox from?
And just to make sure, is "svg.enabled" set to true in your about:config?
Firefox is multithreaded in the sense that multiple threads are used for multiple different tasks.
However all layout currently happens on one thread. So yes, 25% CPU on a quad-core in your situation is what I would expect.
If you read the article carefully, the only feature that is planned to ship as part of the security+stability releases so far (note the "stability" part) is out-of-process plugins. And the point there is stability.