It seems like HP is exclusively a GSM phone manufacturer, and has no CDMA offerings whatsoever.
Thus, not putting in UMTS would be a wise decision for them. Their units will have no problems competing in the U.S. on GSM-based providers, and they're not even bothering to try competing with EV-DO capable CDMA phones - they won't work on Verizon or Sprint networks at all.
There's a chance that some idiot reporter did s/UMTS/3G/.
UMTS is still an infant technology with very few successful rollouts outside of the U.S. and no rollouts whatsoever within the U.S. HP would be very smart not to support UMTS, given its abysmal track record.
On the other hand, not supporting CDMA2000 1xEV-DO in the U.S. market would be suicidal with any new smartphone. Note that it seems like this announcement was made by one of their Asian region VPs, so he may indeed have been talking about UMTS. From what I've heard, DoCoMo's UMTS rollout in Japan was a huge flop (handsets with horrible battery life/major overheating problems) while KDDI's EV-DO rollout went very well.
Multi streaming does not mean multicast. Multi streaming means multiple substreams in one connection. Good for voice trunks (each stream is a voice channel), no benefit for torrents (each connection between two peers usually carries data from only one source.)
Multicast would rock for a P2P distribution system, even "explicit multicast" which has a rather low limit on the number of destinations, as opposed to IP multicast which has no limit on the number of destinations but presents a nightmare for backbone providers. (State must be kept for every multicast group that a particular router handles traffic for.)
The performance of the extensions themselves are not necessarily the issue, but differences in the design of the CPUs.
Intel P4-series CPUs are infamous for their low performance-per-clock-cycle in most applications due to that deep 20+ stage pipeline which cripples the CPU when a pipeline stall occurs. In most applications, an AMD clocked at a much lower rate could beat an Intel CPU. Signal processing and video compression applications fall under the category of things that *don't* take a huge penalty from the P4's deep pipeline, and as a result for a while P4s were considered superior for video encoding/decoding/editing. Over time, the A64's kickass memory subsystem has eroded Intel's superiority in that one area.
That said, all of what I've said only applies to the P4, and not to the new Yonah (aka Core Duo) chips. A low-end Core Duo (presumably not locked out by Skype) will always get trashed by a mid-to-high-end Athlon 64 X2 in any app. In fact, even the lowest end X2 (2.0 GHz clock rate) will probably beat the lower end Core Duos in any application.
What happened is that in doing the cost/benefit analysis of the TDP plant for turkey offal, the analysts were counting on pending U.S. legislation that would ban the use of animal waste as animal feed. (Similar to laws that have been enacted in nearly every other country in order to combat mad cow disease.)
In the end, the law died out (a Bad Thing for U.S. meat consumers - agricultural industry money won out over concerns for public health.), and as a result what was originally going to become biological waste potentially classified as a biohazard which companies would have to PAY to dispose of, the status quo of being able to use animal leftovers as feed for other animals remained. The new oil plant isn't what made people decide to charge for their animal waste, they were ALREADY doing it.
In short, an increase in demand didn't cause the cost effectiveness of the TDP plant in Carthage to fail, but lack of an expected decrease in demand did.
Old style "bag phones" with 3W transmit power could possibly have the potential for causing contact RF burns if direct skin contact with the antenna were involved. The threshold for a burn is somewhere in the 3-5W range, and partly depends on which part of the antenna one touches (high voltage region vs. high current.) That said, it would be an extremely mild burn similar to brief contact with hot metal.
No cell phone I know of permits actual direct contact with the antenna element, plus 3W phones are a thing of the past. I think most handheld phones are in the region of 600 mW maximum for analog mode, and 200 mW for cdmaOne/CDMA2000. I know those were the specs for one of my first cdmaOne cell phones. I'm not sure about UMTS, GSM, or D-AMPS.
Note that the types of RF burns described are almost exactly the same as thermal burns until you get to power levels high enough to start internal cooking. It'll hurt, your skin will be red and sensitive, but you won't get cancer.
Yeah, for example, any potential damage caused by RF exposure is from heating of the tissue. Microwave radiation is an entirely different beast from nuclear radiation. Nuclear radiation consists of high energy particles (alpha and beta particles), and extremely high energy electromagnetic radiation (gamma rays) which have shorter wavelengths (higher energy) than visible light. High energy radiation has the ability to "flip bits" in our DNA and other nasty effects that cause permanent and cumulative damage even at low levels.
Cell phones, on the other hand, emit extremely low-energy electromagnetic radiation, with wavelengths on the order of 10-30 cm depending on the exact frequency band they operate at. (30 cm = 1 GHz, 10 cm = 3 GHz). Visible light is in the area of 400-700 *nano*meters.
Thus, cells that may be damaged in culture where they have no way of dissipating extra heat from RF absorption may not be affected in any way within a human body where blood flow will carry away extra heat. RF only becomes dangerous when the heating from RF absorbtion exceeds the body's ability to manage it, at which point you literally start cooking.
I believe the rationale for removing MP3 support "by default" from FC (and numerous other distributions) is that the MP3 patents are free for non-profit use. i.e. if you give your software away for free, no patent royalties apply (at least for players.)
But you say these OSes are free? Not quite, nothing in the GPL (or most other FOSS licenses) prevents you from selling something which includes the software. Take a look at cheapbytes.com, or any other company that sells pre-burned Linux distros on CDs. For these people, it would NOT be legal to sell a Linux distro that had MP3 playback support. This is why most distros don't include it on the default distro CDs but do include it in their repositories - It's not legal for the CD vendors to sell Linux distros with MP3 capability without royalties, but it is legal to have all the packages on a distribution mirror as long as you do not charge for access to that mirror, effectively "selling" the MP3 playback software.
Gold-on-gold contacts are very corrosion resistant. (Gold-on-other-metal contacts will cause the "other metal" to corrode faster though. So if you want gold plated electronic connectors, make sure BOTH sides of the connection are gold plated.)
It's not a full hybrid, but it still has the electric motor.
(Actually, if the motor can be in any way charged from the TDI engine, it's a hybrid, although a hybrid diesel without regenerative braking is kind of pointless except for the insane acceleration from having a 200 HP electric motor added to a 200 HP traditional engine. 90% of the benefits of converting a diesel vehicle to be a hybrid would be from regenrative braking.)
BTW, to those who don't know - While the power output of internal combustion engines is proportional to RPM (to a point, at the extreme low and high RPM regions torque suffers, which also reduces power.), the power capability of an electric motor is essentially fixed. An ideal electric motor at 0 RPM will have infinite torque. In reality, the torque is not inifinite, but is extremely high.
For various reasons, diesels do not have nearly the efficiency penalty that gasoline engines do when operating at low loads. As a result, resizing the engine to be smaller won't really help that much. Plus most of the acceleration comes from the electric motor I suspect, just as it does with most other hybrids.
BTW, the main reason diesels are so much more efficient than gasoline engines is the way they are throttled. In a gasoline engine (Otto or Atkinson cycle), if the fuel burns too lean (too much air), the combustion temperature increases significantly and increases NOx emissions, and more importantly, tends to melt parts of the engine. The result is that to throttle down a gasoline engine, you can't just remove fuel - you need to remove AIR and adjust fuel delivery as appropriate, by essentially choking the engine's air supply. Thus at low loads the engine is essentially breathing through a tiny straw, and paying penalties in pumping losses.
Diesels, on the other hand, usually do not have any throttles in their air intake, they CAN be throttled simply by adjusting fuel supply. (I'm not sure why it is that they don't have to deal with lean burning, I'm guessing that one reason is that fuel is injected during the combustion cycle, rather than being premixed prior to ignition.) Since the engine never has to breathe through a straw (Although I think some large trucks do have options for switching a restrictor into the exhaust to allow for engine breaking), it can operate much more efficiently at low loads.
Diesels also happen to have higher peak efficiencies, but that doesn't affect choice of engine sizing nearly as much as the lack of pumping losses at low loads.
You probably know this, but the GP poster probably doesn't since he didn't know about/etc/portage/package.keywords to begin with
In addition to "some-category/package ~x86" to unmask all ~x86 versions of the package, you can use
"=some-category/package-x.y.z ~x86" to unmask just one version. i.e. if you want a more recent version of a package to get Some Nifty New Feature you really want, but don't always want that package to be on the bleeding edge. You can also use , and a few other things.
For example, you might want to do such a thing for KDE so that you can use 3.5 but don't want 4.0 to be emerged when it is released until the Gentoo devs have polished things a bit w.r.t. Gentoo integration. So perhaps "kdes-category-i-cant-remember/kde-4.0 ~x86" to unmask all KDE versions below 4.0.
"=kdes-category-i-cant-remember/kde-3.5* ~x86" will unmask all 3.5.x versions of KDE. (BTW, for some reason, x.y* works but not x.y.*)
They were unsuspecting when they received the tissue.
Then the "morgue bust" was made, and the police started auditing the paper trail.
That trail eventually let to many recipients being notified that they may have received transplants of unkown origin. Like the guy in the article who was notified a year or two after receiving bone fragments that they may have come from a questionable source, who had himself tested and discovered that he had Hepatitis A.
I have a C3030Z and was able to get it working with gphoto2 back in Fall 2000ish when I got one as a birthday gift.
The process was a bit convoluted though, I eventually moved to using a Smartmedia to CF adapter because it was MUCH faster than the Olympus USB link under Linux or Windows. I'm sure things have improved in the nearly six years since support for that camera was added.
I just recently complete an M.S. in Electrical Engineering at Rutgers University.
Despite being a state school where New Jersey residents get *DIRT CHEAP* tuition (thus nullifying the cost/reward argument some people have made against graduate school), the graduate engineering programs at Rutgers (at least EE) are utterly dominated by foreign students. In many of my classes, I was the *ONLY* U.S. citizen out of 10-20 students in the class. Figures of enrollment in U.S. graduate schools are most definately not inflated by any means. The author clearly has no clue - he's been looking at papers and studies (probably finding ones biased in his desired direction), he hasn't actually experienced first hand the sad state of non-foriegn enrollment in U.S. graduate programs.
Even though I feel that Rutgers' program was substandard (I got what I paid for), the increase in starting pay from having my M.S. at my new job will pay for the costs of my M.S. within 4-5 years.
This article is talking about allowing *PAYING* users to use their music as they please, not about giving users music for free.
I own a Treo 650. It is my only portable device other than my laptop. It will stay that way until I replace it wholesale with another PDA/phone combo.
I will willingly pay for music, under one condition - it will play back on my Treo. This means no DRM. I HAVE purchased music from iTMS during the periods where PyMusique worked, and I have never made the un-DRMed purchased tracks available to anyone else.
If it won't play back on my Treo and can't be played under Linux, I won't pay for it. It's simple as that. If both of those conditions are met, I will (and have) paid for my music.
More importantly than distance-related losses, I'm pretty sure that the GPS satellites have directional antennas which point downwards towards the Earth.
Of course, if a satellite is "rising" from behind the Earth relative to the Moon, then the Moon might be in its antenna pattern, but the satellites with the best LOS to the Moon will have their antennas pointed in the opposite direction.
If the files are encrypted for each individual user, then many approaches for saving bandwidth (peer-to-peer, multicast) are no longer usable, because the content is different for each user.
Thus, a switch to legal downloads (with the assumption of accompanying DRM) will cause massive bandwidth problems near the source of the content, because DRM forces a centralized distribution topology.
(The one exception is if a content provider distributed many content servers all over the Internet which would perform encryption locally before serving up the content.)
I would say that many BitTorrent swarms (I've seen some with 10,000+ users) would qualify here.
Yes, BitTorrent doesn't currently support multicast, but if networks actually supported multicast it wouldn't be long before it was either integrated into BT or as a sort of "back channel" for BT.
Multicast would also be a great way to "push" content to local caches.
As someone else pointed out, IP Multicast in its current implementation presents some scalability problems, probably one of the main reasons it hasn't been implemented. What crack were its designers smoking when they came up with a system so complex and difficult for implementers to understand?
Admittedly, there isn't really any "magic bullet" solution, but at least an approach more similar to XCAST ( http://www.google.com/search?hl=en&q=XCAST&btnG=Go ogle+Search ) is much easier to implement and would have provided some short-term benefits. (Yes, it has its limitations, such as a relatively low maximum number of recipients, but still, 16 recipients of an IP packet is a lot more efficient than 16 packets with one recipient, especially if the sender intelligently groups recipients to maximize the number of hops before the packet has to be split to multiple routes.) The basic idea of XCAST is similar to SMTP - one packet with multiple recipients that is split as needed. Of course, this has some problems (packet spam), which is why it would make sense to limit an approach like XCAST to 8 or 16 recipients per transmitted packet. Still, intelligent grouping of every 8-16 recipients would essentially cut used bandwidth by a factor of 8-16.
Simple. The Via Unichromes go WAY beyond XvMC. They're not quite the "full blown" MPEG decoders that take an MPEG stream in and pipe video out, but unlike basic XvMC video cards (which accelerate IDCT, MoComp, and scaling, to the tune of 30-50% reduction in CPU load), they accelerate more MPEG functionality, in the end offloading 80-90% or more of the MPEG-2 decoding tasks.
In the process of tying to "bite off" more of the MPEG-2 processing load, they are subject to the same restrictions as most of the full-blown dedicated MPEG-2 decoders. The original Unichromes were only capable of accelerating SD content like 90% of the dedicated MPEG-2 decoders on the market, only the CN400 is capable of accelerating high definition MPEG-2 decoding.
Slashdot Mirror
It seems like HP is exclusively a GSM phone manufacturer, and has no CDMA offerings whatsoever.
Thus, not putting in UMTS would be a wise decision for them. Their units will have no problems competing in the U.S. on GSM-based providers, and they're not even bothering to try competing with EV-DO capable CDMA phones - they won't work on Verizon or Sprint networks at all.
There's a chance that some idiot reporter did s/UMTS/3G/.
UMTS is still an infant technology with very few successful rollouts outside of the U.S. and no rollouts whatsoever within the U.S. HP would be very smart not to support UMTS, given its abysmal track record.
On the other hand, not supporting CDMA2000 1xEV-DO in the U.S. market would be suicidal with any new smartphone. Note that it seems like this announcement was made by one of their Asian region VPs, so he may indeed have been talking about UMTS. From what I've heard, DoCoMo's UMTS rollout in Japan was a huge flop (handsets with horrible battery life/major overheating problems) while KDDI's EV-DO rollout went very well.
No, they're not releasing protocol specs from the looks of it. They're releasing a closed source library that people can write their apps around.
BTW, multi-protocol clients a la Gaim and Trillian are verboten with this new library.
Supposedly those problems were already fixed in Gaim 2.0. Try the betas if you're concerned with those features.
Multi streaming does not mean multicast. Multi streaming means multiple substreams in one connection. Good for voice trunks (each stream is a voice channel), no benefit for torrents (each connection between two peers usually carries data from only one source.)
Multicast would rock for a P2P distribution system, even "explicit multicast" which has a rather low limit on the number of destinations, as opposed to IP multicast which has no limit on the number of destinations but presents a nightmare for backbone providers. (State must be kept for every multicast group that a particular router handles traffic for.)
The performance of the extensions themselves are not necessarily the issue, but differences in the design of the CPUs.
Intel P4-series CPUs are infamous for their low performance-per-clock-cycle in most applications due to that deep 20+ stage pipeline which cripples the CPU when a pipeline stall occurs. In most applications, an AMD clocked at a much lower rate could beat an Intel CPU. Signal processing and video compression applications fall under the category of things that *don't* take a huge penalty from the P4's deep pipeline, and as a result for a while P4s were considered superior for video encoding/decoding/editing. Over time, the A64's kickass memory subsystem has eroded Intel's superiority in that one area.
That said, all of what I've said only applies to the P4, and not to the new Yonah (aka Core Duo) chips. A low-end Core Duo (presumably not locked out by Skype) will always get trashed by a mid-to-high-end Athlon 64 X2 in any app. In fact, even the lowest end X2 (2.0 GHz clock rate) will probably beat the lower end Core Duos in any application.
What happened is that in doing the cost/benefit analysis of the TDP plant for turkey offal, the analysts were counting on pending U.S. legislation that would ban the use of animal waste as animal feed. (Similar to laws that have been enacted in nearly every other country in order to combat mad cow disease.)
In the end, the law died out (a Bad Thing for U.S. meat consumers - agricultural industry money won out over concerns for public health.), and as a result what was originally going to become biological waste potentially classified as a biohazard which companies would have to PAY to dispose of, the status quo of being able to use animal leftovers as feed for other animals remained. The new oil plant isn't what made people decide to charge for their animal waste, they were ALREADY doing it.
In short, an increase in demand didn't cause the cost effectiveness of the TDP plant in Carthage to fail, but lack of an expected decrease in demand did.
Old style "bag phones" with 3W transmit power could possibly have the potential for causing contact RF burns if direct skin contact with the antenna were involved. The threshold for a burn is somewhere in the 3-5W range, and partly depends on which part of the antenna one touches (high voltage region vs. high current.) That said, it would be an extremely mild burn similar to brief contact with hot metal.
No cell phone I know of permits actual direct contact with the antenna element, plus 3W phones are a thing of the past. I think most handheld phones are in the region of 600 mW maximum for analog mode, and 200 mW for cdmaOne/CDMA2000. I know those were the specs for one of my first cdmaOne cell phones. I'm not sure about UMTS, GSM, or D-AMPS.
Note that the types of RF burns described are almost exactly the same as thermal burns until you get to power levels high enough to start internal cooking. It'll hurt, your skin will be red and sensitive, but you won't get cancer.
Yeah, for example, any potential damage caused by RF exposure is from heating of the tissue. Microwave radiation is an entirely different beast from nuclear radiation. Nuclear radiation consists of high energy particles (alpha and beta particles), and extremely high energy electromagnetic radiation (gamma rays) which have shorter wavelengths (higher energy) than visible light. High energy radiation has the ability to "flip bits" in our DNA and other nasty effects that cause permanent and cumulative damage even at low levels.
Cell phones, on the other hand, emit extremely low-energy electromagnetic radiation, with wavelengths on the order of 10-30 cm depending on the exact frequency band they operate at. (30 cm = 1 GHz, 10 cm = 3 GHz). Visible light is in the area of 400-700 *nano*meters.
Thus, cells that may be damaged in culture where they have no way of dissipating extra heat from RF absorption may not be affected in any way within a human body where blood flow will carry away extra heat. RF only becomes dangerous when the heating from RF absorbtion exceeds the body's ability to manage it, at which point you literally start cooking.
I believe the rationale for removing MP3 support "by default" from FC (and numerous other distributions) is that the MP3 patents are free for non-profit use. i.e. if you give your software away for free, no patent royalties apply (at least for players.)
But you say these OSes are free? Not quite, nothing in the GPL (or most other FOSS licenses) prevents you from selling something which includes the software. Take a look at cheapbytes.com, or any other company that sells pre-burned Linux distros on CDs. For these people, it would NOT be legal to sell a Linux distro that had MP3 playback support. This is why most distros don't include it on the default distro CDs but do include it in their repositories - It's not legal for the CD vendors to sell Linux distros with MP3 capability without royalties, but it is legal to have all the packages on a distribution mirror as long as you do not charge for access to that mirror, effectively "selling" the MP3 playback software.
Ever heard of gold plated connectors?
Gold-on-gold contacts are very corrosion resistant. (Gold-on-other-metal contacts will cause the "other metal" to corrode faster though. So if you want gold plated electronic connectors, make sure BOTH sides of the connection are gold plated.)
It's not a full hybrid, but it still has the electric motor.
(Actually, if the motor can be in any way charged from the TDI engine, it's a hybrid, although a hybrid diesel without regenerative braking is kind of pointless except for the insane acceleration from having a 200 HP electric motor added to a 200 HP traditional engine. 90% of the benefits of converting a diesel vehicle to be a hybrid would be from regenrative braking.)
BTW, to those who don't know - While the power output of internal combustion engines is proportional to RPM (to a point, at the extreme low and high RPM regions torque suffers, which also reduces power.), the power capability of an electric motor is essentially fixed. An ideal electric motor at 0 RPM will have infinite torque. In reality, the torque is not inifinite, but is extremely high.
For various reasons, diesels do not have nearly the efficiency penalty that gasoline engines do when operating at low loads. As a result, resizing the engine to be smaller won't really help that much. Plus most of the acceleration comes from the electric motor I suspect, just as it does with most other hybrids.
BTW, the main reason diesels are so much more efficient than gasoline engines is the way they are throttled. In a gasoline engine (Otto or Atkinson cycle), if the fuel burns too lean (too much air), the combustion temperature increases significantly and increases NOx emissions, and more importantly, tends to melt parts of the engine. The result is that to throttle down a gasoline engine, you can't just remove fuel - you need to remove AIR and adjust fuel delivery as appropriate, by essentially choking the engine's air supply. Thus at low loads the engine is essentially breathing through a tiny straw, and paying penalties in pumping losses.
Diesels, on the other hand, usually do not have any throttles in their air intake, they CAN be throttled simply by adjusting fuel supply. (I'm not sure why it is that they don't have to deal with lean burning, I'm guessing that one reason is that fuel is injected during the combustion cycle, rather than being premixed prior to ignition.) Since the engine never has to breathe through a straw (Although I think some large trucks do have options for switching a restrictor into the exhaust to allow for engine breaking), it can operate much more efficiently at low loads.
Diesels also happen to have higher peak efficiencies, but that doesn't affect choice of engine sizing nearly as much as the lack of pumping losses at low loads.
You probably know this, but the GP poster probably doesn't since he didn't know about /etc/portage/package.keywords to begin with
In addition to
"some-category/package ~x86" to unmask all ~x86 versions of the package, you can use
"=some-category/package-x.y.z ~x86" to unmask just one version. i.e. if you want a more recent version of a package to get Some Nifty New Feature you really want, but don't always want that package to be on the bleeding edge. You can also use , and a few other things.
For example, you might want to do such a thing for KDE so that you can use 3.5 but don't want 4.0 to be emerged when it is released until the Gentoo devs have polished things a bit w.r.t. Gentoo integration. So perhaps
"kdes-category-i-cant-remember/kde-4.0 ~x86" to unmask all KDE versions below 4.0.
"=kdes-category-i-cant-remember/kde-3.5* ~x86" will unmask all 3.5.x versions of KDE. (BTW, for some reason, x.y* works but not x.y.*)
Ever heard of a typo?
(Yeah, even before your post I noticed that as soon as I reread my post.)
They were unsuspecting when they received the tissue.
Then the "morgue bust" was made, and the police started auditing the paper trail.
That trail eventually let to many recipients being notified that they may have received transplants of unkown origin. Like the guy in the article who was notified a year or two after receiving bone fragments that they may have come from a questionable source, who had himself tested and discovered that he had Hepatitis A.
In short - RTFA.
I have a C3030Z and was able to get it working with gphoto2 back in Fall 2000ish when I got one as a birthday gift.
The process was a bit convoluted though, I eventually moved to using a Smartmedia to CF adapter because it was MUCH faster than the Olympus USB link under Linux or Windows. I'm sure things have improved in the nearly six years since support for that camera was added.
The simplest explanation that I've seen so far is that Hymn has always depended on cracks by DVD Jon.
:)
DVD Jon is too busy enjoying the San Francisco bay area to do any reverse engineering at the moment.
(And the fact that he is now within the reach of the DMCA itself constitutes a problem too.)
I just recently complete an M.S. in Electrical Engineering at Rutgers University.
Despite being a state school where New Jersey residents get *DIRT CHEAP* tuition (thus nullifying the cost/reward argument some people have made against graduate school), the graduate engineering programs at Rutgers (at least EE) are utterly dominated by foreign students. In many of my classes, I was the *ONLY* U.S. citizen out of 10-20 students in the class. Figures of enrollment in U.S. graduate schools are most definately not inflated by any means. The author clearly has no clue - he's been looking at papers and studies (probably finding ones biased in his desired direction), he hasn't actually experienced first hand the sad state of non-foriegn enrollment in U.S. graduate programs.
Even though I feel that Rutgers' program was substandard (I got what I paid for), the increase in starting pay from having my M.S. at my new job will pay for the costs of my M.S. within 4-5 years.
This article is talking about allowing *PAYING* users to use their music as they please, not about giving users music for free.
I own a Treo 650. It is my only portable device other than my laptop. It will stay that way until I replace it wholesale with another PDA/phone combo.
I will willingly pay for music, under one condition - it will play back on my Treo. This means no DRM. I HAVE purchased music from iTMS during the periods where PyMusique worked, and I have never made the un-DRMed purchased tracks available to anyone else.
If it won't play back on my Treo and can't be played under Linux, I won't pay for it. It's simple as that. If both of those conditions are met, I will (and have) paid for my music.
More importantly than distance-related losses, I'm pretty sure that the GPS satellites have directional antennas which point downwards towards the Earth.
Of course, if a satellite is "rising" from behind the Earth relative to the Moon, then the Moon might be in its antenna pattern, but the satellites with the best LOS to the Moon will have their antennas pointed in the opposite direction.
Compared to a "whole Internet" implementation, any single organization does not count as large.
If the files are encrypted for each individual user, then many approaches for saving bandwidth (peer-to-peer, multicast) are no longer usable, because the content is different for each user.
Thus, a switch to legal downloads (with the assumption of accompanying DRM) will cause massive bandwidth problems near the source of the content, because DRM forces a centralized distribution topology.
(The one exception is if a content provider distributed many content servers all over the Internet which would perform encryption locally before serving up the content.)
I would say that many BitTorrent swarms (I've seen some with 10,000+ users) would qualify here.
o ogle+Search ) is much easier to implement and would have provided some short-term benefits. (Yes, it has its limitations, such as a relatively low maximum number of recipients, but still, 16 recipients of an IP packet is a lot more efficient than 16 packets with one recipient, especially if the sender intelligently groups recipients to maximize the number of hops before the packet has to be split to multiple routes.) The basic idea of XCAST is similar to SMTP - one packet with multiple recipients that is split as needed. Of course, this has some problems (packet spam), which is why it would make sense to limit an approach like XCAST to 8 or 16 recipients per transmitted packet. Still, intelligent grouping of every 8-16 recipients would essentially cut used bandwidth by a factor of 8-16.
Yes, BitTorrent doesn't currently support multicast, but if networks actually supported multicast it wouldn't be long before it was either integrated into BT or as a sort of "back channel" for BT.
Multicast would also be a great way to "push" content to local caches.
As someone else pointed out, IP Multicast in its current implementation presents some scalability problems, probably one of the main reasons it hasn't been implemented. What crack were its designers smoking when they came up with a system so complex and difficult for implementers to understand?
Admittedly, there isn't really any "magic bullet" solution, but at least an approach more similar to XCAST ( http://www.google.com/search?hl=en&q=XCAST&btnG=G
Simple. The Via Unichromes go WAY beyond XvMC. They're not quite the "full blown" MPEG decoders that take an MPEG stream in and pipe video out, but unlike basic XvMC video cards (which accelerate IDCT, MoComp, and scaling, to the tune of 30-50% reduction in CPU load), they accelerate more MPEG functionality, in the end offloading 80-90% or more of the MPEG-2 decoding tasks.
In the process of tying to "bite off" more of the MPEG-2 processing load, they are subject to the same restrictions as most of the full-blown dedicated MPEG-2 decoders. The original Unichromes were only capable of accelerating SD content like 90% of the dedicated MPEG-2 decoders on the market, only the CN400 is capable of accelerating high definition MPEG-2 decoding.