Where by "some tiny number of people" you mean "everyone broadcasting H.264 on the Internet, next year when the moratorium on H.264 Internet broadcast fees runs out".
> A lot of operating systems these days include FFMpeg libraries as well as the H.264 and AAC libraries (which is > really what this is all about)
Where by "a lot" you mean "Mac"? Windows 7 will be the first version of Windows to include H.264. No freely redistributable Linux includes it, for obvious reasons.
> it would seem that for something as ubiquitous and freely licensable as the FFMpeg libraries
The ffmpeg source code is freely licensable, the patent licenses you need in the USA and elsewhere are not.
I think Fermi's paradox is stronger when you think about interstellar colonization, not communication. It's even stronger when you think about intelligent machines doing the colonization, not biological organisms. Assuming intelligent machines can be built (which every materialist must, I presume), then it seems we will build them quite soon, certainly soon enough that *some* intelligent civilization would build them before destroying itself. And then the situation completely changes: it's easy for machines to voyage through space, even at interstellar distances with conventional rocket technology (just go into sleep mode); it's easy for machines to reproduce themselves with limited resources; and it's impossible to image an event so catastrophic as to wipe out their entire civilization. So if *any* of these machines feel like colonizing the galaxy, or (given time) beyond the galaxy, they can and they will. Given that one of the fundamental characteristics of life is to want to spread and grow, it seems likely that our machines will have the same tendencies, especially if we take the easy route of simulating our own minds. It certainly seems implausible that *none* of our machines will want to do this.
So then, if this is an inevitable result of intelligent life, and intelligent life is common, then it should have happened already in our galaxy, so why hasn't our solar system been colonized already?
Yes, it was created by Apple, but it's fundamentally a better benchmark (disclaimer: I work for Mozilla). It has more tests than V8 and they test more different kinds of code. V8's strategy of counting "runs per minute" lets it hide compilation time, which is a really big issue for Web apps.
Apart from that, Google's had access to V8 for much longer than the other players, so comparing on Sunspider which everyone's had access to for years is fundamentally more fair.
There's some weird stuff in this "article". For example, what does it mean to "include V8 code" in a browser? Even choosing V8 as a benchmark is a mistake. Sunspider is the standard JS benchmark and it's much broader in scope.
Awarding 10 points for winning a category and then adding up the points to reach a final score is the most statistically bogus "methodology" ever.
It's nice to see SVG and canvas in benchmarks, but "IE8 will fix that compatibility issue"? Completely untrue, IE8 will not support SVG and canvas. This bit of ignorance makes me worry about the whole piece.
And as others have noted, comparing the Chrome beta against various-aged releases of other browsers makes little sense.
"Education is definitely not enough because people just don't care. They want to do what they want to do and the computer should magically understand that and play along. There's little respect for the complexity of general purpose computers and any possible learning curve needed to use them properly."
There is absolutely nothing wrong with this expectation.
Until you have internalized this, you won't be able to design great software.
Yes, Theora is not as good quality as H.264. But it's not bad, and there are many ways to use video on the Web other than playing full-screen HD video in Youtube. Lots of Web applications will benefit from being able to include *royalty-free* video as part of the application. Also let's not forget that we also have Vorbis in Firefox; all your favourite Web games and apps will be able to have decent sound effects without resorting to hidden Flash objects.
Opera, although it is excellent, has never had enough market share to look like a threat. Competition from Safari, and of course IE, is the major competitive driver for us.
It's very misleading to start talking about message passing and no-shared-memory as "Erlang-style concurrency". There is a huge history of languages and frameworks in this area that predate Erlang by decades. It does no credit to Erlang when its advocates ignore this.
The missing part of your story is that Microsoft halted IE development completely for three years, 2001-2004. They did this because they felt they had an unassailable position in IE6 with 90%+ market share, Netscape 6 a terrible product and AOL losing interest in its development thanks to their deal with Microsoft. So Microsoft decided to focus their resources developing a new platform --- WPF --- that they would control completely (no connection to "open standards") and that would crush both the open Web and Flash. Many of the core IE developers went to work on WPF.
I think this has turned out to be one of Microsoft's biggest ever mistakes. Thanks to open source, Mozilla did not die. Liberated from AOL, we actually managed to produce a decent product in Firefox 1.0. With better security, tabs, popup blocking, speed, and passable Web compatibility, we started taking market share. Google showed Web search could be a huge money-spinner and that opened revenue channels for browser vendors, allowing Mozilla to start growing again. Microsoft finally acknowledged the danger in 2004 and restarted IE development, but they're still trying to catch up after losing those three years. IE8 won't catch up; it probably won't be as good as Firefox 3, let alone Firefox 3.x which should be out around the same time.
It's about controlling the development platform, which grants enormous power:
-- The Windows monopoly is strong because so many applications only run on Windows. If all apps were Web apps that worked in Firefox, the "applications barrier to entry" is gone and it's suddenly much easier for users to switch away from Windows. That is Microsoft's greatest fear.
-- Controlling the platform means your apps will work first and best on the platform.
-- Controlling the platform lets you be the gatekeeper for all kinds of innovation. For example, if someone invents a new kind of hardware device it's not much use unless you support it in your platform so that applications can use it. By adding or denying APIs and components you can bless or curse all kinds of initiatives.
-- Controlling the platform lets you decide what software will be preinstalled. For example, you can favour your own media codecs.
It's not directly about money; it's about power. But power can be monetized.
If so: -- I'm sorry. -- Looks like Robert Longson slipped up by not copying over contributor information. But I don't see any complaints from your people about that in the bugs. (Note, he's a volunteer, not paid by Mozilla or anyone else.) Would be easy to fix. -- Tim Rowley got taken off Firefox SVG work by IBM which partly explains why the patch never got final review. -- Looks like "25% no longer required", not 80%. -- I don't see any sign of your displeasure anywhere in these bugs. People are busy, timely hurry-up gripes usually help prioritize things.
The awesomebar has one huge advantage over URL autocomplete: URL autocomplete is very poor for quickly finding one of multiple pages at the same site.
For example, I spend a lot of time in Bugzilla. With the awesomebar I can type "bug 1234" and the awesomebar will find the bug I want if I've visited it before. I can even type "bug image crash" and get a list of bugs with those words in the title that I've visited before.
I think the awesomebar is one of those things that will take people time to get used to, but then they won't be able to live without.
There is nothing here about "Mozilla Hitting 'Brick Walls' Getting Firefox on Phones".
Some blogger is *talking* about brick walls and speculating that they might make it hard to get Firefox on phones. There is no data showing that is actually the case.
Hyatt's comment is fair but it doesn't really help. "This is why we don't want to expose the APIs", well great, but the fact remains that Webkit can use them and we can't.
People embed Gecko on Mac, and we want to work on Tiger too, so those needs apply just as much to us as they do to Webkit.
Actually in Firefox 3/Gecko 1.9, external CSS loads do not block the parser. Woohoo! However, we do block the parser if the page tries to execute script while there are pending CSS loads.
This will be terrible for both Microsoft and Yahoo. MSN and Yahoo were both already on the ropes against Google, the struggle to integrate them will slow them down and make them even more vulnerable. A lot of Yahoo people won't want to work for Microsoft, Google will welcome them with open arms. Microsoft is just desperate for market share; this will be a temporary boost, but after this there is no-one to buy and nowhere to hide.
That doesn't work because watermarks are incredibly easy to get around. Simple signal processing techniques will eliminate most watermarks without noticeably affecting the output. In many cases you can just add your own watermark over the top and either destroy the existing watermark or no-one knows which one is the original watermark.
Pretty much all watermarking research assumes that an attacker does not know how the watermarking technique works and does not intelligently attack the watermark. That assumption is hopelessly unrealistic. It's 100% security by obscurity.
Slashdot Mirror
Where by "some tiny number of people" you mean "everyone broadcasting H.264 on the Internet, next year when the moratorium on H.264 Internet broadcast fees runs out".
> A lot of operating systems these days include FFMpeg libraries as well as the H.264 and AAC libraries (which is
> really what this is all about)
Where by "a lot" you mean "Mac"? Windows 7 will be the first version of Windows to include H.264. No freely redistributable Linux includes it, for obvious reasons.
> it would seem that for something as ubiquitous and freely licensable as the FFMpeg libraries
The ffmpeg source code is freely licensable, the patent licenses you need in the USA and elsewhere are not.
Adobe has complete control over the evolution of SWF. Until that changes, it's not really open.
Same goes for Microsoft and .NET, of course.
I think Fermi's paradox is stronger when you think about interstellar colonization, not communication. It's even stronger when you think about intelligent machines doing the colonization, not biological organisms. Assuming intelligent machines can be built (which every materialist must, I presume), then it seems we will build them quite soon, certainly soon enough that *some* intelligent civilization would build them before destroying itself. And then the situation completely changes: it's easy for machines to voyage through space, even at interstellar distances with conventional rocket technology (just go into sleep mode); it's easy for machines to reproduce themselves with limited resources; and it's impossible to image an event so catastrophic as to wipe out their entire civilization. So if *any* of these machines feel like colonizing the galaxy, or (given time) beyond the galaxy, they can and they will. Given that one of the fundamental characteristics of life is to want to spread and grow, it seems likely that our machines will have the same tendencies, especially if we take the easy route of simulating our own minds. It certainly seems implausible that *none* of our machines will want to do this.
So then, if this is an inevitable result of intelligent life, and intelligent life is common, then it should have happened already in our galaxy, so why hasn't our solar system been colonized already?
Yes, it was created by Apple, but it's fundamentally a better benchmark (disclaimer: I work for Mozilla). It has more tests than V8 and they test more different kinds of code. V8's strategy of counting "runs per minute" lets it hide compilation time, which is a really big issue for Web apps.
Apart from that, Google's had access to V8 for much longer than the other players, so comparing on Sunspider which everyone's had access to for years is fundamentally more fair.
There's some weird stuff in this "article". For example, what does it mean to "include V8 code" in a browser? Even choosing V8 as a benchmark is a mistake. Sunspider is the standard JS benchmark and it's much broader in scope.
Awarding 10 points for winning a category and then adding up the points to reach a final score is the most statistically bogus "methodology" ever.
It's nice to see SVG and canvas in benchmarks, but "IE8 will fix that compatibility issue"? Completely untrue, IE8 will not support SVG and canvas. This bit of ignorance makes me worry about the whole piece.
And as others have noted, comparing the Chrome beta against various-aged releases of other browsers makes little sense.
"Education is definitely not enough because people just don't care. They want to do what they want to do and the computer should magically understand that and play along. There's little respect for the complexity of general purpose computers and any possible learning curve needed to use them properly."
There is absolutely nothing wrong with this expectation.
Until you have internalized this, you won't be able to design great software.
One option is (will be) to convert your font to an SVG font. Then you get precisely predictable spacing and rasterization.
Yes, Theora is not as good quality as H.264. But it's not bad, and there are many ways to use video on the Web other than playing full-screen HD video in Youtube. Lots of Web applications will benefit from being able to include *royalty-free* video as part of the application. Also let's not forget that we also have Vorbis in Firefox; all your favourite Web games and apps will be able to have decent sound effects without resorting to hidden Flash objects.
Opera, although it is excellent, has never had enough market share to look like a threat. Competition from Safari, and of course IE, is the major competitive driver for us.
It's very misleading to start talking about message passing and no-shared-memory as "Erlang-style concurrency". There is a huge history of languages and frameworks in this area that predate Erlang by decades. It does no credit to Erlang when its advocates ignore this.
The missing part of your story is that Microsoft halted IE development completely for three years, 2001-2004. They did this because they felt they had an unassailable position in IE6 with 90%+ market share, Netscape 6 a terrible product and AOL losing interest in its development thanks to their deal with Microsoft. So Microsoft decided to focus their resources developing a new platform --- WPF --- that they would control completely (no connection to "open standards") and that would crush both the open Web and Flash. Many of the core IE developers went to work on WPF.
I think this has turned out to be one of Microsoft's biggest ever mistakes. Thanks to open source, Mozilla did not die. Liberated from AOL, we actually managed to produce a decent product in Firefox 1.0. With better security, tabs, popup blocking, speed, and passable Web compatibility, we started taking market share. Google showed Web search could be a huge money-spinner and that opened revenue channels for browser vendors, allowing Mozilla to start growing again. Microsoft finally acknowledged the danger in 2004 and restarted IE development, but they're still trying to catch up after losing those three years. IE8 won't catch up; it probably won't be as good as Firefox 3, let alone Firefox 3.x which should be out around the same time.
It's about controlling the development platform, which grants enormous power:
-- The Windows monopoly is strong because so many applications only run on Windows. If all apps were Web apps that worked in Firefox, the "applications barrier to entry" is gone and it's suddenly much easier for users to switch away from Windows. That is Microsoft's greatest fear.
-- Controlling the platform means your apps will work first and best on the platform.
-- Controlling the platform lets you be the gatekeeper for all kinds of innovation. For example, if someone invents a new kind of hardware device it's not much use unless you support it in your platform so that applications can use it. By adding or denying APIs and components you can bless or curse all kinds of initiatives.
-- Controlling the platform lets you decide what software will be preinstalled. For example, you can favour your own media codecs.
It's not directly about money; it's about power. But power can be monetized.
Vince Vizzaccaro is not a Mozilla VP. He seems to work for Net Applications.
What was this? Bug 388547?
If so:
-- I'm sorry.
-- Looks like Robert Longson slipped up by not copying over contributor information. But I don't see any complaints from your people about that in the bugs. (Note, he's a volunteer, not paid by Mozilla or anyone else.) Would be easy to fix.
-- Tim Rowley got taken off Firefox SVG work by IBM which partly explains why the patch never got final review.
-- Looks like "25% no longer required", not 80%.
-- I don't see any sign of your displeasure anywhere in these bugs. People are busy, timely hurry-up gripes usually help prioritize things.
The awesomebar has one huge advantage over URL autocomplete: URL autocomplete is very poor for quickly finding one of multiple pages at the same site.
For example, I spend a lot of time in Bugzilla. With the awesomebar I can type "bug 1234" and the awesomebar will find the bug I want if I've visited it before. I can even type "bug image crash" and get a list of bugs with those words in the title that I've visited before.
I think the awesomebar is one of those things that will take people time to get used to, but then they won't be able to live without.
There is nothing here about "Mozilla Hitting 'Brick Walls' Getting Firefox on Phones".
Some blogger is *talking* about brick walls and speculating that they might make it hard to get Firefox on phones. There is no data showing that is actually the case.
Hyatt's comment is fair but it doesn't really help. "This is why we don't want to expose the APIs", well great, but the fact remains that Webkit can use them and we can't.
People embed Gecko on Mac, and we want to work on Tiger too, so those needs apply just as much to us as they do to Webkit.
Actually in Firefox 3/Gecko 1.9, external CSS loads do not block the parser. Woohoo! However, we do block the parser if the page tries to execute script while there are pending CSS loads.
It's called "GMail"
Um, we read the paper and implemented David Bacon's technique.
We had to extend it in some ways, in particular to integrate it with the JS mark-and-sweep collector.
This will be terrible for both Microsoft and Yahoo. MSN and Yahoo were both already on the ropes against Google, the struggle to integrate them will slow them down and make them even more vulnerable. A lot of Yahoo people won't want to work for Microsoft, Google will welcome them with open arms. Microsoft is just desperate for market share; this will be a temporary boost, but after this there is no-one to buy and nowhere to hide.
I've blogged about why I don't think we'll follow this path in Firefox.
http://weblogs.mozillazine.org/roc/archives/2008/01/post_2.html
http://weblogs.mozillazine.org/roc/archives/2008/01/slipping_the_ba.html
One interesting thing is that as far as I can tell, this will become a crushing burden on IE development.
> Why? Because if there was even a 1/1000th of a percent of a chance that it could cause irreparable
> harm I wasn't going to take the risk.
So then, your child will never cross a road?
(I'm a parent, but this is ridiculous)
That doesn't work because watermarks are incredibly easy to get around. Simple signal processing techniques will eliminate most watermarks without noticeably affecting the output. In many cases you can just add your own watermark over the top and either destroy the existing watermark or no-one knows which one is the original watermark.
Pretty much all watermarking research assumes that an attacker does not know how the watermarking technique works and does not intelligently attack the watermark. That assumption is hopelessly unrealistic. It's 100% security by obscurity.