False. Cell phones DO work at high altitudes. High altitudes gives them good LOS to multiple cell towers.
What IS true and a scientifically proven fact is that cell phones at high altitudes create unusually high loads on the cellular network. See what I said earlier about good LOS to *multiple* towers? The end result is that instead of appearing as a user on one tower on a given frequency and nowhere else, it appears as a user or a strong interferer on many towers.
The end result is that while a cell network may have the capacity to server N users on the ground per cell, it can only support a total of around N users in the air for ALL cells within LOS of the aircraft. This is why the ban on airborne cell phones was originally an FCC rule, not an FAA one.
And before anyone brings up that TFA does mention "clocking", the impression I get is that the writer of the article isn't very technically literate and doesn't really understand the difference between RF circuitry and clocked logic circuitry. See the comment about mobile phones operating in the 1 GHz range - even the fastest smartphones have a CPU clock speed of only 400-500 MHz at most, but mobile phones have been operating with RF carriers close to 1 GHz (specifically 800 and 900 MHz) for 15-20 years, and the 1.8 and 1.9 GHz bands have been in use for close to a decade too. Satellite communications systems frequently operate in the 10-20 GHz region. I don't see any case where the researchers are directly quoted talking about using their new developments for logic circuitry, but a few where they are implying using the new stuff for RF.
No, because whenever Slashdot covers these ultra-high-frequency transistors, they never bother mentioning that there's a huge difference between transistors optimized for logic (always on/off, usually very high drive levels and low gain, fast switching of square waves) and transistors designed for RF signal amplification (Usually designed for linear amplification of sinusoidal or modulated sinusoidal signals, lower drive levels with higher gain, and no one cares about the switching time, just the highest frequency sinusoid at which the device exhibits gain.) In essentially every case, the article is covering amplification of a signal at the record-setting frequency, not operation of a logic gate at that frequency.
There is also a very good chance that while the manufacturing process may be suitable for single (relatively) large tranistors (perfectly suitable, and often desireable for RF), it is not suitable for integrated circuits with multiple tranistors and other components on a die. Gallium Arsenide is a perfect example of this - The IC industry gave up on it pretty quickly because it was simply too difficult to make integrated circuits with it and the performance benefits for logic circuits weren't worth the costs, but manufacturers of RF transistors are still putting large amounts of effort into GaAs and plenty of commercial products exist. (Yes, there are still issues with GaAs technology and a lot of companies still don't trust GaAs in their products except in low-volume high-performance applications, but it's not like logic circuits where nothing exists on the market.)
Same thing with IBM's big SiGe push - great for RF but doesn't seem to have made any inroads to logic, probably due to cost issues and technical problems that make SiGe potentially unsuitable for logic but don't really affect their RF performance.
Most likely, AIX may also have some code in it that prevents them from open-sourcing it due to licensing.
Keep in mind they're already in enough legal battles over intellectual property licensing. While SCO's claims regarding IBM and Linux may be trollish, the impression I get is that SCO WOULD actually have significant legitimate claims against an "open source" AIX.
The end result is that rather than opensourcing AIX (which would be a rather pointless endeavor as the impression I get is that IBM is "sunsetting" it in favor of Linux), IBM is simply taking all of the Good Parts from AIX which they can and merging them into Linux.
Remember, open-sourcing a product isn't always a simple matter of taking a snapshot of your source tree, making it public, and adding a new license. Frequently, a company may not own all the code in a program and can't open source it without ripping out some of their code and either spending time replacing/rewriting it or releasing what is essentially open-source crippleware. In a situation where there is no even remotely competitive open-source alternative (see Quake and Mozilla), it makes sense to release crippleware and let the community fill in the holes over time, as even if it takes the community years (Mozilla/Firefox) to fix the holes, it still puts them way ahead. In the case of AIX, there would be utterly no point whatsoever in releasing it if IBM were required by licensing agreements to remove critical parts. Unlike Mozilla, with AIX there's a healthy and robust open-source competitor which would be dominant in developer and user mindshare even if it were open-sourced in complete form.
Remember that the SR-71 was a recon aircraft. Why make a recon aircraft that can fly faster/higher when you can just upgrade the optics and imager on a satellite and get improved results, less risk of intelligence asset loss, and greater ground coverage from a bunch of satellites?
The sad thing is, that Sony is probably the best manufacturer of Li-Ions you can buy from.
They get so much bad press for their batteries simply because of their market dominance in the battery market. The catastrophic failure rate for batteries from other manufacturers is much higher, it just happens that many of them (such as cheap knockoff cell phone batteries) are not as low profile as exploding Dells, partly due to the reduced size of cell phone batteries.
The simple fact of the matter is that lithium ion batteries are nasty temperamental things and very easy to cause to explode. There's a reason why (to my knowledge) only Li-Ion has the restriction that bare cells may not be sold to anyone other than people licensed to work with Li-Ions in the U.S. (Any place you order "bare cells" from will have a disclaimer stating that the cells are in a pack with protective circuitry of unknown functionality.)
I'm surprised your deception-through-misinformation post was moderated up.
In the U.K., I believe ALL portable electronics are forbidden in carry-on luggage. Laptops and all other electronics must be in checked baggage. (This is for the same reason the U.S. is banning all liquids in carry-on luggage.)
Make sure you are exporting in a standard DVD resolution/format/framerate.
Some export utilities will allow you to export resolutions that are valid MPEG-2 but not compliant with the MPEG-2 subset used with DVDs. The end result is usually that PC-based players will play it fine, some standalones play it fine, some standalones will do weird things when playing it, and some standalones won't play it at all.
"Even with all these exploding Dell notebooks and other notebook safety problems, Apple has seemed relatively immune."
The original submitter doesn't seem to remember that Apple was one of the first manufacturers to have exploding/spontaneously combusting batteries in their laptop. Not only are they NOT relatively immune, they were the first to have a problem.
It doesn't matter who you are, if your battery supplier screws up, this problem can affect any company that uses lithium ion batteries. Since there are only a handful of manufacturers of lithium ion batteries, if there is some sort of quality control slipup (it happens at even the best of companies), you potentially have a few timebombs on your hands. Of course, it's the manufacturer of the end system that gets blamed even if it was the fault of their supplier.
Before you say, "They should have used a more reputable supplier!", keep in mind that the spontaneously combusting PowerBook fiasco was the fault of batteries from (I believe) either Sharp or Sony, I can't recall which but at the time they were the #1 manufacturer of Li-Ion batteries in the world.
So? The same goes for any driver. Drivers must be maintained for compatibility. I have never seen a case where the NVidia drivers were broken by a kernel and I couldn't find a patch that fixed it when I needed it, i.e. people start working on patching the drivers during the kernel prerelease phase.
Their silicon is just crippled - there's honestly no way around that when you're effectively producing a $5 graphics solution (which is approximately the cost difference between Intel chipsets without integrated graphics and Intel chipsets with integrated graphics.) Even if a technology is economical to implement in silicon, at that price point it's not feasible to license technologies from other companies unless absolutely necessary, such as S3 Texture Compression, which was the technology that basically started the branch between closed-source and open-source ATI chipset support.
It does what it's designed to do extremely well (unlike many other "el cheapo" solutions which are designed to do more but just don't do any of it well), it just simply is NOT designed to do very much.
This may no longer be the case, but back in March/April or so, E1505s and E1705s were easier to get running under Linux with NVidia cards than Intel cards. The GMA950 drivers were just plain Not Ready Yet, despite the existence of documentation for that driver.
My E1705 with a 7800 Go worked flawlessly from day one, but I saw numerous reports indicating that getting the GMA950 working was possible but a massive nightmare. I'm pretty sure things have improved in the past few months now that there has been time for the GMA950 drivers to improve, but the fact is that the closed-source NV drivers had mature and stable support before the open-source fully-documented drivers for the Intel chip.
Or, more specifically, providing such documentation is forbidden by companies they license crucial technologies from.
Companies have one of two choices in such situations: 1) License the technologies, and only release incomplete documentation not covering those technologies. (ATI, NVidia's approach) 2) Don't use such technologies, allowing the release of complete documentation but crippling the chipset. (Intel's approach).
Chances are they have licensed things in their silicon implementation that they are forbidden to release documentation for.
You seem to have forgotten that ATI cards were fully documented until about 2002-2003 or so, when they started licensing technologies from other companies that were forbidding them from releasing documentation or open-source drivers for said technologies.
The Unreal Tournament 2003/S3 Texture Compression fiasco showed that not licensing such technologies would be commercial suicide. ATI started releasing closed-source drivers shortly after that incident, and initially the main difference was S3TC support.
"Closed-source Linux drivers can work well enough for a single kernel version in a controlled environment."
Or you have a closed-source driver with a "kernel glue" abstraction layer that DOES have source available.
This is how NVidia does things with their binary drivers, and it requires neither a single kernel version nor a controlled environment. It works perfectly fine with "roll your own" kernels and oddball distributions.
Open source drivers would be nice, but the fact is that NV's drivers Just Plain Work.
"That's a stupid excuse, though. They could always isolate the SGI-laden parts, LGPL the rest, and let the community at least have a fighting chance at replacing what's behind the proprietary API's. I'm not claiming that our homebrew routines would *ever* be better, but I suppose it is within the realm of possibility. Oh, and when I say "always", I do really mean *always*... at any point, even right this minute, they could do so." They tried that. After a while it Simply Didn't Work - It's not just SGI, and in fact the particular issue that I remember was support for S3 Texture Compression, aka S3TC. For whatever reason, the licensing of S3TC prevented them from ever supporting it in an open-source driver.
ATI started releasing binary-only drivers for Linux shortly after the UT2003 S3TC support fiasco. (In short, UT2K3 would only run on NVidia cards under Linux because they were the only ones that supported S3TC under Linux.)
"Traditionally, Linux support of new notebook video chips was very uncertain, as it is not possible to get a new notebook with a 2 year old graphics controller."
That's a load of bullshit. Even the most recent NVidia mobile chipsets work absolutely fine under Linux. In fact, my Dell E1705 (Core Duo, NVidia 7800 Go) has not had a single problem with any component under Linux since April, and the only problems I have ever had were with sound due to the drivers taking a month or two for the headphone detection code to get stabilized. I have not had a single video problem of any kind, despite the fact that the video chipset in my laptop is brand new.
It's not exactly wireless... Yes, the toothbrush and the power supply ARE physically isolated, but essentially it is done by making the toothbrush and its power supply each half of a standard transformer.
Let's just say that as soon as the coils of the transformer are no longer actually *inside* of each other as they are in such electric toothbrushes, efficiency goes way down. Also in the case of those electric toothbrushes, efficiency was way down to begin with. I used to have one of those, it was a perfect example of inductive heating...
Most such "abuses" become useless/irrelevant with any situation these cards would be put into. i.e. in most cases there will be one of the following on the other end of the cable:
1) A cable/DSL modem with an ethernet bridge. i.e. the network is only being used as a point-to-point link 2) A switch - no one uses hubs any more. Again, since CSMA/CD is effectively never used in this situation, tweaking its behavior does nothing.
Unrelated to your post 3) Most games use UDP - Almost every "network accelerator card" I've seen was designed to offload the complexity of TCP. UDP and IP are incredibly simple and there is little to no benefit whatsoever to trying to accelerate them.
If you use an EVDO-enabled phone (such as the aforementioned RAZR), your data service is an add-on option to your voice contract which you can remove from your contract at any time.
If you use a seperate data card (or this new USB dongle), you are required to get a contract just for data service.
So this new USB adapter gives you less but makes more money for the provider.
As I mentioned in my post, even a limited form of multicast such as explicit multicast (Google for xcast) solves both the issue of limited multicast groups and of massive routing tables. It isn't as formalized a standard as traditional IP Multicast, but that doesn't really matter since IP Multicast is basically not implemented by anyone except in very limited scopes. Yes, xcast has its own limitations (limit on number of destinations from the maximum size of an IP datagram, and the potential for "spam" style abuse), but even if xcast (or a similar approach) were limited to a maximum of x (say, 8 for example) recipients per datagram by routers, it would present a MASSIVE advantage for P2P.
It looks like (from TFA), there will be restrictions in place that only allow caching of non-copyrighted, legal content.
It goes a LONG way towards legitimizing BitTorrent in case anyone tries to sue Bram, but contains no real-world benefits.
If ISPs want to reduce bandwidth overuse by seeders... Just IMPLEMENT MULTICAST ALREADY!
Yes, I realize multicast has historically presented major problems in scalability at the backbone router level, but with modern processing power and memory economics, it shouldn't be that difficult to implement now, and in the end presents far more benefits (massive reduction in bandwidth usage) than its disadvantages (backbone routers need some pretty hefty amounts of memory to track all of the multicast groups.)
Even "limited" multicast solutions like xcast (explicit multicast - basically instead of sending to a "multicast group" an IP datagram is given multiple destinations) would result in MASSIVE reductions in bandwidth usage by P2P applications like BitTorrent.
Due to the nature of BitTorrent and how it is used in general, caching is just an extremely hackish and limited way of implementing a shitty form of multicast... If the backbone supported multicast, there wouldn't be any need for caching of torrents.
Slashdot Mirror
False. Cell phones DO work at high altitudes. High altitudes gives them good LOS to multiple cell towers.
What IS true and a scientifically proven fact is that cell phones at high altitudes create unusually high loads on the cellular network. See what I said earlier about good LOS to *multiple* towers? The end result is that instead of appearing as a user on one tower on a given frequency and nowhere else, it appears as a user or a strong interferer on many towers.
The end result is that while a cell network may have the capacity to server N users on the ground per cell, it can only support a total of around N users in the air for ALL cells within LOS of the aircraft. This is why the ban on airborne cell phones was originally an FCC rule, not an FAA one.
And before anyone brings up that TFA does mention "clocking", the impression I get is that the writer of the article isn't very technically literate and doesn't really understand the difference between RF circuitry and clocked logic circuitry. See the comment about mobile phones operating in the 1 GHz range - even the fastest smartphones have a CPU clock speed of only 400-500 MHz at most, but mobile phones have been operating with RF carriers close to 1 GHz (specifically 800 and 900 MHz) for 15-20 years, and the 1.8 and 1.9 GHz bands have been in use for close to a decade too. Satellite communications systems frequently operate in the 10-20 GHz region. I don't see any case where the researchers are directly quoted talking about using their new developments for logic circuitry, but a few where they are implying using the new stuff for RF.
No, because whenever Slashdot covers these ultra-high-frequency transistors, they never bother mentioning that there's a huge difference between transistors optimized for logic (always on/off, usually very high drive levels and low gain, fast switching of square waves) and transistors designed for RF signal amplification (Usually designed for linear amplification of sinusoidal or modulated sinusoidal signals, lower drive levels with higher gain, and no one cares about the switching time, just the highest frequency sinusoid at which the device exhibits gain.) In essentially every case, the article is covering amplification of a signal at the record-setting frequency, not operation of a logic gate at that frequency.
There is also a very good chance that while the manufacturing process may be suitable for single (relatively) large tranistors (perfectly suitable, and often desireable for RF), it is not suitable for integrated circuits with multiple tranistors and other components on a die. Gallium Arsenide is a perfect example of this - The IC industry gave up on it pretty quickly because it was simply too difficult to make integrated circuits with it and the performance benefits for logic circuits weren't worth the costs, but manufacturers of RF transistors are still putting large amounts of effort into GaAs and plenty of commercial products exist. (Yes, there are still issues with GaAs technology and a lot of companies still don't trust GaAs in their products except in low-volume high-performance applications, but it's not like logic circuits where nothing exists on the market.)
Same thing with IBM's big SiGe push - great for RF but doesn't seem to have made any inroads to logic, probably due to cost issues and technical problems that make SiGe potentially unsuitable for logic but don't really affect their RF performance.
Most likely, AIX may also have some code in it that prevents them from open-sourcing it due to licensing.
Keep in mind they're already in enough legal battles over intellectual property licensing. While SCO's claims regarding IBM and Linux may be trollish, the impression I get is that SCO WOULD actually have significant legitimate claims against an "open source" AIX.
The end result is that rather than opensourcing AIX (which would be a rather pointless endeavor as the impression I get is that IBM is "sunsetting" it in favor of Linux), IBM is simply taking all of the Good Parts from AIX which they can and merging them into Linux.
Remember, open-sourcing a product isn't always a simple matter of taking a snapshot of your source tree, making it public, and adding a new license. Frequently, a company may not own all the code in a program and can't open source it without ripping out some of their code and either spending time replacing/rewriting it or releasing what is essentially open-source crippleware. In a situation where there is no even remotely competitive open-source alternative (see Quake and Mozilla), it makes sense to release crippleware and let the community fill in the holes over time, as even if it takes the community years (Mozilla/Firefox) to fix the holes, it still puts them way ahead. In the case of AIX, there would be utterly no point whatsoever in releasing it if IBM were required by licensing agreements to remove critical parts. Unlike Mozilla, with AIX there's a healthy and robust open-source competitor which would be dominant in developer and user mindshare even if it were open-sourced in complete form.
Potentially yes
Remember that the SR-71 was a recon aircraft. Why make a recon aircraft that can fly faster/higher when you can just upgrade the optics and imager on a satellite and get improved results, less risk of intelligence asset loss, and greater ground coverage from a bunch of satellites?
The sad thing is, that Sony is probably the best manufacturer of Li-Ions you can buy from.
They get so much bad press for their batteries simply because of their market dominance in the battery market. The catastrophic failure rate for batteries from other manufacturers is much higher, it just happens that many of them (such as cheap knockoff cell phone batteries) are not as low profile as exploding Dells, partly due to the reduced size of cell phone batteries.
The simple fact of the matter is that lithium ion batteries are nasty temperamental things and very easy to cause to explode. There's a reason why (to my knowledge) only Li-Ion has the restriction that bare cells may not be sold to anyone other than people licensed to work with Li-Ions in the U.S. (Any place you order "bare cells" from will have a disclaimer stating that the cells are in a pack with protective circuitry of unknown functionality.)
I'm surprised your deception-through-misinformation post was moderated up.
In the U.K., I believe ALL portable electronics are forbidden in carry-on luggage. Laptops and all other electronics must be in checked baggage. (This is for the same reason the U.S. is banning all liquids in carry-on luggage.)
Make sure you are exporting in a standard DVD resolution/format/framerate.
Some export utilities will allow you to export resolutions that are valid MPEG-2 but not compliant with the MPEG-2 subset used with DVDs. The end result is usually that PC-based players will play it fine, some standalones play it fine, some standalones will do weird things when playing it, and some standalones won't play it at all.
"Even with all these exploding Dell notebooks and other notebook safety problems, Apple has seemed relatively immune."
The original submitter doesn't seem to remember that Apple was one of the first manufacturers to have exploding/spontaneously combusting batteries in their laptop. Not only are they NOT relatively immune, they were the first to have a problem.
It doesn't matter who you are, if your battery supplier screws up, this problem can affect any company that uses lithium ion batteries. Since there are only a handful of manufacturers of lithium ion batteries, if there is some sort of quality control slipup (it happens at even the best of companies), you potentially have a few timebombs on your hands. Of course, it's the manufacturer of the end system that gets blamed even if it was the fault of their supplier.
Before you say, "They should have used a more reputable supplier!", keep in mind that the spontaneously combusting PowerBook fiasco was the fault of batteries from (I believe) either Sharp or Sony, I can't recall which but at the time they were the #1 manufacturer of Li-Ion batteries in the world.
So? The same goes for any driver. Drivers must be maintained for compatibility. I have never seen a case where the NVidia drivers were broken by a kernel and I couldn't find a patch that fixed it when I needed it, i.e. people start working on patching the drivers during the kernel prerelease phase.
Intel DOES release full specifications.
Their silicon is just crippled - there's honestly no way around that when you're effectively producing a $5 graphics solution (which is approximately the cost difference between Intel chipsets without integrated graphics and Intel chipsets with integrated graphics.) Even if a technology is economical to implement in silicon, at that price point it's not feasible to license technologies from other companies unless absolutely necessary, such as S3 Texture Compression, which was the technology that basically started the branch between closed-source and open-source ATI chipset support.
It does what it's designed to do extremely well (unlike many other "el cheapo" solutions which are designed to do more but just don't do any of it well), it just simply is NOT designed to do very much.
This may no longer be the case, but back in March/April or so, E1505s and E1705s were easier to get running under Linux with NVidia cards than Intel cards. The GMA950 drivers were just plain Not Ready Yet, despite the existence of documentation for that driver.
My E1705 with a 7800 Go worked flawlessly from day one, but I saw numerous reports indicating that getting the GMA950 working was possible but a massive nightmare. I'm pretty sure things have improved in the past few months now that there has been time for the GMA950 drivers to improve, but the fact is that the closed-source NV drivers had mature and stable support before the open-source fully-documented drivers for the Intel chip.
Or, more specifically, providing such documentation is forbidden by companies they license crucial technologies from.
Companies have one of two choices in such situations:
1) License the technologies, and only release incomplete documentation not covering those technologies. (ATI, NVidia's approach)
2) Don't use such technologies, allowing the release of complete documentation but crippling the chipset. (Intel's approach).
Chances are they have licensed things in their silicon implementation that they are forbidden to release documentation for.
You seem to have forgotten that ATI cards were fully documented until about 2002-2003 or so, when they started licensing technologies from other companies that were forbidding them from releasing documentation or open-source drivers for said technologies.
The Unreal Tournament 2003/S3 Texture Compression fiasco showed that not licensing such technologies would be commercial suicide. ATI started releasing closed-source drivers shortly after that incident, and initially the main difference was S3TC support.
"Closed-source Linux drivers can work well enough for a single kernel version in a controlled environment."
Or you have a closed-source driver with a "kernel glue" abstraction layer that DOES have source available.
This is how NVidia does things with their binary drivers, and it requires neither a single kernel version nor a controlled environment. It works perfectly fine with "roll your own" kernels and oddball distributions.
Open source drivers would be nice, but the fact is that NV's drivers Just Plain Work.
"That's a stupid excuse, though. They could always isolate the SGI-laden parts, LGPL the rest, and let the community at least have a fighting chance at replacing what's behind the proprietary API's. I'm not claiming that our homebrew routines would *ever* be better, but I suppose it is within the realm of possibility. Oh, and when I say "always", I do really mean *always*... at any point, even right this minute, they could do so."
They tried that. After a while it Simply Didn't Work - It's not just SGI, and in fact the particular issue that I remember was support for S3 Texture Compression, aka S3TC. For whatever reason, the licensing of S3TC prevented them from ever supporting it in an open-source driver.
ATI started releasing binary-only drivers for Linux shortly after the UT2003 S3TC support fiasco. (In short, UT2K3 would only run on NVidia cards under Linux because they were the only ones that supported S3TC under Linux.)
"Traditionally, Linux support of new notebook video chips was very uncertain, as it is not possible to get a new notebook with a 2 year old graphics controller."
That's a load of bullshit. Even the most recent NVidia mobile chipsets work absolutely fine under Linux. In fact, my Dell E1705 (Core Duo, NVidia 7800 Go) has not had a single problem with any component under Linux since April, and the only problems I have ever had were with sound due to the drivers taking a month or two for the headphone detection code to get stabilized. I have not had a single video problem of any kind, despite the fact that the video chipset in my laptop is brand new.
No, the voltage on telephone wires is more like 90v with a high resistance.
The guy you're replying to was referring to -48VDC power supplies for telco rack equipment, which is NOT low-current stuff.
In the case of 802.11, there's a lot of overhead. You can usually expect real-world performance to be 50-75% of the signaling rate.
Yes, a 7 Mbps connection could easily overload an 11b connection. 11g? Not going to happen unless something is wrong.
It's not exactly wireless... Yes, the toothbrush and the power supply ARE physically isolated, but essentially it is done by making the toothbrush and its power supply each half of a standard transformer.
Let's just say that as soon as the coils of the transformer are no longer actually *inside* of each other as they are in such electric toothbrushes, efficiency goes way down. Also in the case of those electric toothbrushes, efficiency was way down to begin with. I used to have one of those, it was a perfect example of inductive heating...
Most such "abuses" become useless/irrelevant with any situation these cards would be put into. i.e. in most cases there will be one of the following on the other end of the cable:
1) A cable/DSL modem with an ethernet bridge. i.e. the network is only being used as a point-to-point link
2) A switch - no one uses hubs any more. Again, since CSMA/CD is effectively never used in this situation, tweaking its behavior does nothing.
Unrelated to your post
3) Most games use UDP - Almost every "network accelerator card" I've seen was designed to offload the complexity of TCP. UDP and IP are incredibly simple and there is little to no benefit whatsoever to trying to accelerate them.
If you use an EVDO-enabled phone (such as the aforementioned RAZR), your data service is an add-on option to your voice contract which you can remove from your contract at any time.
If you use a seperate data card (or this new USB dongle), you are required to get a contract just for data service.
So this new USB adapter gives you less but makes more money for the provider.
Dammit, where are my mod points when I need them for a +1 Utterly Hilarious. :)
As I mentioned in my post, even a limited form of multicast such as explicit multicast (Google for xcast) solves both the issue of limited multicast groups and of massive routing tables. It isn't as formalized a standard as traditional IP Multicast, but that doesn't really matter since IP Multicast is basically not implemented by anyone except in very limited scopes. Yes, xcast has its own limitations (limit on number of destinations from the maximum size of an IP datagram, and the potential for "spam" style abuse), but even if xcast (or a similar approach) were limited to a maximum of x (say, 8 for example) recipients per datagram by routers, it would present a MASSIVE advantage for P2P.
It looks like (from TFA), there will be restrictions in place that only allow caching of non-copyrighted, legal content.
It goes a LONG way towards legitimizing BitTorrent in case anyone tries to sue Bram, but contains no real-world benefits.
If ISPs want to reduce bandwidth overuse by seeders... Just IMPLEMENT MULTICAST ALREADY!
Yes, I realize multicast has historically presented major problems in scalability at the backbone router level, but with modern processing power and memory economics, it shouldn't be that difficult to implement now, and in the end presents far more benefits (massive reduction in bandwidth usage) than its disadvantages (backbone routers need some pretty hefty amounts of memory to track all of the multicast groups.)
Even "limited" multicast solutions like xcast (explicit multicast - basically instead of sending to a "multicast group" an IP datagram is given multiple destinations) would result in MASSIVE reductions in bandwidth usage by P2P applications like BitTorrent.
Due to the nature of BitTorrent and how it is used in general, caching is just an extremely hackish and limited way of implementing a shitty form of multicast... If the backbone supported multicast, there wouldn't be any need for caching of torrents.