> Actually, I thought FF sold competition vs IE to Google.
FF doesn't "sell" anything to Google. Google pays for any searches that are done on Google via the FF search bar. So do other search providers.
> With Chrome the future of FF looks bleak when contract renewal comes up.
Does it? Google has search deals with FF and Opera. Why does Chrome change that calculation?
Google is not in the business of building a browser to build a browser. They're in the business of selling advertising; everything else is just a means to have more opportunities to sell said advertising.
Which part? Exact sources of revenue? Those are as open as the various revenue sources will allow, last I checked. Exact spending? The general categories are published; the exact salaries of particular people are not. Something else?
If that happens, it's a win for Mozilla, at least, since their goal here is a free and open web, not controlling how users get information. Firefox having 100% market share would be a loss for Mozilla....
> it is merely the means to generate the real product: users.
No, the real product is an open web not tied to a particular technology. Users are just a means to that end.
> and their habits are sold to the advertisers.
What does Firefox sell, exactly? I'd really like to know.
> that money comes from selling user behavior.
Not quite. That money comes from partnerships with search engines. The only thing "sold" is whatever you decide to submit to a search engine, and only if you use the little search bar at the top right of the browser, iirc, and is only "sold" to the search engine provider (who is obviously getting that data anyway; you want them to have it so as to actually do the search).
Mozilla is not just open source, it's also open. Open in the sense that all project management (and indeed everything else) is done in the open as much as possible. There are no secret project crash landings of the sort that Chrome was or the current iteration of the Safari JS engine, unless there are external requirements for such (as there were with WebM).
This has the benefit that project contributors who are not Mozilla employees can fully participate in goal-setting and development. It does have the drawback that competitors can borrow the ideas, and possibly even ship them first; this happens all the time. This is viewed as an acceptable cost of doing business in an open way.
Generally, not much harder than writing any piece of technical writing of the same length which has multiple authors with different (and generally conflicting) agendas. The time will also depend on the desired quality of the standard, of course. Writing a standard that says "do something here" or "behavior is not defined" takes less effort than one that carefully describes what a conforming implementation is supposed to do.
The length in this case is order of 1000 pages, last I checked. The desired quality is high (in that "behavior is not defined" stuff is being avoided). The number of authors depends on how you count them, ranging from a minimum of 1 to a maximum of several thousand depending on whom you ask. Realistically, there are at least 5 separate organizations (each with internal politics!) that have veto power over things they don't like, plus the editor, the three working group chairs (one of whom belongs to none of the above 5 organizations), and various invited experts, etc.
That's not even counting the bikeshedding that goes on.
I'm assuming you've either never been involved in a standardization effort of any kind or got very very lucky when you were involved and dealt with something small and uncontroversial.
It wouldn't be hard to support the small subset Opera and Webkit implemented to pass Acid3. Especially if one settles for an implementation as broken as Opera's (font fallback? What's that?)
Properly implementing SVG Fonts in a UA that also supports HTML is really really hard.
Opera and Webkit implemented (very brokenly, in at least Opera's case) a small subset of SVG 1.1 Fonts; basicallu just enough to pass Acid 3. We don't particular want to do that small subset in Gecko, since it gives no benefits to authors or users over the existing downloadable font support (beyond the brownie points on Acid3). On the other hand, support for the full specification in a UA that also supports HTML is... very difficult. SVG fonts are just not designed with integration with HTML in mind. Once you put an in a glyph, all sorts of issues arise (both in terms of the spec being underdefined and in terms of the behavior being very difficult to implement no matter what the spec said).
One of the previous commenters here linked to Robert O'Callahan's post about this, which covers the issues pretty well.
At this point, the SVG working group has decided that SVG Fonts will no longer be a core part of SVG but will be a separate specification, and that it might need some serious work if anyone is ever to implement it in full.
What you were using was a test build, not the actual beta. As you can tell by the fact that the actual beta is different from the build you were using...
Apple is pushing a mix of three things, without differentiating between them very much:
1) Things that are part of the proposed HTML5, CSS3, etc standards and that other
implementors agree are a good idea. 2) Things that Apple has implemented and unilaterally proposed for standardization (which
just means they sort of wrote up how it works in their implementation, without going
too much into detail and threw the writeup over the wall at the W3C) but that other
vendors aren't convinced are a good idea 3) Things that Apple has implemented that they have no plans to propose for
standardization as far as anyone can tell.
A number of -webkit CSS properties fall into bucket 3.
> it isn't a bunch of closed extensions like Microsoft pushed for IE years ago
It actually is, _just_ like the MS and IE situation in the late 1990s. Completely and utterly like it.
> though it is a faster and better browser for the moment.
It's not better if you happen to be blind or have other accessibility needs. Webkit's accessibility support, and therefore Chrome's is a long ways behind Gecko or Trident. Just one example of cases where Webkit's just incomplete compared to the competition (along with handling of CSS selectors and some other things along those lines).
Given the number of employees involved, I would be very surprised if at least some of them didn't need decent screen reader support in the browser; requiring them to use Chrome would almost certainly be a violation of the ADA.
They're not dying; they just moved. Quite a number of mobile sites do the same thing with Safari instead of IE, and Apple pushes its proprietary -webkit things as hard as MS ever did theirs (see the recent fiasco when MS felt like it had to implement -webkit-text-size-adjust, which is otherwise only implemented in Mobile Safari and apparently widely used to make web pages which will only render correctly in Mobile Safari, in its mobile browser...)
Different big company, slightly different technologies, same old tactics.
> The Moz Foundation hasn't published a financial report since 2008
The "2008" report obviously can't be published until a good ways into 2009 (in particular, until after the 2008 tax return has been filed, which is typically by April 15, 2009 if there are no extensions involved).
So the only missing report on that page is the 2009 one, which should be published sometime this year, just like the 2008 one was published last year.
> As I always understood it, only one claim of a patent has to read on a product for the > product to infringe, but all elements of that claim have to be present for that one claim > to succeed
Ah, indeed. I'd misunderstood where in the hierarchy of stuff in a patent "claim" sat, apparently. Thanks for the correction!
Re:What does that tell you about the patent trolls
on
VP8 Codec Coming To FFmpeg
·
· Score: 1, Informative
> requires proof that VP8 uses processes and techniques that are substantially similar to > those claimed
Not even that. To be infringing, you have to be subject to _all_ the claims of the patent. "substantially similar" is not enough if there is one particular claim that doesn't apply to you.
A common way of working around a patent is to pick a particular claim from the patent and make sure that your work is not covered by that claim.
Not yet. Of course the format is less than 2 months old, and there _were_ several hardware companies who committed to implementing support for it at launch.
Also, note that mobile phones don't support "hardware decoding of H.264". They support hardware-acceleration of operations needed to decode a particular profile of H.264: the Basic profile. The one that has lower quality output than VP8 does.
So if you start bringing the hardware accel issue into the picture, then your quality metrics are suddenly in VP8's favor...
All of which is to say that the situation is complicated.;)
> I had been blaming those sites for having bad scripts. Nope. It's IE.
Those aren't mutually exclusive. For something like a language runtime, real slowness happens when the language runtime doesn't happen to efficiently handle something really stupid that a program in the language does. The key is to make the things you don't handle efficiently be the ones that won't get tickled in practice most of the time.... but that doesn't mean program authors shouldn't try to avoid doing stupid things.
> Thus they should be no more protected than people standing on soapboxes.
I happen to agree with that, especially if that's enforced in an even-handed manner (something that hasn't been the case in the state of Washington, sadly); I just disagreed with the blithe dismissal of the petition-signers concerns.;)
Slashdot Mirror
> Actually, I thought FF sold competition vs IE to Google.
FF doesn't "sell" anything to Google. Google pays for any searches that are done on Google via the FF search bar. So do other search providers.
> With Chrome the future of FF looks bleak when contract renewal comes up.
Does it? Google has search deals with FF and Opera. Why does Chrome change that calculation?
Google is not in the business of building a browser to build a browser. They're in the business of selling advertising; everything else is just a means to have more opportunities to sell said advertising.
Nope.
Which part? Exact sources of revenue? Those are as open as the various revenue sources will allow, last I checked. Exact spending? The general categories are published; the exact salaries of particular people are not. Something else?
> But there will be no winner.
No winner in terms of market share, right?
If that happens, it's a win for Mozilla, at least, since their goal here is a free and open web, not controlling how users get information. Firefox having 100% market share would be a loss for Mozilla....
> it is merely the means to generate the real product: users.
No, the real product is an open web not tied to a particular technology. Users are just a means to that end.
> and their habits are sold to the advertisers.
What does Firefox sell, exactly? I'd really like to know.
> that money comes from selling user behavior.
Not quite. That money comes from partnerships with search engines. The only thing "sold" is whatever you decide to submit to a search engine, and only if you use the little search bar at the top right of the browser, iirc, and is only "sold" to the search engine provider (who is obviously getting that data anyway; you want them to have it so as to actually do the search).
Mozilla is not just open source, it's also open. Open in the sense that all project management (and indeed everything else) is done in the open as much as possible. There are no secret project crash landings of the sort that Chrome was or the current iteration of the Safari JS engine, unless there are external requirements for such (as there were with WebM).
This has the benefit that project contributors who are not Mozilla employees can fully participate in goal-setting and development. It does have the drawback that competitors can borrow the ideas, and possibly even ship them first; this happens all the time. This is viewed as an acceptable cost of doing business in an open way.
> How hard is it to decide on a new standard?
Generally, not much harder than writing any piece of technical writing of the same length which has multiple authors with different (and generally conflicting) agendas. The time will also depend on the desired quality of the standard, of course. Writing a standard that says "do something here" or "behavior is not defined" takes less effort than one that carefully describes what a conforming implementation is supposed to do.
The length in this case is order of 1000 pages, last I checked. The desired quality is high (in that "behavior is not defined" stuff is being avoided). The number of authors depends on how you count them, ranging from a minimum of 1 to a maximum of several thousand depending on whom you ask. Realistically, there are at least 5 separate organizations (each with internal politics!) that have veto power over things they don't like, plus the editor, the three working group chairs (one of whom belongs to none of the above 5 organizations), and various invited experts, etc.
That's not even counting the bikeshedding that goes on.
Typical mail volume on the mailing list is around 900 messages a month or so, from a quick look at the archives (conveniently available at http://lists.w3.org/Archives/Public/public-html/ ). Another 400 messages a month or so on the whatwg list (archives at http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ ).
I'm assuming you've either never been involved in a standardization effort of any kind or got very very lucky when you were involved and dealt with something small and uncontroversial.
Please read again.
It wouldn't be hard to support the small subset Opera and Webkit implemented to pass Acid3. Especially if one settles for an implementation as broken as Opera's (font fallback? What's that?)
Properly implementing SVG Fonts in a UA that also supports HTML is really really hard.
> That still counts as performing poorly
Sure. Did I say anything about that? My point was that canvas performance is not the issue here.
Those remaining 3 points are SVG Fonts.
Opera and Webkit implemented (very brokenly, in at least Opera's case) a small subset of SVG 1.1 Fonts; basicallu just enough to pass Acid 3. We don't particular want to do that small subset in Gecko, since it gives no benefits to authors or users over the existing downloadable font support (beyond the brownie points on Acid3). On the other hand, support for the full specification in a UA that also supports HTML is ... very difficult. SVG fonts are just not designed with integration with HTML in mind. Once you put an in a glyph, all sorts of issues arise (both in terms of the spec being underdefined and in terms of the behavior being very difficult to implement no matter what the spec said).
One of the previous commenters here linked to Robert O'Callahan's post about this, which covers the issues pretty well.
At this point, the SVG working group has decided that SVG Fonts will no longer be a core part of SVG but will be a separate specification, and that it might need some serious work if anyone is ever to implement it in full.
In Firefox, about 25% of the time on that page is spent in anything canvas-related. Another 20% is spent painting.
Also, 10% is spent allocating arrays, 20% is spent sorting arrays. Another 15% is spent running other JavaScript of various sorts.
So the issue here is not exactly canvas performance...
> Merging the address and search fields is a big drawback
Of course Mozilla hasn't merged them. So I'm not sure what you think they got wrong.
What you were using was a test build, not the actual beta. As you can tell by the fact that the actual beta is different from the build you were using...
> We're talking real-world (not synthetic benchmarks, but actual page loads)
I'd be interested in the data here. Can you point me to a particular page you're thinking of?
> Isn't Apple pushing standard HTML5?
Apple is pushing a mix of three things, without differentiating between them very much:
1) Things that are part of the proposed HTML5, CSS3, etc standards and that other
implementors agree are a good idea.
2) Things that Apple has implemented and unilaterally proposed for standardization (which
just means they sort of wrote up how it works in their implementation, without going
too much into detail and threw the writeup over the wall at the W3C) but that other
vendors aren't convinced are a good idea
3) Things that Apple has implemented that they have no plans to propose for
standardization as far as anyone can tell.
A number of -webkit CSS properties fall into bucket 3.
> it isn't a bunch of closed extensions like Microsoft pushed for IE years ago
It actually is, _just_ like the MS and IE situation in the late 1990s. Completely and utterly like it.
> though it is a faster and better browser for the moment.
It's not better if you happen to be blind or have other accessibility needs. Webkit's accessibility support, and therefore Chrome's is a long ways behind Gecko or Trident. Just one example of cases where Webkit's just incomplete compared to the competition (along with handling of CSS selectors and some other things along those lines).
Given the number of employees involved, I would be very surprised if at least some of them didn't need decent screen reader support in the browser; requiring them to use Chrome would almost certainly be a violation of the ADA.
They're not dying; they just moved. Quite a number of mobile sites do the same thing with Safari instead of IE, and Apple pushes its proprietary -webkit things as hard as MS ever did theirs (see the recent fiasco when MS felt like it had to implement -webkit-text-size-adjust, which is otherwise only implemented in Mobile Safari and apparently widely used to make web pages which will only render correctly in Mobile Safari, in its mobile browser...)
Different big company, slightly different technologies, same old tactics.
> The Moz Foundation hasn't published a financial report since 2008
The "2008" report obviously can't be published until a good ways into 2009 (in particular, until after the 2008 tax return has been filed, which is typically by April 15, 2009 if there are no extensions involved).
So the only missing report on that page is the 2009 one, which should be published sometime this year, just like the 2008 one was published last year.
> As I always understood it, only one claim of a patent has to read on a product for the
> product to infringe, but all elements of that claim have to be present for that one claim
> to succeed
Ah, indeed. I'd misunderstood where in the hierarchy of stuff in a patent "claim" sat, apparently. Thanks for the correction!
> requires proof that VP8 uses processes and techniques that are substantially similar to
> those claimed
Not even that. To be infringing, you have to be subject to _all_ the claims of the patent. "substantially similar" is not enough if there is one particular claim that doesn't apply to you.
A common way of working around a patent is to pick a particular claim from the patent and make sure that your work is not covered by that claim.
http://lists.xiph.org/pipermail/theora/2010-April/003769.html has a pretty good summary of the state of the patent situation for H.264. Especially note the paragraph starting "It doesn't have to be this way".
> Can the same be said of VP8?
Not yet. Of course the format is less than 2 months old, and there _were_ several hardware companies who committed to implementing support for it at launch.
Also, note that mobile phones don't support "hardware decoding of H.264". They support hardware-acceleration of operations needed to decode a particular profile of H.264: the Basic profile. The one that has lower quality output than VP8 does.
So if you start bringing the hardware accel issue into the picture, then your quality metrics are suddenly in VP8's favor...
All of which is to say that the situation is complicated. ;)
> I had been blaming those sites for having bad scripts. Nope. It's IE.
Those aren't mutually exclusive. For something like a language runtime, real slowness happens when the language runtime doesn't happen to efficiently handle something really stupid that a program in the language does. The key is to make the things you don't handle efficiently be the ones that won't get tickled in practice most of the time.... but that doesn't mean program authors shouldn't try to avoid doing stupid things.
> as far as I know, FireFox 2.0 is no longer receiving security updates
Yep. Neither is Firefox 3.0. The only supported release versions of Firefox right now are 3.5.x and 3.6.x.
> Thus they should be no more protected than people standing on soapboxes.
I happen to agree with that, especially if that's enforced in an even-handed manner (something that hasn't been the case in the state of Washington, sadly); I just disagreed with the blithe dismissal of the petition-signers concerns. ;)
> I am intrigued at your definition of "ugly".
Seems to match yours.
> If all you've ever had to deal with was spray-paint and slogans,
While there were many incidents like this, for sure, there was a number of more serious ones too.