The keygen feature has been deprecated. It's likely edge will support more open formats in the future: http://blogs.windows.com/msedg..., including opus+vorbis.
Between firefox, chrome and edge, I'd suggest that today it is chrome that has the greatest support for non-standard features, tracing back to the hastily designed extensions to webkit for the early iphones. In particular many non standard things like speed synthesis and recognition are only on in blink/webkit, as is WebSQL (which, to be fair, was at least once proposed as a standard, even though it was rejected). Those three features alone account for a 15 point headstart (17 if you count keygen) that chrome has over edge+firefox, even though their support should if anything, decrease the score.
It's no coincidence than non-webkit browsers started supporting -webkit- prefixed css properties - webkit has included a large amount of non-standard extensions over the years. Edge's declared preference for feature toggles (and firefox I believe prefers those too, exposing speech api's only if an about:config flag is set for instance) is friendlier to standardization because it means that non-standard features do not become entrenched and hard to fix.
If anything, a high score in html5test means a non-standard browser. Just take a look at the actual features where the major browsers differ and that amount to chrome's advantage - almost all of them are experimental, entirely non-standard, deprecated, or rejected. Why exactly should that count as standards compliant?
Don't read too much into sunspider scores. Octane v2 isn't perfect either, but it's a lot better. Mozilla's kraken is probably even better, but it's much more focused on what CPU-intensive JS can do than on what normal JS actually does. I wouldn't call it a general purpose JS benchmark.
Despite what the summary may suggest, there's no evidence presented that edge lacks standards compliance or indeed that chrome leads in standards compliance. The test used (html5test) isn't a test of standards compliance nor of html5; it's simply a large grabbag of features some of which happen to be defined in html5 - and those features aren't even really tested for, they just use feature detection. Many of those features are experimental (i.e. it's probably better if a browser *doesn't* support those without a feature toggle or prefix), and a few are deprecated or even rejected.
html5test should probably be renamed webkit-as-of-2013-test. As is, higher scoring browsers aren't more standards compliant, they simply include more legacy and experimental features (i.e. are *less* standards compliant).
See http://tech.slashdot.org/comme... - in short, the html5test site is deeply flawed. If anything, a high score suggests a browser that supports deprecated, rejected or experimental features without decent feature toggles. Not a good idea.
HTML5test is not a test of standards compliance; the title is misleading. It's a wishlist of features, some of which are standardized, but many of which are not (or are not part of HTML5). For example, html5test doesn't (in general) test whether you've really implemented a feature correctly (or really - at all) it just uses feature detection to check whether you've claimed to implement a feature. Fortunately, browsers are never buggy and this distinction doesn't matter.
Then, html5test follows the whatwg's "living standard" instead of the less-cutting year-old actual standard html. This makes sense at first glance - we want to know which browsers support "new" features too! As a developer, that's great. As a score for a browser, that's questionable. Many features are added to the standard because one of the browsers initially experimented with a non-standard extension; lately that's been webkit/blink due to the mobile push, but previous names have included IE6. By *intent* the whatwg living spec is a few steps ahead of the browsers. What this means is that if you use this as a score is that you're going to penalize whoever is following the spec, and promote those leading the spec. That deserves at least a separate score.
Then, there are HTML5 features that are deprecated, like . The continued support for scores chrome two points, and edge+firefox none. Is that really what you wanted to know? I bet there are *lots* of deprecated features in old IE; if you're going to start counting those...
Then there's features like speech synthesis and recognition. Those aren't part of the spec, have never been part of the spec, yet they're worth 5 points together. Or worse, the Web SQL features, that have explicitly been rejected, also worth 5 points (only webkit-derived browsers support this).
Almost all of the point differences between browsers can be explained by features that are experimental, deprecated or rejected.
HTML5test is not a test of standards compliance; the title is misleading. It's a wishlist of features, some of which are standardized, but many of which are not (or are not part of HTML5).
Oh and one minor detail: did you see the final compiled code sizes and how much smaller the optimized versions are (esp. clang!). I'm willing to bet the entire benchmark just code "optimized away" by dead code elimination; and that's an entirely unrealistic situation... Also, where's the code? Is this reproducible?
I think there's some merit to blaming the reporter for being negligent. But it's important to note that that does not in any way, shape or form excuse the behavior of the police in this matter.
Frankly, I think individual officers in cases like these should be held personally responsible for infractions they commit, even if they're just following orders, and even if they didn't know any better. It happens all too frequently that some anonymous police or other organization gets blamed, and the consequences to anyone personally are then irrelevant at best. Perhaps some committee harasses those involved; or the police pays some fine (but that's really the taxpayers paying it, after all) - but at the end of the day, the actual people that in all likelihood intentionally violated other's rights get away scott free.
And there's no pushback from inside the organization, because, well, nobody ever got fired for following orders when there's even a whiff of plausible deniability here. Nobody is taking responsibility for their own actions; so it shouldn't surprise anyone that the police act irresponsibly and unethically despite the fact that most people involved only ever had the best of intentions. If you want it to be normal for the officers in a raid to question the need for it, the circumstances in which it is made, the force with which it is executed, or the damage that is done to those they raid, then there's got to be an incentive for officers to push back and do what's right. Right now, we reward officers for doing what's wrong and punish them for thinking and having a conscience, and that is deeply disturbing.
Heck, I bet anybody that texts at all probably is more likely to text recklessly while driving; we should just issue them a traffic violation whenever they text to save some time and trouble.
So? even if true, that's only meaningful if less than 90% of the set of "people that drive and that text" text *while* driving. And that I seriously doubt.
In other words: the frequency of texting surely correlates with the frequency of texting while driving, but I doubt that after correcting for that texting while stopped predicts texting while driving very strongly.
Is it any less "armchair" to simply assume an article is valid without corroboration, or to assume this particular scientist is a fraud without actually checking?
Just because it's more easily said than done doesn't make it untrue - and I strongly suspect none of us particularly care about these specific results anyhow, so of course we'll just comment from afar without actually doing anything.
I mean, if this bothers you, do you have an alternative suggestion?
They just removed the UI - this doesn't affect things like Firebug, Noscript, and they *probably* didn't even remove the UI completely - if you can call about:config a UI.
That depends on what kind of slowness they mean - bandwidth, or latency? I don't think X dealt well at all with medium-to-high latencies, so that's perhaps what you're seeing.
You suggest that the 5th applies equally serious limitations to all laws, and that therefore Noryungi's argument is irrelevant since it would equally apply to a good law.
I'm not so convinced that's acutally true: The 5th applies particularly well to "crimes" that affect no others. And laws that try to control not how you treat others but how you treat yourself are perhaps intrinsically unwelcome. If you're not even free to make your own choices even when they don't harm others... well, what exactly are you free to do then? Choose a favorite color as long as it's red, white or blue?
Indirectly, the 5th encourages laws that affect how people treat each other or behave publically, and discourage laws about private, unverifiable behavior - and indeed child pornography unfortunately falls in the latter category. And perhaps that's not surprising, because the laws aren't actually targeting the appropriate crime - the "problem" (hopefully) isn't trying to impose control on people (even if you think they're guilty of thoughtcrime), the problem is that it might encourage actual abuse of children.
I think it's wise not to let an emotive but ultimately rather rare crime undermine something so fundamentally beneficial to long-term sustained freedom. The 5th isn't just a good law now, it encourages the system of laws to stay that way, and that's something that we really shouldn't take for granted.
Because the alternative is that he wouldn't speak up at all, and the harm caused by murder is greater than that by theft. In essence, this can be construed as a whistleblowing case: better to
I also don't think it's a very convincing example, but just because somebody is guilty of *some* crime doesn't necessarily mean you want to convict him. Not to mention the fact that guilty does not mean bad - there are so many crazy laws out there, I seriously doubt there are many people in the country that aren't "guilty" of something.
To use the inevitable car analogy, if a researcher discovers that all automobiles manufactured by GM, Ford, Chrysler, and Honda can be unlocked, started, and driven with the use of a paperclip and that researcher adopts your policy, what happens?
I don't understand how your comment got modded Insightful, but here goes...
The car analogy isn't at all appropriate. Unlike physical car locks, software kernels can are are regularly patched. The types of risk are completely different.
Perhaps responsible disclosure is a better option. But your argument does not in any way support that statement.
The username/password in question supposedly were "admin". And it sounds like it was probably overheard because the sharing was routine and the authentication a farce. So perhaps they didn't have a technical problem, but they certainly don't sound blameless.
I think these kind of issues are harmful to everyone because they encourage black-hat hacking (which is trivial), and they discourage whistleblowing. It's perhaps not honorable, but obviously many whistleblowers like the attention. But if that's the currency that needs to be payed for better security, it sounds like a pretty reasonable tradeoff. In short: typically the hackee should be fined and shamed, not the hacker, even if the hacker's a jerk. It's not about the hacker after all - he's probably not the person you've entrusted your data to - it's about the resposible party taking responsibilty.
Having used default parameters in a medium sized team on a large codebase for quite a while now (basically since day 1), I can assure you that the default argument argument feature is a wolf in sheeps clothing.
They seem sort-of handy and thus get used when you just need to toggle this small thing. However, that encourages methods to do more than one thing; or to work subtly different in different scenarios. The reliability of your codebase suffers. Furthermore, they break programming 101: encapsulation. You can't encapsulate a function with a default parameter. If you wrap that call in something else and need to pass along the default parameter, you need to add the default argument to that second function now too. If the default changes... oh boy. In essence, they encourage misdesign by allowing API's with terrible method signatures and then making it cumbersome to abstract those APIs - so you're being hurt on both ends.
Another small problem is that they're entirely static. I find the binary compatibility argument to be largely irrelevant (seriously, what tiny percentage of your API is outward facing anyhow, and how many people even have customers that buy libraries but don't recompile dependencies?). A much more serious problem is that they thus encourage placeholder values (null, -1, etc) that mean something entirely different. This makes reasoning about functions much harder (irregularities are bad), and can cause surprising bugs when you manage to accidentally pass one of those placeholders. Secondly, they somewhat undermine an actually useful part of C#, namely expression-tree lambdas, which don't support this feature (so APIs with default paramaters tend to be unworkable in expression trees).
I wish they'd never released the feature, or at least made it very annoying to write APIs for so that its usage would be limited to there where absolutely necessary (e.g. interop with APIs designed with it in mind).
That's not a reasonable position for Apple to take; not at all. They could have simply left the old gmaps app since their license had not *yet* expired, and at least avoided this debacle. Furthermore, you present "plastering" google's logo all over the app as if its certain this was something truly terrible - when that's not sure at all; it's not unreasonable to claim credit for an app you made so a logo might be reasonable.
All in all - if both parties had wanted this to work out they would have made it work. It's certain apple wasn't being reasonable, and quite believable Google wasn't either (but we really only have Apple's word for that). In any case - it's Apple's device; they're Apple customers, and that makes it Apple's responsibility to come up with a solution that doesn't suck - whether that solution involves using an old-fashioned app for another year, or a different provider, or kowtowing to Google isn't really important.
Regardless of who else is involved, Apple chose to harm their customers, probably intentionally, because that fit their strategic aims better. Given apple's dealings with samsung (and others), Apple doesn't come across as a very open-minded company: does it really surprise anyone they played hardball even if doing so cost them something?
Put it this way: if you blame some third party for a seller's failure to provide quality goods, that's not exactly a great incentive for said seller to be fair with you the next time - why bother? Defending Apple for their abuse of their customers reminds me a little too much of the stockholm syndrome for comfort.
I don't think these power-fights are good for customers.
Sorry, I think you may have gotten it wrong. From my understanding, Linus was stating a well-established fact -- that Romney is a fucking mor[m]on. Simple typo; he knows genius when he sees it.
Or fucking [a] mor[m]on, i.e. just pointing out that Romney has a healthy sexual relationships with his wife, who is also a mormon. SImple mistake.
Slashdot Mirror
The keygen feature has been deprecated. It's likely edge will support more open formats in the future: http://blogs.windows.com/msedg..., including opus+vorbis.
Between firefox, chrome and edge, I'd suggest that today it is chrome that has the greatest support for non-standard features, tracing back to the hastily designed extensions to webkit for the early iphones. In particular many non standard things like speed synthesis and recognition are only on in blink/webkit, as is WebSQL (which, to be fair, was at least once proposed as a standard, even though it was rejected). Those three features alone account for a 15 point headstart (17 if you count keygen) that chrome has over edge+firefox, even though their support should if anything, decrease the score.
It's no coincidence than non-webkit browsers started supporting -webkit- prefixed css properties - webkit has included a large amount of non-standard extensions over the years. Edge's declared preference for feature toggles (and firefox I believe prefers those too, exposing speech api's only if an about:config flag is set for instance) is friendlier to standardization because it means that non-standard features do not become entrenched and hard to fix.
If anything, a high score in html5test means a non-standard browser. Just take a look at the actual features where the major browsers differ and that amount to chrome's advantage - almost all of them are experimental, entirely non-standard, deprecated, or rejected. Why exactly should that count as standards compliant?
I meant to say deprecated like keygen, but slashdot stripped the "html" tag.
Well, sunspider certainly doesn't have the most reliable name:
http://news.softpedia.com/news...
Don't read too much into sunspider scores. Octane v2 isn't perfect either, but it's a lot better. Mozilla's kraken is probably even better, but it's much more focused on what CPU-intensive JS can do than on what normal JS actually does. I wouldn't call it a general purpose JS benchmark.
Despite what the summary may suggest, there's no evidence presented that edge lacks standards compliance or indeed that chrome leads in standards compliance. The test used (html5test) isn't a test of standards compliance nor of html5; it's simply a large grabbag of features some of which happen to be defined in html5 - and those features aren't even really tested for, they just use feature detection. Many of those features are experimental (i.e. it's probably better if a browser *doesn't* support those without a feature toggle or prefix), and a few are deprecated or even rejected.
html5test should probably be renamed webkit-as-of-2013-test. As is, higher scoring browsers aren't more standards compliant, they simply include more legacy and experimental features (i.e. are *less* standards compliant).
See http://tech.slashdot.org/comme... - in short, the html5test site is deeply flawed. If anything, a high score suggests a browser that supports deprecated, rejected or experimental features without decent feature toggles. Not a good idea.
HTML5test is not a test of standards compliance; the title is misleading. It's a wishlist of features, some of which are standardized, but many of which are not (or are not part of HTML5). For example, html5test doesn't (in general) test whether you've really implemented a feature correctly (or really - at all) it just uses feature detection to check whether you've claimed to implement a feature. Fortunately, browsers are never buggy and this distinction doesn't matter.
Then, html5test follows the whatwg's "living standard" instead of the less-cutting year-old actual standard html. This makes sense at first glance - we want to know which browsers support "new" features too! As a developer, that's great. As a score for a browser, that's questionable. Many features are added to the standard because one of the browsers initially experimented with a non-standard extension; lately that's been webkit/blink due to the mobile push, but previous names have included IE6. By *intent* the whatwg living spec is a few steps ahead of the browsers. What this means is that if you use this as a score is that you're going to penalize whoever is following the spec, and promote those leading the spec. That deserves at least a separate score.
Then, there are HTML5 features that are deprecated, like . The continued support for scores chrome two points, and edge+firefox none. Is that really what you wanted to know? I bet there are *lots* of deprecated features in old IE; if you're going to start counting those...
Then there's features like speech synthesis and recognition. Those aren't part of the spec, have never been part of the spec, yet they're worth 5 points together. Or worse, the Web SQL features, that have explicitly been rejected, also worth 5 points (only webkit-derived browsers support this).
Almost all of the point differences between browsers can be explained by features that are experimental, deprecated or rejected.
In short: don't use html5test. It's pointless.
HTML5test is not a test of standards compliance; the title is misleading. It's a wishlist of features, some of which are standardized, but many of which are not (or are not part of HTML5).
Don't worry, it's OK to *have* patents, you just can't *use* them very well...
unless, of course, you count phones...
Oh and one minor detail: did you see the final compiled code sizes and how much smaller the optimized versions are (esp. clang!). I'm willing to bet the entire benchmark just code "optimized away" by dead code elimination; and that's an entirely unrealistic situation... Also, where's the code? Is this reproducible?
The benchmark isn't worth anything.
And you base this on what? Did the spagetti-monster tell you JSON was technically a better fit, or that XQuery doesn't work?
I think there's some merit to blaming the reporter for being negligent. But it's important to note that that does not in any way, shape or form excuse the behavior of the police in this matter.
Frankly, I think individual officers in cases like these should be held personally responsible for infractions they commit, even if they're just following orders, and even if they didn't know any better. It happens all too frequently that some anonymous police or other organization gets blamed, and the consequences to anyone personally are then irrelevant at best. Perhaps some committee harasses those involved; or the police pays some fine (but that's really the taxpayers paying it, after all) - but at the end of the day, the actual people that in all likelihood intentionally violated other's rights get away scott free.
And there's no pushback from inside the organization, because, well, nobody ever got fired for following orders when there's even a whiff of plausible deniability here. Nobody is taking responsibility for their own actions; so it shouldn't surprise anyone that the police act irresponsibly and unethically despite the fact that most people involved only ever had the best of intentions. If you want it to be normal for the officers in a raid to question the need for it, the circumstances in which it is made, the force with which it is executed, or the damage that is done to those they raid, then there's got to be an incentive for officers to push back and do what's right. Right now, we reward officers for doing what's wrong and punish them for thinking and having a conscience, and that is deeply disturbing.
Heck, I bet anybody that texts at all probably is more likely to text recklessly while driving; we should just issue them a traffic violation whenever they text to save some time and trouble.
So? even if true, that's only meaningful if less than 90% of the set of "people that drive and that text" text *while* driving. And that I seriously doubt.
In other words: the frequency of texting surely correlates with the frequency of texting while driving, but I doubt that after correcting for that texting while stopped predicts texting while driving very strongly.
Is it any less "armchair" to simply assume an article is valid without corroboration, or to assume this particular scientist is a fraud without actually checking?
Just because it's more easily said than done doesn't make it untrue - and I strongly suspect none of us particularly care about these specific results anyhow, so of course we'll just comment from afar without actually doing anything.
I mean, if this bothers you, do you have an alternative suggestion?
They just removed the UI - this doesn't affect things like Firebug, Noscript, and they *probably* didn't even remove the UI completely - if you can call about:config a UI.
That depends on what kind of slowness they mean - bandwidth, or latency? I don't think X dealt well at all with medium-to-high latencies, so that's perhaps what you're seeing.
You suggest that the 5th applies equally serious limitations to all laws, and that therefore Noryungi's argument is irrelevant since it would equally apply to a good law.
I'm not so convinced that's acutally true: The 5th applies particularly well to "crimes" that affect no others. And laws that try to control not how you treat others but how you treat yourself are perhaps intrinsically unwelcome. If you're not even free to make your own choices even when they don't harm others... well, what exactly are you free to do then? Choose a favorite color as long as it's red, white or blue?
Indirectly, the 5th encourages laws that affect how people treat each other or behave publically, and discourage laws about private, unverifiable behavior - and indeed child pornography unfortunately falls in the latter category. And perhaps that's not surprising, because the laws aren't actually targeting the appropriate crime - the "problem" (hopefully) isn't trying to impose control on people (even if you think they're guilty of thoughtcrime), the problem is that it might encourage actual abuse of children.
I think it's wise not to let an emotive but ultimately rather rare crime undermine something so fundamentally beneficial to long-term sustained freedom. The 5th isn't just a good law now, it encourages the system of laws to stay that way, and that's something that we really shouldn't take for granted.
Because the alternative is that he wouldn't speak up at all, and the harm caused by murder is greater than that by theft. In essence, this can be construed as a whistleblowing case: better to
I also don't think it's a very convincing example, but just because somebody is guilty of *some* crime doesn't necessarily mean you want to convict him. Not to mention the fact that guilty does not mean bad - there are so many crazy laws out there, I seriously doubt there are many people in the country that aren't "guilty" of something.
To use the inevitable car analogy, if a researcher discovers that all automobiles manufactured by GM, Ford, Chrysler, and Honda can be unlocked, started, and driven with the use of a paperclip and that researcher adopts your policy, what happens?
I don't understand how your comment got modded Insightful, but here goes...
The car analogy isn't at all appropriate. Unlike physical car locks, software kernels can are are regularly patched. The types of risk are completely different.
Perhaps responsible disclosure is a better option. But your argument does not in any way support that statement.
The username/password in question supposedly were "admin". And it sounds like it was probably overheard because the sharing was routine and the authentication a farce. So perhaps they didn't have a technical problem, but they certainly don't sound blameless.
I think these kind of issues are harmful to everyone because they encourage black-hat hacking (which is trivial), and they discourage whistleblowing. It's perhaps not honorable, but obviously many whistleblowers like the attention. But if that's the currency that needs to be payed for better security, it sounds like a pretty reasonable tradeoff. In short: typically the hackee should be fined and shamed, not the hacker, even if the hacker's a jerk. It's not about the hacker after all - he's probably not the person you've entrusted your data to - it's about the resposible party taking responsibilty.
Having used default parameters in a medium sized team on a large codebase for quite a while now (basically since day 1), I can assure you that the default argument argument feature is a wolf in sheeps clothing.
They seem sort-of handy and thus get used when you just need to toggle this small thing. However, that encourages methods to do more than one thing; or to work subtly different in different scenarios. The reliability of your codebase suffers. Furthermore, they break programming 101: encapsulation. You can't encapsulate a function with a default parameter. If you wrap that call in something else and need to pass along the default parameter, you need to add the default argument to that second function now too. If the default changes... oh boy. In essence, they encourage misdesign by allowing API's with terrible method signatures and then making it cumbersome to abstract those APIs - so you're being hurt on both ends.
Another small problem is that they're entirely static. I find the binary compatibility argument to be largely irrelevant (seriously, what tiny percentage of your API is outward facing anyhow, and how many people even have customers that buy libraries but don't recompile dependencies?). A much more serious problem is that they thus encourage placeholder values (null, -1, etc) that mean something entirely different. This makes reasoning about functions much harder (irregularities are bad), and can cause surprising bugs when you manage to accidentally pass one of those placeholders. Secondly, they somewhat undermine an actually useful part of C#, namely expression-tree lambdas, which don't support this feature (so APIs with default paramaters tend to be unworkable in expression trees).
I wish they'd never released the feature, or at least made it very annoying to write APIs for so that its usage would be limited to there where absolutely necessary (e.g. interop with APIs designed with it in mind).
var newarr = []; for(var i=0;iarr.length;i++) newarr[i]=arr[arr.length-1-i];
or
for(var i=0;iarr.length/2;i++) { var tmp = arr[i], j= arr.length-1-i; arr[i] = arr[j]; arr[j]= tmp;}
if you really want it in place...
That's not a reasonable position for Apple to take; not at all. They could have simply left the old gmaps app since their license had not *yet* expired, and at least avoided this debacle. Furthermore, you present "plastering" google's logo all over the app as if its certain this was something truly terrible - when that's not sure at all; it's not unreasonable to claim credit for an app you made so a logo might be reasonable.
All in all - if both parties had wanted this to work out they would have made it work. It's certain apple wasn't being reasonable, and quite believable Google wasn't either (but we really only have Apple's word for that). In any case - it's Apple's device; they're Apple customers, and that makes it Apple's responsibility to come up with a solution that doesn't suck - whether that solution involves using an old-fashioned app for another year, or a different provider, or kowtowing to Google isn't really important.
Regardless of who else is involved, Apple chose to harm their customers, probably intentionally, because that fit their strategic aims better. Given apple's dealings with samsung (and others), Apple doesn't come across as a very open-minded company: does it really surprise anyone they played hardball even if doing so cost them something?
Put it this way: if you blame some third party for a seller's failure to provide quality goods, that's not exactly a great incentive for said seller to be fair with you the next time - why bother? Defending Apple for their abuse of their customers reminds me a little too much of the stockholm syndrome for comfort.
I don't think these power-fights are good for customers.
Sorry, I think you may have gotten it wrong. From my understanding, Linus was stating a well-established fact -- that Romney is a fucking mor[m]on. Simple typo; he knows genius when he sees it.
Or fucking [a] mor[m]on, i.e. just pointing out that Romney has a healthy sexual relationships with his wife, who is also a mormon. SImple mistake.
Dude... that's just priceless :-D