Could the bug have just been the result of the same failure in design?
Even worse - could it have been the result of very good emulation? I can see the comment now: "Blizzard's doing something funky with this with no good clear reason, but if we see this kind of packet act the same way Battle.net does even if it seems wrong."
The thing is, there is an almost garauntee that some block of code within Bnetd will resemble some block of code in Blizzards server software in some significant manner, simply because the two programs do the exact same thing.
I have to wonder how the assorted revisions of Blizzard's battle.net code look. Wouldn't it be interesting if upon review (and digging back to previous versions) it became apparent that some optimizations, etc. were strikingly similar to the bnetd code?
Sounds like this is similar to what MojoNation is/was trying to do. Their site doesn't seem to be responding right now, but here's the Google Cached version of the technical docs.
The US civilian GPS system supports something called Selective Availability or SA. Basically, it's possible for them to "degrade" the satellite signals slightly to make it much more difficult to get an accurate position reading. In addition it's possible to temporarily disable satellites in such a way as to prevent GPS from being used in a particular area, though this has a noticeable effect on accuracy in surrounding areas as well ("surrounding" = somewhere between 25% and 50% of the Earth's surface). Differential GPS (DGPS) is a way to eliminate the effects of SA for a local area, but requires a DGPS transmitter at a fixed location and additional hardware on each receiver.
Note that all of this applies to the civilian system - the GPS satellites also send out a separate (and encrypted) signal that can be used only with military GPS receivers. Those receivers include both decryption information which must be refreshed every 6 months and a quick 2-3 finger way to flush that information if the receiver is about to fall into enemy hands. All of this means that civilian GPS can be turned off completely without preventing the US military from using it. There are also other limitations in civilian equipment (won't work above 50,000 feet and/or 1000mph, etc.) to make it less suitable for some military use.
Until relatively recently, SA was always on, generally with an accuracy of around 50 meters. That meant basically that 95+% of the time the position reported by a GPS receiver was within 50 meters of the actual position of that receiver. SA can be turned up much higher to at least the 250-300 meter mark. The one exception for SA was actually during the Gulf War, when there were not enough military receivers available to meet demand. For a time, SA was turned off so that the military could conveniently use civilian GPS hardware. More recently (2-3 years ago, during the Clinton administration), SA was turned off or at least down to a minimal level, so consumer units can get an accuracy of 3-5 meters with only the satellite signals. SA is the reason that many civilian receivers have an "average position" function - the best way to get an accurate position was to leave the receiver on and averaging for a day or two.
A concern for foreign governments and at times for the US FAA has been that military control of the availability and accuracy of the signals - no foreign military wants to be dependent on the US for something vital, and the FAA was looking at ways to do more flight automation and didn't like the possibility that they might someday have automated planes landing using GPS when something happened and the military tweaked or turned off the signals. The foreign solution was to build their own system, which the Europeans have been talking about for years now (the Russian GLONASS system was never finished and isn't as accurate as the US system). The FAA solution was to look at putting up one or two satellites of their own, effectively acting as differential GPS transmitters to let aircraft filter out the effects of SA.
Really all of this is a consequence of the system being at its heart a US military system and everyone understanding that what they want is for the most part irrelevant to the US military.
There is (or was) a fairly active Usenet group for discussion of all this at sci.geo.satellite-nav.
I'd say that's the real irony behind the whole thing. He was trying to ghost the drive!
My nightmare on this was doing much the same thing, but instead of damaging pins I forgot to rejumper the drive. IDE chain with two master devices = thoroughly horked partition tables on both.
I was able to recover one of them using a package called Hard Drive Mechanic that basically examined the drive looking for the start and end of the partitions, but the "working" disk that had several partitions of different types and some intermediate empty space was unrecoverable and had to be completely wiped.
That sinking sensation when you plug the drive you were going to back up back into its original system and it's completely dead is just no fun at all....
If Sony can get these into businesses, the camera may be fine. It's also fine for minor little things like Japanese kids taking quick pictures of each other (along the lines of those little sticker photo machines you see occasionally imported from Japan).
For businesses, there are lots of things where a picture is needed but high resolution isn't important - I ran into someone the other day who has one of those wristwatch digital cameras and is quite happy with it for basic assessment use.
And that's for the Sony-branded ones. The SanDisk and Lexar ones are marginally cheaper. This is pricing from Pricewatch for the retail-packaged sticks.
Memory Stick prices have dropped enormously in price over the last six months to a year - they're still more expensive than CF, but they're no longer insanely expensive for what you get.
Things like sharing connections and the ability to run servers without having to worry about being cut off are a good reason to spend the extra money for a business-grade DSL connection. Sure it costs more, but for a lot of Slashdot readers the extra cost wouldn't be that much of an issue.
So it's actually working on the basis of webs of related sites - not a novel concept, but useful.
I suspect that some of the commercial knowledge management tools have been doing something much like this for some time, and TheBrain.com has had a product to manually build this kind of network of clusters for some time. The key thing about this is that with web indexing/cataloging the information needed to do the automatic linking is available.
TheBrain.com seems to have a working demo of using it for the Web at WebBrain.com based on the Open Directory Project. It's not a great example because of display limitations that don't really let you see more than one cluster of information at the time, but it's one example of the general concept. Once you dig down in an area you can see how it shows links between related categories as well.
Note: the demo above says it requires Java 1.1 and IE 4.01 or Netscape 4.07+, to bypass that test try here. Seems to work fine in Netscape 6.2, and will probably be OK in Mozilla if the JRE is available.)
Knowing who you're trying to keep secrets from is a big part of deciding how (and whether) to secure any data.
The needed approaches are radically different depending on whether you're trying to keep secrets from highly-skilled groups with plenty of resources (e.g. government agencies investigating you in particular), skilled groups with some resources (corporate espionage, small countries), snoopy ISPs (e.g. Comcast), skilled interested parties (IS groups), the casually curious (repair techs), and the unskilled (your grandmother). At the top end, you have to do all sorts of things that make using computers much more of a pain in the ass to keep them from adding keyboard sniffers, monitoring emissions, etc. At the low end, you have to learn how to hide files (using a.prefix or "hidden" flag, who cares) to keep your grandmother from being shocked by all that hot monkey lovin' in your porn archive. In between there are tradeoffs - how important is the information (do you need to keep it at all?), how important is it that it not be seen by others, how much inconvenience are you willing to go to to ensure that nobody else sees it?
Keep in mind that encryption isn't security. Encryption isn't even close to security. Encryption is a tool.
AT&T mentioned this in the internal support gr
on
Spam Slows AT&T Email
·
· Score: 2
The cause of the mail slowdown has been discussed in the worldnet.* internal groups.
When you read a lot, it's sometimes useful to use a program like ReaderWare to catalog your books. It even understands that spiffy CueCat you snagged and use as a nightlight.
This is actually something that has all sorts of potential, particularly with truly flexible and durable material. Xerox is also far from being the only company working on this - I think I've seen press on at least three, all with different technologies.
Consider the advantages of having an e-book using flexible, durable electronic paper. Make a sheet, perhaps eight inches by twelve. Put a couple of seams on it so it can be folded down to ~4x8. Now make it flexible enough to roll into a cylinder around (or inside) a 1.5-inch tube holding batteries, a few MB of RAM, and either flash memory or a memory card socket (memory stick or the MMC cards in Palms would both be good sizes).
Go through all the above, and what would you end up with? Something easy to read[1], easy to carry[2], capable of holding a large number of books (including school texts with illustrations, etc.), low-power[3], easy to use[4], and inexpensive[5].
Sure there'd be drawbacks - the lines across the page at the seams might be as much as an eighth of an inch apiece disrupting large images (affecting what % of books?); the display might be black & white (though this would likely change quickly); the display might wear out after a few hundred rollings/unrollings (so make it socketed); it might not be readable in the dark (so add a port for a Flylight-like LED).
With the exception of the electronic paper itself, there's nothing that would keep this from being manufactured today, probably for under $200. If there's enough market for e-books, I wouldn't be surprised to see something very much like this within two years.
Even at 150x150 resolution this wouldn't be difficult to read, and I suspect that higher resolutions would be quite achievable.
If you don't think you could conveniently carry something that size, you haven't thought about it.
Part of all of the e-paper stuff I've seen is that it consumes very little power - one black & white solution actually needed power only while changing what was displayed. You could probably run something like this for months with two AA batteries.
Most e-book readers have very simple controls - you could probably get by with no more than 4 buttons (power, up/down, select) though 7 would probably be more convenient (add left/right & back).
Everything I've described here is basically a low-end Palm with a funky display.
One of the frustrating things for me at various times has been that if I'm looking at learning a new programming language, most of the books I seem to find are at the extremes - "Learn To Program using XYZ" or "XYZ Esoterica and Deep Internals". That's a big part of the reason I've gravitated toward the Nutshell books - to get good information without all the hand-holding.
ZIP+4 isn't actually down to the unique address level for the most part - it takes it down to chunks that I believe are in the 4-20 address range.
The Delivery Point Barcode is probably what you're thinking of for unique addressing - it's the ZIP+4 followed by two additional digits (total of 11 digits); information on how to calculate it is one of those "it's complicated, call us" things. I assume that putting DPBCs on your direct mail results in a slight additional savings beyond what you get for presorting and barcoding the ZIP+4.
For info, hit http://www.usps.gov/, then keyword search for either "dpbc" or "postnet".
The wireless access point in the Routefinder family (model RF802EW) has this kind of setup. Unfortunately, it only has a single LAN port (plus WAN and serial ports).
For a long time, the non-wireless model (RF500S) was the only consumer-priced firewall/router that supported a backup modem.
Cooper (really badly paraphrased) places more emphasis on pre-coding work. But it seemed to me that there are situations where a client lacks the ability not just to communicate what they want, but to envision a system and even know what they need. If a customer is unable to sufficiently help you in pre-coding work, then it's on code and actual demo that will enable them to *realize* what they need, and give feedback.
As I understand Cooper's base from his books, he's a strong advocate of making that demo a narrative. Further, he's a real proponent of making it a narrative based on a specific "person" who's using the system. There's no "the user clicks here," there's "Bob clicks on the Continue button." "Bob" is described in detail elsewhere - he's an accountant in his early 40s, has been with the company for 20 years and has spent most of that time using terminals connecting to mainframes and minicomputers. He did some work with spreadsheets on IBM PCs back before IS set up minicomputer access for the accounting department.
That kind of information is at least as important as your interface when you're putting together a system, because it's going to have a dramatic effect on acceptance of the system. If you think that acceptance by fiat ("You will use only Microsoft OSs on the company network!") is going to work, go check around your offices and find out how many covert *nix/BSD boxes are floating around. It won't work any better for general office staff than it does for the geeks.
Here's mine - focused on the future not the past
on
Respond To The Tunney Act
·
· Score: 4, Insightful
22 January, 2002
Renata B. Hesse
Antitrust Division
U.S. Department of Justice
Suite 1200
601 D Street NW
Washington, DC 20530-0001
Ms. Hesse,
I am writing to add my name to the list of people opposed to the Proposed Final Judgement in the United States v. Microsoft antitrust case.
As a software developer with 11 years of business experience, I have watched Microsoft's rise to dominance in several markets and been dismayed by many of the techniques it has used to attain and maintain dominance at the expense of other companies, competing software platforms and consumers such as myself. Still, while I have often found Microsoft's techniques distasteful and unethical, I am far less concerned about remedies for its past behavior than I am about ensuring that the same types of behavior are prevented in the future.
From my reading of the Proposed Judgement those remedies that actually work against Microsoft would be ineffective against a company determined to bypass them and would not even constitute significant obstacles in that bypassing process, further in many cases the remedies and definitions seem to have been specifically crafted to make them effectively nonexistent or to actually strengthen Microsoft's position in current or potential future markets. That Microsoft will work to bypass the original intent of the Judgement is clear for both technical and business practices - even during the course of the trial and settlement negotiations it continued to use tactics that should be blocked by a solid agreement.
As an example, the future direction of Microsoft's focus has just this month been declared to be security, while under the Proposed Judgement anything related to security need not be disclosed even if such would otherwise be mandatory. Under a strict reading, if Microsoft adds even rudimentary security interfaces to its APIs then none of those APIs need be disclosed and there is no penalty for not disclosing them -a requirement for receiving documentation for those APIs is that any business needing it must meet Microsoft-developed standards of business viability; non-businesses need not apply at all because access will simply not be available.
Overall, I feel that the Proposed Final Judgement is deeply flawed and should be substantially revised to remove these flaws before being accepted. A software and content monoculture such as Microsoft clearly wishes to have in place harms all of us in the long term, including Microsoft and its investors.
One of the features that I like about the MultiTech router/switch I have is that a modem can be hung off the serial port and used as a backup connection. What would it take to do the same with this, and is there a getty out there that would support operating both ways (i.e. use a modem for dialout, but if a terminal was connected instead then allow login).
My initial reaction to the ban on receiving assistance from people who've taken the course in the past was that that was a bad idea, but the reasoning given later for the allowed collaboration (that collaborating with someone helps you formulate your own thoughts into a more organized structure) makes sense. That would be something you could get from assistance with some people who'd taken the course, but for others it wouldn't.
I think the one thing I'd change is that you could get assistance from "approved" students who'd taken the course in the past. Those who were willing (and deemed suitable) to provide assistance in understanding concepts rather than in coding would have to be approved in advance by the professor.
If you have everyone close together in one big room, I can almost guarantee that a significant proportion of your people (the ones who don't have to spend a lot of time on the phone) are wearing headphones and using CD or MP3 players.
Slashdot Mirror
Even worse - could it have been the result of very good emulation? I can see the comment now: "Blizzard's doing something funky with this with no good clear reason, but if we see this kind of packet act the same way Battle.net does even if it seems wrong."
I have to wonder how the assorted revisions of Blizzard's battle.net code look. Wouldn't it be interesting if upon review (and digging back to previous versions) it became apparent that some optimizations, etc. were strikingly similar to the bnetd code?
Sounds like this is similar to what MojoNation is/was trying to do. Their site doesn't seem to be responding right now, but here's the Google Cached version of the technical docs.
Note that all of this applies to the civilian system - the GPS satellites also send out a separate (and encrypted) signal that can be used only with military GPS receivers. Those receivers include both decryption information which must be refreshed every 6 months and a quick 2-3 finger way to flush that information if the receiver is about to fall into enemy hands. All of this means that civilian GPS can be turned off completely without preventing the US military from using it. There are also other limitations in civilian equipment (won't work above 50,000 feet and/or 1000mph, etc.) to make it less suitable for some military use.
Until relatively recently, SA was always on, generally with an accuracy of around 50 meters. That meant basically that 95+% of the time the position reported by a GPS receiver was within 50 meters of the actual position of that receiver. SA can be turned up much higher to at least the 250-300 meter mark. The one exception for SA was actually during the Gulf War, when there were not enough military receivers available to meet demand. For a time, SA was turned off so that the military could conveniently use civilian GPS hardware. More recently (2-3 years ago, during the Clinton administration), SA was turned off or at least down to a minimal level, so consumer units can get an accuracy of 3-5 meters with only the satellite signals. SA is the reason that many civilian receivers have an "average position" function - the best way to get an accurate position was to leave the receiver on and averaging for a day or two.
A concern for foreign governments and at times for the US FAA has been that military control of the availability and accuracy of the signals - no foreign military wants to be dependent on the US for something vital, and the FAA was looking at ways to do more flight automation and didn't like the possibility that they might someday have automated planes landing using GPS when something happened and the military tweaked or turned off the signals. The foreign solution was to build their own system, which the Europeans have been talking about for years now (the Russian GLONASS system was never finished and isn't as accurate as the US system). The FAA solution was to look at putting up one or two satellites of their own, effectively acting as differential GPS transmitters to let aircraft filter out the effects of SA.
Really all of this is a consequence of the system being at its heart a US military system and everyone understanding that what they want is for the most part irrelevant to the US military.
There is (or was) a fairly active Usenet group for discussion of all this at sci.geo.satellite-nav .
My nightmare on this was doing much the same thing, but instead of damaging pins I forgot to rejumper the drive. IDE chain with two master devices = thoroughly horked partition tables on both.
I was able to recover one of them using a package called Hard Drive Mechanic that basically examined the drive looking for the start and end of the partitions, but the "working" disk that had several partitions of different types and some intermediate empty space was unrecoverable and had to be completely wiped.
That sinking sensation when you plug the drive you were going to back up back into its original system and it's completely dead is just no fun at all....
For businesses, there are lots of things where a picture is needed but high resolution isn't important - I ran into someone the other day who has one of those wristwatch digital cameras and is quite happy with it for basic assessment use.
Memory Stick prices have dropped enormously in price over the last six months to a year - they're still more expensive than CF, but they're no longer insanely expensive for what you get.
Things like sharing connections and the ability to run servers without having to worry about being cut off are a good reason to spend the extra money for a business-grade DSL connection. Sure it costs more, but for a lot of Slashdot readers the extra cost wouldn't be that much of an issue.
So it's actually working on the basis of webs of related sites - not a novel concept, but useful.
I suspect that some of the commercial knowledge management tools have been doing something much like this for some time, and TheBrain.com has had a product to manually build this kind of network of clusters for some time. The key thing about this is that with web indexing/cataloging the information needed to do the automatic linking is available.
TheBrain.com seems to have a working demo of using it for the Web at WebBrain.com based on the Open Directory Project. It's not a great example because of display limitations that don't really let you see more than one cluster of information at the time, but it's one example of the general concept. Once you dig down in an area you can see how it shows links between related categories as well.
Note: the demo above says it requires Java 1.1 and IE 4.01 or Netscape 4.07+, to bypass that test try here. Seems to work fine in Netscape 6.2, and will probably be OK in Mozilla if the JRE is available.)
The needed approaches are radically different depending on whether you're trying to keep secrets from highly-skilled groups with plenty of resources (e.g. government agencies investigating you in particular), skilled groups with some resources (corporate espionage, small countries), snoopy ISPs (e.g. Comcast), skilled interested parties (IS groups), the casually curious (repair techs), and the unskilled (your grandmother). At the top end, you have to do all sorts of things that make using computers much more of a pain in the ass to keep them from adding keyboard sniffers, monitoring emissions, etc. At the low end, you have to learn how to hide files (using a .prefix or "hidden" flag, who cares) to keep your grandmother from being shocked by all that hot monkey lovin' in your porn archive. In between there are tradeoffs - how important is the information (do you need to keep it at all?), how important is it that it not be seen by others, how much inconvenience are you willing to go to to ensure that nobody else sees it?
Keep in mind that encryption isn't security. Encryption isn't even close to security. Encryption is a tool.
The cause of the mail slowdown has been discussed in the worldnet.* internal groups.
When you read a lot, it's sometimes useful to use a program like ReaderWare to catalog your books. It even understands that spiffy CueCat you snagged and use as a nightlight.
This is actually something that has all sorts of potential, particularly with truly flexible and durable material. Xerox is also far from being the only company working on this - I think I've seen press on at least three, all with different technologies.
Consider the advantages of having an e-book using flexible, durable electronic paper. Make a sheet, perhaps eight inches by twelve. Put a couple of seams on it so it can be folded down to ~4x8. Now make it flexible enough to roll into a cylinder around (or inside) a 1.5-inch tube holding batteries, a few MB of RAM, and either flash memory or a memory card socket (memory stick or the MMC cards in Palms would both be good sizes).
Go through all the above, and what would you end up with? Something easy to read[1], easy to carry[2], capable of holding a large number of books (including school texts with illustrations, etc.), low-power[3], easy to use[4], and inexpensive[5].
Sure there'd be drawbacks - the lines across the page at the seams might be as much as an eighth of an inch apiece disrupting large images (affecting what % of books?); the display might be black & white (though this would likely change quickly); the display might wear out after a few hundred rollings/unrollings (so make it socketed); it might not be readable in the dark (so add a port for a Flylight-like LED).
With the exception of the electronic paper itself, there's nothing that would keep this from being manufactured today, probably for under $200. If there's enough market for e-books, I wouldn't be surprised to see something very much like this within two years.
Hah, I still haven't seen any proof that the Jar-Jar gay porn I've heard rumors of exists.
One of the frustrating things for me at various times has been that if I'm looking at learning a new programming language, most of the books I seem to find are at the extremes - "Learn To Program using XYZ" or "XYZ Esoterica and Deep Internals". That's a big part of the reason I've gravitated toward the Nutshell books - to get good information without all the hand-holding.
ZIP+4 isn't actually down to the unique address level for the most part - it takes it down to chunks that I believe are in the 4-20 address range.
The Delivery Point Barcode is probably what you're thinking of for unique addressing - it's the ZIP+4 followed by two additional digits (total of 11 digits); information on how to calculate it is one of those "it's complicated, call us" things. I assume that putting DPBCs on your direct mail results in a slight additional savings beyond what you get for presorting and barcoding the ZIP+4.
For info, hit http://www.usps.gov/, then keyword search for either "dpbc" or "postnet".
The wireless access point in the Routefinder family (model RF802EW) has this kind of setup. Unfortunately, it only has a single LAN port (plus WAN and serial ports). For a long time, the non-wireless model (RF500S) was the only consumer-priced firewall/router that supported a backup modem.
no matter how you write it, not need for high-ASCII characters.
Are you sure it's not supposed to be curriculum vitæ?
Cooper (really badly paraphrased) places more emphasis on pre-coding work. But it seemed to me that there are situations where a client lacks the ability not just to communicate what they want, but to envision a system and even know what they need. If a customer is unable to sufficiently help you in pre-coding work, then it's on code and actual demo that will enable them to *realize* what they need, and give feedback.
As I understand Cooper's base from his books, he's a strong advocate of making that demo a narrative. Further, he's a real proponent of making it a narrative based on a specific "person" who's using the system. There's no "the user clicks here," there's "Bob clicks on the Continue button." "Bob" is described in detail elsewhere - he's an accountant in his early 40s, has been with the company for 20 years and has spent most of that time using terminals connecting to mainframes and minicomputers. He did some work with spreadsheets on IBM PCs back before IS set up minicomputer access for the accounting department.
That kind of information is at least as important as your interface when you're putting together a system, because it's going to have a dramatic effect on acceptance of the system. If you think that acceptance by fiat ("You will use only Microsoft OSs on the company network!") is going to work, go check around your offices and find out how many covert *nix/BSD boxes are floating around. It won't work any better for general office staff than it does for the geeks.
22 January, 2002
Renata B. Hesse
Antitrust Division
U.S. Department of Justice
Suite 1200
601 D Street NW
Washington, DC 20530-0001
Ms. Hesse,
I am writing to add my name to the list of people opposed to the Proposed Final Judgement in the United States v. Microsoft antitrust case.
As a software developer with 11 years of business experience, I have watched Microsoft's rise to dominance in several markets and been dismayed by many of the techniques it has used to attain and maintain dominance at the expense of other companies, competing software platforms and consumers such as myself. Still, while I have often found Microsoft's techniques distasteful and unethical, I am far less concerned about remedies for its past behavior than I am about ensuring that the same types of behavior are prevented in the future.
From my reading of the Proposed Judgement those remedies that actually work against Microsoft would be ineffective against a company determined to bypass them and would not even constitute significant obstacles in that bypassing process, further in many cases the remedies and definitions seem to have been specifically crafted to make them effectively nonexistent or to actually strengthen Microsoft's position in current or potential future markets. That Microsoft will work to bypass the original intent of the Judgement is clear for both technical and business practices - even during the course of the trial and settlement negotiations it continued to use tactics that should be blocked by a solid agreement.
As an example, the future direction of Microsoft's focus has just this month been declared to be security, while under the Proposed Judgement anything related to security need not be disclosed even if such would otherwise be mandatory. Under a strict reading, if Microsoft adds even rudimentary security interfaces to its APIs then none of those APIs need be disclosed and there is no penalty for not disclosing them -a requirement for receiving documentation for those APIs is that any business needing it must meet Microsoft-developed standards of business viability; non-businesses need not apply at all because access will simply not be available.
Overall, I feel that the Proposed Final Judgement is deeply flawed and should be substantially revised to remove these flaws before being accepted. A software and content monoculture such as Microsoft clearly wishes to have in place harms all of us in the long term, including Microsoft and its investors.
Sincerely,
Alan J. Miller
Des Plaines, IL
Anyone with a better memory or a shortwave radio?
One of the features that I like about the MultiTech router/switch I have is that a modem can be hung off the serial port and used as a backup connection. What would it take to do the same with this, and is there a getty out there that would support operating both ways (i.e. use a modem for dialout, but if a terminal was connected instead then allow login).
I think the one thing I'd change is that you could get assistance from "approved" students who'd taken the course in the past. Those who were willing (and deemed suitable) to provide assistance in understanding concepts rather than in coding would have to be approved in advance by the professor.
That's what my fully-over-the-ear Aiwas are for, much of the time they aren't plugged in.
Unfortunately, they get a bit hot after a while.
If you have everyone close together in one big room, I can almost guarantee that a significant proportion of your people (the ones who don't have to spend a lot of time on the phone) are wearing headphones and using CD or MP3 players.