If you tell them to put you on their "don't call" list, they're legally required to do so. I work for AT&T, so it's MCI that used to call me:-) It took a while to get the modem line on the don't-call list also, since usually if I was home it would have a computer on it, so it would either be busy or answer with modem tones, and their databases weren't bright enough to decide that since my primary line wanted not to be called, so did the modem line.
You'd be sending equipment, not people. On the other hand, the 1kg/day propellant is a much more serious problem. It's probably not steerable enough to do a good flyby of one of the outer gas planets or their moons to pickup some hydrogen without risking falling into their gravity well. But you can find some interesting balance of weights and propulsion strengths to get out to interesting parts of space and send telemetry back, and once you're going that fast, it's a nice cruising speed.
Coulda been worse - at least their reaction, when put on the spot with something they didn't know about and hadn't paid attention to years of hoax warnings, was "no, we shouldn't be taxing the net" as opposed to "yes, my staff has been evaluating the right way to tax the net and we'll be sure to check out that proposal as well."
Remember CompaQ showing off Linux on an iPAQ at LinuxWorld? Maybe it wasn't Debian, but it was some flavor of Linux, and they'd done a nice job, and had a XWindows telnet font that was small enough to fit usable amounts of text in a window while still being readable, partly because of the gorgeously bright battery-burning screen. They also had some non-text apps running on it, but it was clearly the real thing.
I've got a Palm 3xe running 3.5, and it's easy to crash, by trying to use the Magnifying Glass find-button in Memo Pad. With no memory protection, you'd expect user-written apps to crash the thing, but you'd think they'd have at least tested the basic functions that they're providing themselves.
I think I may have crashed my Psion 3a in the past, but it didn't happen on things I want to do every day.
Magic phrase for getting people not to call you back: Please put me on your don't-call list.
Disclaimer: I work for AT&T, but my comments here are just my personal comments. You can read AT&T's comments on slamming on their web page. AT&T got lots of flack for a while from people being slammed by their subcontractors, and they started putting a lot more control on that, but they still screw up sometimes.
I've never particularly liked the local phone companies' approach to slamming, which is to continue to bill you for the long distance service and have you resolve it. My own preference is to write to the local telco and the slammer telco notifying them that unsolicited services are legally a gift, and you did not request any services from them and will not pay for them, and thank you for freely handling all the calls that you tried to make using your preferred long-distance carrier (in my case, AT&T) and that they can return you back at their leisure but could they fix that little hiss in the background?
I haven't tried this, and the telcos probably wouldn't like having this used widely because it's an obvious method for fraud, but tough luck, eh?
I haven't had to use AT&T's don't-call lists, though I think one of their telemarketer subcontractors did call me once even though I'm a subscriber:-)
MCI does a decent job of maintaining don't-call lists - I usually ask them if their employee discount is better than AT&T's and they get the hint. They aren't bright enough to figure out about don't call lists for multiple phone lines at the same address, and they once got lucky and called my modem line between the time I got home and the time I plugged in my laptop, so it's in the list now also...
Gale Secure Messaging Service gale.org
on
IRC Improvements
·
· Score: 2
I saw the Compaq Linux-running iPaq at Linuxworld. It's got all the audio it needs, and you _could_ hold it up to your face and the speaker and microphone are in the right place to talk and listen. It doesn't have a radio module in whichever slot format it uses (PCMCIA? or Compact Flash) that's designed for cellular, but you could build one and integrate it into the phone, and there are cellular modem systems and 11Mbps radio and similar things you could build a cell-like network with.
Now if they'd build an integrated system that used a standard cellular headphone, and move the battery life from current MS-Palmtop levels (less than a day) to Palm levels (multiple weeks) or even just vanilla cellphone levels (4-7 days for Nokia), that'd rock.
How much it costs makes a major impact in usefulness. $100 - easy win. $500 - marginal. $2000 - specialized uses only. The Sony glasses are about $500, but the resolution's not high enough; I think it was something like 600x225.
The USB provides control for the tuning - it's much nicer than adding Yet Another Interrupt-Wasting Serial Port Frob. I've got mixed feelings about whether it should do audio over the USB (which is what I'd expected also) - it's actually connecting analog audio to the sound card, rather than digitizing it itself, which would have added to the cost of the device. I have noticed a major quality difference between playing the audio directly from my sound card into the speakers and using the radio software to digitize it as a WAV file - not sure if this is because I've got an El Cheapo $5 sound card, or because the PC software doesn't use the best possible settings for the card, but there's typically lots of hiss and distortion in the saved version (bad enough it's not worth degrading it further by MP3ifying the WAV.) It might be interesting to try it with a better soundcard, so I may move it the radio to the office and see if it works better here - I'm certainly not going to spend $50 on a new sound card and $100 on more disk space just to make the $29 radio work better:-)
Of course the port is mostly for hack value. But Cisco 2500s on EBay are rumored to cost ~US$500-1000, so it's not much more expensive than a much faster low-end PC.:-) The question is whether you can run Linux Router Project or equivalent router software on them with enough drivers for the various interface cards.
I've got a D-Link USB-controlled radio on my home PC. Nice hardware. Software sucks rocks - it's way clueless, e.g. there's a freeware MP3 encoder available, but to actually produce MP3s, you need to store the radio program in WAV format in RAM/Swapspace, save it to disk, and then run the encoder. (So you're using 2X the uncompressed space, instead of 1X uncompressed + 1x compressed, or even better 2X compressed.) And it's got a timer that knows how to wake up and record stuff - with a 24-hour clock only, so you have to reset the thing TODAY. You can't go away for the weekend and tell it to record something Sunday night, or tell it to record The Grateful Dead Hour every Wednesday night. You could probably do something to integrate it with a Win98 scheduler, but it's pretty tough.
By contrast, when you buy a Cisco router, you're mainly buying IOS and the design of the hardware - manufacturing's less important.
Mr. Lee, of Mr. Lee's Greater Hong Kong in Snow Crash is a positive figure.
Unless I'm misremembering, the scary Asian general in Cryptonomicon is Japanese, not Chinese. While most generals may be scary madmen (:-), WW2 Japan certainly had some.
It's still timesharing, you've just given root the ability to do a "notnice" as well as nicing things:-) More precisely, hard realtime schedulers let you guarantee response times to applications that need it, typically on the few-microseconds or few-milliseconds scale, and the "every process is equal" gets replaced with "some processes are better than others, but every process of the same social class is equal." Yes, this means the low-class tasks may starve; if you don't like that, don't schedule too many high-priority tasks.
"will definately not be a toy when it's out" somewhat correlates with "what's the REAL shipping date for 1.0. not 0.9, not 0.9":-)
I wish them luck - the more realtime capabilities are available in Linux, the more applications can use it instead of either specialized embedded system OS's or close-enough Windows products.
You're not going to transfer the raw ~48MB images, any more than you transfer raw images with digital cameras now. The camera's CPU will do JPEG compression to shrink it to manageable size, though I'm not sure how much compression would be appropriate to use. (Even compressed, you'll still be storing and hauling a lot of data, so cameras for this resolution will presumably use disk-based storage and either USB or something faster like firewire.
Amazing how tough it is in some places to get permission to put up antennas, even for the cellphones that the yuppies who live there use. At least in farm country they're a lot more relaxed about it (just another frob on top of the grain elevator that was there already), and probably get a lot of benefit from it. Next step might be telephone service, if it's reliable enough?
Part of the reason for the price difference is that customers will pay it (:-) Part of it is engineering for extreme smallness. But a lot of it's the cost of 64MB of Flash memory. For a widget hanging off your PC, that's not required - you can use the PC's disk to store lots more.
(I'm not convinced of the value of a parallel-port MP3 player either - why not just use the CPU and sound card? Is this a laptop market thing?)
Any place you put enough infrastructure and people to build something like this will become high-tech if it wasn't already. Probably higher-tech than current Silicon Valley:-)
Governmental stability is a separate problem - you not only have to worry about populations throwing out their governments, you have to worry about governments extorting money from the tower. Chances are that any project spending the kind of money that it'd take to build a 50km tower and a stairway to heaven will be able to negotiate how much graft it'll have to pay the local government, given the boost the thing will be to the local economy.
It's relatively easy to outsource development of a large project where you've done detailed top-down design work first and didn't make any seriously mistaken assumptions that will require restructuring the whole project later to fix. Some projects work fine in this environment, some don't. It's nearly impossible to outsource tight interactive cycles of "design a piece, prototype, evaluate, redesign", especially if the project requires extensive technical knowledge of fields outside the programming business. Some projects have to fit into this space, some don't, some don't have to but are more efficient if you do them this way. On the other hand, outsourcing a project to someone who's got specialized knowledge when you don't can be a major win.
I used to work on air-traffic control systems; we were using the biggest hairiest Mil-Spec (1067?) design/development methodology that required 175 separate deliverable documents in 3 years, all of them entirely compatible with all the other deliverables that had come before, which was abso-expletive-deleted-lutely impossible to do even if you had all the requirements explicitly laid out up front, as opposed to knowing only that if two airplanes crash it's your fault, so everything's rabidly conservatively overspecified beyond the limits of current technology, plus you don't *know* the limits of current technology because the other subcontractors on the project haven't developed it yet, though they got their requests for extra milliseconds for their components of response time in before your team did, and the real specs of the current system consist of antique mainframes running undocumented JOVIAL code you'll need to be compatible with and operations techs named "Skippy" who know each detail very well, wouldn't know a "big picture" if it bit them on the elbow, and have to have each detail pried out of them one at a time by trial and error. (We found a successful way to work in this environment - it was a design "fly-off" between our team and another team of contractors, both on time&materials, and we *lost*, getting ourselves out of the line of fire while the poor suckers who won *still* haven't finished a decade later, and BTW, we knew back in ~1987 that the specs for the regional system wouldn't let you fly the Concorde across the Continental US above Mach 1 even if you *were* allowed to have sonic booms over populated areas.)
Off-site development, especially other-side-of-the-world development, is a less interactive environment than longterm-coworker-in-the-next-cube development. If you need to be highly interactive, you need to be nearby (maybe not geographically, but at least in terms of shared knowledge and interaction speed.) A well-defined project can work; a whiteboard design discussion is a much different environment. If you're handing off something to people you don't know well in a much different environment, it needs to be better-defined, and big enough to handle the learning curve you'll both go through. Smaller tasks often have as much overhead as bigger ones, though if you're going to outsource multiple projects, it's worth trying the small ones first rather than the bet-the-company projects. Learn what kinds of interactions work well and what kinds don't.
It's not just languages - it's business and technical expectations. It usually works fine, as long as you understand that you're outsourcing, not micromanaging. When I've worked with Indian consulting firms in the past, they've typically got a couple of experienced foremen who've worked in the US with US firms, who speak English just fine and know US business environments, and then a group of workers who at least read and write English adequately even though they may not all speak it in real-time with Silicon Valley accents and may be just off the plane. So you'll do most of the interaction with the lead guys, and they may go discuss it with their crew in Indian-accent English or Hindi or Kannada or other regional language.
But in any All-American outsourcing environment you'd often have similar interactions, where the lead Speaker-to-Techies huddles with his krewe and comes back to say "Yeah, we can make the Frobulator do that, but it'll take two more weeks", or the Speaker-to-Marketers goes to play golf and comes back saying "Wait, it's not telepathically controlled and adding buzzword-of-the-week-compliance will cost how much extra?!?"
Legal issues are a different game - you've always got that in an outsourcing or consulting environment, and you've got to be more careful if you're doing international business. But many Indian consulting firms have US parts to them, and you write the contract to specify the customer's state as the defining law, and you realize that the contractor will use the expertise they gained doing your job as a stepping-stone to charge more money for the next job for their next customer, just like you would if you were consulting:-) Since this is Slashdot, there's the extra legal wrinkle of open-source code - you're no longer paranoid that they might take code you paid them to develop and sell it to their next customer - you know they will, because you're requiring them too. So just make sure there isn't too much scope creep in the statement of work.
Why GPG is STILL partly vulnerable to ADK attack
on
GPG vs. PGP?
·
· Score: 5
PGP added a feature called the "Additional Decryption Key", which you or your administrators can add to your PGP public key record so that they can decrypt your messages if Bad Things happen, such as you getting hit with by a truck or a subpoena or a great offer from a pre-IPO startup. If you have a version of PGP that supports this feature, and you encrypt a message to somebody whose key has an ADK field attached to it, and you have a public key matching the ADK's KeyID in your keyring, your message will also be encrypted to the ADK's public key.
The GPG developers wisely chose to reject this feature, so if you use GPG or another non-ADK-supporting variant on PGP to encrypt a message to somebody who has an ADK stuck on their key, it will not encrypt the message to the ADK. This is good, but it's not enough - it only protects your outgoing messages, not incoming messages encrypted to you.
The recently discovered ADK attack found that if a Bad Guy attaches an ADK to somebody's key, it doesn't invalidate the signatures on their key, and doesn't require their signature, so the Bad Guy can distribute that bugged key, and anybody who uses a pre-6.5.8 version of PGP that supports ADKs and uses the bugged key will encrypt to the Bad Guy as well. If you use GPG to encrypt all your PGP messages, you won't accidentally encrypt to the Bad Guy's ADK, which is good. BUT, if you use GPG or other safe PGP version to create a Diffie-Hellman key, and some Bad Guy adds an ADK to the your public key and distributes it, people who send messages to you using unsafe versions of PGP will still encrypt to the Bad Guy's ADK if it's on their keyring.
Slashdot Mirror
If you tell them to put you on their "don't call" list, they're legally required to do so. I work for AT&T, so it's MCI that used to call me :-) It took a while to get the modem line on the don't-call list also, since usually if I was home it would have a computer on it, so it would either be busy or answer with modem tones, and their databases weren't bright enough to decide that since my primary line wanted not to be called, so did the modem line.
You'd be sending equipment, not people. On the other hand, the 1kg/day propellant is a much more serious problem. It's probably not steerable enough to do a good flyby of one of the outer gas planets or their moons to pickup some hydrogen without risking falling into their gravity well. But you can find some interesting balance of weights and propulsion strengths to get out to interesting parts of space and send telemetry back, and once you're going that fast, it's a nice cruising speed.
Coulda been worse - at least their reaction, when put on the spot with something they didn't know about and hadn't paid attention to years of hoax warnings, was "no, we shouldn't be taxing the net" as opposed to "yes, my staff has been evaluating the right way to tax the net and we'll be sure to check out that proposal as well."
Remember CompaQ showing off Linux on an iPAQ at LinuxWorld? Maybe it wasn't Debian, but it was some flavor of Linux, and they'd done a nice job, and had a XWindows telnet font that was small enough to fit usable amounts of text in a window while still being readable, partly because of the gorgeously bright battery-burning screen. They also had some non-text apps running on it, but it was clearly the real thing.
I think I may have crashed my Psion 3a in the past, but it didn't happen on things I want to do every day.
Disclaimer: I work for AT&T, but my comments here are just my personal comments. You can read AT&T's comments on slamming on their web page.
AT&T got lots of flack for a while from people being slammed by their subcontractors, and they started putting a lot more control on that, but they still screw up sometimes.
I've never particularly liked the local phone companies' approach to slamming, which is to continue to bill you for the long distance service and have you resolve it. My own preference is to write to the local telco and the slammer telco notifying them that unsolicited services are legally a gift, and you did not request any services from them and will not pay for them, and thank you for freely handling all the calls that you tried to make using your preferred long-distance carrier (in my case, AT&T) and that they can return you back at their leisure but could they fix that little hiss in the background?
I haven't tried this, and the telcos probably wouldn't like having this used widely because it's an obvious method for fraud, but tough luck, eh?
I haven't had to use AT&T's don't-call lists, though I think one of their telemarketer subcontractors did call me once even though I'm a subscriber:-)
MCI does a decent job of maintaining don't-call lists - I usually ask them if their employee discount is better than AT&T's and they get the hint. They aren't bright enough to figure out about don't call lists for multiple phone lines at the same address, and they once got lucky and called my modem line between the time I got home and the time I plugged in my laptop, so it's in the list now also...
The Gale secure messaging service is in version 0.99a. FAQ. The name is a takeoff on MIT Zephyr. Goals include scalability as well as security. The Gale documentation has a page comparing Other secure instant messaging systems.
Now if they'd build an integrated system that used a standard cellular headphone, and move the battery life from current MS-Palmtop levels (less than a day) to Palm levels (multiple weeks) or even just vanilla cellphone levels (4-7 days for Nokia), that'd rock.
How much it costs makes a major impact in usefulness. $100 - easy win. $500 - marginal. $2000 - specialized uses only. The Sony glasses are about $500, but the resolution's not high enough; I think it was something like 600x225.
The USB provides control for the tuning - it's much nicer than adding Yet Another Interrupt-Wasting Serial Port Frob. I've got mixed feelings about whether it should do audio over the USB (which is what I'd expected also) - it's actually connecting analog audio to the sound card, rather than digitizing it itself, which would have added to the cost of the device. I have noticed a major quality difference between playing the audio directly from my sound card into the speakers and using the radio software to digitize it as a WAV file - not sure if this is because I've got an El Cheapo $5 sound card, or because the PC software doesn't use the best possible settings for the card, but there's typically lots of hiss and distortion in the saved version (bad enough it's not worth degrading it further by MP3ifying the WAV.) It might be interesting to try it with a better soundcard, so I may move it the radio to the office and see if it works better here - I'm certainly not going to spend $50 on a new sound card and $100 on more disk space just to make the $29 radio work better :-)
A Cisco 2500 is what, a 20MHz 68030? Lotsa spare cycles there....
Of course the port is mostly for hack value. But Cisco 2500s on EBay are rumored to cost ~US$500-1000, so it's not much more expensive than a much faster low-end PC. :-) The question is whether you can run Linux Router Project or equivalent router software on them with enough drivers for the various interface cards.
By contrast, when you buy a Cisco router, you're mainly buying IOS and the design of the hardware - manufacturing's less important.
It's still timesharing, you've just given root the ability to do a "notnice" as well as nicing things :-) More precisely, hard realtime schedulers let you guarantee response times to applications that need it, typically on the few-microseconds or few-milliseconds scale, and the "every process is equal" gets replaced with "some processes are better than others, but every process of the same social class is equal." Yes, this means the low-class tasks may starve; if you don't like that, don't schedule too many high-priority tasks.
I wish them luck - the more realtime capabilities are available in Linux, the more applications can use it instead of either specialized embedded system OS's or close-enough Windows products.
Is this 8-bits per color? 12-bit? What's the linearity like?
You're not going to transfer the raw ~48MB images, any more than you transfer raw images with digital cameras now. The camera's CPU will do JPEG compression to shrink it to manageable size, though I'm not sure how much compression would be appropriate to use. (Even compressed, you'll still be storing and hauling a lot of data, so cameras for this resolution will presumably use disk-based storage and either USB or something faster like firewire.
Amazing how tough it is in some places to get permission to put up antennas, even for the cellphones that the yuppies who live there use. At least in farm country they're a lot more relaxed about it (just another frob on top of the grain elevator that was there already), and probably get a lot of benefit from it. Next step might be telephone service, if it's reliable enough?
(I'm not convinced of the value of a parallel-port MP3 player either - why not just use the CPU and sound card? Is this a laptop market thing?)
Governmental stability is a separate problem - you not only have to worry about populations throwing out their governments, you have to worry about governments extorting money from the tower. Chances are that any project spending the kind of money that it'd take to build a 50km tower and a stairway to heaven will be able to negotiate how much graft it'll have to pay the local government, given the boost the thing will be to the local economy.
I used to work on air-traffic control systems; we were using the biggest hairiest Mil-Spec (1067?) design/development methodology that required 175 separate deliverable documents in 3 years, all of them entirely compatible with all the other deliverables that had come before, which was abso-expletive-deleted-lutely impossible to do even if you had all the requirements explicitly laid out up front, as opposed to knowing only that if two airplanes crash it's your fault, so everything's rabidly conservatively overspecified beyond the limits of current technology, plus you don't *know* the limits of current technology because the other subcontractors on the project haven't developed it yet, though they got their requests for extra milliseconds for their components of response time in before your team did, and the real specs of the current system consist of antique mainframes running undocumented JOVIAL code you'll need to be compatible with and operations techs named "Skippy" who know each detail very well, wouldn't know a "big picture" if it bit them on the elbow, and have to have each detail pried out of them one at a time by trial and error. (We found a successful way to work in this environment - it was a design "fly-off" between our team and another team of contractors, both on time&materials, and we *lost*, getting ourselves out of the line of fire while the poor suckers who won *still* haven't finished a decade later, and BTW, we knew back in ~1987 that the specs for the regional system wouldn't let you fly the Concorde across the Continental US above Mach 1 even if you *were* allowed to have sonic booms over populated areas.)
Off-site development, especially other-side-of-the-world development, is a less interactive environment than longterm-coworker-in-the-next-cube development. If you need to be highly interactive, you need to be nearby (maybe not geographically, but at least in terms of shared knowledge and interaction speed.) A well-defined project can work; a whiteboard design discussion is a much different environment. If you're handing off something to people you don't know well in a much different environment, it needs to be better-defined, and big enough to handle the learning curve you'll both go through. Smaller tasks often have as much overhead as bigger ones, though if you're going to outsource multiple projects, it's worth trying the small ones first rather than the bet-the-company projects. Learn what kinds of interactions work well and what kinds don't.
But in any All-American outsourcing environment you'd often have similar interactions, where the lead Speaker-to-Techies huddles with his krewe and comes back to say "Yeah, we can make the Frobulator do that, but it'll take two more weeks", or the Speaker-to-Marketers goes to play golf and comes back saying "Wait, it's not telepathically controlled and adding buzzword-of-the-week-compliance will cost how much extra?!?"
Legal issues are a different game - you've always got that in an outsourcing or consulting environment, and you've got to be more careful if you're doing international business. But many Indian consulting firms have US parts to them, and you write the contract to specify the customer's state as the defining law, and you realize that the contractor will use the expertise they gained doing your job as a stepping-stone to charge more money for the next job for their next customer, just like you would if you were consulting
The GPG developers wisely chose to reject this feature, so if you use GPG or another non-ADK-supporting variant on PGP to encrypt a message to somebody who has an ADK stuck on their key, it will not encrypt the message to the ADK. This is good, but it's not enough - it only protects your outgoing messages, not incoming messages encrypted to you.
The recently discovered ADK attack found that if a Bad Guy attaches an ADK to somebody's key, it doesn't invalidate the signatures on their key, and doesn't require their signature, so the Bad Guy can distribute that bugged key, and anybody who uses a pre-6.5.8 version of PGP that supports ADKs and uses the bugged key will encrypt to the Bad Guy as well. If you use GPG to encrypt all your PGP messages, you won't accidentally encrypt to the Bad Guy's ADK, which is good. BUT, if you use GPG or other safe PGP version to create a Diffie-Hellman key, and some Bad Guy adds an ADK to the your public key and distributes it, people who send messages to you using unsafe versions of PGP will still encrypt to the Bad Guy's ADK if it's on their keyring.