Re:This site works best with...
on
OK Go Goes HTML5
·
· Score: 2
NPAPI Flash (the kind that Chrome uses) is not commonly preinstalled on computers, though some OEMs do preinstall it. The commonly preinstalled thing is ActiveX Flash (the kind IE uses).
So yes, Chrome is helping spread Flash. And vice versa: the Flash installer (e.g. if you're using Firefox or Opera) bundles Chrome onto your computer if you're not careful
Re:This site works best with...
on
OK Go Goes HTML5
·
· Score: 2
> As long as the standards are open
Define "open"? Do you mean "we wrote up something based on our implementation, sorta, and published it", or do you mean "a bunch of people got together and figured out how this should work across a variety of use cases"?
The two cases are very different, and both have catastrophic failure modes as well as some amazing success modes.
Re:This site works best with...
on
OK Go Goes HTML5
·
· Score: 2
Almost everything in that list is pie-in-the-sky stuff of various sorts (in-progress specs, etc).
The IE10 numbers are based on the released IE10 preview builds.
The Firefox numbers are "stagnating" from Firefox 5 (released June 2011) to Firefox 7 (planned to be released Sept 2011). A few percentage points every three months is not that bad.;)
Re:This site works best with...
on
OK Go Goes HTML5
·
· Score: 1
> Despite supporting MP3/AAC, Google willfully > dropped H.264 support.
No, they said that they will drop it. Sometime. Hasn't happened yet, no timeline announced, no mention of it since that one announcement.
Re:This site works best with...
on
OK Go Goes HTML5
·
· Score: 2
And to be clear, the real problems are encouraging people to use the new stuff and pretending it's open standards when it's not and when it's not ready for production use. And then people doing just that, whether because they don't know any better or because they don't care, on public-facing sites.
Re:This site works best with...
on
OK Go Goes HTML5
·
· Score: 3, Insightful
> and Chrome really uses open standards and > protocols.
Except it doesn't. It uses a mishmash of open standards, proposed open standards, things they wrote up and threw over the "standards" wall, and flat-out proprietary extensions.
Seriously, try to implement CSS Animations based on the "draft spec". You can't. It's too vague to actually implement it without reverse-engineering WebKit first. And that's one of the ones that people are actually planning to standardize, unlike some of the other stuff Chrome is implementing.
> The problem is that Google is developing it at such > an astonishing pace
The "problem" is that Google is implementing random things, exposing them to the web, encouraging people to use them, and maybe writing up a vague description of what the functionality is supposed to do (not enough to actually implement interoperably) and calling that a "standards draft".
Pretty similar to the way Microsoft did OOXML, actually. Except they wrote a better spec.
The "yet another platform" in this case is the web. So it's not a matter of porting as much as just being able to write web apps that compete with native apps in ways that they can't right now.
I think the upshot in previous discussions was that Mozilla needs the core people working on the things they're actually working on more than it needs the money.
Or put another way, nothing is stopping other organizations from just paying people to do LTS (and Debian and Red Hat have done just that, with Mozilla providing the bug database, version control setup, some code reviewer bandwidth, etc). Presumably if people want _Mozilla_ to do LTS and pay for it (as opposed to paying a third party) that means they want something more than than those things... the question is what.
> Other software organizations hire, integrate, and are > productive with many more developers than Mozilla.
Yes, but they also typically took their time growing to that point.... Mozilla Corp has grown by at least a factor of 3 in size over the last few years. That's always pretty difficult.
Note that the problem is not just hiring people, but hiring people who actually get open source (and don't get upset when they don't get checkin privileges their first day on the job, will actually work well with non-employee contributors, etc). Ending up with an "open source" project like Android or various other "throw the source over the wall every so often" cases is not a goal here.
I didn't say Josephus was contemporaneous. I was responding to your second point, where you said there were no credible non-contemporaneous sources. Josephus indeed reports second-hand, but he doesn't say anything about the miraculous act strawman that you're arguing about. He does say that he's told there was a particular person in the right timeframe who had that name and somewhat of a following. Obviously not as good as eyewitness original sources, but much better than your overstated claims of "a work of blatantly obvious fiction".
> Because if your programmers can't write secure > code, why are they writing Internet facing code?
The location bar, which is the context here, is NOT internet-facing, actually.
But that's not the point. Writing security fixes doesn't just require writing secure code but also an understanding of what the security model is, why it failed, and how to fix it. This is much harder than writing code to start with.
> The language should just automatically take care > of all known security vulnerabilities
The language can take care of mechanism (and yes, C++ falls down here, say), but it can't do _policy_. The language has no idea that sending one file (the one the user selected in the file input) to the web site is secure but sending some other file (/etc/passwd, say) is not.
> We invented garbage collection in the 1960s, right?
Yep, and have been fixing it to not suck ever since. We're getting pretty close. At this point, with custom hardware specially designed for it, you can more or less get a GC system that doesn't hurt either throughput or latency too much. Too bad normal people aren't running this hardware...
> And array bounds checking? Why are > programmers still having to juggle this stuff > manually?
Because the languages that handle it for you have some drawbacks. It's being worked on (Go, Rust, that sort of thing) and I really hope that problem will be in our past soon. Then again, there were hopes for that with Java, and that got screwed up (startup time too slow, etc).
> 2) The only other reports we have of this person > arise from a work of blatantly obvious fiction
I assume that you've arbitrarily decided to ignore Josephus here, yes? Granted, he's not contemporaneous, but he's more so than the Gospels, and happens to not be a Christian, a Christian apologist, or an anti-Christian. He also happens to not be in the business of making up fiction (well, any more so than any of the ancient or some of the modern historians, which is not necessarily a high bar).
> since we do have a contemporary documentary > reference to him
Citation please? Last I checked we had much later references that mentioned that they'd seen something about him somewhere. Has something new been found on the matter?
> The 15 different iterations of the search > / address bar that we've had in the last couple > months would be a nice start.
Which of the people working on that would have been able to write core security fixes for stable branches?
> They could also merge existing projects such as > Frontmotion's work into their own
That would involve Frontmotion wanting that, no? Do they?
Seriously, this has been discussed literally for years, pretty seriously. It's not like the people involved are dumb. It's just that the problem is harder than it seems, assuming you have goals other than legacy suppor...
What would be useful would be providing people, not money. Mozilla _has_ money if you look at financial statements; what they have a hard time doing is finding good people and working them into the organization (c.f. mythical man-month for the problems with the latter).
Currently there is one version actively being developed, a testing version which fixes may need to be backported to, a release candidate (requires basically no resources, more or less by definition) which is misnamed "Beta", and a release version which only gets a fix in extraordinary situations (actively-exploited zero-day). So there are only two versions to really support, and they're very similar to each other so most of the time the same patch applies to both.
With LTS, you lose that last benefit; backporting patches to 3.6 and 3.5 during 4.0 development was a huge production; they often had to be redone from scratch because the code had changed so much.
Note that I didn't say you need to double the number of people or anything, but based on workload in the past I'd guess we're taking 20% more work. And not just for the new people, because code reviews are spread out over existing module owners and are a large part of the time commitment.
Now this is all doable; if one is willing to slow down new work by 20%. That's how other projects do it, after all, and how Mozilla has done it in the past. But it's not clear that this is necessarily a good tradeoff. Maybe it is, maybe not.
> nowhere near "way more than it will ever have."
That's not what I said. I said "way more than they ever have" (past tense, not future; significant difference in meaning).
My general experience with Firefox on Linux is that Mozilla listens to the people who send them feedback (chiefly distros) too much. Unfortunately, these people are saying things that happen to be false (e.g. that Linux users really want Gnome theme integration more than, say, performance improvements; the two are mututally exclusive in many cases due to the way the Gnome theme system works).
1) There's a difference between "there is no hard evidence that this person existed" and "there is hard evidence this person did not exist". We're in the former situation. While it's possible there was no such person, that involves more assumptions and convoluted explanations than assuming that there was a person who was in fact teaching people something (note that _what_ he was teaching is a separate issue; more on that below). None of that has to do with the miracles and such, which _you_ are insisting on pulling into the conversation.
2) I quite sympathize with your objections to people using the Gospels to write laws. That has no bearing on whether there is a historical basis to the non-ridiculous events described in the Gospels. Again, there may not be, but that requires more assumptions than simply assuming that there is a historical basis that people added all the magic on top of as they do all the time.
3) It's not clear to me why whether Jesus existed or not matters for purposes of the whole "alleged words" bit, unless you insist on conflating the idea of "Jesus existed" and "Jesus existed and actually said and did the stuff the Gospels claim". I would fully expect that everything that the Gospels claim Jesus did and the vast majority of the things they claim Jesus said are fabricated.
Again, you really want to argue against "Jesus as the gospels portray him" existing, which is fine, and almost certainly true. But don't conflate this with the argument that there is no person the stories are based on. That argument is a lot weaker. Could still be true, if there was enough of a conspiracy to fabricate the story. But a lot less likely.
There's no contemporaneous evidence for Hannibal either. And all that people can add to the that is a story from hundreds of years later about a guy who crossed the Alps with elephants. What does Occam's razor tell you about that?
The difference between the cases you cite and the Jesus case is that his story includes various historical events that are verifiable from other sources. Now maybe he was just cleverly inserted into those, Waldo-fashion. It's possible. But the general setup makes it somewhat unlikely. Just as it's unlikely, imo, that any actual miracles got performed.
> and a couple of christian insertians in Josephus
Did you even read the link I cited?
> as you couldnt prove that most of the people alive > in those years ever lived either of course
Exactly.
> but he was supposed to have been someone > rather more extraordinary
That's claim #2 (miracles and the like), not claim #1 (a guy who preaches and has a folllowing). People like that were a dime a dozen at the time.
Now I agree that "well-proven fact" existence of Jesus certainly is not. Neither is existence of Hannibal, by the same metrics. Do read the link I suggested, please!
Slashdot Mirror
NPAPI Flash (the kind that Chrome uses) is not commonly preinstalled on computers, though some OEMs do preinstall it. The commonly preinstalled thing is ActiveX Flash (the kind IE uses).
So yes, Chrome is helping spread Flash. And vice versa: the Flash installer (e.g. if you're using Firefox or Opera) bundles Chrome onto your computer if you're not careful
> As long as the standards are open
Define "open"? Do you mean "we wrote up something based on our implementation, sorta, and published it", or do you mean "a bunch of people got together and figured out how this should work across a variety of use cases"?
The two cases are very different, and both have catastrophic failure modes as well as some amazing success modes.
Almost everything in that list is pie-in-the-sky stuff of various sorts (in-progress specs, etc).
The IE10 numbers are based on the released IE10 preview builds.
The Firefox numbers are "stagnating" from Firefox 5 (released June 2011) to Firefox 7 (planned to be released Sept 2011). A few percentage points every three months is not that bad. ;)
> Despite supporting MP3/AAC, Google willfully
> dropped H.264 support.
No, they said that they will drop it. Sometime. Hasn't happened yet, no timeline announced, no mention of it since that one announcement.
And to be clear, the real problems are encouraging people to use the new stuff and pretending it's open standards when it's not and when it's not ready for production use. And then people doing just that, whether because they don't know any better or because they don't care, on public-facing sites.
> and Chrome really uses open standards and
> protocols.
Except it doesn't. It uses a mishmash of open standards, proposed open standards, things they wrote up and threw over the "standards" wall, and flat-out proprietary extensions.
Seriously, try to implement CSS Animations based on the "draft spec". You can't. It's too vague to actually implement it without reverse-engineering WebKit first. And that's one of the ones that people are actually planning to standardize, unlike some of the other stuff Chrome is implementing.
> The problem is that Google is developing it at such
> an astonishing pace
The "problem" is that Google is implementing random things, exposing them to the web, encouraging people to use them, and maybe writing up a vague description of what the functionality is supposed to do (not enough to actually implement interoperably) and calling that a "standards draft".
Pretty similar to the way Microsoft did OOXML, actually. Except they wrote a better spec.
The "yet another platform" in this case is the web. So it's not a matter of porting as much as just being able to write web apps that compete with native apps in ways that they can't right now.
Making the world a better place is Mozilla's primary goal. The browser is a means to that end.
I think the upshot in previous discussions was that Mozilla needs the core people working on the things they're actually working on more than it needs the money.
Or put another way, nothing is stopping other organizations from just paying people to do LTS (and Debian and Red Hat have done just that, with Mozilla providing the bug database, version control setup, some code reviewer bandwidth, etc). Presumably if people want _Mozilla_ to do LTS and pay for it (as opposed to paying a third party) that means they want something more than than those things... the question is what.
> Other software organizations hire, integrate, and are
> productive with many more developers than Mozilla.
Yes, but they also typically took their time growing to that point.... Mozilla Corp has grown by at least a factor of 3 in size over the last few years. That's always pretty difficult.
Note that the problem is not just hiring people, but hiring people who actually get open source (and don't get upset when they don't get checkin privileges their first day on the job, will actually work well with non-employee contributors, etc). Ending up with an "open source" project like Android or various other "throw the source over the wall every so often" cases is not a goal here.
I didn't say Josephus was contemporaneous. I was responding to your second point, where you said there were no credible non-contemporaneous sources. Josephus indeed reports second-hand, but he doesn't say anything about the miraculous act strawman that you're arguing about. He does say that he's told there was a particular person in the right timeframe who had that name and somewhat of a following. Obviously not as good as eyewitness original sources, but much better than your overstated claims of "a work of blatantly obvious fiction".
> Because if your programmers can't write secure
> code, why are they writing Internet facing code?
The location bar, which is the context here, is NOT internet-facing, actually.
But that's not the point. Writing security fixes doesn't just require writing secure code but also an understanding of what the security model is, why it failed, and how to fix it. This is much harder than writing code to start with.
> The language should just automatically take care
> of all known security vulnerabilities
The language can take care of mechanism (and yes, C++ falls down here, say), but it can't do _policy_. The language has no idea that sending one file (the one the user selected in the file input) to the web site is secure but sending some other file (/etc/passwd, say) is not.
> We invented garbage collection in the 1960s, right?
Yep, and have been fixing it to not suck ever since. We're getting pretty close. At this point, with custom hardware specially designed for it, you can more or less get a GC system that doesn't hurt either throughput or latency too much. Too bad normal people aren't running this hardware...
> And array bounds checking? Why are
> programmers still having to juggle this stuff
> manually?
Because the languages that handle it for you have some drawbacks. It's being worked on (Go, Rust, that sort of thing) and I really hope that problem will be in our past soon. Then again, there were hopes for that with Java, and that got screwed up (startup time too slow, etc).
> 2) The only other reports we have of this person
> arise from a work of blatantly obvious fiction
I assume that you've arbitrarily decided to ignore Josephus here, yes? Granted, he's not contemporaneous, but he's more so than the Gospels, and happens to not be a Christian, a Christian apologist, or an anti-Christian. He also happens to not be in the business of making up fiction (well, any more so than any of the ancient or some of the modern historians, which is not necessarily a high bar).
Ah, interesting. Thank you for the pointer!
> since we do have a contemporary documentary
> reference to him
Citation please? Last I checked we had much later references that mentioned that they'd seen something about him somewhere. Has something new been found on the matter?
> The 15 different iterations of the search
> / address bar that we've had in the last couple
> months would be a nice start.
Which of the people working on that would have been able to write core security fixes for stable branches?
> They could also merge existing projects such as
> Frontmotion's work into their own
That would involve Frontmotion wanting that, no? Do they?
Seriously, this has been discussed literally for years, pretty seriously. It's not like the people involved are dumb. It's just that the problem is harder than it seems, assuming you have goals other than legacy suppor...
What would be useful would be providing people, not money. Mozilla _has_ money if you look at financial statements; what they have a hard time doing is finding good people and working them into the organization (c.f. mythical man-month for the problems with the latter).
Currently there is one version actively being developed, a testing version which fixes may need to be backported to, a release candidate (requires basically no resources, more or less by definition) which is misnamed "Beta", and a release version which only gets a fix in extraordinary situations (actively-exploited zero-day). So there are only two versions to really support, and they're very similar to each other so most of the time the same patch applies to both.
With LTS, you lose that last benefit; backporting patches to 3.6 and 3.5 during 4.0 development was a huge production; they often had to be redone from scratch because the code had changed so much.
Note that I didn't say you need to double the number of people or anything, but based on workload in the past I'd guess we're taking 20% more work. And not just for the new people, because code reviews are spread out over existing module owners and are a large part of the time commitment.
Now this is all doable; if one is willing to slow down new work by 20%. That's how other projects do it, after all, and how Mozilla has done it in the past. But it's not clear that this is necessarily a good tradeoff. Maybe it is, maybe not.
> nowhere near "way more than it will ever have."
That's not what I said. I said "way more than they ever have" (past tense, not future; significant difference in meaning).
You don't even have to cut exec salaries to hire more people. But:
1) Hiring more people may not move the work faster (c.f. mythical man-month).
2) Hiring people is not that simple. Mozilla has been actively hiring for years, and just can't find enough people so far.
3) By your argument, the same people could be hired to work on something more important, if something else seems to be more important.
Where did "Linux" come into this, if I might ask?
My general experience with Firefox on Linux is that Mozilla listens to the people who send them feedback (chiefly distros) too much. Unfortunately, these people are saying things that happen to be false (e.g. that Linux users really want Gnome theme integration more than, say, performance improvements; the two are mututally exclusive in many cases due to the way the Gnome theme system works).
So your proposal #2 + #3 is basically that Mozilla spend a bunch more engineer time on support than they ever have, right?
Are you planning to provide those engineers, their management structure, training, etc?
Or are you hoping they'll magically appear? What do you suggest Mozilla _not_ work on to do that?
The answer to your last question is, as always, opportunity cost.
That is, they could take such a stab by not doing something else instead. And then you have to decide whether the something else is more important.
1) There's a difference between "there is no hard evidence that this person existed" and "there is hard evidence this person did not exist". We're in the former situation. While it's possible there was no such person, that involves more assumptions and convoluted explanations than assuming that there was a person who was in fact teaching people something (note that _what_ he was teaching is a separate issue; more on that below). None of that has to do with the miracles and such, which _you_ are insisting on pulling into the conversation.
2) I quite sympathize with your objections to people using the Gospels to write laws. That has no bearing on whether there is a historical basis to the non-ridiculous events described in the Gospels. Again, there may not be, but that requires more assumptions than simply assuming that there is a historical basis that people added all the magic on top of as they do all the time.
3) It's not clear to me why whether Jesus existed or not matters for purposes of the whole "alleged words" bit, unless you insist on conflating the idea of "Jesus existed" and "Jesus existed and actually said and did the stuff the Gospels claim". I would fully expect that everything that the Gospels claim Jesus did and the vast majority of the things they claim Jesus said are fabricated.
Again, you really want to argue against "Jesus as the gospels portray him" existing, which is fine, and almost certainly true. But don't conflate this with the argument that there is no person the stories are based on. That argument is a lot weaker. Could still be true, if there was enough of a conspiracy to fabricate the story. But a lot less likely.
Did you ever read the book review I linked to?
There's no contemporaneous evidence for Hannibal either. And all that people can add to the that is a story from hundreds of years later about a guy who crossed the Alps with elephants. What does Occam's razor tell you about that?
The difference between the cases you cite and the Jesus case is that his story includes various historical events that are verifiable from other sources. Now maybe he was just cleverly inserted into those, Waldo-fashion. It's possible. But the general setup makes it somewhat unlikely. Just as it's unlikely, imo, that any actual miracles got performed.
> and a couple of christian insertians in Josephus
Did you even read the link I cited?
> as you couldnt prove that most of the people alive
> in those years ever lived either of course
Exactly.
> but he was supposed to have been someone
> rather more extraordinary
That's claim #2 (miracles and the like), not claim #1 (a guy who preaches and has a folllowing). People like that were a dime a dozen at the time.
Now I agree that "well-proven fact" existence of Jesus certainly is not. Neither is existence of Hannibal, by the same metrics. Do read the link I suggested, please!