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:

1. For satellite to earth communication, provided they ensure that the transmissions from the satellite do not leak out of their licensed bands.
2. 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).

Just to help with that feeling that things are improving, I've been and looked up the modern equivalent of my SEAT (size-wise - it has a more powerful engine to make up for weighing a bit more, getting it marginally better 0-60 figures than my current car). It's got the same size fuel tank, and is rated to get between 487 and 690 miles on one tank. I could get a bit more mileage (about 50 to 100 miles per tank) by going for a less powerful engine that closely matches my current car.

As my normal driving is dominated by high-speed roads, I'm getting close to the highest end figures my car can manage - it's only rated to get 550 miles on a tank at most, and I should expect about 400 to 450 miles per tank.

So, things are improving - it helps that fuel prices here are much higher than in the USA, so poor fuel economy is higher on people's shopping list. Plus, you'd be mad to buy a car today without expect fuel prices to at least double if not triple in the next 3 years - either the price of crude will do it, or the tax rate will be increased again.

I'm going from a small car to a big car. My new car is 6.5" wider, 30" longer, and 2" higher than the one it's replacing, giving me twice the carrying capacity; it's also about 50% heavier than the old one.

Given all that, it's not surprising that it's a little more fuel hungry.

4 litres is roughly one US gallon - so my 500 mile range is on a 10 gallon tank. My future car (not chosen for fuel economy - I could get a less powerful engine and much higher range) has a 15 gallon tank.The Prius is supposed to be an 11 gallon tank - so similar MPG to my SEAT.

A 600 mile range on a tank of fuel isn't especially large - I get 500 miles per tank (40 litres) on my 1998 SEAT Cordoba Vario. My new car (a Skoda Superb that's being built now) is rated (manufacturer figures) to get anything from 490 to 730 miles on a single tank of fuel (60 litres).

There is a market for 3kW kettles - I even own a cordless one from Krups. John Lewis's online list of kettles is dominated by 3kW units.

Your cheap (under £20) kettle will be a 2kW model, so that they can sell the same kettle EU-wide (just change the plug), but more expensive ones are able to draw more; checking Comet's web site, I see that all 12 kettles they sell for under £20 are also under 10A draw, but once you're spending £20 or more, you can get 3kW kettles.

And it's important to have a fast boiling kettle - there's enough waiting involved in making tea as it is.

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.