I do agree that it's not a good idea to create a bad grammatical construction to avoid it. I don't agree with some of the article's examples. In particular, the one where they moved "with" to the end of a sentence actually made it less understandable because the word was so far away from the word "whom".
Often, when you find a preposition at the end of the sentence, it means that the sentence would benefit from a complete rewrite anyway. For example, the classic quote often attributed to Churchill, "That is something up with which we shall not put" could be better written as "That is something we shall not tolerate." The idiom "put up with" is expected to be followed by an article and then a noun, not to be the last thing in a sentence.
In the majority of cases where people think a sentence sounds better with a preposition at the end, there are better word choices that completely avoid the problem. It is certainly true of every example in that article. In order:
"If we already know about a problem, you do not need to notify us about it again."
"Officials in Iraq have still not decided who his contact will be." The original sentence ("with whom") is also okay. I'd also accept, "Although he will meet with an Iraqi official, the Iraqi government has not yet decided which one." This also has the advantage of better conveying the level of dysfunction involved in a situation that would lead itself to such a sentence.:-)
"A verbal still retains some of the properties of the original verb."
Sorry to tell you, lexidation, but you're full of s***. Although violent crime occurs everywhere on occasion, the overwhelming majority of violent crime in America occurs in cities. In spite of this, Americans feel threatened by crime even if they live in the middle of nowhere. There are no serial rapists haunting the suburbs, so sane people should not feel compelled to pack a firearm in self-defense. And unless you are dealing drugs or walking around in gang colors, there is usually no danger in any city—even large cities, as long as you don't count Central Park. America is a culture of paranoia and fear, pure and simple.
"Think of the children" and the "War on Terrah" are rallying cries that politicians use to scare the public into allowing an ever-increasing police state with fewer and fewer individual rights, and as they do, Americans become more and more afraid that the person next door might be a pedophile or a rapist or a killer or a terrorist. This is compounded by well-meaning people who drum into our children from a young age that they should never talk to strangers, that drum into college girls that they will probably be raped, etc. And the result is that everybody is afraid of bad things happening to them even though that fear is almost entirely irrational paranoid delusion brought on mostly by overexposure to people who deliberately inflate minor nuisances into credible threats to improve their chances of reelection.
I've seen this bug, too, with the build-and-analyze stuff. I think the bug that mine was a dup of has been fixed already, so your problem might just go away in the Xcode build that came with this SDK beta.
If it's still there, go back to your bugs and if you haven't already, attach a test project that reproduces the bug along with detailed steps to reproduce. That tends to make these sorts of problems a lot easier to find and fix. If it hasn't been fixed by now, that probably means that it only reproduces with certain project settings or structure, so without attaching a test project, you might be waiting a long time for them to find and fix the bug.:-)
At least in my case, I found that there are two ways to get lists of errors, and that when the error messages are displayed in the leftmost column, they don't jump to the right line in the file, but when they are displayed in the next column over, they do. Dig around and see if you can find another view that displays those same errors. If you can, I'd imagine you'll find that it will work.
People probably on average buy a new TV (even Apple fans) every 3-4 years--if that.
With the exception of disruptive changes like the HDTV transition, It's almost unheard of to upgrade a TV before it breaks, which basically means that TVs get bought when people want to add a set. TVs are major appliances, not consumer electronics, and they follow the same replacement schedule as appliances. So if a TV is replaced in fewer than twenty years, that's unusual. Then again, if people have three TVs per household (on average), that means one dies every six or seven years. So you're probably in the right ballpark, albeit a bit on the low side.
I doubt it. I suspect there will, for at least another decade, be at least some subset of the TVs out there that provide analog composite video (and perhaps S-Video) inputs, if only because AFAIK there are no consumer-priced devices for converting from an analog input to a digital input, and people still own VCRs and older DVD players that they expect to be able to use with their new TVs. It's much, much cheaper to build that into the TV set to begin with. It's somewhat surprising to me that you have a set with component and no composite. Once you have enough analog electronics to do component video, I'd expect the extra hardware required for composite video to be minimal.... *shrugs*
As for VGA, I'm surprised anybody ever put VGA connectors on TVs. With the exception of netbooks, VGA has been disappearing as an output format for at least five or six years, and it has never been particularly popular to connect computers to TV sets, with the possible exception of small sets in somebody's dorm room. It will probably hang around on monitors for at least five or six more years, but I'd expect it to go away on TVs because it never made sense to have it there in the first place.
Well, my actual website's SSL cert expires two weeks from today. They have not emailed me as of today. And StartSSL is down, and this new site isn't up yet. I'm certainly not looking forward to paying money to any of the dirtbag SSL providers I've dealt with in the past....
The coverage maps aren't lies. They're just useless because they don't provide nearly high enough granularity, don't account for variations in handsets, and don't take into account whether you are in a building or not.
Odds are good that in most of the places where they claim to have a signal, you can get a signal, so long as you have a good handset and are outdoors. The problem is that with a typical handset, indoors, you can't. Sure, the wall is only... say an 8dB difference, and the handset is just another 12 dB on top of that, but when your signal is dodgy to begin with, that's more than enough.
The only way to get a really good idea of the cellular phone signal in a particular area is to drive around and plot signal strengths all around the area under various weather conditions and at various times of day. This is not an easily solved problem. If it were, you'd already have the data.:-) That said, if your particular area is covered by it, the CNET/Root Metrics coverage map is generally a good approximation of reality, from what I've seen.
FBI does not know who is doing what, or which servers host which data. They are not going to send a letter looking for the hosted clients' data, since the host could be the one with the website they are after.
A modicum of common sense comes into play here. 99.999% of the time, a hosting provider is just that. We really shouldn't have millions of dollars in collateral damage every few weeks just for an edge case of an edge case. We should have a different warrant process for cases where the police suspect that the hosting provider isn't a legitimate business, and there should be liability involved if you abuse that process for a provider that obviously is legitimate.
Look for one that specifically can restore within a reasonable timeframe from offsite backup, or hosts in multiple companies.
Another poster made a comment that pretty much covers this. It went something like this: "Oh, look. The hosting provider keeps backups offsite. We'd better simultaneously raid the data warehouse because that might be evidence, too."
You can't win. The only winning move is not to play. This means either A. host everything yourself, B. massively overpay to design a replicated hosting system from two different hosting providers, or C. force the FBI to use some common sense. We're not talking about Fortune 500 companies here. These are small firms that can't afford the sort of replicated hosting that would be required to protect against this sort of event.
Does that mean that equal protection under the law and the right to be secure against unwarranted searches and seizures should apply only to people and companies with enough money to secure themselves? Because that's really the only way to interpret your suggestion, and it's not consistent with the Constitution that I grew up believing in.
You have a warrant to sieze information, then you don't know what information to request specifically (racks 1-2 out of 4 is not something you can know in advance).
Again, you know who the client is. You already had to determine which server(s) the user's data was on (and trust that the hosting provider gave you the true information) because no judge is going to give you a warrant to seize the entire data center, and if you try it anyway, you're committing grand larceny. How much of a stretch is it, then, to require that they take that one extra step to seize an account instead of an entire box? This isn't about rules of evidence or any such bullshit. This is about not having the proper training, not understanding the collateral damage that they can cause, and gross criminal negligence in data acquisition. Nothing more, nothing less.
Yeah, because you didn't go to a neutral magistrate and get a search warrant based on a sworn affidavit.
Even if I have appropriate legal authority to repossess a car, I can still be held criminally liable if I do so with someone's child in the back seat. This is basically the equivalent, only with several thousand people's children in the back seat.
Evidence in criminal investigations does not need to be seized voluntarily, that's the entire point of a warrant. What's more, your proposed scheme puts them at the mercy of a hosting company that might be conspiring with the suspects. There's no reason to trust the hosting company not to wipe the actual customer disks and give you some random junk instead.
This is why the FBI agents involved should be proper computer specialists who are trained in how to clone the data, and should perform the cloning themselves. What you're giving isn't an argument. It's an excuse for lack of training.
No, they can't. That's the whole point. As soon as you "grab" a system, you're taking down tens or even hundreds of different websites, each of which is a separate commercial company, each of which has the potential to lose significant business as a result. It is the equivalent of closing and seizing a shopping mall because some drug dealer is selling drugs in the parking lot. Property seizure is utterly ridiculous in this case, and whether they return it intact after a week or not is really not relevant.
And if we're talking about a colossal setup with distributed virtual data volumes spread across multiple boxes, physically seizing the data might be closer to bombing an entire city because of one drug dealer who sold drugs in the parking lot last week.
There is simply no way to "grab" a server that does not cause huge amounts of collateral damage to large numbers of other people/companies. It is simply not possible to do so. Therefore, locking out that customer and cloning the system in place (including that customer's data and any unallocated blocks that might have previously belonged to the customer, but not including anyone else's data files) is the only legitimate solution to the problem. Period. Anything more than that cannot be done without collateral damage, and the FBI should be liable for any collateral damage that they cause.
I think it's time to hold the FBI to the same standards that they would hold the rest of us. If I went in waving a gun around and demanding to walk away with somebody else's server, they'd throw my ass in jail.
If they want access to a particular client's content, they can go through the same process as a DMCA takedown request or a backup request would. They make a request, the company yanks that customer's access, then clones that customer's data onto a new drive, then hands them the drive.
As far as I'm concerned, every single client of this ISP ought to sue the FBI for the damage they caused—for the downtime, for the loss of data, for the time spent trying to reach the ISP to figure out what was going on, for the cost of any failover hardware or service that they had to pay for in lieu of that service, etc. If the FBI had to pay out a few million dollar settlements every time they pulled a stunt like this, they'd think twice about acting like a bunch of thugs, and they would go through proper channels and do their investigation in a way that doesn't cause collateral damage.
There's simply no excuse for such sloppy investigative work. If they screwed up so royally with the servers, you have to wonder how many grievous errors they made in other areas that would lead to the evidence being declared tainted, criminals going free, etc.
No, the complaint is that it is supposed to be a benchmark of overall system performance, and that benchmarking just the GPU does not do this. For example, in running a typical OS, a lot of the screen redrawing performance is dependent on the GPU if the GPU can handle it. If the GPU can't, a lot of that work gets offloaded onto the CPU, and performance suffers. Thus, by benchmarking only the CPU, you cannot get an accurate picture of the real-world performance of the system as a whole, or even of the processing capabilities of the system as a whole.
True, to some extent, one might argue that it is a contract of adhesion, and thus not necessarily enforceable, but that doesn't make it inherently not a contract, unless by "not a contract", you really mean "not necessarily a binding contract". And truthfully, that's true even for contracts that are negotiated and signed. If you realize later that certain terms are illegal, the courts can invalidate them. In other words, software licenses are really no different than any other contract.
According to the page in question, the test methodology is:
1. Connect with RFC 5746. Upon success, mark as "Good".
2. If the connection fails, the site is not patched. Send a request "HEAD / HTTP/1.1" without using RFC 5746, and save the response for later comparison.
3. Run the actual test. This basically does the following:
Connect.
Send part of the request.
Renegotiate.
Send the rest of the request
Check to see if the status code matches the status code from step 2.
If a site has been updated with a partial hotfix, it should either disconnect or sent an HTTP status code in the 400s. These sites are flagged as "Uncertain" because the server might initiate a renegotiation. If the site sends data after the second handshake and the response code is the same as the response code from step #2, it is marked as BAD.
The competent IT guy would say, "Okay. Let's take one machine temporarily off of the load balancer's list. Patch that one up. We'll reintroduce it into the farm when you're done. If there are no problems with it, we'll update the remaining machines a few at a time."
Don't get me wrong, that doesn't always work. For example, it's a lot harder if you're trying to introduce changes that affect the actual client content (e.g. JavaScript fixes). For everything else, there's MasterCard... or something....
Well, we've done pretty well at maintaining freight lines, for the most part. The big problem is that the passenger rail services haven't brought in enough income to warrant having separate rails, so they are forced to depend on freight lines. This brings with it all the delays that inherently accompany the use of freight rails due to track maintenance, other trains using the tracks, etc.
And, of course, freight doesn't require comfort, so those tracks are maintained to a lower degree of consistency than passenger rails should be. Also, freight cars can be significantly heavier than passenger cars, and thus cause a lot more compaction of the material underneath. This means that the rails are a much rougher ride than would be acceptable for high speed rail.
So the answer is probably yes, but only if those tracks are used exclusively for high speed passenger rail, and only if they are constructed properly to begin with. It would also help if passenger rail cars didn't weigh about 2.5 times as much per passenger as a small automobile.... (Think carbon fiber and aluminum instead of steel.)
Example blue rays: 2001 is encoded at 13.39Mbps. 300 - 16.80Mbps. Batman Begins - 13.70. Blade Runner - 16.87. Blood Diamond - 12.71. The Chronicles of Riddick - 14.01. Constantine - 11.88. Superman Returns - 14.82.
Every single example in your list is an older title that was originally mastered for HD-DVD, which had a cap of 25 GB. The studios generally did not remaster those titles when they went to Blu-Ray. Please list some more recent titles.
Yes, but you're talking about 720p, which is a lot less data than the 1080i that I was specifically referring to. 1080i has 2.25 times as many pixels. Remember, I was talking about what would be needed to stream Blu-Ray-quality 1080i, not 720p. If we assume that 4-6 Mbps is acceptable quality for 720p HD content (and I'm not conceding that point, but merely assuming it for comparison purposes), then a comparable 1080i stream with similar levels of content would be expected to take at least 9 megabits per second, which means a 250 GB cap gives you almost exactly one movie view per night, assuming you are doing nothing else with the connection at all. And it's still somewhere between a third and half of typical Blu-Ray data rates.
Either way, my point was not that you can't stream usable video with lower data rates. For some definitions of usable, you could stream 1 Mbps SD video. My point was that Blu-Ray's only reason for even existing is that network providers aren't willing to provide the bandwidth needed for Blu-Ray-quality high definition video over the Internet, and that streaming HD video is at a lower resolution and is encoded at a data rate that is fully an order of magnitude lower than Blu-Ray quality, despite using largely the same codecs. And, more importantly, we're never going to get to Blu-Ray quality over the Internet if we allow telcos to cap our data rates arbitrarily.
As for the GOP sizes, you're right, but I would argue that increasing the GOP size arbitrarily is not a panacea. With fast-moving video, by the end of a short GOP, you've likely diverged substantially from the original frame, and at some point, you've basically replaced all the original image data anyway. Thus, you're probably not saving that much data rate because the deltas are so large. And for slow-moving video, you have the full size of a DVD or Blu-Ray to work with, so there's no real advantage to not using that space. Sure, for streaming over a network, it's a laudable goal, but heaven help us all if consumers start thinking to themselves, "I could watch the new Sci-Fi movie, but that would use as much bandwidth as three romantic comedy retreads," for this would truly be the end of civilization as we know it. Just saying.
Oh, and larger GOPs tend to reduce usability of computer-based players, too, in my experience, so there's a very real tradeoff to doing what you suggest.
See, I would refer to having any visually noticeable artifacts on moving shots as "crap". You could stream the same data rate with standard def content, scale it up, and nobody would notice the difference in resolution, but they will notice the artifacts.
No, it really doesn't make sense. When pay-as-you-go causes users to start being concerned about how much bandwidth they use, this means that Internet services can no longer usefully improve in any way that would required more bandwidth. Imagine if every Internet user had been capped at typical usage fifteen or sixteen years ago (when 33.6kbps was the hot new thing). We'd have no YouTube, no iTunes or Amazon or Netflix movie services, no Skype or iChat AV or FaceTime, no RapidShare (okay, well, maybe it wouldn't be all bad).... You get the idea.
Who knows when the next cool innovation will happen? One thing is for sure, statistically, it will be an even greater bandwidth pig than those services listed above. It's like the old saying about CPU speed—Andy Grove giveth, Bill Gates taketh away.
The absolute last thing you want, assuming you aren't in favor of utter stagnation, is for Internet users to be spending any significant amount of effort worrying about whether they're going to use too much bandwidth and get spanked with a huge overage bill. It's disgusting the way the telcos abuse their customers, and they'll keep doing it until we as a society push back and say, "No more." Charging by usage made sense in the line-switching world of 1960s telecommunications. In a packet-switched world, it's outright highway robbery, and utterly absurd.
And then, because 95% of people chose the $50 microwaves, the $150 microwave market becomes unsustainable at that price, so they become $500 microwaves, then $1,000 microwaves, and eventually disappear from the market entirely, leaving nothing but the junk available for purchase. And this is why the consumer electronics market is in large part a race to the bottom, both in price and in quality.
Slashdot Mirror
I do agree that it's not a good idea to create a bad grammatical construction to avoid it. I don't agree with some of the article's examples. In particular, the one where they moved "with" to the end of a sentence actually made it less understandable because the word was so far away from the word "whom".
Often, when you find a preposition at the end of the sentence, it means that the sentence would benefit from a complete rewrite anyway. For example, the classic quote often attributed to Churchill, "That is something up with which we shall not put" could be better written as "That is something we shall not tolerate." The idiom "put up with" is expected to be followed by an article and then a noun, not to be the last thing in a sentence.
In the majority of cases where people think a sentence sounds better with a preposition at the end, there are better word choices that completely avoid the problem. It is certainly true of every example in that article. In order:
"If we already know about a problem, you do not need to notify us about it again."
"Officials in Iraq have still not decided who his contact will be." The original sentence ("with whom") is also okay. I'd also accept, "Although he will meet with an Iraqi official, the Iraqi government has not yet decided which one." This also has the advantage of better conveying the level of dysfunction involved in a situation that would lead itself to such a sentence. :-)
"A verbal still retains some of the properties of the original verb."
And so on.
Sorry to tell you, lexidation, but you're full of s***. Although violent crime occurs everywhere on occasion, the overwhelming majority of violent crime in America occurs in cities. In spite of this, Americans feel threatened by crime even if they live in the middle of nowhere. There are no serial rapists haunting the suburbs, so sane people should not feel compelled to pack a firearm in self-defense. And unless you are dealing drugs or walking around in gang colors, there is usually no danger in any city—even large cities, as long as you don't count Central Park. America is a culture of paranoia and fear, pure and simple.
"Think of the children" and the "War on Terrah" are rallying cries that politicians use to scare the public into allowing an ever-increasing police state with fewer and fewer individual rights, and as they do, Americans become more and more afraid that the person next door might be a pedophile or a rapist or a killer or a terrorist. This is compounded by well-meaning people who drum into our children from a young age that they should never talk to strangers, that drum into college girls that they will probably be raped, etc. And the result is that everybody is afraid of bad things happening to them even though that fear is almost entirely irrational paranoid delusion brought on mostly by overexposure to people who deliberately inflate minor nuisances into credible threats to improve their chances of reelection.
I've seen this bug, too, with the build-and-analyze stuff. I think the bug that mine was a dup of has been fixed already, so your problem might just go away in the Xcode build that came with this SDK beta.
If it's still there, go back to your bugs and if you haven't already, attach a test project that reproduces the bug along with detailed steps to reproduce. That tends to make these sorts of problems a lot easier to find and fix. If it hasn't been fixed by now, that probably means that it only reproduces with certain project settings or structure, so without attaching a test project, you might be waiting a long time for them to find and fix the bug. :-)
At least in my case, I found that there are two ways to get lists of errors, and that when the error messages are displayed in the leftmost column, they don't jump to the right line in the file, but when they are displayed in the next column over, they do. Dig around and see if you can find another view that displays those same errors. If you can, I'd imagine you'll find that it will work.
Which just means that nobody ever told them not to end a sentence with a preposition....
With the exception of disruptive changes like the HDTV transition, It's almost unheard of to upgrade a TV before it breaks, which basically means that TVs get bought when people want to add a set. TVs are major appliances, not consumer electronics, and they follow the same replacement schedule as appliances. So if a TV is replaced in fewer than twenty years, that's unusual. Then again, if people have three TVs per household (on average), that means one dies every six or seven years. So you're probably in the right ballpark, albeit a bit on the low side.
I doubt it. I suspect there will, for at least another decade, be at least some subset of the TVs out there that provide analog composite video (and perhaps S-Video) inputs, if only because AFAIK there are no consumer-priced devices for converting from an analog input to a digital input, and people still own VCRs and older DVD players that they expect to be able to use with their new TVs. It's much, much cheaper to build that into the TV set to begin with. It's somewhat surprising to me that you have a set with component and no composite. Once you have enough analog electronics to do component video, I'd expect the extra hardware required for composite video to be minimal.... *shrugs*
As for VGA, I'm surprised anybody ever put VGA connectors on TVs. With the exception of netbooks, VGA has been disappearing as an output format for at least five or six years, and it has never been particularly popular to connect computers to TV sets, with the possible exception of small sets in somebody's dorm room. It will probably hang around on monitors for at least five or six more years, but I'd expect it to go away on TVs because it never made sense to have it there in the first place.
Well, my actual website's SSL cert expires two weeks from today. They have not emailed me as of today. And StartSSL is down, and this new site isn't up yet. I'm certainly not looking forward to paying money to any of the dirtbag SSL providers I've dealt with in the past....
The coverage maps aren't lies. They're just useless because they don't provide nearly high enough granularity, don't account for variations in handsets, and don't take into account whether you are in a building or not.
Odds are good that in most of the places where they claim to have a signal, you can get a signal, so long as you have a good handset and are outdoors. The problem is that with a typical handset, indoors, you can't. Sure, the wall is only... say an 8dB difference, and the handset is just another 12 dB on top of that, but when your signal is dodgy to begin with, that's more than enough.
The only way to get a really good idea of the cellular phone signal in a particular area is to drive around and plot signal strengths all around the area under various weather conditions and at various times of day. This is not an easily solved problem. If it were, you'd already have the data. :-) That said, if your particular area is covered by it, the CNET/Root Metrics coverage map is generally a good approximation of reality, from what I've seen.
A modicum of common sense comes into play here. 99.999% of the time, a hosting provider is just that. We really shouldn't have millions of dollars in collateral damage every few weeks just for an edge case of an edge case. We should have a different warrant process for cases where the police suspect that the hosting provider isn't a legitimate business, and there should be liability involved if you abuse that process for a provider that obviously is legitimate.
Another poster made a comment that pretty much covers this. It went something like this: "Oh, look. The hosting provider keeps backups offsite. We'd better simultaneously raid the data warehouse because that might be evidence, too."
You can't win. The only winning move is not to play. This means either A. host everything yourself, B. massively overpay to design a replicated hosting system from two different hosting providers, or C. force the FBI to use some common sense. We're not talking about Fortune 500 companies here. These are small firms that can't afford the sort of replicated hosting that would be required to protect against this sort of event.
Does that mean that equal protection under the law and the right to be secure against unwarranted searches and seizures should apply only to people and companies with enough money to secure themselves? Because that's really the only way to interpret your suggestion, and it's not consistent with the Constitution that I grew up believing in.
Again, you know who the client is. You already had to determine which server(s) the user's data was on (and trust that the hosting provider gave you the true information) because no judge is going to give you a warrant to seize the entire data center, and if you try it anyway, you're committing grand larceny. How much of a stretch is it, then, to require that they take that one extra step to seize an account instead of an entire box? This isn't about rules of evidence or any such bullshit. This is about not having the proper training, not understanding the collateral damage that they can cause, and gross criminal negligence in data acquisition. Nothing more, nothing less.
Even if I have appropriate legal authority to repossess a car, I can still be held criminally liable if I do so with someone's child in the back seat. This is basically the equivalent, only with several thousand people's children in the back seat.
This is why the FBI agents involved should be proper computer specialists who are trained in how to clone the data, and should perform the cloning themselves. What you're giving isn't an argument. It's an excuse for lack of training.
No, they can't. That's the whole point. As soon as you "grab" a system, you're taking down tens or even hundreds of different websites, each of which is a separate commercial company, each of which has the potential to lose significant business as a result. It is the equivalent of closing and seizing a shopping mall because some drug dealer is selling drugs in the parking lot. Property seizure is utterly ridiculous in this case, and whether they return it intact after a week or not is really not relevant.
And if we're talking about a colossal setup with distributed virtual data volumes spread across multiple boxes, physically seizing the data might be closer to bombing an entire city because of one drug dealer who sold drugs in the parking lot last week.
There is simply no way to "grab" a server that does not cause huge amounts of collateral damage to large numbers of other people/companies. It is simply not possible to do so. Therefore, locking out that customer and cloning the system in place (including that customer's data and any unallocated blocks that might have previously belonged to the customer, but not including anyone else's data files) is the only legitimate solution to the problem. Period. Anything more than that cannot be done without collateral damage, and the FBI should be liable for any collateral damage that they cause.
I think it's time to hold the FBI to the same standards that they would hold the rest of us. If I went in waving a gun around and demanding to walk away with somebody else's server, they'd throw my ass in jail.
If they want access to a particular client's content, they can go through the same process as a DMCA takedown request or a backup request would. They make a request, the company yanks that customer's access, then clones that customer's data onto a new drive, then hands them the drive.
As far as I'm concerned, every single client of this ISP ought to sue the FBI for the damage they caused—for the downtime, for the loss of data, for the time spent trying to reach the ISP to figure out what was going on, for the cost of any failover hardware or service that they had to pay for in lieu of that service, etc. If the FBI had to pay out a few million dollar settlements every time they pulled a stunt like this, they'd think twice about acting like a bunch of thugs, and they would go through proper channels and do their investigation in a way that doesn't cause collateral damage.
There's simply no excuse for such sloppy investigative work. If they screwed up so royally with the servers, you have to wonder how many grievous errors they made in other areas that would lead to the evidence being declared tainted, criminals going free, etc.
No, the complaint is that it is supposed to be a benchmark of overall system performance, and that benchmarking just the GPU does not do this. For example, in running a typical OS, a lot of the screen redrawing performance is dependent on the GPU if the GPU can handle it. If the GPU can't, a lot of that work gets offloaded onto the CPU, and performance suffers. Thus, by benchmarking only the CPU, you cannot get an accurate picture of the real-world performance of the system as a whole, or even of the processing capabilities of the system as a whole.
I know, but I thought it was worth putting that number into the proper perspective.
True, to some extent, one might argue that it is a contract of adhesion, and thus not necessarily enforceable, but that doesn't make it inherently not a contract, unless by "not a contract", you really mean "not necessarily a binding contract". And truthfully, that's true even for contracts that are negotiated and signed. If you realize later that certain terms are illegal, the courts can invalidate them. In other words, software licenses are really no different than any other contract.
On the flip side, at $0.50 per megabyte, the equivalent of the 2 GB AT&T iPhone plan would cost you a grand a month....
According to the page in question, the test methodology is:
1. Connect with RFC 5746. Upon success, mark as "Good".
2. If the connection fails, the site is not patched. Send a request "HEAD / HTTP/1.1" without using RFC 5746, and save the response for later comparison.
3. Run the actual test. This basically does the following:
If a site has been updated with a partial hotfix, it should either disconnect or sent an HTTP status code in the 400s. These sites are flagged as "Uncertain" because the server might initiate a renegotiation. If the site sends data after the second handshake and the response code is the same as the response code from step #2, it is marked as BAD.
Discuss.
The competent IT guy would say, "Okay. Let's take one machine temporarily off of the load balancer's list. Patch that one up. We'll reintroduce it into the farm when you're done. If there are no problems with it, we'll update the remaining machines a few at a time."
Don't get me wrong, that doesn't always work. For example, it's a lot harder if you're trying to introduce changes that affect the actual client content (e.g. JavaScript fixes). For everything else, there's MasterCard... or something....
Software licenses are generally governed by contract law, so I'm not quite clear on what difference you think exists.
Well, we've done pretty well at maintaining freight lines, for the most part. The big problem is that the passenger rail services haven't brought in enough income to warrant having separate rails, so they are forced to depend on freight lines. This brings with it all the delays that inherently accompany the use of freight rails due to track maintenance, other trains using the tracks, etc.
And, of course, freight doesn't require comfort, so those tracks are maintained to a lower degree of consistency than passenger rails should be. Also, freight cars can be significantly heavier than passenger cars, and thus cause a lot more compaction of the material underneath. This means that the rails are a much rougher ride than would be acceptable for high speed rail.
So the answer is probably yes, but only if those tracks are used exclusively for high speed passenger rail, and only if they are constructed properly to begin with. It would also help if passenger rail cars didn't weigh about 2.5 times as much per passenger as a small automobile.... (Think carbon fiber and aluminum instead of steel.)
Every single example in your list is an older title that was originally mastered for HD-DVD, which had a cap of 25 GB. The studios generally did not remaster those titles when they went to Blu-Ray. Please list some more recent titles.
Yes, but you're talking about 720p, which is a lot less data than the 1080i that I was specifically referring to. 1080i has 2.25 times as many pixels. Remember, I was talking about what would be needed to stream Blu-Ray-quality 1080i, not 720p. If we assume that 4-6 Mbps is acceptable quality for 720p HD content (and I'm not conceding that point, but merely assuming it for comparison purposes), then a comparable 1080i stream with similar levels of content would be expected to take at least 9 megabits per second, which means a 250 GB cap gives you almost exactly one movie view per night, assuming you are doing nothing else with the connection at all. And it's still somewhere between a third and half of typical Blu-Ray data rates.
Either way, my point was not that you can't stream usable video with lower data rates. For some definitions of usable, you could stream 1 Mbps SD video. My point was that Blu-Ray's only reason for even existing is that network providers aren't willing to provide the bandwidth needed for Blu-Ray-quality high definition video over the Internet, and that streaming HD video is at a lower resolution and is encoded at a data rate that is fully an order of magnitude lower than Blu-Ray quality, despite using largely the same codecs. And, more importantly, we're never going to get to Blu-Ray quality over the Internet if we allow telcos to cap our data rates arbitrarily.
As for the GOP sizes, you're right, but I would argue that increasing the GOP size arbitrarily is not a panacea. With fast-moving video, by the end of a short GOP, you've likely diverged substantially from the original frame, and at some point, you've basically replaced all the original image data anyway. Thus, you're probably not saving that much data rate because the deltas are so large. And for slow-moving video, you have the full size of a DVD or Blu-Ray to work with, so there's no real advantage to not using that space. Sure, for streaming over a network, it's a laudable goal, but heaven help us all if consumers start thinking to themselves, "I could watch the new Sci-Fi movie, but that would use as much bandwidth as three romantic comedy retreads," for this would truly be the end of civilization as we know it. Just saying.
Oh, and larger GOPs tend to reduce usability of computer-based players, too, in my experience, so there's a very real tradeoff to doing what you suggest.
See, I would refer to having any visually noticeable artifacts on moving shots as "crap". You could stream the same data rate with standard def content, scale it up, and nobody would notice the difference in resolution, but they will notice the artifacts.
No, it really doesn't make sense. When pay-as-you-go causes users to start being concerned about how much bandwidth they use, this means that Internet services can no longer usefully improve in any way that would required more bandwidth. Imagine if every Internet user had been capped at typical usage fifteen or sixteen years ago (when 33.6kbps was the hot new thing). We'd have no YouTube, no iTunes or Amazon or Netflix movie services, no Skype or iChat AV or FaceTime, no RapidShare (okay, well, maybe it wouldn't be all bad).... You get the idea.
Who knows when the next cool innovation will happen? One thing is for sure, statistically, it will be an even greater bandwidth pig than those services listed above. It's like the old saying about CPU speed—Andy Grove giveth, Bill Gates taketh away.
The absolute last thing you want, assuming you aren't in favor of utter stagnation, is for Internet users to be spending any significant amount of effort worrying about whether they're going to use too much bandwidth and get spanked with a huge overage bill. It's disgusting the way the telcos abuse their customers, and they'll keep doing it until we as a society push back and say, "No more." Charging by usage made sense in the line-switching world of 1960s telecommunications. In a packet-switched world, it's outright highway robbery, and utterly absurd.
And then, because 95% of people chose the $50 microwaves, the $150 microwave market becomes unsustainable at that price, so they become $500 microwaves, then $1,000 microwaves, and eventually disappear from the market entirely, leaving nothing but the junk available for purchase. And this is why the consumer electronics market is in large part a race to the bottom, both in price and in quality.