> whenever a resolution offends a rather small, > arbitrarily chosen set of nations
It wasn't quite arbitrarily chosen, you realize? It was the set of nations that had something like functioning militaries at the end of World War II.
Then later it was the set of nuclear-armed nations, which continued to make sense.
It _is_ interesting that India or Pakistan or North Korea haven't been trying to get into the club, though.... And Israel, I suppose, though Israel also doesn't claim to have nuclear weapons (nor does it claim to lack them).
> There should be no expectation that any non webkit > browser support -webkit-* properties
There isn't. Please read what I clearly said the expectation is. And there _is_ in fact such an expectation.
> For developers, right now there is Webkit and really > no much else of note to support.
Yes, that's what web developers said in 2002 or so, with "IE6" in place of "WebKit". And look where we are today.
Mobile site developers are not consciously targeting WebKit to any more of an extent than web developers in 2002 were targeting IE. They're just both using whatever works in the only browser they happen to care about (largely based on tutorials and whatnot). They know some of it is standards-track and some is not, but they don't care. So the upshot is the same: vendor lockin.
Except in 2002 another browser could implement XMLHttpRequest or document.all without web developers (or really even the W3C) getting all pissed off at them, whereas implementing a -webkit prefixed CSS property in a different browser causes people to get up all in arms. This perpetuates the vendor lockin, of course, making it harder to get out of the chicken-and-egg situation (sites coded to a particular browser because others don't have much market share, and others can't get market share because they're not compatible enough with the sites).
> Having the leader of a country which does have a > majority of the parlement against him/he is such a > problematic concept that it should just be stopped.
That depends on whether the goal is to make it easy or hard for the government to create new laws.
Mozilla's core product should be (and is) a free and open web.
In 2004 that meant a web browser. And perhaps more to the point, that was all Mozilla had the resources to do at the time.
Today that's not enough. And, importantly, it's been done. Users have a pretty wide choice of web browsers. Improving Firefox is still important, but is no longer sufficient. In fact, overfocus (needed at the time due to resource constraints) on Firefox in the past has led to some of the issues that Mozilla is now facing on mobile...
Sort of. Google has access to the Flash source, and the Flash shipping in Chrome is modified from stock flash; it has different version numbers and carries various patches Google has made but not (yet, possibly) upstreamed.
I'm a browser developer. I just have to deal with the consequences of web developers using them. And they're using them, not least because Apple and Google heavily advertise them to web developers.
> We aren't going to raise a new generation of web > developers who think that "-webkit-*" properties are > standard CSS
We have _already_ raised a new generation of web developers who think that all "-webkit-*" properties are standards-track CSS. "salesgeek" (the post I was replying to initially) is a prime example. And these web developers think non-WebKit browsers are weird and icky for not implementing the _exact_ same behavior with their own prefix.
It's really no different from the old IE lockin, actually, except worse in some ways: when other browsers _do_ implement the same functionality it doesn't start working automatically on sites that only used the -webkit prefix and not the other ones. And such sites are very common, especially amongst mobile-targeted sites.
This is why Mozilla, Opera, and Microsoft are all considering supporting a limited subset of -webkit-prefixed properties directly....
No. According to the standard, the browser should ignore any policy _statement_ it doesn't understand. That's very different from what you said, because a _policy_ is a list of statements indicating what the cookies are used for. A policy containing no statements is the way for a site to use P3P to say "we don't use the cookies for anything".
So the the standard requires that a policy with only invalid statements be treated like a policy with no statements at all, which is the "these cookies are not used for anything" policy.
You can argue that that's a dumb standard (and I would agree), but IE is in fact implementing it correctly as far as I can tell. And Google is purposefully abusing the standard, again as far as I can tell.
Because if NaCl had become a standard across browsers in 2000, say, it would never have been possible to use an ARM chip to build a device that browses the web, because all web pages would depend on the browser running on x86.
_That_ is why NaCl is a bad idea.
If you dislike JavaScript, that's fine. You can compile other languages to JavaScript, instead of compiling them to hardware-specific blobs...
> so unless there's evidence Chrome intends to start > down the old proprietay-extensions path
So Dart and NaCl don't count as proprietary extensions? You even mention them yourself. The strongest argument you make against them is that Google is likely to fail pushing them. That may be, but it's not likely to be for lack of trying.....
> It's just a step towards eventually becoming part of > the css standard
Except when it's not. There are plenty of -webkit properties that have never been proposed for standardization, and some that Apple is refusing to propose even though people are asking them to. Presumably because Apple has patents covering the behavior of those properties and doesn't actually want to license them.
Agreed on all of the above. The upshot for PNaCl is:
1) Unreliable performance characteristics have to be traded off against not allowing all programs to run, as you note. 2) Sandboxing is a problem. 3) Actually getting it to run on a new architecture involves implementing the relevant LLVM virtual machine, not just writing the LLVM-to-native compiler you were probably writing anyway.
LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.
Now of course you can take any LLVM target you want and define a virtual machine for that target. Heck, you could define a virtual machine whose "bytecode" is x86 assembly. Whether such things are "suitable" or good for the web is a separate question entirely.
Chrome is not in fact open source. It includes a bunch of open source code but also various closed-source components. Perhaps you confused Chrome and Chromium? They're not the same thing.
If you compile Chrome yourself, you're not using Chrome, of course (and in particular, some features that this particular security evaluation ticks as positives, like the bundled Flash, will be missing).
(There's the side issue that compiling yourself gives you no particular guarantees either if your compiler is in cahoots with the code you're compiling, but for now the chances of that for Chrome are low.)
> You have to go out and download it to get it on your > computer.
As it happens, this is not true, and was even less true last year, before Microsoft bought Skype. See http://en.wikipedia.org/wiki/Google_Chrome#Bundling_practices for a brief summary, but there's plenty of information on this out there if you go to look for it.
You were saying you see startup being slow when it didn't use to be slow, right? What would be good is testing the various nightlies to see which one is the first one that appears.
I really have no idea what the issue could be here, hence trying to gather more data.
I totally understand not being willing to stick python on your machines.
If you're willing to, you can also manually download nightlies from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (you want the dated directories ending in "mozilla-central"). Again, I understand if you don't want to put in the time to do this; it's just that we do have AMD test machines and they're not showing the symptoms you describe....
I believe every single one of Firefox 5, 6, 7, 8, 9, 10 had changes to web standards support... That's one of the reasons the version numbers are what they are.
That's really odd. If you're willing to spend a bit of time on this and have a machine on which performance noticeably dropped from one Firefox release to another, would you be willing to use http://harthur.github.com/mozregression/ to find when exactly that drop happened? That would be incredibly useful!
What sort of AMD chip are you using? Does it have SSE2 support?
For some workloads, I can definitely see a P4 with SSE2 blowing away a processor that doesn't have SSE2.... Some of those workloads can include "JS execution", because at least some JS jits depend on having SSE2 instructions (the alternative being to have a whole bunch of extra code to do x87 codegen).
So what qualifies as a "major change" in your book? A rewritten JS JIT apparently does not. Significant additions to web standards support apparently do not. Rearchitecture of various parts of the browser to reduce memory usage don't.
Do you only consider random user-interface changes "major"?
Using memory is easy. You just have to want to trade it for performance.;)
For example, a typical 10MP digital camera image, once you decode it to RGBA so that you can paint it fast, is about 40MB in memory. If you skimp on the "fast" and only store it in RGB, it's 30MB. If you want it to take less space, you have to store it compressed and decompress on every paint. And finding a web page with a bunch of such images on it is not hard at all.
The other large user of memory is the JS execution environment. All you need here are badly-written scripts that create tons of objects and hang on to them. Oh, and your typical website nowadays comes with hundreds of kilobytes of source JS (which then needs to be compiled and actually executed, which takes a lot more memory than just storing the text).
The upside is that you can put together a webpage in hours to do something that would take a lot of development time in the 70s, of course.
Google and Microsoft don't have to adopt this. The system is designed such that browsers that have no native support can still work with it via a JS polyfill. So sites can deploy this right this second, even though no browser (and that includes Firefox) has native support yet.
Slashdot Mirror
I know this was supposed to be a joke, but Israel is not a signatory to the NPT, so no one has been inspecting its installations.
> whenever a resolution offends a rather small,
> arbitrarily chosen set of nations
It wasn't quite arbitrarily chosen, you realize? It was the set of nations that had something like functioning militaries at the end of World War II.
Then later it was the set of nuclear-armed nations, which continued to make sense.
It _is_ interesting that India or Pakistan or North Korea haven't been trying to get into the club, though.... And Israel, I suppose, though Israel also doesn't claim to have nuclear weapons (nor does it claim to lack them).
> There should be no expectation that any non webkit
> browser support -webkit-* properties
There isn't. Please read what I clearly said the expectation is. And there _is_ in fact such an expectation.
> For developers, right now there is Webkit and really
> no much else of note to support.
Yes, that's what web developers said in 2002 or so, with "IE6" in place of "WebKit". And look where we are today.
Mobile site developers are not consciously targeting WebKit to any more of an extent than web developers in 2002 were targeting IE. They're just both using whatever works in the only browser they happen to care about (largely based on tutorials and whatnot). They know some of it is standards-track and some is not, but they don't care. So the upshot is the same: vendor lockin.
Except in 2002 another browser could implement XMLHttpRequest or document.all without web developers (or really even the W3C) getting all pissed off at them, whereas implementing a -webkit prefixed CSS property in a different browser causes people to get up all in arms. This perpetuates the vendor lockin, of course, making it harder to get out of the chicken-and-egg situation (sites coded to a particular browser because others don't have much market share, and others can't get market share because they're not compatible enough with the sites).
> Having the leader of a country which does have a
> majority of the parlement against him/he is such a
> problematic concept that it should just be stopped.
That depends on whether the goal is to make it easy or hard for the government to create new laws.
Mozilla's core product should be (and is) a free and open web.
In 2004 that meant a web browser. And perhaps more to the point, that was all Mozilla had the resources to do at the time.
Today that's not enough. And, importantly, it's been done. Users have a pretty wide choice of web browsers. Improving Firefox is still important, but is no longer sufficient. In fact, overfocus (needed at the time due to resource constraints) on Firefox in the past has led to some of the issues that Mozilla is now facing on mobile...
http://blog.lizardwrangler.com/2011/07/26/the-browser-by-many-other-names/ is worth reading in this context.
Sort of. Google has access to the Flash source, and the Flash shipping in Chrome is modified from stock flash; it has different version numbers and carries various patches Google has made but not (yet, possibly) upstreamed.
And http://news.ycombinator.com/item?id=3621263 (from a Google employee) makes it pretty clear that Google is involved in helping maintain Pepper Flash.
> So don't use those.
I'm a browser developer. I just have to deal with the consequences of web developers using them. And they're using them, not least because Apple and Google heavily advertise them to web developers.
> We aren't going to raise a new generation of web
> developers who think that "-webkit-*" properties are
> standard CSS
We have _already_ raised a new generation of web developers who think that all "-webkit-*" properties are standards-track CSS. "salesgeek" (the post I was replying to initially) is a prime example. And these web developers think non-WebKit browsers are weird and icky for not implementing the _exact_ same behavior with their own prefix.
It's really no different from the old IE lockin, actually, except worse in some ways: when other browsers _do_ implement the same functionality it doesn't start working automatically on sites that only used the -webkit prefix and not the other ones. And such sites are very common, especially amongst mobile-targeted sites.
This is why Mozilla, Opera, and Microsoft are all considering supporting a limited subset of -webkit-prefixed properties directly....
No. According to the standard, the browser should ignore any policy _statement_ it doesn't understand. That's very different from what you said, because a _policy_ is a list of statements indicating what the cookies are used for. A policy containing no statements is the way for a site to use P3P to say "we don't use the cookies for anything".
So the the standard requires that a policy with only invalid statements be treated like a policy with no statements at all, which is the "these cookies are not used for anything" policy.
You can argue that that's a dumb standard (and I would agree), but IE is in fact implementing it correctly as far as I can tell. And Google is purposefully abusing the standard, again as far as I can tell.
Because if NaCl had become a standard across browsers in 2000, say, it would never have been possible to use an ARM chip to build a device that browses the web, because all web pages would depend on the browser running on x86.
_That_ is why NaCl is a bad idea.
If you dislike JavaScript, that's fine. You can compile other languages to JavaScript, instead of compiling them to hardware-specific blobs...
> so unless there's evidence Chrome intends to start
> down the old proprietay-extensions path
So Dart and NaCl don't count as proprietary extensions? You even mention them yourself. The strongest argument you make against them is that Google is likely to fail pushing them. That may be, but it's not likely to be for lack of trying.....
> It's just a step towards eventually becoming part of
> the css standard
Except when it's not. There are plenty of -webkit properties that have never been proposed for standardization, and some that Apple is refusing to propose even though people are asking them to. Presumably because Apple has patents covering the behavior of those properties and doesn't actually want to license them.
Agreed on all of the above. The upshot for PNaCl is:
1) Unreliable performance characteristics have to be traded off against not allowing all programs to run, as you note.
2) Sandboxing is a problem.
3) Actually getting it to run on a new architecture involves implementing the relevant LLVM virtual machine, not just writing the LLVM-to-native compiler you were probably writing anyway.
The message in question is http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043719.html
LLVM is only expressive enough to have C++ compiled to it if you use the parts of LLVM that are architecture-dependent. In particular, they depend on word sizes and endianness at the very least. You can't compile C++ to architecture-independent LLVM.
See http://news.ycombinator.com/item?id=2499763 for some links to the relevant LLVM documentation.
Now of course you can take any LLVM target you want and define a virtual machine for that target. Heck, you could define a virtual machine whose "bytecode" is x86 assembly. Whether such things are "suitable" or good for the web is a separate question entirely.
Chrome is not in fact open source. It includes a bunch of open source code but also various closed-source components. Perhaps you confused Chrome and Chromium? They're not the same thing.
If you compile Chrome yourself, you're not using Chrome, of course (and in particular, some features that this particular security evaluation ticks as positives, like the bundled Flash, will be missing).
(There's the side issue that compiling yourself gives you no particular guarantees either if your compiler is in cahoots with the code you're compiling, but for now the chances of that for Chrome are low.)
> You have to go out and download it to get it on your
> computer.
As it happens, this is not true, and was even less true last year, before Microsoft bought Skype. See http://en.wikipedia.org/wiki/Google_Chrome#Bundling_practices for a brief summary, but there's plenty of information on this out there if you go to look for it.
> What should I do with the nightlies?
You were saying you see startup being slow when it didn't use to be slow, right? What would be good is testing the various nightlies to see which one is the first one that appears.
I really have no idea what the issue could be here, hence trying to gather more data.
Mostly additions, but it turns out that the way web apps are written adding new APIs can easily break them....
I totally understand not being willing to stick python on your machines.
If you're willing to, you can also manually download nightlies from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ (you want the dated directories ending in "mozilla-central"). Again, I understand if you don't want to put in the time to do this; it's just that we do have AMD test machines and they're not showing the symptoms you describe....
I believe every single one of Firefox 5, 6, 7, 8, 9, 10 had changes to web standards support... That's one of the reasons the version numbers are what they are.
That's really odd. If you're willing to spend a bit of time on this and have a machine on which performance noticeably dropped from one Firefox release to another, would you be willing to use http://harthur.github.com/mozregression/ to find when exactly that drop happened? That would be incredibly useful!
What sort of AMD chip are you using? Does it have SSE2 support?
For some workloads, I can definitely see a P4 with SSE2 blowing away a processor that doesn't have SSE2.... Some of those workloads can include "JS execution", because at least some JS jits depend on having SSE2 instructions (the alternative being to have a whole bunch of extra code to do x87 codegen).
So what qualifies as a "major change" in your book? A rewritten JS JIT apparently does not. Significant additions to web standards support apparently do not. Rearchitecture of various parts of the browser to reduce memory usage don't.
Do you only consider random user-interface changes "major"?
Using memory is easy. You just have to want to trade it for performance. ;)
For example, a typical 10MP digital camera image, once you decode it to RGBA so that you can paint it fast, is about 40MB in memory. If you skimp on the "fast" and only store it in RGB, it's 30MB. If you want it to take less space, you have to store it compressed and decompress on every paint. And finding a web page with a bunch of such images on it is not hard at all.
The other large user of memory is the JS execution environment. All you need here are badly-written scripts that create tons of objects and hang on to them. Oh, and your typical website nowadays comes with hundreds of kilobytes of source JS (which then needs to be compiled and actually executed, which takes a lot more memory than just storing the text).
The upside is that you can put together a webpage in hours to do something that would take a lot of development time in the 70s, of course.
> So if something went from say, 3.5.8 to 3.5.9 I knew
> it was just bug fixes, no testing needed just deploy it.
And then going from 3.6.3 to 3.6.4 totally changed how NPAPI plug-ins were run.
Oh, and "just bugfixes" can still break things, especially security bugfixes.
Seriously, what you mostly had before was the illusion that you could push a change out without testing.
> There's a new "major" version like once a month,
> some which seem to be changed not at all
Every one of the releases since Firefox 4 has contained significant changes and new feature additions.
You're right that in a large deployment setting this is a problem; this is why the ESR was created.
I'm not sure what's confusing to users, though. Users just get an update.
Google and Microsoft don't have to adopt this. The system is designed such that browsers that have no native support can still work with it via a JS polyfill. So sites can deploy this right this second, even though no browser (and that includes Firefox) has native support yet.