Rainbows - some people see them, most don't (under normal conditions). If you don't see them in the store, you're not likely to see them at home. There are ways to "try" to see them you can use in a store. Newer versions use more segments in the wheels, higher rpm, etc to reduce rainbows.
Power up time - DLPs can take up to 30 seconds to turn on. A few models just introduced use LEDs instead of lamps, and power on in circa 5-7 seconds.
Bulb replacement costs - Not cheap, more frequent than many people expect. See previous item about LEDs.
Projection - harder to see in bright light than Plasma or LCD. Not as crisp up close as plasma/LCD, though at correct viewing distance that's not a big issue. May be less sharp on the sides due to optics (not sure).
Cheap ones are still 720p
Older/cheaper models may have a slight delay, which can be annoying in games. Newer ones have "Game Mode" which minimizes delay.
Good things:
No convergence problems like tube projection.
Much smaller/lighter than tube projection. Lighter than plasma. Can be as little as 7" thick. In some cases can be wall mounted.
Less power use than plasma (much I think).
Probably better low-lighting performance than LCD (better contrast when the room isn't bright).
I was offered a job at 3DO (where a bunch of my friends worked) in 1993, for a good salary for the time. I ended up turning it down, because when I got home I said "I should be a primary customer for this - 30ish early-adopter-gamer-techie - and I wouldn't pay what they're asking ($700)". I had met with Trip Hawkins (head of 3DO and EA), and he's used his reality-distortion field to convince me (temporarily) that early adopters would buy it anyways, and there was no need to push the price down. Luckily, I had told myself I wouldn't decide while I was there.
Trip even called me at home the next weekend to try to change my mind (and find out why I turned them down), and I told him the same thing. He disagreed. I think I was proven right.:-)
Mailing lists - I can't count the number of people on the Yahoo rhododendron list who are from Germany, Belgium, etc. Nihonto (japanese sword) lists - while it's all in english (if you ignore the huge number of romanized japanese words in the postings), contributers are from the US, Japan, England, europe, australia, etc.
Web sites: online Japanese sword shops - more than a few have english versions of their pages, and often they can be useful even without it. Tourist info, local info about places you might be visiting. Maps, sightseeing, etc.
Frequently I'll find myself browsing stuff from Europe (technical pages, hardware, software, all sorts of random stuff). Often in english, when not babel/etc are sometimes useful. Not so often Asia unless they're in English - and they more-than-occasionally are.
And SCSI has had tags since around... 1991? 1992? maybe a few years earlier.
Even back around 1992/1993 we (Commodore Amiga) had tagged-queue implementations that were done entirely in the NCR 53c710 SCSI chip with no processor intervention. When a new request was added, we fiddled the "list" (really an instruction sequence for the '710) so when a tagged continuation occurred, it could be handled and DMA into memory without a processor interrupt.
It's criminal that ATA took until a couple of years ago to even get close to that.
Not all operating systems use block/sector numbers at the device-driver level (and there are good arguments against it, though most OS's do it).
The Amiga used byte-offsets and lengths for all IO's. This did eventually cause problems when disk drives (which started at 10-20MB when the Amiga was designed) got to 4GB, but a minor extension allowing 64-bit offsets solved that. 64-bit offsets shouldn't overflow very soon....
For the device driver, it's no big deal to shift the offset if the sector size is a power-of-two, and it allows for weird-ass devices with non-power-of-two sector sizes (like old MAC SCSI drives), devices without a sector paradigm, etc all using the same API. Thus you can mount a 2048-byte block FS on a 512-byte sector device without knowing or caring; you can (with a cooperative device driver) mount a 512-byte FS on a 2048-byte sector device (if the device is willing to accept arbitrary-offset transfers, which they can, though it hurts speed), or mount a block-oriented FS on a bytestream-oriented device (like a file...).
On the Amiga, we supported fairly arbitrary sector sizes (though there was a lower limit), and allowed a FS to use N sectors/block. Given the FS structure (hash-chains in directories, block-lists for files, and shadow directory blocks for speeding up directory searches/listing, larger FS blocks sizes (even 1K or 2K) made huge improvements in many common operations. There was little win above that - but those were in the days of 200MB-1GB drives, 3600 RPM (I was beta-testing the first Maxtor higher-RPM ("Magic") SCSI drives at the time).
I vaguely remember that old Apple Macs used some oddball HD sector size like 532; some SCSI drives back then could be low-level-formatted for that.
That's fine - until they subpoena the reporter to provide the decryption key, with contempt of court as a whip. 5th amendment doesn't apply if they're investigating someone else's crime. Admittedly, this does put the reporter in the position to block it - potentially at considerable personal cost. And this assumes the encryption/security was done "right" and the password is nowhere to be found on the disk (like in the page file, "suspend" area, etc...)
I wonder what the patent is on? Transport stream? Main/High profile (requires a bunch of patent licenses via MPEG-LA already), or Baseline (which was supposed to be license-free, but didn't end up that way)? MPEG4-SP, ASP, or AVC (H..264)? Audio? (Not too likely.)
While I agree with your principle, some people _do_ pay more for hour-long local calls. Yes, minimum basic service in most states is still per-minute billed for local calls. When I was in college (gasp >20 years ago), all local calls were charged per minute - and much more than we pay now for long distance, assuming we don't buy unlimited long distance.
The PA legislature had hearings at Temple about supposed liberal bias (they're going to all universities). Only one person testified (and he was president of the young republicans). He admitted even though there were extensive procedures in place at Temple, he hadn't filed a report (and he didn't have much to say anyways).
A quote from a conservative organization:
"Despite our years-long national campaign to get conservative students to expose their liberal professors' schemes of indoctrination, we've come up with next to nothing."
The organization then uses the lack of evidence (despite all their hard work) to "prove" that the "liberal intimidation" is hiding the evidence - i.e. that lack of proof is proof itself. Apparently they read their Orwell quite well.
Another quote from a blog:
But while Horowitz was declaring the hearings "a great victory" for his cause, he lost some powerful stories. For example, Horowitz has said several times that a biology professor at Pennsylvania State University used a class session just before the 2004 election to show the Michael Moore documentary Fahrenheit 9/11, but he acknowledged Tuesday that he didn't have any proof that this took place.
So "no personally identifiable data", eh? So they look through it (they can take all the time they want, and once they have it there's no further subpoena needed to mine it). They find someone searched for "How to make metamphetamines". They then subpoena the IP's/etc of whomever searched for that, using the data they have as the basis for probable cause.
Replays sometimes get touchy about booting. See AVSforum.com for examples. Often, this is due to either a) the drive starting to die, or b) the power supply is starting to die, or c) the IDE cable is loose/bad, or d) the power connectors between motherboard and PS are arcing/glitchy/resistive (this has been seen a number of times, often with discoloration).
If it gets really bad, and a different HD doesn't fix it, there's someone who repairs them as a business who's on avsforum all the time, and also sells replacement power supplies.
Great boxes; we have 4. One other was blown up by lightning, and another had a PS die.
You're absolutely correct that deeper setbacks are (barring a few edge cases) always more energy efficient, so long as the efficiency of the heater doesn't vary. Most don't vary, other than being a bit more efficient when they have longer runtimes (stops and starts are a smidge less efficient). The exception is heat pumps.
Heat pumps should always be used with a thermostat designed for use with a heat pump. The reason is that heat pumps have an "aux heat" mode that they use when they need to change the temp in a hurry. Regular setback thermostats just change the temp and tell the heater to heat (binary). This causes a heat pump to kick in the aux heat, which in many cases is resistive electric (i.e. $$$$). Thermostats designed for heat pumps change the setpoint early and slowly, a degree or so at a time, so the heat pump hopefully never needs to kick in aux heat mode. (Modern heat pumps are 250-350% efficient, compared to 100% for resistive.)
If you manually bump a thermostat for a heat pump up by more than around 2 degrees, it will normally kick in aux heat until the temp has reached the setting. So manually doing setbacks or frequently increasing the temp by a bunch over the programmed value will be more expensive than letting the program run.
** The edge cases mentioned are things like condensation, pipes in danger of freezing in really deep setbacks, or where temp changes cause cracks to open in caulk, etc.
Another heap debugger (not stack) well worth using is dmalloc http://dmalloc.com/. Works in non-MMU embedded environments too; very configurable; checks for write-after-free, etc.
Back in the day.... (when the sun was young and the Soviet empire was still around) this was called "NSA Food" and was attached in signatures to email and USENET postings. Typically it would reference things like kremvax, kgbvax, uranium, trigger, afganistan, etc.
The centerpiece of our war effort is to bring the blessings of liberty to the oppressed peoples of the Middle East.
Really.... I thought it was to stop them from using weapons of mass destruction on us... no, wait, that was all a lie. It was to unseat Saddam Hussein and let the Iraqi people throw flowers at us... no, wait, they don't like us. It was to bring the blessings of a modern pluralistic western society to... no, wait, they had a (relatively) modern secular society and are now moving to a purely religious society combined with a likely eventual civil war or religious oppression (would you want to be an Iraqi christian now, with the laws now based on the Koran, and religious parties in charge?)
I resent the fact that the president just couldn't be bothered to go and get the legal authorization 'post-facto'; perhaps because there was no authorization or justification to be granted
The reason is that the even the FISA court would have rejected a request covering random or total monitoring of "any and all traffic"; they only approve monitoring traffic of a specified person. That's the real crime here - they may well have monitored ALL calls for keywords, etc. Just discussing what happened with your brother in London might have gotten you sucked into the mass of intelligence gathering, and caused them to start monitoring all your calls, listening to the entirety until they decided you really were just a mailroom lackey from Detroit talking to his brother. Or until they decided it was all elaborate code, and you and your brother silently vanish into black sites...
That's why this is such a slippery slope. It's not a slope, it's a triple-black-diamond downhill of ice.:-(
I think the poster was referring to it being Amiga-like in terms of "GP CPU plus coprocessors for sound/video/etc". And in a way, it is. The coprocessor core (DSP) is more general-purpose, and it's all on a chip instead of as a system, but the general idea of specialization is there. It is a bit stretched, though.
The C64 name is a bit amusing. Even C65 would be - the Commodore C65 actually existed, and after bankruptcy about the about 100-200 C65's escaped into the wild. 4?MHz 6502 (we had 10MHz 6502s but I think this used a 4MHz; the original C64 was 1MHz), "hires" 256-color display (palette either 65K or 16M), high speed disk built in, (simple) bit blitter, etc.
The C++ compiler supports templates as well. How well and how efficiently - those are other questions I haven't answered, but as far as I've tested they work.
Breaking DAT_copy() was a real "oops". How in the world did that ever escape...
It's really annoying how looking at certain things (stats windows, CPU use, etc) slows down all future JTAG operations including loading code, dramatically, until you quit and restart.
The IDE/JTAG losing communication with the CPU - this happens way too often if the DSP iloops (perhaps in non-interruptible loops).
Profiling (and figuring how to set it up) is a mess. This may be a combined tool, OS, design and documentation issue.
You're right - but this doesn't address that. DaVinci is a dual-core solution ala OMAP; you have an ARM running Linux and a DSP running DSP/BIOS on the same chip. Admittedly, with well-defined communication channels and "standard" TI XDIAS modules on the DSP you can mostly avoid doing real "DSP programming" - but then you're limited to using canned DSP algorithms or at most playing "building blocks" with them.
Not to say this isn't a nice setup - it is. Just don't assume it will remove the need to do traditional signal-processing coding.
I see comments EXACTLY like this:
i=i+1;/* Add one to i */
Then find some better programmers to work with, or teach them how the write more useful comments.
That style makes sense in one, and only one usage: ASM code. Even there, it should be used with care. (Ok, and in APL).
The gp poster wasn't suggesting those. That is a comment on "function" not "functionality". See a previous article here.
Here's something I wrote there that's relevant:
comments can lie
I worked with a programmer who disliked comments so much he'd remove them before looking at a function. Ok. So I wrote some code and he came to me and said "why do you have an empty else case?" I was puzzled, then realized that I'd written something like this:
else { /* we don't have to do anything in the else case because of x y and z */ }
where x y and z would be non-obvious to anyone who wasn't fully immersed in this code. He's run it through a filter that removed all comments. He was a genius programmer - but wrote code that almost no one else could ever maintain. Tons of reliances on edge conditions without comment, reuse of generically-named variables (1 and 2 character names), tricky (but efficient) algorithms. So far as I know, I was the only one there ever to manage to really grok his code, and that required days of immersing myself.
x = x++;// add one to x
is obviously not useful.
// Test FU_E (End bit) after FU_A/FU_B test! If there's a gap, do not consider // hitting the End bit a marker to stop - continue until we see another // packet/timestamp (in which case we return TRUE), or until we are // at the end of the buffer (in which case we return FALSE and keep // hoping to assemble it). if (((*curr)->GetPayload()[1] & FU_E_BIT) && !gap) break;// no error in fragment // if there's a gap we still won't return true unless // we find a non-fragment packet (or one from another fragment!)
This is an example of a useful comment - and yes, it has to be maintained if the line of source were to change. I chose that at random; there are better examples - such as explaining what the edge cases are (especially if not handled), and under what circumstances they would become relevant, and how they could be dealt with then.
Please excuse the incorrent indenting above; "" doesn't work exactly like 'pre'
CALEA requires that the tap be undetectable, and able to set up effectively by flipping a virtual switch. Since RTP in VoIP can be point-to-point (i.e. untappable), and since tapping by routing a call through a proxy that could record the packets would be detectable (given a network sniffer), VoIP providers would have to route ALL calls through proxies just in case they might have to tap them. Realize they already had the power to ask for a subpoena for a tap, but that VoIP providers didn't have to engineer their network to make it easy and quick (or possible). Now they will have to. And it includes all the universities, who say it may cost them 5-10 BILLION dollars to comply.
This means added delay to all calls (lower quality), and extra expense for the VoIP companies (proxies and/or Session Border Controllers for all calls, and the associated bandwidth. For students, increased tuition (and not a small amount). Plus, part of why you don't want this done ever is that the easier it is technically to do, the more temptation there is to use this ability. Slippery slope and all that. The FBI/NSA/etc already tried to force OnStar to let them turn on the mic's in cars remotely as bugging devices; the judge stopped them because it would have disabled or otherwise interfered with safety features in OnStar (reporting of airbag deployments, etc).
Yes, you can make direct SIP/RTP calls without going through a VoIP provider. However, the FCC ruled that all 200Kbps and above broadband suppliers were ALSO required to comply with CALEA and make it possible for them to tap (all) traffic easily.
Can you say, huge blinking arrow saying "Hack this box"? Talk about a tempting target for malicious people, not to mention espionage.
As for encryption in a direct SIP call - it's hard (though not totally impossible) to avoid a possible MiTM attack in that case, unless you have communicated with that destination before, and cached their credentials, and it was before the MiTM attack was put in place. And if they realize you are in that situation (where you could detect MiTM due to credentials), then all they have to do is find some way to subvert/kill/etc one of the two endpoints. (Product recall, software update, cleaning lady knocked it over "by mistake", etc.) If you're using encryption via a VoIP provider, then who's verifying these certs you're accepting? Even if you did cache credentials, that only helps if they don't have a copy of the private cert subpoenaed from whomever provided it.
Slashdot Mirror
- Rainbows - some people see them, most don't (under normal conditions). If you don't see them in the store, you're not likely to see them at home. There are ways to "try" to see them you can use in a store. Newer versions use more segments in the wheels, higher rpm, etc to reduce rainbows.
- Power up time - DLPs can take up to 30 seconds to turn on. A few models just introduced use LEDs instead of lamps, and power on in circa 5-7 seconds.
- Bulb replacement costs - Not cheap, more frequent than many people expect. See previous item about LEDs.
- Projection - harder to see in bright light than Plasma or LCD. Not as crisp up close as plasma/LCD, though at correct viewing distance that's not a big issue. May be less sharp on the sides due to optics (not sure).
- Cheap ones are still 720p
- Older/cheaper models may have a slight delay, which can be annoying in games. Newer ones have "Game Mode" which minimizes delay.
Good things:I was offered a job at 3DO (where a bunch of my friends worked) in 1993, for a good salary for the time. I ended up turning it down, because when I got home I said "I should be a primary customer for this - 30ish early-adopter-gamer-techie - and I wouldn't pay what they're asking ($700)". I had met with Trip Hawkins (head of 3DO and EA), and he's used his reality-distortion field to convince me (temporarily) that early adopters would buy it anyways, and there was no need to push the price down. Luckily, I had told myself I wouldn't decide while I was there.
:-)
Trip even called me at home the next weekend to try to change my mind (and find out why I turned them down), and I told him the same thing. He disagreed. I think I was proven right.
Mailing lists - I can't count the number of people on the Yahoo rhododendron list who are from Germany, Belgium, etc. Nihonto (japanese sword) lists - while it's all in english (if you ignore the huge number of romanized japanese words in the postings), contributers are from the US, Japan, England, europe, australia, etc.
Web sites: online Japanese sword shops - more than a few have english versions of their pages, and often they can be useful even without it. Tourist info, local info about places you might be visiting. Maps, sightseeing, etc.
Frequently I'll find myself browsing stuff from Europe (technical pages, hardware, software, all sorts of random stuff). Often in english, when not babel/etc are sometimes useful. Not so often Asia unless they're in English - and they more-than-occasionally are.
Just another random user's examples.
And SCSI has had tags since around ... 1991? 1992? maybe a few years earlier.
Even back around 1992/1993 we (Commodore Amiga) had tagged-queue implementations that were done entirely in the NCR 53c710 SCSI chip with no processor intervention. When a new request was added, we fiddled the "list" (really an instruction sequence for the '710) so when a tagged continuation occurred, it could be handled and DMA into memory without a processor interrupt.
It's criminal that ATA took until a couple of years ago to even get close to that.
Not all operating systems use block/sector numbers at the device-driver level (and there are good arguments against it, though most OS's do it).
The Amiga used byte-offsets and lengths for all IO's. This did eventually cause problems when disk drives (which started at 10-20MB when the Amiga was designed) got to 4GB, but a minor extension allowing 64-bit offsets solved that. 64-bit offsets shouldn't overflow very soon....
For the device driver, it's no big deal to shift the offset if the sector size is a power-of-two, and it allows for weird-ass devices with non-power-of-two sector sizes (like old MAC SCSI drives), devices without a sector paradigm, etc all using the same API. Thus you can mount a 2048-byte block FS on a 512-byte sector device without knowing or caring; you can (with a cooperative device driver) mount a 512-byte FS on a 2048-byte sector device (if the device is willing to accept arbitrary-offset transfers, which they can, though it hurts speed), or mount a block-oriented FS on a bytestream-oriented device (like a file...).
On the Amiga, we supported fairly arbitrary sector sizes (though there was a lower limit), and allowed a FS to use N sectors/block. Given the FS structure (hash-chains in directories, block-lists for files, and shadow directory blocks for speeding up directory searches/listing, larger FS blocks sizes (even 1K or 2K) made huge improvements in many common operations. There was little win above that - but those were in the days of 200MB-1GB drives, 3600 RPM (I was beta-testing the first Maxtor higher-RPM ("Magic") SCSI drives at the time).
I vaguely remember that old Apple Macs used some oddball HD sector size like 532; some SCSI drives back then could be low-level-formatted for that.
That's fine - until they subpoena the reporter to provide the decryption key, with contempt of court as a whip. 5th amendment doesn't apply if they're investigating someone else's crime. Admittedly, this does put the reporter in the position to block it - potentially at considerable personal cost. And this assumes the encryption/security was done "right" and the password is nowhere to be found on the disk (like in the page file, "suspend" area, etc...)
I wonder what the patent is on? Transport stream? Main/High profile (requires a bunch of patent licenses via MPEG-LA already), or Baseline (which was supposed to be license-free, but didn't end up that way)? MPEG4-SP, ASP, or AVC (H..264)? Audio? (Not too likely.)
While I agree with your principle, some people _do_ pay more for hour-long local calls. Yes, minimum basic service in most states is still per-minute billed for local calls. When I was in college (gasp >20 years ago), all local calls were charged per minute - and much more than we pay now for long distance, assuming we don't buy unlimited long distance.
A quote from a conservative organization:
The organization then uses the lack of evidence (despite all their hard work) to "prove" that the "liberal intimidation" is hiding the evidence - i.e. that lack of proof is proof itself. Apparently they read their Orwell quite well.
Another quote from a blog:
So "no personally identifiable data", eh? So they look through it (they can take all the time they want, and once they have it there's no further subpoena needed to mine it). They find someone searched for "How to make metamphetamines". They then subpoena the IP's/etc of whomever searched for that, using the data they have as the basis for probable cause.
Replays sometimes get touchy about booting. See AVSforum.com for examples. Often, this is due to either a) the drive starting to die, or b) the power supply is starting to die, or c) the IDE cable is loose/bad, or d) the power connectors between motherboard and PS are arcing/glitchy/resistive (this has been seen a number of times, often with discoloration).
If it gets really bad, and a different HD doesn't fix it, there's someone who repairs them as a business who's on avsforum all the time, and also sells replacement power supplies.
Great boxes; we have 4. One other was blown up by lightning, and another had a PS die.
You're absolutely correct that deeper setbacks are (barring a few edge cases) always more energy efficient, so long as the efficiency of the heater doesn't vary. Most don't vary, other than being a bit more efficient when they have longer runtimes (stops and starts are a smidge less efficient). The exception is heat pumps.
Heat pumps should always be used with a thermostat designed for use with a heat pump. The reason is that heat pumps have an "aux heat" mode that they use when they need to change the temp in a hurry. Regular setback thermostats just change the temp and tell the heater to heat (binary). This causes a heat pump to kick in the aux heat, which in many cases is resistive electric (i.e. $$$$). Thermostats designed for heat pumps change the setpoint early and slowly, a degree or so at a time, so the heat pump hopefully never needs to kick in aux heat mode. (Modern heat pumps are 250-350% efficient, compared to 100% for resistive.)
If you manually bump a thermostat for a heat pump up by more than around 2 degrees, it will normally kick in aux heat until the temp has reached the setting. So manually doing setbacks or frequently increasing the temp by a bunch over the programmed value will be more expensive than letting the program run.
** The edge cases mentioned are things like condensation, pipes in danger of freezing in really deep setbacks, or where temp changes cause cracks to open in caulk, etc.
Another heap debugger (not stack) well worth using is dmalloc http://dmalloc.com/. Works in non-MMU embedded environments too; very configurable; checks for write-after-free, etc.
Bush thinks he's Colonel Jessup (boy, am I glad they spelled it with two S's!) from "A Few Good Men".
Colonel Jessup didn't realize he'd done anything wrong, either. And Bush doesn't do that good of a Jack Nicholson inpersonation, anyways.
Back in the day.... (when the sun was young and the Soviet empire was still around) this was called "NSA Food" and was attached in signatures to email and USENET postings. Typically it would reference things like kremvax, kgbvax, uranium, trigger, afganistan, etc.
That's why this is such a slippery slope. It's not a slope, it's a triple-black-diamond downhill of ice. :-(
I think the poster was referring to it being Amiga-like in terms of "GP CPU plus coprocessors for sound/video/etc". And in a way, it is. The coprocessor core (DSP) is more general-purpose, and it's all on a chip instead of as a system, but the general idea of specialization is there. It is a bit stretched, though.
The C64 name is a bit amusing. Even C65 would be - the Commodore C65 actually existed, and after bankruptcy about the about 100-200 C65's escaped into the wild. 4?MHz 6502 (we had 10MHz 6502s but I think this used a 4MHz; the original C64 was 1MHz), "hires" 256-color display (palette either 65K or 16M), high speed disk built in, (simple) bit blitter, etc.
There are couple other Linux's available for the C6000 series of TI DSPs (SoftTier, etc), though not from TI.
The C++ compiler supports templates as well. How well and how efficiently - those are other questions I haven't answered, but as far as I've tested they work.
Breaking DAT_copy() was a real "oops". How in the world did that ever escape...
It's really annoying how looking at certain things (stats windows, CPU use, etc) slows down all future JTAG operations including loading code, dramatically, until you quit and restart.
The IDE/JTAG losing communication with the CPU - this happens way too often if the DSP iloops (perhaps in non-interruptible loops).
Profiling (and figuring how to set it up) is a mess. This may be a combined tool, OS, design and documentation issue.
You're right - but this doesn't address that. DaVinci is a dual-core solution ala OMAP; you have an ARM running Linux and a DSP running DSP/BIOS on the same chip. Admittedly, with well-defined communication channels and "standard" TI XDIAS modules on the DSP you can mostly avoid doing real "DSP programming" - but then you're limited to using canned DSP algorithms or at most playing "building blocks" with them.
Not to say this isn't a nice setup - it is. Just don't assume it will remove the need to do traditional signal-processing coding.
That style makes sense in one, and only one usage: ASM code. Even there, it should be used with care. (Ok, and in APL).
The gp poster wasn't suggesting those. That is a comment on "function" not "functionality". See a previous article here.
Here's something I wrote there that's relevant:
I worked with a programmer who disliked comments so much he'd remove them before looking at a function. Ok. So I wrote some code and he came to me and said "why do you have an empty else case?" I was puzzled, then realized that I'd written something like this:where x y and z would be non-obvious to anyone who wasn't fully immersed in this code. He's run it through a filter that removed all comments. He was a genius programmer - but wrote code that almost no one else could ever maintain. Tons of reliances on edge conditions without comment, reuse of generically-named variables (1 and 2 character names), tricky (but efficient) algorithms. So far as I know, I was the only one there ever to manage to really grok his code, and that required days of immersing myself.is obviously not useful.This is an example of a useful comment - and yes, it has to be maintained if the line of source were to change. I chose that at random; there are better examples - such as explaining what the edge cases are (especially if not handled), and under what circumstances they would become relevant, and how they could be dealt with then.Please excuse the incorrent indenting above; "" doesn't work exactly like 'pre'
CALEA requires that the tap be undetectable, and able to set up effectively by flipping a virtual switch. Since RTP in VoIP can be point-to-point (i.e. untappable), and since tapping by routing a call through a proxy that could record the packets would be detectable (given a network sniffer), VoIP providers would have to route ALL calls through proxies just in case they might have to tap them. Realize they already had the power to ask for a subpoena for a tap, but that VoIP providers didn't have to engineer their network to make it easy and quick (or possible). Now they will have to. And it includes all the universities, who say it may cost them 5-10 BILLION dollars to comply.
This means added delay to all calls (lower quality), and extra expense for the VoIP companies (proxies and/or Session Border Controllers for all calls, and the associated bandwidth. For students, increased tuition (and not a small amount). Plus, part of why you don't want this done ever is that the easier it is technically to do, the more temptation there is to use this ability. Slippery slope and all that. The FBI/NSA/etc already tried to force OnStar to let them turn on the mic's in cars remotely as bugging devices; the judge stopped them because it would have disabled or otherwise interfered with safety features in OnStar (reporting of airbag deployments, etc).
Yes, you can make direct SIP/RTP calls without going through a VoIP provider. However, the FCC ruled that all 200Kbps and above broadband suppliers were ALSO required to comply with CALEA and make it possible for them to tap (all) traffic easily.
Can you say, huge blinking arrow saying "Hack this box"? Talk about a tempting target for malicious people, not to mention espionage.
As for encryption in a direct SIP call - it's hard (though not totally impossible) to avoid a possible MiTM attack in that case, unless you have communicated with that destination before, and cached their credentials, and it was before the MiTM attack was put in place. And if they realize you are in that situation (where you could detect MiTM due to credentials), then all they have to do is find some way to subvert/kill/etc one of the two endpoints. (Product recall, software update, cleaning lady knocked it over "by mistake", etc.) If you're using encryption via a VoIP provider, then who's verifying these certs you're accepting? Even if you did cache credentials, that only helps if they don't have a copy of the private cert subpoenaed from whomever provided it.