That comparison misses the point, though - for most people, the goal isn't to have as many channels available as possible, it's to have something to watch whenever you want to watch TV. I currently have around 100 TV channels (all free to air), but I'm not guaranteed to find something I want to watch when I choose to watch TV.
I used to pay to get around 300 channels, but stopped when I realised that I still wasn't able to find something I wanted to watch whenever I turned on the TV set, and that when I did find channels I wanted to watch, they tended to be from the free to air set anyway.
A simple question illustrates the point - would you prefer 5,000 nearly identical home shopping channels for the same money you pay now, or would you prefer your existing TV package? I suspect you'd find that most people would prefer your current TV package, with its mere 200 channels, to a package of 5,000 channels that they're mostly not interested in.
And that's where the debate lies. LightSquared's license permits them two uses of the frequencies licensed:
For satellite to earth communication, provided they ensure that the transmissions from the satellite do not leak out of their licensed bands.
As a later waiver, made after the spectrum was initially licensed: For earth to earth and earth to space communication, provided that they ensure that their earth-based transmitters do not interfere with earth-based receivers designed to pick up satellite to earth transmissions in neighbouring bands.
LightSquared's argument is that they have met the second term of their license if they ensure that their earth-based transmitters do not leak out of their licensed bands, even if they interfere with licensed users of neighbouring bands; note that the FCC has been clear that one way to meet the second requirement is to replace receivers of the neighbouring bands with ones that cope with your interference, an option LS has rejected as impractical, as they cannot find affordable receivers that have both the GPS abilities of the receivers they're replacing and better rejection of LS's signals.
I'm typing this on a Dell N-series laptop that came with Ubuntu pre-installed. I bought the most expensive Linux preloaded laptop Dell would sell me, complete with all the options they offered (including things like the insurance), partly to make the point to Dell that not everyone who buys a Linux preloaded machine is aiming to cheap out. I find it interesting that I cannot find numbers from Dell on how much they actually made (on a like-for-like) basis from the Ubuntu preloaded N series laptops as compared to the Windows laptops with the same hardware; I do wonder if they found that there is actually a niche market for them, in which they could make money, but chose to serve the bulk market instead.
It could, yes, but in both cases, you're likely to have more than just an allegation against an anonymous identifier; as soon as you can show the judge the outline of your future case against the identified individual, you've passed the bar he set.
Taking your examples in turn, in the telephone line subscriber case, you would be expected to show the judge some evidence that you were receiving silent or abusive calls (maybe a call recording, maybe a diary of the calls paired up with some records from your phone provider to show that those calls did actually happen, even if the content isn't as you state). You now have some evidence that your request isn't just a fishing expedition, and the subpoena process can continue.
In the car case, if you present a police record of your incident report, that's a good enough start to get you going - you've again demonstrated that there is more to your request than a simple fishing expedition.
In the case presented to the judge, there was no evidence of infringement that was of high enough standard to present in court, merely an allegation by the plaintiff; the judge basically told the plaintiff "come back with evidence, and then we'll talk".
I read the judgement - did you? In it, the judge makes it clear that the IP address and a naked assertion of infringement is not enough to get the subpoena; you need sufficient evidence to show the judge that you can tie the infringement to the IP address, and could continue to tie the infringement to an individual if you were given the chance to identify possible individuals.
So, if I can show that I know that a user of the IP address infringed, and that if I could get the Limewire user GooberToo who was also sharing Ubuntu 10.04 x86_64 and Fedora 15 i686 I would have the user who infringed, I could still get the subpoena. If all I have is an IP and an allegation of infringement, tough.
At a technical level, there still are ATM fees for using a bank ATM in the UK. It's just that our banks have worked out that it's better for business overall if the fees are internal bookkeeping between banks rather than something to pass onto a customer.
Put simply, banks with huge ATM networks like Barclays make a net profit on ATM fees; they receive more than they pay out. Banks with small ATM networks often find it cheaper to pay the fees than to either expand their network or deal with the customer service problem of guiding irate customers to their only ATM in town (partly because mobile phones means that people are more likely to call in and ask for help, mostly because - as you've said - no foreign withdrawal fees is a selling point).
A bigger problem over here in old blighty is articulated lorries getting stuck by driving down roads that are too narrow or otherwise unsuitable. One big problem in this case is it's virtually impossible to turn a lorry on a narrow road. So if the road starts looking bad the choices are to carry on and hope they don't get stuck, try to reverse out (very slow and likely to require a second person) or tow the lorry out.
In America, there are GPS maps created by commercial services for sale to the trucking industry. These maps include weight restrictions, width and height restrictions, truck routes, diesel fuel truck stops, tire and service centers, all kinds of information that is specific to the driving of big rigs. I would assume you have similar services available over there. But if your ordinary trucker thinks he can just drop a $99 Garmin on his dashboard and use it to drag a 30 tonne trailer to wherever he wants, well, that's almost as foolish as trying to cross two hundred miles of desert because there's a little blue line on the screen.
The same class of GPS map is sold in the UK; the problem is that they cost more than the cheap car GPS units. Taking Garmin as a sample manufacturer, the cheapest car unit they sell here is £99. The cheapest truck unit is £259. A trucker buying a GPS unit on his own dime because he's a bit unsure about how best to get to his destination, but isn't brave enough to ask the office to get the maps out is going to buy the £99 unit. And then he's going to foul up; if it wasn't such a problem for the rest of us, it'd just be funny.
Indeed - once the overflow state caused by bufferbloat gets that bad for most people, we'll see a repeat of the 1986 NSFNet congestion collapse. Lots of packets flowing, buffers filling and emptying, and next to no usable throughput, as each bloated buffer in turn overflows and causes a full-blown RTO timeout, not a fast recovery.
The TCP window has only grown that large because there's been no congestion signalled; thanks to slow start, my TCP window started out at just 2 packets, but grew and grew until TCP experienced congestion. Bufferbloat has meant that TCP has not experienced any congestion until the latency has reached insane values (as congestion is signalled in the Internet by dropping packets).
This is the root cause of the problem; we have lots of workarounds for it, but at heart, the issue is that the only working mechanism for indicating congestion on the Internet is packet drops (packets marked as ECN-capable are blocked by too many idiots with firewalls to be useful). TCP by design will increase the current in-use window size until such point as it experiences congestion, then it will scale back to fit within the link; because we've removed congestion notification in the name of zero packet loss (yet we still have packet loss on these "zero packet loss" links - go figure), we hit pain.
If you artificially constrain TCP so that it cannot fill a link (i.e. make the maximum window tiny compared to BDP - noting that on today's Internet, I experience BDPs from as little as 1 kilobyte, to as high as 10 megabytes), then, yes, you won't hit bufferbloat - you won't hit saturation, either. If you rate limit outside the application layer (and how exactly is Slashdot's web server meant to know what the bottleneck rate between Slashdot and my PC is, exactly?), you have to signal congestion back to TCP somehow. On the Internet, that's done by dropping packets instead of queueing them; but, thanks to bufferbloat, my link doesn't drop packets until the latency is very high. As a result, TCP doesn't scale back its send rate until it's too late; I can fix that locally, by rate limiting at my router to some fraction of my link speed, but then I have to drop the packets that exceed that fraction. Why shouldn't the ISP drop them instead, and thus let me use more of the link speed I'm paying for?
How much bandwidth can I have, though? Take the link between my desktop and a Slashdot server; is the correct answer "1GBit/s, no more" (speed of my network card)? Is is "20MBit/s, no more" (speed of my current Internet connection)? Is it "0.5MBit/s, no more" (my fair share of this office's Internet connection)? In practice, you need the answer to change rapidly, depending on network conditions - maybe I can have the full 20MBit/s if no-one else is using the Internet, maybe I should slow down briefly while someone else handles their e-mail.
TCP doesn't slam the network; it starts off slowly (TCP slow start currently sends just two packets initially), and gradually ramps up as it finds that packets aren't dropped. When packet drop happens, it realises that it's pushing too hard, and drops back. If there's been no packet drop for a while, it goes back to trying to ramp up. RFC 5681 talks about the gory details. It's possible (bar idiots with firewalls that block it) to use ECN (explicit congestion notification) instead of packet drop to indicate congestion, but the presence of people who think that ECN-enabled packets should be dropped (regardless of whether congestion has happened) means that you can't implement ECN on the wider Internet.
This works well in practice, given sane buffers; it dynamically shares the link bandwidth, without overflowing it. Bufferbloat destroys this, because TCP no longer gets the feedback it expects until the latency is immense. As a result, instead of sending typically 20MBit/s (assuming I'm the only user of the connection), and occasionally trying 20.01MBit/s, my TCP stack tries 20.01MBit/s, finds it works (thanks to the queue), speeds up to 20.10MBit/s, and still no failure, until it's trying to send at (say) 25MBit/s over a 20MBit/s bottleneck. Then packet loss kicks in, and brings it back down to 20MBit/s, but now the link latency is 5 seconds, not 5 milliseconds.
The point he's making is that in the days when TCP was developed, RAM was expensive, so we didn't have big queues. As a result, you didn't need to rate limit any connections to get low latency and high throughput.
Remember that no matter how big the queue is, if you saturate your link for long enough, you get a degree of packet loss. If, for example, the queue is 5 seconds long at maximum speed, and you saturate the link for 6 seconds, you lose some packets. TCP exploits this by using the packet drop as an indication that a link in the path between two hosts is saturated. When buffers are appropriately sized, and queue length appropriately managed by something active like RED, this is not a problem; latency stays low because the queue isn't that big compared to the link throughput, and packet drops genuinely indicate congestion on the path.
Bufferbloat creates the symptom you're working around by QoS and rate-limiting. Because the queue is immense, there's no packet drop until the latency is insane. Because there's no packet drop, the TCP stacks sending data your way don't believe that your link is congested, so don't slow down. Your rate-limiting and QoS fixes this by letting the packets come in via your Internet connection, then dropping them if the actual data rate exceeds a level below that which your line is capable of; Gettys is asking why you need to do that. Why can't your ISP shrink their queue, and drop packets when your line is just saturated, rather than building up an immense queue, which you promptly go and waste by throttling to less than the speed you've paid for?
Looks like my English irony didn't come over properly. Let me explain:-)
One of the other justifications I hear for "must have an SUV" is that the owner couldn't fit their entire family plus luggage for a trip away in a Smart, or a Mini, or a Renault Clio, and thus must drive a massive SUV. There's a false dichotomy there; the fair comparison is not "Range Rover" versus "Smart"; it's "Range Rover" versus (say) "Audi A8", where carrying capacity is similar.
As the Lexus IS (while not a small vehicle) has lower carrying capacity than many SUVs, I thought I'd describe it as "small"; I didn't want SUV apologists attacking me for not realising that they need immense load carrying capacity.
FWIW, I do see the market niche for SUVs; round here, it's people who need the carrying capacity of something like a Ford Transit Connect, but also need to be able to go offroad. I mentioned that my mother in law drives an SUV; she's a nurse, and has to make house visits to patients who can't get out in good weather, let alone snow. Worse, some of those patients aren't in houses on good tarmac roads, they're at the ends of muddy clearings that they used to maintain, but can't now they're injured. The SUV lets her get out to these patients whatever the weather, which means fewer people in hospital (i.e. more space for people who really cannot be elsewhere).
I've seen two fatal road accidents, and one injury accident in the last ten years. All three involved children, all three involved SUVs.
In the case of the two fatalities, the SUV driver was confident that the power and weight of their vehicle would let them do things that other road users weren't risking; it turns out that even a 3-ton SUV is going to lose against a 40-odd ton truck.
In the case of the injury, it was even simpler; the kid did something stupid (ran in front of their parent's vehicle, not behind it, to cross to the shop opposite their school), got hit at relatively low speeds (about 10 mph), and instead of going over the car (seen that, too, with a Lexus IS - quite survivable by the size of kids in question, who were merely shocked), went under the wheels (Range Rover). The resulting injuries needed hospital treatment.
As to the two fatalities? Fatality one was caused when two big rigs on a 3-lane highway hadn't seen each other and decided to signal to change lanes, the one on the left moving right, the one on the right moving left. The rest of us dropped back - you do not want to be next to a big rig when it's in a crash. The SUV driver went round the traffic that had dropped back, and tried to overtake - they nearly made it, but got hit by one of the big rigs. The SUV was crushed against the central reservation, then driven over by the rig that hit it. Result? Two adults declared dead on the scene, their child declared dead before I'd finished giving my statement of what I'd seen to the police.
The second was in icy conditions, climbing a hill with (again) big rigs coming down towards us. The SUV decided to try and overtake, lost control, span onto the other side of the road, and got hit in the side by a big rig. The resulting damage meant that people on the side that was hit were killed (possibly at time of impact, possibly when the SUV rolled and then slid on the damaged side), but people on the other side of the vehicle were OK.
You will notice a pattern to the serious incidents; someone does something stupid, and an accident ensues. In the two fatal cases, a better driver wouldn't have been involved in the first place; for the first of the two, they'd have observed that the trucks were signalling stupid plans, and that everyone else was dropping back, for the second, they'd have noted the icy conditions, and decided to take a bit longer rather than overtake when there's traffic coming downhill. I find myself wondering whether the sense that the SUV would protect them encouraged these drivers to take risks that they just wouldn't risk in a smaller car; if it did, it cost them dearly.
In the injury case, there wasn't that much the driver could do - similar accidents occurred at that spot about once every three months, as there was a school on one side of the road, and a shop on the other. Kids dropped off at school sometimes decided to go to the shop instead; if the kid was especially distracted, or especially foolish, they'd dart just in front of the car that just dropped them off. Result is one accident - small vehicles like the Lexus IS throw the kid over the bonnet, and there are no injuries, just a seriously terrified kid and parent. SUVs force the kids under the car, and if the wheels get them, it's serious injury time.
My conclusion? If you're buying an SUV to "keep the kids safe", you're better off spending the difference in price between a car and an SUV on advanced driving lessons; learn to read the road, and make better judgement calls. You're better off with half the chance of being in an accident, and a 25% higher chance of someone dying in the accident than you are with a slightly lower chance of someone dying in the accident, but twice the odds of being in an accident in the first place.
Further, it's worth thinking about the bumps and scrapes you've actually been in - if your experience is that you're regularly in high speed crashes involving other vehicles, but never in incidents where the collision sp
I don't see why the German language student shouldn't have access to the vocab list, or the political science student shouldn't have access to the detailed history of the Thirty Years War. If the exam questions are good (which was the case for the exams I took at undergraduate level), using your vocab list or your detailed history costs you time that you need to provide a high scoring answer.
If you have to check something in the history to ensure that you're not confusing the Thirty Years War with the Hundred Years War, or check the vocab list to ensure that you've correctly understood one or two words, you don't lose much time, and can give a strong answer based on your comprehension of the subject. If you have to check every word in the vocab list, or read the history during the exam to understand the subject, you're not going to have time to answer the questions properly. In short, letting them have the vocab list, the history, the notes on electronic circuits isn't a bad thing - it forces the student to demonstrate comprehension and understanding, rather than recall of arbitrary facts.
You miss something important that applies in both directions; when a Brit brings their judgement to the US, or an American brings their judgement to the UK, it's not automatically enforceable (as a judgement from New York state would be in an Illinois court). If I (a UK resident) were sued by e360 in Illinois, judgement was granted, then e360 tried to get it enforced here, I would be able to argue in the UK that I didn't show up because the Illinois court has no jurisdiction over me. If the UK court buys my argument, the judgement cannot be enforced over here, and e360 would have to sue me again in a UK court to get at my assets. Of course, if I brought assets into the US, they could be seized to pay my US debt; I'd have to be careful to not bring things over.
Same applies the other way round - if my local court rules that e360 owes me £1,000,000 because they don't show up, and I try to get it enforced in the USA, e360 could argue jurisdiction when I arrive in Illinois. If the US court agrees with e360, my UK judgement is unenforceable in the US, and I have to get a fresh US judgement to get at any US assets of e360; again, if they bring assets into the UK, I can have them seized under my UK judgement.
The target group are the people who currently have two cars, one that gets 10mpg, one that gets 33mpg, both doing similar mileage. They're in a position to replace one car, and they want to change whichever car will save them most on gas.
TFA claims that 2 out of 3 people will choose to replace the 33mpg car with a 50mpg car in preference to replacing the 10mpg car with a 20mpg car, presumably on the basis that they're improving by 17mpg, which is a bigger number than 10mpg.
Even if the computers in the 737 cost 1,000 times as much per unit as those in the Prius, it's still cheaper per unit sold to fit 3 to the aircraft than it is to fit 3 to the car. Plus, of course, avionics failure is pretty much guaranteed to end in bad press for Boeing; many failure modes for the Prius's computers end up with the driver being blamed, and no bad press for Toyota (car accidents are so much more common than plane accidents that they're not automatically newsworthy).
That's the problem - my provider has analysed the issue, and determined that ESR BRASes (a BRAS converts your PPP link into L2TP for the pipe to the ISP) corrupt small IPv6 packets in the process of taking them from the ISP's pipe and passing them onto my PPP link. ERX BRASes are OK.
BT's reaction to being told this is to say "so what if we corrupt packets between you and your customers? They're IPv6 packets, and we don't support that."
And that's entirely the problem. Both of those ISPs are advertising native IPv6 over BT's Wholesale infrastructure. Said infrastructure corrupts all small IPv6 packets - BT's answer is to say that it's not a problem, because they don't support IPv6.
Page 10 onwards of this document discuss the limits of carrier-grade NAT. In particular, page 18 shows how many simultaneous sessions various common websites need when you're using them (including things like DNS) - something simple like Yahoo needs about 10, while iTunes needs more like 250 sessions.
NTT's observation is that customers end up with around 500 sessions at a time, on average; realistically, they believe that carrier-grade NAT only allows you to put 8 users per IP address with today's Internet, without risking noticeable degradation.
Even assuming that you can limit end users to basic browsing and e-mail, you're still looking at no more than a 250:1 gain from NAT - and that breaks many things that we currently expect to Just Work.
Bad news for you - although sex is legal at age 16, in order to make cross-border investigations of child pornography simpler, we've criminalised depictions of sex which involve under-18s.
So, Ethanol-fueled is right - it's completely legal to have sex with your 17 year old sweetheart. It's a criminal offence to take a photograph of her that would be deemed pornographic.
To take your points in order; senders do care about when their bills arrive, as the sooner the bill arrives, the sooner it can get paid. Further, they don't want to have to extend their payment terms to allow for a slow carrier (if I receive a bill tomorrow for payment on the 1st December, I can't pay on time, and it's the sender's fault, so they can't legally charge me for it).
They also care about condition; if the bill is damaged beyond readability in the post, they're issuing a new one, and dealing with customers on the phone to get it sorted.
Finally, my point is that if you apply regulations that indicate the outcome you want, and give the regulator teeth to ensure that companies don't see the cost of breaking regulations as part of the cost of doing business, you end up with the service you want (although not necessarily at the price you want). You could also fix the problems you're raising by making mail carriers liable to the recipient for consequential damages caused by mail delays or damage.
There's a simple answer to that though; instead of giving the USPS a monopoly, require all mail carriers to provide fixed-fee service to the entire country. Don't limit how the carrier does this; a carrier concentrating on urban service could (for example) pay the USPS to handle remote areas, and eat the loss whenever it leaves its own delivery area; if it's got a process advantage over the USPS (such as better sorting systems), it may not make a loss whenever it does have to pay the USPS to fill in coverage gaps. To protect the USPS from abuse, once you're a mail carrier, you may not make use of another carrier's fixed-fee services (so you'd need to negotiate a suitable commercial contract with the USPS to fill in your coverage gaps).
If postal services are a natural monopoly, the USPS ends up as the only carrier. If there's room for someone to undercut the USPS, they will do so, and make a profit in the process. So long as the USPS isn't stupid enough to set its rates below the level where they can continue to make a profit on every delivery, it survives to provide fill-in coverage.
Put another way; the USPS is a monopoly because we want reliable postal services at a fixed rate, anywhere in the country. If we regulate for the outcome we want, and let private enterprise do as it wishes within those regulations (with business-destroying penalties for flouting them), we should get the results we want for the minimum price possible. If that means a USPS monopoly, it's clear that the monopoly is a consequence of our desire; if it means competing carriers, then the monopoly was an inefficient way to get what we wanted.
In my first week at my first full time job, I got landed with answering the phones after hours. The first call I receive: "Seymour Bush please."
Thankfully, I was still too new to dare risk fouling up, so I looked him up in the company phone directory and passed the call onto Mr Bush; I still wonder whether it was a genuine caller, or someone whose prank backfired.
.xxx as a compulsory place for porn is a bad idea..xxx providing a safe haven for porn is a good idea. The difficult bit is that we can't trust our politicians to go for.xxx as a safe haven over.xxx as a compulsory place for porn.
What do I mean by a safe haven? Things like:
A site in.xxx can safely assume that anyone visiting is over the appropriate age limit in their locale, whether that be 18, 21 or 80.
A site in.xxx is protected from obscenity laws, as it's expected to be obscene. There may be hard and fast rules (like all photos must be of over 18s at time of photography), but no subjective rules apply (so you can't find the most prudish old spinster in Utah, and have her condemn a site).
A site in.xxx is protected from local laws of viewers; only the laws that apply in the place where the site is run from apply.
Basically,.xxx with a stick is a bad idea; there's too many definitions of porn for the stick to work. A carrot might work to move porn sites over, as it reduces their operating costs and risk factors.
Slashdot Mirror
That comparison misses the point, though - for most people, the goal isn't to have as many channels available as possible, it's to have something to watch whenever you want to watch TV. I currently have around 100 TV channels (all free to air), but I'm not guaranteed to find something I want to watch when I choose to watch TV.
I used to pay to get around 300 channels, but stopped when I realised that I still wasn't able to find something I wanted to watch whenever I turned on the TV set, and that when I did find channels I wanted to watch, they tended to be from the free to air set anyway.
A simple question illustrates the point - would you prefer 5,000 nearly identical home shopping channels for the same money you pay now, or would you prefer your existing TV package? I suspect you'd find that most people would prefer your current TV package, with its mere 200 channels, to a package of 5,000 channels that they're mostly not interested in.
And that's where the debate lies. LightSquared's license permits them two uses of the frequencies licensed:
LightSquared's argument is that they have met the second term of their license if they ensure that their earth-based transmitters do not leak out of their licensed bands, even if they interfere with licensed users of neighbouring bands; note that the FCC has been clear that one way to meet the second requirement is to replace receivers of the neighbouring bands with ones that cope with your interference, an option LS has rejected as impractical, as they cannot find affordable receivers that have both the GPS abilities of the receivers they're replacing and better rejection of LS's signals.
I'm typing this on a Dell N-series laptop that came with Ubuntu pre-installed. I bought the most expensive Linux preloaded laptop Dell would sell me, complete with all the options they offered (including things like the insurance), partly to make the point to Dell that not everyone who buys a Linux preloaded machine is aiming to cheap out. I find it interesting that I cannot find numbers from Dell on how much they actually made (on a like-for-like) basis from the Ubuntu preloaded N series laptops as compared to the Windows laptops with the same hardware; I do wonder if they found that there is actually a niche market for them, in which they could make money, but chose to serve the bulk market instead.
It could, yes, but in both cases, you're likely to have more than just an allegation against an anonymous identifier; as soon as you can show the judge the outline of your future case against the identified individual, you've passed the bar he set.
Taking your examples in turn, in the telephone line subscriber case, you would be expected to show the judge some evidence that you were receiving silent or abusive calls (maybe a call recording, maybe a diary of the calls paired up with some records from your phone provider to show that those calls did actually happen, even if the content isn't as you state). You now have some evidence that your request isn't just a fishing expedition, and the subpoena process can continue.
In the car case, if you present a police record of your incident report, that's a good enough start to get you going - you've again demonstrated that there is more to your request than a simple fishing expedition.
In the case presented to the judge, there was no evidence of infringement that was of high enough standard to present in court, merely an allegation by the plaintiff; the judge basically told the plaintiff "come back with evidence, and then we'll talk".
I read the judgement - did you? In it, the judge makes it clear that the IP address and a naked assertion of infringement is not enough to get the subpoena; you need sufficient evidence to show the judge that you can tie the infringement to the IP address, and could continue to tie the infringement to an individual if you were given the chance to identify possible individuals.
So, if I can show that I know that a user of the IP address infringed, and that if I could get the Limewire user GooberToo who was also sharing Ubuntu 10.04 x86_64 and Fedora 15 i686 I would have the user who infringed, I could still get the subpoena. If all I have is an IP and an allegation of infringement, tough.
At a technical level, there still are ATM fees for using a bank ATM in the UK. It's just that our banks have worked out that it's better for business overall if the fees are internal bookkeeping between banks rather than something to pass onto a customer.
Put simply, banks with huge ATM networks like Barclays make a net profit on ATM fees; they receive more than they pay out. Banks with small ATM networks often find it cheaper to pay the fees than to either expand their network or deal with the customer service problem of guiding irate customers to their only ATM in town (partly because mobile phones means that people are more likely to call in and ask for help, mostly because - as you've said - no foreign withdrawal fees is a selling point).
A bigger problem over here in old blighty is articulated lorries getting stuck by driving down roads that are too narrow or otherwise unsuitable. One big problem in this case is it's virtually impossible to turn a lorry on a narrow road. So if the road starts looking bad the choices are to carry on and hope they don't get stuck, try to reverse out (very slow and likely to require a second person) or tow the lorry out.
In America, there are GPS maps created by commercial services for sale to the trucking industry. These maps include weight restrictions, width and height restrictions, truck routes, diesel fuel truck stops, tire and service centers, all kinds of information that is specific to the driving of big rigs. I would assume you have similar services available over there. But if your ordinary trucker thinks he can just drop a $99 Garmin on his dashboard and use it to drag a 30 tonne trailer to wherever he wants, well, that's almost as foolish as trying to cross two hundred miles of desert because there's a little blue line on the screen.
The same class of GPS map is sold in the UK; the problem is that they cost more than the cheap car GPS units. Taking Garmin as a sample manufacturer, the cheapest car unit they sell here is £99. The cheapest truck unit is £259. A trucker buying a GPS unit on his own dime because he's a bit unsure about how best to get to his destination, but isn't brave enough to ask the office to get the maps out is going to buy the £99 unit. And then he's going to foul up; if it wasn't such a problem for the rest of us, it'd just be funny.
Indeed - once the overflow state caused by bufferbloat gets that bad for most people, we'll see a repeat of the 1986 NSFNet congestion collapse. Lots of packets flowing, buffers filling and emptying, and next to no usable throughput, as each bloated buffer in turn overflows and causes a full-blown RTO timeout, not a fast recovery.
The TCP window has only grown that large because there's been no congestion signalled; thanks to slow start, my TCP window started out at just 2 packets, but grew and grew until TCP experienced congestion. Bufferbloat has meant that TCP has not experienced any congestion until the latency has reached insane values (as congestion is signalled in the Internet by dropping packets).
This is the root cause of the problem; we have lots of workarounds for it, but at heart, the issue is that the only working mechanism for indicating congestion on the Internet is packet drops (packets marked as ECN-capable are blocked by too many idiots with firewalls to be useful). TCP by design will increase the current in-use window size until such point as it experiences congestion, then it will scale back to fit within the link; because we've removed congestion notification in the name of zero packet loss (yet we still have packet loss on these "zero packet loss" links - go figure), we hit pain.
If you artificially constrain TCP so that it cannot fill a link (i.e. make the maximum window tiny compared to BDP - noting that on today's Internet, I experience BDPs from as little as 1 kilobyte, to as high as 10 megabytes), then, yes, you won't hit bufferbloat - you won't hit saturation, either. If you rate limit outside the application layer (and how exactly is Slashdot's web server meant to know what the bottleneck rate between Slashdot and my PC is, exactly?), you have to signal congestion back to TCP somehow. On the Internet, that's done by dropping packets instead of queueing them; but, thanks to bufferbloat, my link doesn't drop packets until the latency is very high. As a result, TCP doesn't scale back its send rate until it's too late; I can fix that locally, by rate limiting at my router to some fraction of my link speed, but then I have to drop the packets that exceed that fraction. Why shouldn't the ISP drop them instead, and thus let me use more of the link speed I'm paying for?
How much bandwidth can I have, though? Take the link between my desktop and a Slashdot server; is the correct answer "1GBit/s, no more" (speed of my network card)? Is is "20MBit/s, no more" (speed of my current Internet connection)? Is it "0.5MBit/s, no more" (my fair share of this office's Internet connection)? In practice, you need the answer to change rapidly, depending on network conditions - maybe I can have the full 20MBit/s if no-one else is using the Internet, maybe I should slow down briefly while someone else handles their e-mail.
TCP doesn't slam the network; it starts off slowly (TCP slow start currently sends just two packets initially), and gradually ramps up as it finds that packets aren't dropped. When packet drop happens, it realises that it's pushing too hard, and drops back. If there's been no packet drop for a while, it goes back to trying to ramp up. RFC 5681 talks about the gory details. It's possible (bar idiots with firewalls that block it) to use ECN (explicit congestion notification) instead of packet drop to indicate congestion, but the presence of people who think that ECN-enabled packets should be dropped (regardless of whether congestion has happened) means that you can't implement ECN on the wider Internet.
This works well in practice, given sane buffers; it dynamically shares the link bandwidth, without overflowing it. Bufferbloat destroys this, because TCP no longer gets the feedback it expects until the latency is immense. As a result, instead of sending typically 20MBit/s (assuming I'm the only user of the connection), and occasionally trying 20.01MBit/s, my TCP stack tries 20.01MBit/s, finds it works (thanks to the queue), speeds up to 20.10MBit/s, and still no failure, until it's trying to send at (say) 25MBit/s over a 20MBit/s bottleneck. Then packet loss kicks in, and brings it back down to 20MBit/s, but now the link latency is 5 seconds, not 5 milliseconds.
The point he's making is that in the days when TCP was developed, RAM was expensive, so we didn't have big queues. As a result, you didn't need to rate limit any connections to get low latency and high throughput.
Remember that no matter how big the queue is, if you saturate your link for long enough, you get a degree of packet loss. If, for example, the queue is 5 seconds long at maximum speed, and you saturate the link for 6 seconds, you lose some packets. TCP exploits this by using the packet drop as an indication that a link in the path between two hosts is saturated. When buffers are appropriately sized, and queue length appropriately managed by something active like RED, this is not a problem; latency stays low because the queue isn't that big compared to the link throughput, and packet drops genuinely indicate congestion on the path.
Bufferbloat creates the symptom you're working around by QoS and rate-limiting. Because the queue is immense, there's no packet drop until the latency is insane. Because there's no packet drop, the TCP stacks sending data your way don't believe that your link is congested, so don't slow down. Your rate-limiting and QoS fixes this by letting the packets come in via your Internet connection, then dropping them if the actual data rate exceeds a level below that which your line is capable of; Gettys is asking why you need to do that. Why can't your ISP shrink their queue, and drop packets when your line is just saturated, rather than building up an immense queue, which you promptly go and waste by throttling to less than the speed you've paid for?
Looks like my English irony didn't come over properly. Let me explain :-)
One of the other justifications I hear for "must have an SUV" is that the owner couldn't fit their entire family plus luggage for a trip away in a Smart, or a Mini, or a Renault Clio, and thus must drive a massive SUV. There's a false dichotomy there; the fair comparison is not "Range Rover" versus "Smart"; it's "Range Rover" versus (say) "Audi A8", where carrying capacity is similar.
As the Lexus IS (while not a small vehicle) has lower carrying capacity than many SUVs, I thought I'd describe it as "small"; I didn't want SUV apologists attacking me for not realising that they need immense load carrying capacity.
FWIW, I do see the market niche for SUVs; round here, it's people who need the carrying capacity of something like a Ford Transit Connect, but also need to be able to go offroad. I mentioned that my mother in law drives an SUV; she's a nurse, and has to make house visits to patients who can't get out in good weather, let alone snow. Worse, some of those patients aren't in houses on good tarmac roads, they're at the ends of muddy clearings that they used to maintain, but can't now they're injured. The SUV lets her get out to these patients whatever the weather, which means fewer people in hospital (i.e. more space for people who really cannot be elsewhere).
I've seen two fatal road accidents, and one injury accident in the last ten years. All three involved children, all three involved SUVs.
In the case of the two fatalities, the SUV driver was confident that the power and weight of their vehicle would let them do things that other road users weren't risking; it turns out that even a 3-ton SUV is going to lose against a 40-odd ton truck.
In the case of the injury, it was even simpler; the kid did something stupid (ran in front of their parent's vehicle, not behind it, to cross to the shop opposite their school), got hit at relatively low speeds (about 10 mph), and instead of going over the car (seen that, too, with a Lexus IS - quite survivable by the size of kids in question, who were merely shocked), went under the wheels (Range Rover). The resulting injuries needed hospital treatment.
As to the two fatalities? Fatality one was caused when two big rigs on a 3-lane highway hadn't seen each other and decided to signal to change lanes, the one on the left moving right, the one on the right moving left. The rest of us dropped back - you do not want to be next to a big rig when it's in a crash. The SUV driver went round the traffic that had dropped back, and tried to overtake - they nearly made it, but got hit by one of the big rigs. The SUV was crushed against the central reservation, then driven over by the rig that hit it. Result? Two adults declared dead on the scene, their child declared dead before I'd finished giving my statement of what I'd seen to the police.
The second was in icy conditions, climbing a hill with (again) big rigs coming down towards us. The SUV decided to try and overtake, lost control, span onto the other side of the road, and got hit in the side by a big rig. The resulting damage meant that people on the side that was hit were killed (possibly at time of impact, possibly when the SUV rolled and then slid on the damaged side), but people on the other side of the vehicle were OK.
You will notice a pattern to the serious incidents; someone does something stupid, and an accident ensues. In the two fatal cases, a better driver wouldn't have been involved in the first place; for the first of the two, they'd have observed that the trucks were signalling stupid plans, and that everyone else was dropping back, for the second, they'd have noted the icy conditions, and decided to take a bit longer rather than overtake when there's traffic coming downhill. I find myself wondering whether the sense that the SUV would protect them encouraged these drivers to take risks that they just wouldn't risk in a smaller car; if it did, it cost them dearly.
In the injury case, there wasn't that much the driver could do - similar accidents occurred at that spot about once every three months, as there was a school on one side of the road, and a shop on the other. Kids dropped off at school sometimes decided to go to the shop instead; if the kid was especially distracted, or especially foolish, they'd dart just in front of the car that just dropped them off. Result is one accident - small vehicles like the Lexus IS throw the kid over the bonnet, and there are no injuries, just a seriously terrified kid and parent. SUVs force the kids under the car, and if the wheels get them, it's serious injury time.
My conclusion? If you're buying an SUV to "keep the kids safe", you're better off spending the difference in price between a car and an SUV on advanced driving lessons; learn to read the road, and make better judgement calls. You're better off with half the chance of being in an accident, and a 25% higher chance of someone dying in the accident than you are with a slightly lower chance of someone dying in the accident, but twice the odds of being in an accident in the first place.
Further, it's worth thinking about the bumps and scrapes you've actually been in - if your experience is that you're regularly in high speed crashes involving other vehicles, but never in incidents where the collision sp
I don't see why the German language student shouldn't have access to the vocab list, or the political science student shouldn't have access to the detailed history of the Thirty Years War. If the exam questions are good (which was the case for the exams I took at undergraduate level), using your vocab list or your detailed history costs you time that you need to provide a high scoring answer.
If you have to check something in the history to ensure that you're not confusing the Thirty Years War with the Hundred Years War, or check the vocab list to ensure that you've correctly understood one or two words, you don't lose much time, and can give a strong answer based on your comprehension of the subject. If you have to check every word in the vocab list, or read the history during the exam to understand the subject, you're not going to have time to answer the questions properly. In short, letting them have the vocab list, the history, the notes on electronic circuits isn't a bad thing - it forces the student to demonstrate comprehension and understanding, rather than recall of arbitrary facts.
You miss something important that applies in both directions; when a Brit brings their judgement to the US, or an American brings their judgement to the UK, it's not automatically enforceable (as a judgement from New York state would be in an Illinois court). If I (a UK resident) were sued by e360 in Illinois, judgement was granted, then e360 tried to get it enforced here, I would be able to argue in the UK that I didn't show up because the Illinois court has no jurisdiction over me. If the UK court buys my argument, the judgement cannot be enforced over here, and e360 would have to sue me again in a UK court to get at my assets. Of course, if I brought assets into the US, they could be seized to pay my US debt; I'd have to be careful to not bring things over.
Same applies the other way round - if my local court rules that e360 owes me £1,000,000 because they don't show up, and I try to get it enforced in the USA, e360 could argue jurisdiction when I arrive in Illinois. If the US court agrees with e360, my UK judgement is unenforceable in the US, and I have to get a fresh US judgement to get at any US assets of e360; again, if they bring assets into the UK, I can have them seized under my UK judgement.
The target group are the people who currently have two cars, one that gets 10mpg, one that gets 33mpg, both doing similar mileage. They're in a position to replace one car, and they want to change whichever car will save them most on gas.
TFA claims that 2 out of 3 people will choose to replace the 33mpg car with a 50mpg car in preference to replacing the 10mpg car with a 20mpg car, presumably on the basis that they're improving by 17mpg, which is a bigger number than 10mpg.
Also:
Even if the computers in the 737 cost 1,000 times as much per unit as those in the Prius, it's still cheaper per unit sold to fit 3 to the aircraft than it is to fit 3 to the car. Plus, of course, avionics failure is pretty much guaranteed to end in bad press for Boeing; many failure modes for the Prius's computers end up with the driver being blamed, and no bad press for Toyota (car accidents are so much more common than plane accidents that they're not automatically newsworthy).
BT's reaction to being told this is to say "so what if we corrupt packets between you and your customers? They're IPv6 packets, and we don't support that."
And that's entirely the problem. Both of those ISPs are advertising native IPv6 over BT's Wholesale infrastructure. Said infrastructure corrupts all small IPv6 packets - BT's answer is to say that it's not a problem, because they don't support IPv6.
Page 10 onwards of this document discuss the limits of carrier-grade NAT. In particular, page 18 shows how many simultaneous sessions various common websites need when you're using them (including things like DNS) - something simple like Yahoo needs about 10, while iTunes needs more like 250 sessions.
NTT's observation is that customers end up with around 500 sessions at a time, on average; realistically, they believe that carrier-grade NAT only allows you to put 8 users per IP address with today's Internet, without risking noticeable degradation.
Even assuming that you can limit end users to basic browsing and e-mail, you're still looking at no more than a 250:1 gain from NAT - and that breaks many things that we currently expect to Just Work.
So, Ethanol-fueled is right - it's completely legal to have sex with your 17 year old sweetheart. It's a criminal offence to take a photograph of her that would be deemed pornographic.
To take your points in order; senders do care about when their bills arrive, as the sooner the bill arrives, the sooner it can get paid. Further, they don't want to have to extend their payment terms to allow for a slow carrier (if I receive a bill tomorrow for payment on the 1st December, I can't pay on time, and it's the sender's fault, so they can't legally charge me for it).
They also care about condition; if the bill is damaged beyond readability in the post, they're issuing a new one, and dealing with customers on the phone to get it sorted.
Finally, my point is that if you apply regulations that indicate the outcome you want, and give the regulator teeth to ensure that companies don't see the cost of breaking regulations as part of the cost of doing business, you end up with the service you want (although not necessarily at the price you want). You could also fix the problems you're raising by making mail carriers liable to the recipient for consequential damages caused by mail delays or damage.
There's a simple answer to that though; instead of giving the USPS a monopoly, require all mail carriers to provide fixed-fee service to the entire country. Don't limit how the carrier does this; a carrier concentrating on urban service could (for example) pay the USPS to handle remote areas, and eat the loss whenever it leaves its own delivery area; if it's got a process advantage over the USPS (such as better sorting systems), it may not make a loss whenever it does have to pay the USPS to fill in coverage gaps. To protect the USPS from abuse, once you're a mail carrier, you may not make use of another carrier's fixed-fee services (so you'd need to negotiate a suitable commercial contract with the USPS to fill in your coverage gaps).
If postal services are a natural monopoly, the USPS ends up as the only carrier. If there's room for someone to undercut the USPS, they will do so, and make a profit in the process. So long as the USPS isn't stupid enough to set its rates below the level where they can continue to make a profit on every delivery, it survives to provide fill-in coverage.
Put another way; the USPS is a monopoly because we want reliable postal services at a fixed rate, anywhere in the country. If we regulate for the outcome we want, and let private enterprise do as it wishes within those regulations (with business-destroying penalties for flouting them), we should get the results we want for the minimum price possible. If that means a USPS monopoly, it's clear that the monopoly is a consequence of our desire; if it means competing carriers, then the monopoly was an inefficient way to get what we wanted.
Thankfully, I was still too new to dare risk fouling up, so I looked him up in the company phone directory and passed the call onto Mr Bush; I still wonder whether it was a genuine caller, or someone whose prank backfired.
What do I mean by a safe haven? Things like:
Basically, .xxx with a stick is a bad idea; there's too many definitions of porn for the stick to work. A carrot might work to move porn sites over, as it reduces their operating costs and risk factors.