It wasn't too bad if you have a horizontal scrollwheel or a touch screen. What MS could have done to make it a bit better is to allow the standard vertical scrollwheel most mice come with nowadays to scroll the start screen; down = right, up = left (because you always started at the TOP of the start menu, naturally you'd scroll DOWN for more, while the start screen starts at the LEFT, requiring you to scroll RIGHT for more). That would have added immensely to the intuitiveness of the interface and made it much less of a bear to use on non-touch interfaces.
To be clear, I have with a Windows tablet and a touch-enabled Windows laptop and I don't mind the interface on either; but I absolutely abhor it on non-touch equipment.
You'd be surprised how many can't... Have you ever had to support them? Yes, people need hand-holding level support for their iPads and Androids and you're naive if you think they don't. And if you think a car is supposed to be used until it dies, with no maintenance or upkeep (like a TV, stereo, microwave, or tablet), I need to know what roads you commonly drive on so I can avoid them.
If you can't use and maintain it properly and safely (knowing when it needs service and being able to take it to someone who *can* service it if you can't *does* count), then you shouldn't be using it, whether "it" is a car, a computer, a gun, or really anything else... Insisting upon doing so anyway only serves to endanger yourself and those around you and is both selfish and (potentially criminally) irresponsible. If you don't want the expense of paying someone to maintain your things for you, you learn how to maintain them yourself; then you don't have the expense of paying someone to do it for you -- but you have a choice: Learn to maintain it, ay to maintain it, or simply don't use it. There's a fourth option, which is "use it anyway", the irresponsible and often dangerous option, which the raging idiot masses often opt for out of ignorance, then complain (and try and blame someone else) when shit goes south. I've said it a couple different ways now, so hopefully you get it.
Just like the other commenter who said this, you're wrong. Just like the iPad, the iPhone runs iOS, which is based on a BSD kernel similar to the one OSX is layered on top of. But, aside from that, and being made by Apple, there really aren't many other similarities; for example, I can't install any of the OSX software on my Mac onto my iPad and, without an emulator, can't run iOS software on my Mac.
Yes, in the case of Gmail, the property in which the letter is stored (your inbox) is owned by the deliveryman, who does have legal access to that inbox. That's the difference.
Not that they should be allowed to; and it seems they know this, which is why they're insisting upon a court order.
What's the miss rate on an ISP-side cache of the entire Netflix library? I'm guessing it's 0 or some such, since it's oh, uh... the entire library? And you, like everyone else, are still failing to address streaming devices, which have no local storage and, therefore, can't cache gigabytes or terabytes of data (so that'd be what, a 100% miss rate?); and ISP-side cache covers these, as well.
Yes, keeping the cache as close to its point of use as possible is ideal. For the devices most people are streaming to, that's the ISP. Yes, Netflix could sell a cache device their users could install on their networks, but that incurs support costs for millions of users, many, if not most, of whom wouldn't have the first clue how to plug in a network cable, so no, it's not a viable solution, where an ISP-side cache is not only a viable solution, it's one Netflix has been working with ISPs to implement for a while now; Comcast, Verizon, and AT&T are really the only ones refusing to accept the free equipment at this point.
For several months, Netflix offered Comcast the hardware (and support for such) for ISP-side caching, for free, and Comcast's response was to demand payment from Netflix in order to host these servers that work to save Comcast money, then, when Netflix didn't cave, move Level3's (Netflix's provider) peering to lower quality interfaces until they agreed to pay.
Furthermore, how, exactly, would a customer cache work in the way you are describing when the most popular package Comcast sells is barely capable of streaming a single HD stream from Netflix while browsing the web and has about 1/10 as much upstream as it does downstream? How is the second user going to stream from the first when the first, even under ideal conditions, can only provide 1/10 of the required throughput? And Netflix caching servers? You realize that Netflix has a CDN, right? If your ISP doesn't have a local Netflix cache (again, Netflix will provide the hardware and support for free), then you're hitting the Netflix CDN, which will have a node near you. Of course, that node sits on the other side of a backbone provider that your ISP can throttle if they want to extort money from Netflix. That's why both of those solutions fail hard.
Precisely. The entire concept of an end-user-side cache of a several-petabyte library relies on knowing in advance exactly which part(s) of that library the user will want, far enough in advance to cache them, while requiring the user to have available storage for the cache. Since, by definition, streaming services are on-demand, there is no way to know this in advance, so even more storage is required. And still, nobody has addressed the issue of streaming devices (perhaps because those who might be able to address it don't know them by that term -- not likely, but hey -- I'm talking about AppleTV and the like) which have no local storage for such a cache.
I get this, my non-techie wife gets this, my project manager gets this, you seem to get this; why does it seem that nobody else does?
That's precisely one of the points I was trying to make. Thank you for making it more succinctly than I did; I only wish you had replied to GP so they'd be more likely to actually read it.
That is exactly the "fast lane" concept, where you are paying Netflix to pay Comcast...
No, paying the USPS *at all* to deliver to China is akin to me paying Netflix to pay Comcast. Paying the USPS *more* to deliver faster is akin to... what, exactly, in this case? There's no analogue.
Furthermore, "Postage Due" has no analogue here, and is, as I said previously, therefore irrelevant to this discussion; Comcast is delivering the packets, just more slowly, whereas USPS will simply hold a "Postage Due" package until that postage has been paid, or will return it to the sender. You also failed to point out how COD, which you mentioned previously, is relevant, most probably because you realized it's actually not.
The whole "I pay for my post office box" analogy falls apart when you realize that Comcast is actually delaying packets based on their point of origin, rather than which of their peers passed them along. The analog for that would be USPS delaying packages shipped by you, but only if you shipped them via FedEx using SmartPost (google it if you're not familiar) because, even though FedEx is paying them to carry the package for the last leg of the delivery, because you aren't also paying them. This would land the USPS in hot water, as well, which is why people seem to have a problem when Comcast does it.
UPS' service is irrelevant because it cones down to the recipient redirecting the delivery, something the sender has no control over. Keep trying to muddy the waters, though; you ought to be able to get something to stick eventually, right? And the discussion about pricing? Really? I guess, if you really want me to agree with you on something, I'll give you that; not as though I'm conceding on any point I was actually arguing, though.
I pay USPS; if some of what I pay USPS is passed off, by them, to China Post, that is inconsequential to me. Paying extra for special delivery options is an interesting point I hadn't thought of previously; that being said, there is no analogy for that here, as there is no means by which to pay a provider extra to make them maky your ISP deliver the packets faster; you pay your ISP extra for that. As for COD/Postage Due, that's a specific shipping option that some carriers make available to the sender, which, again, has no analogue here. If I'm missing something, please correct me, but I won't hold my breath.
Indeed. Are you trying to educate me, or the other readers here? I ask because it sure seems like you're trying to tell me something I've already more or less stated.
But you have to know *WHAT* to cache. Will I watch Family Guy tonight? Or will I watch American Dad? Or maybe something else entirely? Hell, I might watch anything from the Netflix catalog, so I guess I need to cache all of it. You're totally missing the boat when Netflix is willing and able to colocate their hardware in ISP datacenters and, even in some cases, willing to pay to be allowed to do so; and we're talking about hardware that caches 100% of their catalog. You also fail to address streaming devices which have no local storage (and, therefore, no means by which to cache anything). You're also glossing over the fact that, with an end-user-side cache, each video being cached (whether it's ever watched or not) is yet more data being pushed through external links, which cost both Netflix and the ISP more money, while a colo solution means pushing each piece of content through those links exactly once, after which it's in the ISP-local cache and only has to traverse the ISP's "only as congested as we allow it to be" network.
Seriously, give this a bit of thought before you start mashing keys.
And how, exactly, would implementing an end-user-side cache make things any better? All of that data would have to traverse the ISP network still; in fact, in order to address the issues caused by congestion (e.g. frequent pauses and breaks in the video stream), *more* data would have to traverse the ISP network, in order fo that data to already be in the user's cache before they requested it; since we can't know what the user is going to request before they do so, we have to send a little bit of everything. Were you planning on increasing the system requirements for using Netflix to gigabytes or terrabytes of disk space? And what about streaming devices that don't have local storage at all?
Methinks your solution wasn't very well thought out, my friend.
It's not even a matter of Comcast not investing in their infrastructure; they actively degraded their links to L3 when Netflix was refusing to pony up the dough. I'm pretty sure they had to pay people to do that, so it's more like they actively invested in degrading their network.
Agreed. Between two intermediary providers I could see this, but when it is your end user directly requesting the traffic, there is nothing but upside in allowing them to do so, and as quickly as you possibly can. Happy customers stick around through bigger rate hikes, after all.
There's nothing wrong with Netflix, Hulu, Google, or anyone else for that matter, going directly to an ISP and saying "Here's some equipment; if you install it, your users will be able to get our content, which is a big reason they pay you, faster." There is, likewise, nothing wrong with the ISP saying "Sure, let's get that equipment installed. It's gonna cost you $10,000.00/mo to use our facilities and backbone." And, there's nothing wrong with the two parties agreeing to, and implementing that. What's wrong is the ISP moving the intermediary providers (e.g. the backbones) between them and the provider wishing to install their equipment onto slower links until the provider agrees to pay the fee (at which point, the intermediary becomes irrelevant and probably remains on the degraded link), thereby degrading service for everybody. Especially when there is a peering agreement between the ISP and the intermediary provider and/or the intermediary is willing (and even asking or begging) to pay for the link they were on before.
And if you think that's not exactly what happened, please, explain this.
Slashdot Mirror
It wasn't too bad if you have a horizontal scrollwheel or a touch screen. What MS could have done to make it a bit better is to allow the standard vertical scrollwheel most mice come with nowadays to scroll the start screen; down = right, up = left (because you always started at the TOP of the start menu, naturally you'd scroll DOWN for more, while the start screen starts at the LEFT, requiring you to scroll RIGHT for more). That would have added immensely to the intuitiveness of the interface and made it much less of a bear to use on non-touch interfaces.
To be clear, I have with a Windows tablet and a touch-enabled Windows laptop and I don't mind the interface on either; but I absolutely abhor it on non-touch equipment.
You'd be surprised how many can't... Have you ever had to support them? Yes, people need hand-holding level support for their iPads and Androids and you're naive if you think they don't. And if you think a car is supposed to be used until it dies, with no maintenance or upkeep (like a TV, stereo, microwave, or tablet), I need to know what roads you commonly drive on so I can avoid them.
If you can't use and maintain it properly and safely (knowing when it needs service and being able to take it to someone who *can* service it if you can't *does* count), then you shouldn't be using it, whether "it" is a car, a computer, a gun, or really anything else... Insisting upon doing so anyway only serves to endanger yourself and those around you and is both selfish and (potentially criminally) irresponsible. If you don't want the expense of paying someone to maintain your things for you, you learn how to maintain them yourself; then you don't have the expense of paying someone to do it for you -- but you have a choice: Learn to maintain it, ay to maintain it, or simply don't use it. There's a fourth option, which is "use it anyway", the irresponsible and often dangerous option, which the raging idiot masses often opt for out of ignorance, then complain (and try and blame someone else) when shit goes south. I've said it a couple different ways now, so hopefully you get it.
Just like the other commenter who said this, you're wrong. Just like the iPad, the iPhone runs iOS, which is based on a BSD kernel similar to the one OSX is layered on top of. But, aside from that, and being made by Apple, there really aren't many other similarities; for example, I can't install any of the OSX software on my Mac onto my iPad and, without an emulator, can't run iOS software on my Mac.
So, again, which Mac comes with a touch screen?
That'd be an issue for your insurance to remedy after the fact.
Big Brother would also have to deal with citizens com
Wait... where am I? How did I get in this cell? Nevermind, you can't hear me through this gag. Damn.
Osama Bin Hacken
You, sir, fail to recognize the difference between a house and a mailbox. Once you understand the difference, you'll see why the analogy fails.
Yes, in the case of Gmail, the property in which the letter is stored (your inbox) is owned by the deliveryman, who does have legal access to that inbox. That's the difference.
Not that they should be allowed to; and it seems they know this, which is why they're insisting upon a court order.
More like :
> I've shared you bolding the text "I want you soooooo bad right now, Kevin." with your wife. Would you like to share this activity publicly?
OSX? Touch-based desktop? Which Mac comes with a touch screen?
What's the miss rate on an ISP-side cache of the entire Netflix library? I'm guessing it's 0 or some such, since it's oh, uh... the entire library? And you, like everyone else, are still failing to address streaming devices, which have no local storage and, therefore, can't cache gigabytes or terabytes of data (so that'd be what, a 100% miss rate?); and ISP-side cache covers these, as well.
Yes, keeping the cache as close to its point of use as possible is ideal. For the devices most people are streaming to, that's the ISP. Yes, Netflix could sell a cache device their users could install on their networks, but that incurs support costs for millions of users, many, if not most, of whom wouldn't have the first clue how to plug in a network cable, so no, it's not a viable solution, where an ISP-side cache is not only a viable solution, it's one Netflix has been working with ISPs to implement for a while now; Comcast, Verizon, and AT&T are really the only ones refusing to accept the free equipment at this point.
For several months, Netflix offered Comcast the hardware (and support for such) for ISP-side caching, for free, and Comcast's response was to demand payment from Netflix in order to host these servers that work to save Comcast money, then, when Netflix didn't cave, move Level3's (Netflix's provider) peering to lower quality interfaces until they agreed to pay.
Furthermore, how, exactly, would a customer cache work in the way you are describing when the most popular package Comcast sells is barely capable of streaming a single HD stream from Netflix while browsing the web and has about 1/10 as much upstream as it does downstream? How is the second user going to stream from the first when the first, even under ideal conditions, can only provide 1/10 of the required throughput? And Netflix caching servers? You realize that Netflix has a CDN, right? If your ISP doesn't have a local Netflix cache (again, Netflix will provide the hardware and support for free), then you're hitting the Netflix CDN, which will have a node near you. Of course, that node sits on the other side of a backbone provider that your ISP can throttle if they want to extort money from Netflix. That's why both of those solutions fail hard.
Precisely. The entire concept of an end-user-side cache of a several-petabyte library relies on knowing in advance exactly which part(s) of that library the user will want, far enough in advance to cache them, while requiring the user to have available storage for the cache. Since, by definition, streaming services are on-demand, there is no way to know this in advance, so even more storage is required. And still, nobody has addressed the issue of streaming devices (perhaps because those who might be able to address it don't know them by that term -- not likely, but hey -- I'm talking about AppleTV and the like) which have no local storage for such a cache.
I get this, my non-techie wife gets this, my project manager gets this, you seem to get this; why does it seem that nobody else does?
That's precisely one of the points I was trying to make. Thank you for making it more succinctly than I did; I only wish you had replied to GP so they'd be more likely to actually read it.
That is exactly the "fast lane" concept, where you are paying Netflix to pay Comcast ...
No, paying the USPS *at all* to deliver to China is akin to me paying Netflix to pay Comcast. Paying the USPS *more* to deliver faster is akin to... what, exactly, in this case? There's no analogue.
Furthermore, "Postage Due" has no analogue here, and is, as I said previously, therefore irrelevant to this discussion; Comcast is delivering the packets, just more slowly, whereas USPS will simply hold a "Postage Due" package until that postage has been paid, or will return it to the sender. You also failed to point out how COD, which you mentioned previously, is relevant, most probably because you realized it's actually not.
The whole "I pay for my post office box" analogy falls apart when you realize that Comcast is actually delaying packets based on their point of origin, rather than which of their peers passed them along. The analog for that would be USPS delaying packages shipped by you, but only if you shipped them via FedEx using SmartPost (google it if you're not familiar) because, even though FedEx is paying them to carry the package for the last leg of the delivery, because you aren't also paying them. This would land the USPS in hot water, as well, which is why people seem to have a problem when Comcast does it.
UPS' service is irrelevant because it cones down to the recipient redirecting the delivery, something the sender has no control over. Keep trying to muddy the waters, though; you ought to be able to get something to stick eventually, right? And the discussion about pricing? Really? I guess, if you really want me to agree with you on something, I'll give you that; not as though I'm conceding on any point I was actually arguing, though.
I pay USPS; if some of what I pay USPS is passed off, by them, to China Post, that is inconsequential to me. Paying extra for special delivery options is an interesting point I hadn't thought of previously; that being said, there is no analogy for that here, as there is no means by which to pay a provider extra to make them maky your ISP deliver the packets faster; you pay your ISP extra for that. As for COD/Postage Due, that's a specific shipping option that some carriers make available to the sender, which, again, has no analogue here. If I'm missing something, please correct me, but I won't hold my breath.
Indeed. Are you trying to educate me, or the other readers here? I ask because it sure seems like you're trying to tell me something I've already more or less stated.
But you have to know *WHAT* to cache. Will I watch Family Guy tonight? Or will I watch American Dad? Or maybe something else entirely? Hell, I might watch anything from the Netflix catalog, so I guess I need to cache all of it. You're totally missing the boat when Netflix is willing and able to colocate their hardware in ISP datacenters and, even in some cases, willing to pay to be allowed to do so; and we're talking about hardware that caches 100% of their catalog. You also fail to address streaming devices which have no local storage (and, therefore, no means by which to cache anything). You're also glossing over the fact that, with an end-user-side cache, each video being cached (whether it's ever watched or not) is yet more data being pushed through external links, which cost both Netflix and the ISP more money, while a colo solution means pushing each piece of content through those links exactly once, after which it's in the ISP-local cache and only has to traverse the ISP's "only as congested as we allow it to be" network.
Seriously, give this a bit of thought before you start mashing keys.
And how, exactly, would implementing an end-user-side cache make things any better? All of that data would have to traverse the ISP network still; in fact, in order to address the issues caused by congestion (e.g. frequent pauses and breaks in the video stream), *more* data would have to traverse the ISP network, in order fo that data to already be in the user's cache before they requested it; since we can't know what the user is going to request before they do so, we have to send a little bit of everything. Were you planning on increasing the system requirements for using Netflix to gigabytes or terrabytes of disk space? And what about streaming devices that don't have local storage at all?
Methinks your solution wasn't very well thought out, my friend.
I think your ISP dropped the packet between "can" and "even".
It's not even a matter of Comcast not investing in their infrastructure; they actively degraded their links to L3 when Netflix was refusing to pony up the dough. I'm pretty sure they had to pay people to do that, so it's more like they actively invested in degrading their network.
Agreed. Between two intermediary providers I could see this, but when it is your end user directly requesting the traffic, there is nothing but upside in allowing them to do so, and as quickly as you possibly can. Happy customers stick around through bigger rate hikes, after all.
There's nothing wrong with Netflix, Hulu, Google, or anyone else for that matter, going directly to an ISP and saying "Here's some equipment; if you install it, your users will be able to get our content, which is a big reason they pay you, faster." There is, likewise, nothing wrong with the ISP saying "Sure, let's get that equipment installed. It's gonna cost you $10,000.00/mo to use our facilities and backbone." And, there's nothing wrong with the two parties agreeing to, and implementing that. What's wrong is the ISP moving the intermediary providers (e.g. the backbones) between them and the provider wishing to install their equipment onto slower links until the provider agrees to pay the fee (at which point, the intermediary becomes irrelevant and probably remains on the degraded link), thereby degrading service for everybody. Especially when there is a peering agreement between the ISP and the intermediary provider and/or the intermediary is willing (and even asking or begging) to pay for the link they were on before.
And if you think that's not exactly what happened, please, explain this.
I made it work, actually...