I'm not convinced it doesn't benefit them. I'm betting that eye-tracking tests would show a disproportionate amount of attention to the last position, at least over the middle positions but possibly over the first as well. This hunch is founded on a tendency in UI design to place useful things (eg search and navigation) on the right and an expectation that users have grown accustomed to this.
there's no objective definition of "random enough"
Of course there is: "sufficiently random for the task in question". It's objective, but useless, because it depends on "sufficient" and "the task in question" to be specified, and neither are.
I don't think any current-version browser besides IE has used nearest neighbor scaling for years, and i can't say for sure but I don't think any release version of Safari or Firefox ever did.
HDDs are extremely unreliable. Moving parts equals higher likelihood of failure. I'm not sure I'd say you're lucky to never have experienced unexpected drive failure, but I'm not sure I wouldn't either.
If browser vendors adhered strictly to existing standards—that is, if they didn't innovate and push for standardization of their innovations—there would be nothing to standardize. Standards boards are *not* the place where that innovation should be happening. That's why XHTML2 was a failure. That's why ECMAScript 4 was a failure.
Apart from the video and audio tags, scarcely anything in HTML5 is not derived from existing implementations and consolidation thereof. That is the job of a standard.
Apple and Mozilla (and to a lesser extent, Google and Opera, who do less innovation in this area) are doing the right thing; they're building the web platform, and opening it up to be interoperable. One without the other is useless. IE's history is heavy on building, and weak on interoperability. This often gets condensed to "IE non-standard blah blah blah" but it's just not as simple as that.
I'd pick nits about a few of your more specific points, but I feel the broader point is more important.
Perhaps if some of those people making the decisions find themselves unable to view the sites they want to, they will realise how stupid those decisions were and make efforts to change them. With any luck, this will teach them the dangers of using proprietary apps which are tied to a single platform and they will take the dangers seriously when making any future decisions.
I'm not holding my breath. Considering how many people—many of whom are apparently web developers—can't understand the difference between treating IE 6 as a second-class browser on the one hand and the apparently infamous "this site best viewed in [insert browser]" wars of yore on the other, I suspect your site will get more blame than the browser.
That is, until the sites making this choice reach some kind of critical mass.
This is why there's so much conflict over this issue among web developers. We want eggs and we haven't got a chicken.
It's especially strange to find such a radical difference between Safari and Chrome, both of which use WebKit. They are on different release cycles so some differences in rendering are to be expected. But nothing that substantial... unless they've corrected an existing bug, and you've come to expect the bug's behavior.
What surprised me about it was that the vagueness seems to *weaken* the position they'd need to defend in court. Had they left off "so long" and everything after, it would be much stronger for them. By suggesting that material must violate the Policy to be removed or blocked, they are restricting themselves more than I would expect from being able to say "we can shut off service (or part of the service) for any customer at any time for any reason (or no reason at all)" and not have to worry about consequences.
It has a bunch of parenthetic phrases and a bucket's worth of commas, but as far as I can tell it's valid grammar...
On second glance, it's definitely *valid*, but I'm still surprised it passed muster from a legal perspective. It has me wondering whether or not material is required to violate the Policy, and if so, which Sections, in order to be removed—"so long as it violates this Policy" suggests that it must violate the Policy, but isn't any more specific than that; "deems to be in violation" suggests that a violation must pertain to Sections I or II; "or otherwise harmful" suggests that no violation is necessary.
And as far as grammar itself is concerned, I tend to prefer consistency over style, and the lack of a comma before "so long" bugged me. It may not be strictly necessary, but its absence certainly disrupts the flow.
Please note that my defense of the grammar of this clause of Comcast's ToS should not be construed as defense in any way of the actual terms of service.
I definitely didn't think it was meant that way.
Please note that any and all ironic grammar errors above are a product of sheer exhaustion.;)
In the case of Chrome, possibly. V8 (the Chrome Javascript engine) does a lot of low-level work that is tailored to i386/x86-64. To maintain a fork of that new engine, which has never existed on PPC before, for a platform that's barely in use and dropping rapidly, would require significantly more resources.
Instead of being deliberately obtuse, can you explain what makes an "OS" an "OS", and how that's distinguished from the system software operating those devices?
So... answer the question. If it does not run an operating system—instructions that operate the system (pardon both the oversimplification and the glibness)—what on earth does it run? Does the processor really have instructions for every function the iPhone presents or allows, as well as instructions for drawing the pixels of each UI control and animation? Does it gain new instructions when encountering arbitrary code from the Internet?
It does and it doesn't. It really depends which unique features make OS X and which don't.
If what makes OS X unique is that it's a BSD/xnu OS with a NeXT-based application framework (Cocoa) and a postscript-derived graphics engine (Quartz), iPhone OS is a variant of OS X.
On the other hand, if what makes OS X unique is all of the above plus a subset of the classic MacOS APIs (Carbon), then it is not.
The rest of the differences are limited to the configuration and window manager. In other words, beyond support for legacy applications that were never on the iPhone platform in the first place, the differences between OS X and iPhone OS are essentially equivalent to the differences between Ubuntu and Kubuntu.
Sure, I'm oversimplifying a bit, but quite a bit less than you did.
How is that clear? Has something taken the place of the dinosaurs? Perhaps you should clarify what you mean by "taking its place".
"mainly its descendants"
Really? Domesticated cattle fill the habitat role of aurochs?
"Since we've already mucked up the ecosystem with tens of millions of head of cattle, I fail to see how a few wild aurochs would bugger it up any more than that."
That's the point. We don't know. What would be the consequences of introducing new large mammals into a habitat that has been without them for 400 years? No one freaking knows. "We don't know" isn't the same as "it doesn't exist." Science has a duty to be more cautious than this.
And they won't be aurochs. They'll be novel aurochs-like bovine creatures.
Slashdot Mirror
I think that is actually describing the browsers themselves.
Or Redmond for that matter? 9_9
I'm not convinced it doesn't benefit them. I'm betting that eye-tracking tests would show a disproportionate amount of attention to the last position, at least over the middle positions but possibly over the first as well. This hunch is founded on a tendency in UI design to place useful things (eg search and navigation) on the right and an expectation that users have grown accustomed to this.
Of course there is: "sufficiently random for the task in question". It's objective, but useless, because it depends on "sufficient" and "the task in question" to be specified, and neither are.
I don't think any current-version browser besides IE has used nearest neighbor scaling for years, and i can't say for sure but I don't think any release version of Safari or Firefox ever did.
So's your face!
HDDs are extremely unreliable. Moving parts equals higher likelihood of failure. I'm not sure I'd say you're lucky to never have experienced unexpected drive failure, but I'm not sure I wouldn't either.
Or don't fly. Amtrak seating is at least as spacious as business class.
Singular they, which better accommodates a broader conception of gender.
I think you're going about this all wrong.
If browser vendors adhered strictly to existing standards—that is, if they didn't innovate and push for standardization of their innovations—there would be nothing to standardize. Standards boards are *not* the place where that innovation should be happening. That's why XHTML2 was a failure. That's why ECMAScript 4 was a failure.
Apart from the video and audio tags, scarcely anything in HTML5 is not derived from existing implementations and consolidation thereof. That is the job of a standard.
Apple and Mozilla (and to a lesser extent, Google and Opera, who do less innovation in this area) are doing the right thing; they're building the web platform, and opening it up to be interoperable. One without the other is useless. IE's history is heavy on building, and weak on interoperability. This often gets condensed to "IE non-standard blah blah blah" but it's just not as simple as that.
I'd pick nits about a few of your more specific points, but I feel the broader point is more important.
I'm not holding my breath. Considering how many people—many of whom are apparently web developers—can't understand the difference between treating IE 6 as a second-class browser on the one hand and the apparently infamous "this site best viewed in [insert browser]" wars of yore on the other, I suspect your site will get more blame than the browser.
That is, until the sites making this choice reach some kind of critical mass.
This is why there's so much conflict over this issue among web developers. We want eggs and we haven't got a chicken.
It's especially strange to find such a radical difference between Safari and Chrome, both of which use WebKit. They are on different release cycles so some differences in rendering are to be expected. But nothing that substantial... unless they've corrected an existing bug, and you've come to expect the bug's behavior.
Well, if your client-side code is good, it should perform as well with all the bells and whistles in WebKit and Gecko as it does without in Trident.
Justifiably enforceable? Not at all. Enforceable as a consequence of Comcast's weight and the system's corruption? Quite a lot.
What surprised me about it was that the vagueness seems to *weaken* the position they'd need to defend in court. Had they left off "so long" and everything after, it would be much stronger for them. By suggesting that material must violate the Policy to be removed or blocked, they are restricting themselves more than I would expect from being able to say "we can shut off service (or part of the service) for any customer at any time for any reason (or no reason at all)" and not have to worry about consequences.
On second glance, it's definitely *valid*, but I'm still surprised it passed muster from a legal perspective. It has me wondering whether or not material is required to violate the Policy, and if so, which Sections, in order to be removed—"so long as it violates this Policy" suggests that it must violate the Policy, but isn't any more specific than that; "deems to be in violation" suggests that a violation must pertain to Sections I or II; "or otherwise harmful" suggests that no violation is necessary.
And as far as grammar itself is concerned, I tend to prefer consistency over style, and the lack of a comma before "so long" bugged me. It may not be strictly necessary, but its absence certainly disrupts the flow.
I definitely didn't think it was meant that way.
Please note that any and all ironic grammar errors above are a product of sheer exhaustion. ;)
No way AT&T would fib.
I can't believe that grammar made it past their legal team.
Depends on the congressmen. Er, and depends whether they're there to meet the juveniles.
In the case of Chrome, possibly. V8 (the Chrome Javascript engine) does a lot of low-level work that is tailored to i386/x86-64. To maintain a fork of that new engine, which has never existed on PPC before, for a platform that's barely in use and dropping rapidly, would require significantly more resources.
Instead of being deliberately obtuse, can you explain what makes an "OS" an "OS", and how that's distinguished from the system software operating those devices?
So... answer the question. If it does not run an operating system—instructions that operate the system (pardon both the oversimplification and the glibness)—what on earth does it run? Does the processor really have instructions for every function the iPhone presents or allows, as well as instructions for drawing the pixels of each UI control and animation? Does it gain new instructions when encountering arbitrary code from the Internet?
You were skeptical that there was an OS at all? What did you think it ran on, wishes and unicorns?
It does and it doesn't. It really depends which unique features make OS X and which don't.
If what makes OS X unique is that it's a BSD/xnu OS with a NeXT-based application framework (Cocoa) and a postscript-derived graphics engine (Quartz), iPhone OS is a variant of OS X.
On the other hand, if what makes OS X unique is all of the above plus a subset of the classic MacOS APIs (Carbon), then it is not.
The rest of the differences are limited to the configuration and window manager. In other words, beyond support for legacy applications that were never on the iPhone platform in the first place, the differences between OS X and iPhone OS are essentially equivalent to the differences between Ubuntu and Kubuntu.
Sure, I'm oversimplifying a bit, but quite a bit less than you did.
"Clearly something has taken its place"
How is that clear? Has something taken the place of the dinosaurs? Perhaps you should clarify what you mean by "taking its place".
"mainly its descendants"
Really? Domesticated cattle fill the habitat role of aurochs?
"Since we've already mucked up the ecosystem with tens of millions of head of cattle, I fail to see how a few wild aurochs would bugger it up any more than that."
That's the point. We don't know. What would be the consequences of introducing new large mammals into a habitat that has been without them for 400 years? No one freaking knows. "We don't know" isn't the same as "it doesn't exist." Science has a duty to be more cautious than this.
And they won't be aurochs. They'll be novel aurochs-like bovine creatures.