Apparently somehow the speakers got fed DC current while doing nothing in particular. Impressive if you ask me.
I would guess a software bug that wrote inappropriate values to the DAC (possiblly straight binary vs 2's complement confusion) combined with an idiot hardware designer DC coupling the audio path.
are QRcodes like IPv4 addresses in that we will run out of usable ones for wasting them on our cat's buttcheeks?
No.
QR codes encode arbitary text (in one of several character sets). There is no central registry of what that text means so QR codes in general can't "run out". The ammount of text that can be encoded depends on the size (in "modules") of the QR code, the character set and the desired error correction level.
QR codes used for taking people to websites generally encode URLs. Even a quite long URL can be encoded in a reasonable size QR code though shorter URLs are certainly preferable for more reliable scanning due to stronger error correction and/or larger "modules".
The real speed of actual data delivery is whatever the providers want it to be.
Not entirely true. the real speed of actual data devliery depends on many factors including
1: the speed of your client hardware and software 2: the speed of your local network 3: the speed of your customer premisis equipment 4: any congestion/shaping/prioritisation on your ISPs network 5: any congestion between your ISP and the server host. 6: any congestion on the server hosts network 7: the speed/congestion of the servers connection to it's hosts network 8: the ability of the server itself to keep up 9: TCP issues. Older TCP stacks had a limited window size which limited the bandwidth at a given latency. Even modern stacks have "slow start" which means it will take a while to get up to the full bandwidth on a "long fat network".
Some of these factors are under your ISPs control, many are not.
Afaict speedtest measures about the best case, it uses a nearby fast test server and it waits for the speed to stabalise to allow for TCP slow start.
I couldn't get numion to work so I can't comment on that.
Brish student loans are paid off at a rate based on your income, they are also automatically written off after a set period (the exact set period has varied, for new english and welsh* student loans now it's 30 years, prior to that it was 25 years and prior to that it was at state retirement age). In recent years both tuition fees and loan interest rates have risen sharply while the set period before the loan is written off has been shortened. Claims from different bodies as to what proportion of students will be able to replay their loans vary.
Personally this seems to some extent like an accounting trick to make the current government budget look better at the expense of running up liabilities for future governments to deal with. Rather than subsidising the university education upfront or subsidising the interest on the loans year by year they are kicking the can down the road so some future government will have to pay the cost of writing off those debts.
* Rules in scotland and northern ireland are different.
Noone knows, we only have records of the criminals who were stupid/unlucky enough to get caught. This is especially true for crimes where it is not obvious to the victim that a crime has been committed at all.
However if you cheat on your partner you risk a devorce. If you are the richer partner in the marriage that can lead to much larger losses of wealth than the relatively small tax advantages.
AIUI many greeks are withdrawing as much cash as the banks/government will let them. They know that their bank balances are at risk of a forced conversion to a new currency (and subsequent devaluation) while it's much harder to make such a forced conversion on banknotes held by individuals.
Note: the below is a UK perspective, some of it may also apply elsewhere but details are likely to vary.
Cards can be used offline and even without electricity but the fraud/overspend risk is higher and this can lead to restrictions on use or even the merchant to refuse to accept them altogether.
AIUI for chip and pin the card issuer sets a limit (which can be zero if the card issuer thinks you are a poor credit risk) for offline transactions to mitigate fraud/overspend risk and they don't usually tell you what said limit is in advance. For imprint and magstripe transactions I belive it's down to the merchant (and possiblly their bank) what transactions they are willing to risk taking offline.
If you have already eaten the meal/filled your fuel tank/got on the train then the retailers choice may come down to taking the card offline (and possiblly reverting to magstripe to get around the offline restrictions on chip and pin, I've seen that happen on a train before) or taking an IOU. The card is a lower risk than the IOU.
On the other hand a normal retailer is in a very different situation. If they decide they don't want to take cards offline and/or in a power cut either because they think the risk is too high, or for power cut scenarios because they don't want to bother stocking card imprinters and training their staff how to use them then you are SOL.
Also IIRC in the UK automated vending machines are restricted to online chip and pin transactions only. They are not allowed to do swipe and sign transactions or offline transactions.
So don't rely on your credit/debit card working in an offline/power cut scenario.
Do you have a source for your claim, because it contradicts everything I've read elsewhere.
My understanding is that Nokia sold their whole handset buisness to MS, not just the smartphones. Said sale came with limited rights for MS to use the Nokia brand and certain non-compete terms preventing nokia selling phones under their own name. Right now MS has migrated the lumia smartphones away from the nokia brand but is still selling feature-phones under the nokia brand. In the not too distant future the branding part of the deal will expire, MS will no longer be able to sell phones under the nokia name and nokia will be able to sell phones (smart or otherwise) under their own name again.
UK Trains provide charging points for laptops and mobile phones and have signs announcing this, and this is also on the national rail website .
Fast long distance trains on major routes in the UK usually have sockets near some or all of the seats labeled "laptops and mobile phones only" or similar intended for passenger use. Local trains and slow trains generally do not have them. These are a relatively recent thing, first appearing on new trains in the early 2000s.
Many UK trains have sockets located at the back of the luggage racks or similar labeled with "not for public use" signs and sometimes other warnings . My understanding is that these sockets are intended for use by the cleaners, may not nessacerally meet the voltage/frequency norms for domestic power and even if they did I doubt train operators would want to encourage people to charge phones and laptops there. These have been arround a LOT longer than the sockets intended for passenger use.
Still an arrest seems OTT unless there were aggravating factors.
As long as the manufacturer has a sufficient income stream and a way of making sure that cars with known flaws are fixed there is no reason they couldn't cover the liability for all their cars and they of course have the option of taking out an insurance policy against that eventuality. The key will be ensuring that revenue stream. The nightmare situation for a manufacturer is being held responsible for a product they no longer make any income from or have any control over.
For this reason I imagine when self-driving cars first hit the market it will be on an "all-in lease" basis where the manufacturer remains in control and can therefore respond effectively to dangerous flaws before they run up too much liability. I would expect sales of self-driving cars to require some legislative moves to define the extent of the manufacturer's liability.
Prototype planes are registered as "experimental aircraft". That means that the authorities have looked at it and decided it's safe enough for a test pilot to fly it. Proper type approval comes later when the manufacturer has gathered enough evidence by (among other things) actually flying the plane.
In the USA home built aircraft are also registered as experimental aircraft (despite not being truely "experimental" in most cases) and get much the same level of scrutiny. Other countries may have different rules on homebuilts.
As for which airports it's going to depend on the type of plane. Big planes are going to be built and tested somewhere there is a big runway. Big runways are expensive and politically difficult to built so those facilities are likely to be built next to an existing one which may also form part of a fairly major airport. Airbus do their assembly and testing at tolouse international airporpot. Boeings main manufacturing facilities seem to be attatched to non-international but still reasonablly large airports. Smaller planes are obviously built and tested at smaller airports
Much as the only way you really find out how a plane copes with flying and get the snags out of the design is to perform test flights the only way you really find out how well a self driving car (or a human driver for that matter) handles real road conditions and what situations it has trouble handling is to test it on real roads. Simulations and lab tests are important but they are not a substitute for real world testing. Having experianced humans arround during that real world testing to intervene is also a good idea (again for both human drivers and manchine drivers).
AIUI this is mostly a client issue, servers do not normally validate certs presented to them (client certs do exist but they are rarely used and even where they are used afaict it'susually with a "known cert for each user" model rather than a CA based model).
MS is a buisness built on propietary software. The FSF belives propietary software is unethical. MS donating to the FSF would be like an abortion clinic donating to a "pro life" organisation.
I can't find an exact figure for the donation but according to http://www.openbsdfoundation.o... it was in the $25K to $50K range. That may be a lot for an opensource project running on a shoestring budget but it's pretty trivial to MS. If they get some good PR and some help with the windows port of openssh out of it then it's probablly money well spent.
I'd've loved to see ARIN put a "you can only get v4 space if you show us that you're doing a serious v6 deployment too" policy on their last/8.
I think they should have done that long before the last/8 and they should have carefully defined what was meant by "serious v6 deployment". Something along the lines of
1: all IPv4 customers of the requester must be offered IPv6. 2: For new customers any provider supplied equipment must support IPv6 in it's default configuration and all instructions must cover IPv6. 3: all existing IPv4 customers of the requester must be explicitly contacted and instructed on the steps needed to get IPv6. 4: All public services operated by the requester must be offered on IPv6. 5: The company must operate local relays for 6to4 and teredo and direct all internal customer traffic for 2001::/32 2002::/16 and .
But they didn't. ICANN and the rirs knew or should have known that continuing as they were would lead to v4 exhaustion before serious IPv6 deployment but they did it anyway.
TFA seems to conflate the ideas of speed ratio and force multiplication. That is only true if the mechanism is perfectly efficient. In practice some of the input force will instead be consumed opposing friction in the mechanism and the output force will be limited by the stretch of the parts. So the maximum force multiplication achived may be substantially lower than the speed ratio.
To make a high ratio gearbox practical for force multiplication the low torque high speed parts need to be small to minimise friction while the low speed high torque parts need to be large to prevent them from breaking.
To make it practical for accurate rotational positioning again the low speed parts need to be large, otherwise flexibility in those low speed parts will compromise the ability to accurately maintain position.
AIUI we have a situation where some miners are enforcing stricter rules than others.
If the strict miners significantly out mine the loose ones then not much will happen. The blocks that don't pass the strict rules will quickly be forked off and die and noone sensible accepts a one-block-confirmed transaction for anything important.
However if the loose miners out mine the strict miners you get a long lasting fork between the strict and loose miners. People whose clients only enforce the loose rules will see what is going on in the loose fork. People whose clients enforce the strict rules will see what is going on in the strict fork. The two forks will most likely contain most of the same transactions but there may be some cases where someone manages to engineer that the same bitcoins are transferred to different places in the two forks, newly mined coins will also go to different people in the two forks.
If the mining rate of strict and loose miners are approximately equal then you have a mess. The two forks could run in paralell for some time and then the strict fork could either hit a run of good luck or be boosted by miners switching to the strict rules and kill the loose fork. AIUI that is the present situation.
It is most likely this will end with the strict miners outnumbering the loose ones, any transactions that only happened on a loose branch will then be killed.
If all your users do is create and edit files then sure you can use the --update flag and omit the --delete flag making the rsync operation a lot safer.
but if your users are more active that is not so practical. Assuming this storage is used as a work area by developers they are likely to be doing things like deleting files and sometimes even deleting files and replacing them with a copy of an older file (for example deleting a dirty copy of a source tree and replacing it with a clean one). So to copy all the changes you need to use rsync in a far more agressive mode without the --update flag and with the --delete flag.
It was probablly a mistake to put the agressive rsync in a cronjob, it would almost certainly have sufficed to use a less agressive rsync in the cronjob and only use the agressive one manually for the final sync but I can see how someone inexperianced would fail to think of that.
It was also of-course a mistake not to defuse the old server when decomissioning it. Ideally by BOTH disabling the cronjobs and disabling the credentials that allow the decomissioend server to talk to the active servers.
Normal NATs use one internet ip:port combination for each active (activity may be determined by timeouts and/or by watching for connection closures) internal ip:port combination. That means you can only have ~65K active outgoing connections per internet IP.
You could build a high ratio NAT which didn't do that. Technically for basic connectivity to work the source IP/port combination only needs to be unique for a given destination server (possiblly even a given port on a given destination server) but building such a thing would totally break most nat traversal techniques and hence break things like P2P and online gaming even worse than a normal NAT would.
NAT also really doesn't help much on the server side because people expect their services to be on well-known ports. For some services you can host multiple hostnames on the same ip either by serving them from the same server or using a reverse proxy but for others that is less practical. One specific case of interest is https. Right now for https services that matter people want a dedicated IP because of older clients that don't support SNI but as windows XP and android 2.x decline that will become less of an issue.
The unusual thing about comcast is they are an insanely large triple play provider with a heavy reliance on IP. Their triple play services ended up using about 8-9 IP addresses per household* . Of these only one (the customer's internet device) needed to be a public IP but comcast's system was so damn large and IP hungry that they ran out of space in net10 and had to start using public IPv4 addresses for internal management.
So while most non-botique access providers were probablly thinking "meh, when the IPv4 crises hits we can keep going almost indefinitely with CGN, lets let someone else be the early adopter of IPv6" comcast didn't have that buffer. They faced a stark choice between stopping expansion of services, federating their network**, or adopting IPv6. They chose IPv6.
That is why comcast is so ahead of the game on IPv6.
* http://meetings.ripe.net/ripe-... ** That is splitting it into multiple sections to allow IP reuse and redesigning their management systems to cope with it.
Slashdot Mirror
Apparently somehow the speakers got fed DC current while doing nothing in particular. Impressive if you ask me.
I would guess a software bug that wrote inappropriate values to the DAC (possiblly straight binary vs 2's complement confusion) combined with an idiot hardware designer DC coupling the audio path.
are QRcodes like IPv4 addresses in that we will run out of usable ones for wasting them on our cat's buttcheeks?
No.
QR codes encode arbitary text (in one of several character sets). There is no central registry of what that text means so QR codes in general can't "run out". The ammount of text that can be encoded depends on the size (in "modules") of the QR code, the character set and the desired error correction level.
QR codes used for taking people to websites generally encode URLs. Even a quite long URL can be encoded in a reasonable size QR code though shorter URLs are certainly preferable for more reliable scanning due to stronger error correction and/or larger "modules".
The real speed of actual data delivery is whatever the providers want it to be.
Not entirely true. the real speed of actual data devliery depends on many factors including
1: the speed of your client hardware and software
2: the speed of your local network
3: the speed of your customer premisis equipment
4: any congestion/shaping/prioritisation on your ISPs network
5: any congestion between your ISP and the server host.
6: any congestion on the server hosts network
7: the speed/congestion of the servers connection to it's hosts network
8: the ability of the server itself to keep up
9: TCP issues. Older TCP stacks had a limited window size which limited the bandwidth at a given latency. Even modern stacks have "slow start" which means it will take a while to get up to the full bandwidth on a "long fat network".
Some of these factors are under your ISPs control, many are not.
Afaict speedtest measures about the best case, it uses a nearby fast test server and it waits for the speed to stabalise to allow for TCP slow start.
I couldn't get numion to work so I can't comment on that.
Brish student loans are paid off at a rate based on your income, they are also automatically written off after a set period (the exact set period has varied, for new english and welsh* student loans now it's 30 years, prior to that it was 25 years and prior to that it was at state retirement age). In recent years both tuition fees and loan interest rates have risen sharply while the set period before the loan is written off has been shortened. Claims from different bodies as to what proportion of students will be able to replay their loans vary.
Personally this seems to some extent like an accounting trick to make the current government budget look better at the expense of running up liabilities for future governments to deal with. Rather than subsidising the university education upfront or subsidising the interest on the loans year by year they are kicking the can down the road so some future government will have to pay the cost of writing off those debts.
* Rules in scotland and northern ireland are different.
Or it could mean that in each case she was good but not quite good enough to beat the competition.
Noone knows, we only have records of the criminals who were stupid/unlucky enough to get caught. This is especially true for crimes where it is not obvious to the victim that a crime has been committed at all.
However if you cheat on your partner you risk a devorce. If you are the richer partner in the marriage that can lead to much larger losses of wealth than the relatively small tax advantages.
AIUI many greeks are withdrawing as much cash as the banks/government will let them. They know that their bank balances are at risk of a forced conversion to a new currency (and subsequent devaluation) while it's much harder to make such a forced conversion on banknotes held by individuals.
Note: the below is a UK perspective, some of it may also apply elsewhere but details are likely to vary.
Cards can be used offline and even without electricity but the fraud/overspend risk is higher and this can lead to restrictions on use or even the merchant to refuse to accept them altogether.
AIUI for chip and pin the card issuer sets a limit (which can be zero if the card issuer thinks you are a poor credit risk) for offline transactions to mitigate fraud/overspend risk and they don't usually tell you what said limit is in advance. For imprint and magstripe transactions I belive it's down to the merchant (and possiblly their bank) what transactions they are willing to risk taking offline.
If you have already eaten the meal/filled your fuel tank/got on the train then the retailers choice may come down to taking the card offline (and possiblly reverting to magstripe to get around the offline restrictions on chip and pin, I've seen that happen on a train before) or taking an IOU. The card is a lower risk than the IOU.
On the other hand a normal retailer is in a very different situation. If they decide they don't want to take cards offline and/or in a power cut either because they think the risk is too high, or for power cut scenarios because they don't want to bother stocking card imprinters and training their staff how to use them then you are SOL.
Also IIRC in the UK automated vending machines are restricted to online chip and pin transactions only. They are not allowed to do swipe and sign transactions or offline transactions.
So don't rely on your credit/debit card working in an offline/power cut scenario.
Do you have a source for your claim, because it contradicts everything I've read elsewhere.
My understanding is that Nokia sold their whole handset buisness to MS, not just the smartphones. Said sale came with limited rights for MS to use the Nokia brand and certain non-compete terms preventing nokia selling phones under their own name. Right now MS has migrated the lumia smartphones away from the nokia brand but is still selling feature-phones under the nokia brand. In the not too distant future the branding part of the deal will expire, MS will no longer be able to sell phones under the nokia name and nokia will be able to sell phones (smart or otherwise) under their own name again.
UK Trains provide charging points for laptops and mobile phones and have signs announcing this, and this is also on the national rail website .
Fast long distance trains on major routes in the UK usually have sockets near some or all of the seats labeled "laptops and mobile phones only" or similar intended for passenger use. Local trains and slow trains generally do not have them. These are a relatively recent thing, first appearing on new trains in the early 2000s.
Many UK trains have sockets located at the back of the luggage racks or similar labeled with "not for public use" signs and sometimes other warnings . My understanding is that these sockets are intended for use by the cleaners, may not nessacerally meet the voltage/frequency norms for domestic power and even if they did I doubt train operators would want to encourage people to charge phones and laptops there. These have been arround a LOT longer than the sockets intended for passenger use.
Still an arrest seems OTT unless there were aggravating factors.
I think it's a solvable problem.
As long as the manufacturer has a sufficient income stream and a way of making sure that cars with known flaws are fixed there is no reason they couldn't cover the liability for all their cars and they of course have the option of taking out an insurance policy against that eventuality. The key will be ensuring that revenue stream. The nightmare situation for a manufacturer is being held responsible for a product they no longer make any income from or have any control over.
For this reason I imagine when self-driving cars first hit the market it will be on an "all-in lease" basis where the manufacturer remains in control and can therefore respond effectively to dangerous flaws before they run up too much liability. I would expect sales of self-driving cars to require some legislative moves to define the extent of the manufacturer's liability.
Prototype planes are registered as "experimental aircraft". That means that the authorities have looked at it and decided it's safe enough for a test pilot to fly it. Proper type approval comes later when the manufacturer has gathered enough evidence by (among other things) actually flying the plane.
In the USA home built aircraft are also registered as experimental aircraft (despite not being truely "experimental" in most cases) and get much the same level of scrutiny. Other countries may have different rules on homebuilts.
As for which airports it's going to depend on the type of plane. Big planes are going to be built and tested somewhere there is a big runway. Big runways are expensive and politically difficult to built so those facilities are likely to be built next to an existing one which may also form part of a fairly major airport. Airbus do their assembly and testing at tolouse international airporpot. Boeings main manufacturing facilities seem to be attatched to non-international but still reasonablly large airports. Smaller planes are obviously built and tested at smaller airports
Much as the only way you really find out how a plane copes with flying and get the snags out of the design is to perform test flights the only way you really find out how well a self driving car (or a human driver for that matter) handles real road conditions and what situations it has trouble handling is to test it on real roads. Simulations and lab tests are important but they are not a substitute for real world testing. Having experianced humans arround during that real world testing to intervene is also a good idea (again for both human drivers and manchine drivers).
AIUI this is mostly a client issue, servers do not normally validate certs presented to them (client certs do exist but they are rarely used and even where they are used afaict it'susually with a "known cert for each user" model rather than a CA based model).
Debian claims that their patched versions of openssl for squeeze/wheezy/jessie are not affected by this issue.
MS is a buisness built on propietary software. The FSF belives propietary software is unethical. MS donating to the FSF would be like an abortion clinic donating to a "pro life" organisation.
Do they really need one?
I can't find an exact figure for the donation but according to http://www.openbsdfoundation.o... it was in the $25K to $50K range. That may be a lot for an opensource project running on a shoestring budget but it's pretty trivial to MS. If they get some good PR and some help with the windows port of openssh out of it then it's probablly money well spent.
I'd've loved to see ARIN put a "you can only get v4 space if you show us that you're doing a serious v6 deployment too" policy on their last /8.
I think they should have done that long before the last /8 and they should have carefully defined what was meant by "serious v6 deployment". Something along the lines of
1: all IPv4 customers of the requester must be offered IPv6.
2: For new customers any provider supplied equipment must support IPv6 in it's default configuration and all instructions must cover IPv6.
3: all existing IPv4 customers of the requester must be explicitly contacted and instructed on the steps needed to get IPv6.
4: All public services operated by the requester must be offered on IPv6.
5: The company must operate local relays for 6to4 and teredo and direct all internal customer traffic for 2001::/32 2002::/16 and .
But they didn't. ICANN and the rirs knew or should have known that continuing as they were would lead to v4 exhaustion before serious IPv6 deployment but they did it anyway.
I searched for microsoft nortel broke rules and found a very different picture. http://www.internetgovernance....
The summary seems to be that ARIN has basically no power over these legacy (pre RIR) blocks.
by the stretch of the parts
Sorry typo, that should have said strength of the parts.
TFA seems to conflate the ideas of speed ratio and force multiplication. That is only true if the mechanism is perfectly efficient. In practice some of the input force will instead be consumed opposing friction in the mechanism and the output force will be limited by the stretch of the parts. So the maximum force multiplication achived may be substantially lower than the speed ratio.
To make a high ratio gearbox practical for force multiplication the low torque high speed parts need to be small to minimise friction while the low speed high torque parts need to be large to prevent them from breaking.
To make it practical for accurate rotational positioning again the low speed parts need to be large, otherwise flexibility in those low speed parts will compromise the ability to accurately maintain position.
AIUI we have a situation where some miners are enforcing stricter rules than others.
If the strict miners significantly out mine the loose ones then not much will happen. The blocks that don't pass the strict rules will quickly be forked off and die and noone sensible accepts a one-block-confirmed transaction for anything important.
However if the loose miners out mine the strict miners you get a long lasting fork between the strict and loose miners. People whose clients only enforce the loose rules will see what is going on in the loose fork. People whose clients enforce the strict rules will see what is going on in the strict fork. The two forks will most likely contain most of the same transactions but there may be some cases where someone manages to engineer that the same bitcoins are transferred to different places in the two forks, newly mined coins will also go to different people in the two forks.
If the mining rate of strict and loose miners are approximately equal then you have a mess. The two forks could run in paralell for some time and then the strict fork could either hit a run of good luck or be boosted by miners switching to the strict rules and kill the loose fork. AIUI that is the present situation.
It is most likely this will end with the strict miners outnumbering the loose ones, any transactions that only happened on a loose branch will then be killed.
It does but it isn't always practical to use it.
If all your users do is create and edit files then sure you can use the --update flag and omit the --delete flag making the rsync operation a lot safer.
but if your users are more active that is not so practical. Assuming this storage is used as a work area by developers they are likely to be doing things like deleting files and sometimes even deleting files and replacing them with a copy of an older file (for example deleting a dirty copy of a source tree and replacing it with a clean one). So to copy all the changes you need to use rsync in a far more agressive mode without the --update flag and with the --delete flag.
It was probablly a mistake to put the agressive rsync in a cronjob, it would almost certainly have sufficed to use a less agressive rsync in the cronjob and only use the agressive one manually for the final sync but I can see how someone inexperianced would fail to think of that.
It was also of-course a mistake not to defuse the old server when decomissioning it. Ideally by BOTH disabling the cronjobs and disabling the credentials that allow the decomissioend server to talk to the active servers.
Normal NATs use one internet ip:port combination for each active (activity may be determined by timeouts and/or by watching for connection closures) internal ip:port combination. That means you can only have ~65K active outgoing connections per internet IP.
You could build a high ratio NAT which didn't do that. Technically for basic connectivity to work the source IP/port combination only needs to be unique for a given destination server (possiblly even a given port on a given destination server) but building such a thing would totally break most nat traversal techniques and hence break things like P2P and online gaming even worse than a normal NAT would.
NAT also really doesn't help much on the server side because people expect their services to be on well-known ports. For some services you can host multiple hostnames on the same ip either by serving them from the same server or using a reverse proxy but for others that is less practical. One specific case of interest is https. Right now for https services that matter people want a dedicated IP because of older clients that don't support SNI but as windows XP and android 2.x decline that will become less of an issue.
The unusual thing about comcast is they are an insanely large triple play provider with a heavy reliance on IP. Their triple play services ended up using about 8-9 IP addresses per household* . Of these only one (the customer's internet device) needed to be a public IP but comcast's system was so damn large and IP hungry that they ran out of space in net10 and had to start using public IPv4 addresses for internal management.
So while most non-botique access providers were probablly thinking "meh, when the IPv4 crises hits we can keep going almost indefinitely with CGN, lets let someone else be the early adopter of IPv6" comcast didn't have that buffer. They faced a stark choice between stopping expansion of services, federating their network**, or adopting IPv6. They chose IPv6.
That is why comcast is so ahead of the game on IPv6.
* http://meetings.ripe.net/ripe-...
** That is splitting it into multiple sections to allow IP reuse and redesigning their management systems to cope with it.