Cell phones don't threaten long-distance telcos - they just move the sales job from the direct-to-consumer model to the wholesale-to-cellphone-company model.
They *could* annoy the local telcos, except that (at least in the US), most of them own cellphone companies anyway, and the cellular business lets them compete outside their base geography. Also, while some single people may very well stop using landline phones and only use cell phones, many of those people still have a phone line for DSL, and businesses still use wired phones. Also, about half of the local telcos used to bitch about people using phone lines for modem internet service and messing up the cost model (the other half said "oh, good, we get to sell more phone lines") so we're really just helping them out.
VOIP annoys your local phone company if you're using a cable modem, because they don't get the money - but if you have DSL, they still get to rent the copper lines to your house, and the DSLAM on the end is a lot cheaper than a #5ESS voice switch. They still make money, and if you bought the DSL line partly to run VOIP instead of Napster, well good for you. Also, until the current telco service mostly disappears, VOIP services like Vonage pay by the minute to deliver calls to telco customers, so the local telcos still make money from it (sometimes more than they would from flat-rate lines.)
And the 911 agitation isn't mostly from the local telcos - it's mostly from emergency service bureaus, whose architecture is heavily dependent on the telco infrastructure and the underlying design assumptions (like phones being in well-defined places), who will have to spend a lot of money to develop more flexible architectures unless they can bully the VOIP businesses into doing that (and they don't have budget sources to get the money they'd need.) It's also coming from the wiretapping fans in the FBI, HomelandSecurity, and some police agencies, who not only want to prevent current targets from becoming un-tappable, but who want to gain lots more detailed surveillance capabilities with less judicial oversight (inconveniences like warrants, etc.) - they've been successful at getting cellphones to report position information by whining about how ambulances won't be able to find your grandmother when she's fallen and can't get up, and are doing the same with VOIP.
Traditional PBXs have been headed in the IP-PBX direction for half a decade now, and the big players are mostly in their second generation of equipment, including Nortel and Avaya as well as new competitor Cisco. The economics of building IP-based PBXs and doing feature development on them totally dominate the traditional approaches (though that's partly because of the weaknesses of the traditional approaches.) People pretty much don't look at non-IP solutions for new standalone offices - non-IP PBXs are only used for compatibility with existing sites, or occasionally for recycling spare parts.
Connections between corporate offices have also been moving to VOIP, especially for international connections. You might not use them to talk to customers, but for internal calls they're fine. A few years ago the choices were between adding a voice board to a router (connecting to the PBX with T1), or adding an IP board to the PBX (usually more expensive, but better integrated for support), but now IP PBXs are becoming more common.
Connections to the outside world are gradually becoming more widely used, and everybody in the telco business is trying to figure out how to make money on it even though the prices keep getting radically lower.
VOIP as a replacement for telco service is going to take a while. VOIP as a replacement for early PBX architectures is here, now, has been for a few years, and nobody's seriously using non-VOIP PBXs in a new-office environment unless they're trying to maintain compatibility with the PBXs at their other offices and can't get a matching VOIP solution from their PBX vendor. Similarly, as existing PBXs go end-of-life, they're getting replaced with VOIP PBXs. The real questions are mostly "Do we get a VOIP solution from our existing PBX vendor, or do we buy Cisco since we use their routers anyway?".
VOIP has also been in use in many corporate environments for office-to-office communications, especially internationally, even if it's not used to connect to the telco for outbound calls or inbound customer calls. Back in the mid-80s, everybody ripped out their inter-PBX tie lines because it was cheaper to buy telco phone service by the minute and reduce the management effort; these days, people are putting those things back in, because the economics often justify it, even though long-distance phone minutes keep getting cheaper.
A good berserker rage can lose you a few pounds, and it has the benefit of killing off the people who are sending out this annoying junk. It's one thing to have positive-mental-attitude saccharin sent to you once. A steady diet of it can cause lots of collateral damage, unless you go stop it at the source. There are people who like that sort of thing, and there's a "Successories" catalog just for them. Then there's the rest of us.
A decade ago the company I was working for started putting out lots of happy happy joy joy stuff about taking responsibility for your own career management and managing change, and recycling Clintonesque rhetoric about "Change is Good". Half my department got laid off a couple of months later, by the same happy happy joy joy PR people. A couple of years later, my next company's PR people started putting out 3-inch-diameter buttons saying "We're Navigating Change" with a ship picture in the background, and matching mouse pads and note paper and friendly brochures about how change can be stressful but we can be highly effective people if we manage it well and drink the company Kool-Aid. The layoff that time was only about 10%, not including me. A couple of months later my pen leaked in my pocket, and I decided that I'd rather wear the stupid button and cover the ink spot during the meeting I was having that afternoon, so it had some use...
That's only a beginning.
on
Anatomy of a Hack
·
· Score: 2, Interesting
Sure, you can check the files that are part of the standard distribution. That won't find additions to your password files or the similar permission files for half a dozen different programs that track who's authorized to do what, or find extra programs in root's home directory or search path or/bin (such as a modified version of a file that's normally in/usr/bin, with the/usr/bin version left untouched), and it won't find modified versions of files that get modified during the installation process, and there are probably a bunch of other ways to hide things.
So you have to start by reinstalling known good copies on a reformatted disk slice, and gradually recover things as you prove them safe. It's much easier if you've done a heavy-duty job of configuration management and kept a really solid wall between your development and production systems, but that's surprisingly hard to get anybody to do well enough.
I once found a directory/.something with cracker data on one of my lab honeypots - the cracker had modified "ls" and "ps" so his files and processes wouldn't be found, including all his little setuid toys. Didn't occur to him that I'd be using "find" as a regular administrative tool that he'd need to hack, or looking at/proc wondering why there seemed to be extra processes there. (After all, it's a *lab* machine - I was experimenting with it.) You'd probably find some of those things if you were using Knoppix to check, but you might not, since the evil processes were running with innocuous-looking names and the directory names started with dots.
Article has a good page on cleaning systems
on
Anatomy of a Hack
·
· Score: 4, Interesting
About page 10 of the article, the author gets to a discussion of what you can do to clean up a compromised system, and uses the analogy of cleaning a swimming pool with undesirable liquids in it - you can't just clean the water, you've got to drain the whole thing and start over. He lists a large number of things you can no longer trust on a compromised system, and explains how each of a number of successively more difficult approaches won't work.
You can't just patch the hole the attacker used - he installed a bunch more new holes one he got in.
You can't just reinstall from backup, because you don't know if your backup files are compromised too.
You can't look in your log files to figure out when you got compromised, because any good cracker knows to wipe his traces out of the log file.
You can't just reinstall the operating system over the existing one - too many dangerous files may still be there, including things left in the data and application directories.
3... 4... 5. DON'T PROFIT! 6...
You're stuck reinstalling the OS and applications from known-good media onto a clean disk, and hoping you can salvage some of the data, depending on whether your applications make this possible.
What he doesn't really go into his how to build your production systems in a way that *ASSUMES* you're going to get attacked, maintains a clean environment for developing them in, and gives you the tools to rebuild rapidly from trustable versions. On the other hand, he does show how his example's victim's system was thoroughly broken into, getting from the production system to the development system, because it really *is* hard to do a good job of separating them adequately in a real environment, so even if you think you have a clean-room, you might not.
Some screensavers use almost no CPU, but many of them really scarf down the horsepower. Displaying random JPEGs is pretty cheap, and having them float around a bit can be done with large or small amounts of CPU, but applications like fractal-generators typically draw as fast as your CPU can handle. If you're burning the CPU anyway, might as well calculate the data that you want instead of pretty decorative stuff - especially if your grid-computer application runs at a low enough priority that the screen-saver outranks it, which is often the case.
This used to be a real annoyance when I had a Sun lab a decade or so ago - the server was a big SparcStation 2 with a great screen on it, and most of the clients were IPXs or Sparcstation 1s, and if somebody had running one of the really cool fractal screensavers as their X environment, and logged in to the server to do their applications, the whole network could dog out if they went to lunch or went home for the night without logging out first. The equivalent I put up with these days is that I run some Protein-Folding-At-Home variant on my desktop, and while I use a display-a-picture-every-few-minutes screensaver, my wife runs some flying-starfield screensaver, so if she was the last one to log on, there are fewer CPU cycles available to fold proteins with.
By the way, NEVER run grid-computing applications on laptops - they aren't made for the constant heat load, and obviously if you're using them on batteries, you'll find that they're not made for heavy frequent battery drain either (I learned this the hard way commuting by train back when I was running the GIMPS Great Internet Mersenne Prime Searcher....)
The Black&White Screen Of Death just didn't cut it (and the darker-grey on lighter-grey screen of death was even lamer:-) And besides, Windows can stay up for 45 days at a time, and my phone usually runs out of battery before then.
Just as long as there's no Dancing Paperclip of Death or helpful friendly dog named Bob to go fetch phone numbers for me, it'll be ok....
The way to get cross-platform support is to design using open standards. (That doesn't have to be open source - public standards is enough.) H.323 is a bit too complex and doesn't scale very well, but almost everybody's system out there supports it, at least as a lowest-common-denominator interface. SIP really does the job, and everybody *says* they're supporting SIP, even if that's really only an edge interface in their current product and there's something else inside, like Skinny or H.323-with-extra-help. Obviously standard have the problem that there are so many to choose from, and they have so many options that you can be incompatible while still supporting standards, but we're getting there.
Yeah, Skype supports a couple of platforms, but they're a fundamentally closed system (by policy, not necessarily by technology) which mostly ignores standards, and is only gradually figuring out how to integrate with the outside world - they do some things very well, and bought some good codecs, but they're a consumer-to-consumer solution, not a business solution.
Microsoft, BTW, gets great credit for giving out Netmeeting for free, N years ago, following the H.323 standards. It wasn't perfect, but it really did work, and that helped motivate other vendors to do the compatibility job they should have been doing all along. (I think some of the Linux video apps work with it, like Gnomemeeting.) MS Windows Messenger apparently uses SIP, though I haven't tried it. (My company uses a Jabber-based IM system internally instead, so I use that for work IM, and I find IM sufficiently annoying that I haven't installed any of the other IM products, ESPECIALLY anything that would let me get AOL AIM messages from my mother-in-law:-)
Video, VOIP, and Instant Messaging are really all the same thing - there's some kind of presence server that you register with, and you set up media channels between the end users. H.323, SIP, Jabber, Skinny, and N different proprietary things are just different variations on how to do this, and there's the usual marketdroid struggle for interoperability vs. control. The VOIP people mostly want interoperability, and are working their way toward SIP while trying to maintain backward compatibility if they have older solutions to worry about. Video has two markets - corporate video conferencing, dominated by people like Polycom, who I think are H.323-based migrating to SIP, who make money selling hardware and like interoperability, and video-chat applications which are mostly related to the consumer IM world, where the aggressively non-interoperable control freaks dominate because they're run by consumer ISPs (AOL vs. MSN vs. smallfry) who make money from selling you their ISP service. Most of them have some kind of Windows client that non-subscribers can use to contact subscribers, like the Netscape AOL Messenger frobs, but the reason they won't work with each other is that they try very hard to block anybody who does re-engineer their protocols. (And as noted, I don't want IMs from my mother-in-law, so other than trying out AIM in my lab a couple of years ago, I haven't installed it:-)
POE (Power over Ethernet) is only relevant if you've using VOIP phone hardware, not if you're using PC software clients (like Windows Messenger), and even then you only need it if you want to avoid wall-worts or guarantee that your phones work during power failures, which shouldn't happen very often and only matter if you want your employees to work in the dark without PCs - it's usually not a problem, especially if your employees have cell phones that they can use in case of emergencies.
LAN QoS can matter, but usually doesn't. Most offices have 100 Mbps Ethernet to the desktop these days, with some level of switching behind it, and while you should put your big data servers on different segments than your phone switches, that's usually enough. Windows XP has enough QoS capabilities that you can get it to prioritize outbound VOIP over outbound data, and while that doesn't fix the inbound problem, it's a good start. Sometimes you can still get into trouble, but as long as you've got some control over your infrastructure, you can usually avoid it. Worst case is you throw in a wireless LAN to handle your voice users and leave the wired network for data.
WAN infrastructures are much more interesting, because they're usually much narrower than LANs. One approach is to ignore the problem - use the VOIP for a PBX, replacing your old dedicated clunker PBX, and use telco facilities to reach the outside world. (Yeah, boring...) Another is to look at all the new services from data carriers - many Tier 1 internet vendors support QoS within their networks (which is enough for your PBX services), and almost everybody is pushing some MPLS solution, either to get a few more years out of their Frame/ATM infrastructure, or to use their IP network to muscle in on the Frame/ATM carriers' business, and most of those have QoS.
SIP is designed to work with multiple levels of proxies, so it's easy to design for scalability. If you want a building to be able to talk when its connection to your headquarters data center is down, you do need to have a local server, but that can be implemented as a simple PC with VOIP software on it, or Cisco's SRST feature running on your router. The reason it's a big problem in Cisco-land is that most of the Cisco IP telephony environment really runs their old "Skinny" protocol, with H.323 and SIP only on the edges, so it's harder to make it scale without a lot of extra hackery (i.e. without paying for a bunch of extra licenses and adding a few extra trunks between diverse servers.) (There's also the minor issue of router horsepower, since Cisco tends to use small CPUs and do most routing work in ASICs; not a problem if you're using a PC-based system where CPU and RAM are dirt cheap.) You could avoid much of this problem if you built a system out of Asterisk, or if Microsoft does a good job of integrating Sylantro and has it priced in a way that works.
Traditional PBXs have been doomed for years - Moore's Law means there hasn't been a good reason to deploy a non-IP PBX into a new location for at least 3-4 years, even if it's still going to connect to the public telephone network using a T1 or individual copper lines. The old PBX makers like Avaya (formerly Lucent/AT&T/WesternElectric) have gone from transitional support for old PBXs with VOIP add-ons to full VOIP systems and retained as much of their feature knowledge as they could, and major new players have gotten into the business - Cisco being the obvious big one, since most people also use their routers, but also Nortel/Siemens/Alcatel/etc., and there are also niche players like Asterisk. Most of them support H.323 as lowest-common-denominator standard, have lots of marketing words about using SIP even though they're not really there yet, but many of them use something of their own instead ("Skinny" for Cisco, IAX for Asterisk.)
It's really no surprise that Microsoft would get involved, since almost every business office is already using their products, and they've got surprisingly deep experience with the older H.323 standards (NetMeeting was one of the first widely deployed H.323 systems in the video world, and yes, that's Microsoft pushing standards-based solutions against the proprietary vendors.) Sylantro, who they're making this announcement with, is a major player in the VOIP-for-Telcos market using SIP standards, so they're not just doing a simple roll-your-own. You'll also notice that Microsoft Windows Messenger is based on SIP - so they've already got a desktop client that's just waiting for a server that's designed for phones and not just mainly for IM. We'll see how well and how fast they execute, and how well they can integrate with the rest of the market, but if they were to attach this thing along side of an Exchange server at a reasonable price, they could achieve World Domination fairly quickly, just as Skype has in the consumer-toy market.
Telcos know that the traditional local+long-distance voice market is doomed, and they're adapting to it. The local carriers still have a business model managing the wires out to your house, regardless of whether they're charging $15/month to hook up the wire to a voice switch or charging $15/month to hook it up to a DSLAM (especially if they're providing the DSLAM or at least the upstream network to the ISP.) And they know they're going to need to replace their old #5ESS and Nortel DMS switches with VOIP switches (i.e. big SIP servers), but that's feasible because the new stuff is a LOT cheaper. Long distance companies are either becoming IP and private line carriers (AT&T, MCI/UUnet, Qwest), or becoming cellphone companies (Sprint/Nextel), or both, and selling out to local telcos (AT&T to SBC, MCI to Verizon and/or Qwest).
There's a lot of transitional business connecting up the old telco services to the VOIP services, some of which is coming from the long-distance or local telcos, and some of which is coming from upstart VOIP providers. The long distance companies will have mostly retired the old #4ESS switches within five years or so, replacing them with VOIP services of various types, and they're desperately trying to figure out how to do it in a way that's scalable - it's much easier to replace a PBX with VOIP than to replace a network that handles 300 million calls a day. The two obvious disruptive models to the remains of the long-distance business are that the local telcos get approval to connect to each other using VOIP, dropping the underlying cost of long-distance to basically zero, or that a decentralized solution emerges along Free-World-Dialup lines, e.g. business PBXs and home phones use spare connections to terminate calls from the VOIP space into the local-telco space. The big moneymaker for the long-distance business these days is still call centers, which have a lot of complexity and added value managing inbound calls and therefore get to charge a lot more for doing that. It's not cl
802.16 isn't currently usable for real mobile endpoints, so it's not yet a replacement for cellular. The differences between endpoint types are
Fixed - The antenna's nailed up somewhere, and doesn't move, and you can even aim a directional antenna. This part works pretty solidly.
Portable - you can move one of the endpoints to a different location and it'll still work, as long as it's close enough to the tower, so you can take your laptop to your customer's office or home or the coffeeshop and sit down and work, and you can drive your car somewhere and park, but it won't work while you're driving. This part mostly works.
Mobile - you can use it while you're actually moving around, driving at highway speeds or sitting on a train, and it'll adapt to changing radio parameters, switch between towers like a cell phone, etc. This part is at best bleeding edge right now, and I don't think any carriers are going to be supporting it for at least a year or two except perhaps in limited trials.
You need full mobile to do cell-phone replacement.
There are still issues about using licensed vs. unlicensed spectrum that are going to affect how much interference you can expect (some carriers translate this to "I can do an SLA for licensed bandwidth but not really for unlicensed.")
It's an absolutely stunning technology to use as a backup for wired service, e.g. you've got a copper T1 and an 802.16 wireless service, so even if a backhoe or earthquake takes out your street, the wireless still works, and if it's raining to hard so the wireless is noisy, the T1 still works, and most of the time you can use both connections. For big business offices, you can get diverse fiber access or diverse T3 copper, configured as a ring so a single backhoe can't take out both sides, but it most of the US it's really hard to get that at T1 sizes or smaller, so a small business or a small office of a big business can't get good diversity from the telco (some applications, particularly voice, don't perform well over satellite, and previous generations of cellphone wireless data are often too slow for most businesses, and freespace optical isn't widely deployed.) In some cases, a small office can get some diversity by using a cable modem as the second connection - but that's mostly available in residential areas, not business areas.
If you're running on SDSL, or only running one call at a time, you might have enough data transmission quality to get decent results, but if you're trying to put multiple voice calls on DSL, especially consumer asymmetric DSL, you often won't have a good enough data connection for it. The problem is that while the connection from your premises to the DSLAM may have enough bandwidth (if you're using a Vonage box or something similar to prioritize the voice), but the connection from the DSLAM up to the internet itself is typically oversubscribed, and there may or may not be enough bandwidth for your voice calls on that segment. For instance, that 128kbps upstream may have only 32kbps guaranteed between the DSLAM and the outside world, and while you'll usually get it, sometimes you won't, and your voice packets are now competing with your data packets and everybody else's packets.
Thanks! That's a really extensive network they've got. Looks like my downloads were coming direct from London via Abovenet, rather than from some caching server in the US, which makes the performance even more impressive.
Oh, so it's *your* fault:-) Actually my downloads worked just fine - appeared to be filling my 1.5 Mbps in the US. You must not have saturated your 40 Mbit connection for very long - a 40 MB file would take 8 seconds if you could really go that fast.
In general, this is the best download performance I've seen - usually anything large that I'm downloading other than bittorrents will either saturate a small server with a small number of downloaders, or a large number of downloaders on a large pipe, but this just blazed away.
Sometimes the bargain-bin things are overstock, but sometimes they're the Cheap-Ass Commercial Orchestra putting together something they think they can sell as elevator-music. You're often better off with a low-bit-rate MP3 of a good orchestra with a good conductor (or a scratchy vinyl recording) than a great-quality reproduction of a lousy orchestra.
That doesn't mean that it isn't worth occasionally getting those recordings, especially for obscure composers or pieces that don't get recorded very often, but for major pieces it's going to make a lot of difference. On the other hand, university orchestras may be more interesting than most of the commercial orchestras, because they've got more flexibility to fool around.
Both types of skills are important, and they're radically different. I worked for Bell Labs just after college, and one of the most valuable things they did for new employees was make us take a writing course. Sure, my grammar and spelling were impeccable, and after enough years of studying English, Latin, German, Greek, Southerner, and Academe-speak, I could write in whatever kind of correct, precise, and complex sentence structure seemed entertaining or beautiful at the time, and spelling checkers were also helpful to make up for any typing mistakes. But organizing content for your audience, both to convey information and to clarify your own thinking are different skills than expressing each sentence. Writing for engineers and managers to read are two different problems, but both are much more like writing for newspapers than writing academic papers, and they spent a lot of time emphasizing NOT to write like a grad student. You want to hit the critical points up front, with more detail as your reader progresses farther (if he does), and especially for on-line use it's important to have some idea of your reader's attention span to know how deep an argument you can make and how often to repeat points. The more complex the subject matter, the more it's likely to be worthwhile simplifying the sentence structures, splitting things up into lists, or whatever it'll take so that the reader's attention can be focused on the content and not wasted on your subtle and precise use of the subjunctive mood. (That's still partly true in literature as well, but writing for someone who's going to take an afternoon reading your essay is much different from writing for someone who wants to pick up a manual and find out how to do something, or for someone who wants to know which projects to prioritize and which projects don't need a hardware budget until next quarter.)
Anybody in the programming business deals with syntax and grammar for a living, using it to express complex ideas very precisely. Apparently a large fraction of the technical community does that using different skills or brain functions or something than the ones they use to process English. (I'm not talking about the people whose native languages aren't English or closely related languages - I'm talking about native English speakers.) I don't really understand that, because to me they appear to be tightly related functions, but the problem is sufficiently widespread that I don't think it's just due to the sloppy educations that kids get these days (which were probably just about as sloppy when I was a kid....)
I'm not talking about deliberate use of slang or 1337-sp3k3 or ghetto what-up-dog speak or overabuse of bad punning or even Ebonics and other dialects and pidgins. I'm talking about sloppiness, lack of differentiation between homonyms, bad spelling, and the like. English is sufficiently flexible and mushy and evolving that differentiations such as the one between "like" and "as" are going to evolve, if in fact the language was really ever as precise as your 9th grade English teacher told you it was (you remember her - the one who insisted on grading the class on a precise Bell Curve even if class tracking meant that the whole class was in the top 10% of students to start with?)
You're geeks, get some tools, and if correctness isn't instinctively wired into your fingers when you're typing, fix it by using spellcheckers and grammar checkers and whatever else you've got! (I hate to say it, but Microsoft Word does this really well...) There's no excuse for "definately" when it's not a correct spelling and your spell checker can find it for you. If you've got a grammar checker, use it too, and pay attention when it nags you about incorrect word choices (if it's bright enough to do that, which many of them aren't), though you'll also have to ignore more advice from the grammar checker than the spell checker. You may have to spend a while teaching your spell checker that "31337" is spelled just fine, thank you, but that's what the "Add" menu-item is for, as well as the "ignore words with numbers in them" features.
If you don't spell things correctly and use vaguely correct grammar and word choices, Babelfish is going to have a tough time translating them for non-English-speaking readers.
My mom used to really rant any time the "Winston tastes good like a cigarette should" commercial came on, because it should be "as", not "like" - but that's been part of language evolution.
The EFF was originally founded in response to the abusive seizure of the Steve Jackson Games company's computers. It sounds like there are some definite conflicts between the way Chip's computers were seized and handled and the Federal laws, rules, and procedures for handling computer evidence. (That doesn't mean that Pennsylvania state evidence procedures or prosecutor/police rules are necessarily aligned with Federal, but Federal law still applies.) That's the kind of thing the EFF is good at.
However, the EFF and ACLU seldom get involved with things unless somebody asks them or things are brought to their attention through other channels. No idea if that's happened here.
Sure, it's almost guaranteed that he won't get his job back and wouldn't want it back if it were offered. However, it appears from a cursory reading of Chip's side of the page that not only did they treat him in a highly unethical manner (which may entitle him to sue for damages under some whistleblower laws, if PA's cover that kind of case), but they also appear to have libeled and slandered him and caused his property to be taken in ways that sound probably illegal or at least tortuous, and he's probably got a cause to sue them for that.
Normally it's not good practice to burn your bridges when leaving a job, but if the company blows them up when you're standing on them that principle doesn't really apply. A more serious problem is whether the immoral bastards were making enough money that you can recover anything if you sue them...
Also, there's dubious ethics and dubious legality. If you know your employer is acting in ways that are illegal, and you continue to support those activities, then you may or may not have a share in the guilt, depending on the various rules about corporation vs. employee responsibility and whether the actuions are covered by civil or criminal law. (To the extent mentioned in Chip's article, it sounds like most of the issues are either anti-spam law, which is mostly just civil and not criminal, or possible torts against the people whose systems they abused, plus of course their treatment of him where he's not the guilty party.)
Dubious ethics is a different problem from dubious legality - if you think they're unethical, you've got a personal responsibility to either work against those actions (if that's realistic in that company) or get out. I used to work for the part of my company that sold services and computers to the military. Took me a while to decide I shouldn't be doing that and find another job, but at least it was a big enough company that that was an option, and I've changed jobs a few times since then.
Fuel and Payload in One Small Package!
on
Liquid Hydrogen UAV
·
· Score: 4, Insightful
It's not a WMD with just hydrogen explosive, though there are UAVs that can carry a 50-kilo payload, enough for a US backpack-sized tactical nuke.
It wouldn't have helped the US avoid falsely accusing Iraq of making WMDs, partly because it's not good enough to tell a "baby milk factory" or "pharmaceuticals factory" from a "chemical weapons factory". But the big problem was that the US government *wanted* the conclusion to be "Iraq has SCARY WMDs" to convince the US public to let them invade again, and anything that simply flies over and says "no, didn't see anything suspicious on the outside of those factory buildings" isn't going to either change the propaganda policy or tell the military planners not to target a factory-shaped building.
On the other hand, better UAVs would help improve targeting for the things they did want to blow up, or at least let them see whether groups of people were wearing uniform-colored cloths or not.
Scalia got some things right, and most of the arguments are really detailed discussions about how to deal with regulations made by the FCC about technologies they didn't really understand that implement laws made by the Congress about some tech that hadn't been invented and other tech they didn't understand either, which were generally made to deal with political and economic issues about phone companies and time-sharing services and their competitors.
Scalia indicates that he doesn't see why cable modems and DSL should be treated differently (and he also thinks that DNS has some reason to be tied to your ISP, though he somewhat gets that email and web service are distinct from internet service, which the Portland case didn't get.) But they're fundamentally different services - Cable is IP, DSL isn't.
DSL is really ATM underneath, providing a Layer 2 point-to-point virtual circuit between two devices, and any IP services are provided by the endpoints. So if the telco is providing the DSLAM (as opposed to renting dry copper wires to a CLEC like Covad and renting cage space in the telco wire center for the CLEC's DSLAM), they can support any ISP that wants to either buy a private line to their wire center or else buy an ATM pipe to terminate the virtual circuit on, and it's the ISP's job to provide a router that terminates the Layer 2 virtual circuit and connects to the Internet and optional services like email. In some cases, the telco also provides internet service, or does co-branding partnerships like SBC Yahoo; in other cases the telco only sells to ISPs and doesn't do their own. Also, the telco can either sell the DSL connection to the end user, putting it on their telco bill, or the telco can sell it to the ISP, who bundles it with Internet service and bills the end user.
Cable modem is different - it's an IP technology, which is inherently open unless you try hard to make it closed. It's Ethernet-like shared cables at the bottom, and the right architecture is to provide IP routing from the head end on up, connecting to other ISPs at a few regional peering locations. There's normally no good technical reason for an ISP to put connectivity into each head end office, though they might make a deal for some really special application; connecting at the peering points is almost always the right choice, though that connection might just be a data pipe or it might involve colocating some servers at the cable company's bigger data centers. That's not always how it's implemented - some cable companies use annoying and stupid protocols like PPPoE to gain a bit more control over the user, and do various filtering things to limit their usage.
The ISP coalition that argued so-called "cable openness" in the Portland case and before was really trying to argue for *closing* the cable service and giving themselves special access. The biggest problem was that by buying Internet service from the cable company, the customer feels like he's a customer of the cable company and should get services like email from them along with his Pay-Per-View movies, and the ISPs hadn't figured out how to reinvent themselves as Email and Web service providers rather than bundled-package providers. The real things that would constitute an "open" cable service and still let the ISPs make money would look something like:
Some kind of wholesale pricing that lets the Bundled-service ISP market to the customer and send the customer a bill for the bundle, so he feels like an Example.Net customer and not just a CableTVModemCompany customer. (This requires the ability to handle bulk billing and ideally a slightly lower price.)
Optionally having the cable company NOT bundle email services in with Internet connectivity for the wholesale customers - probably not a big deal, since the cablecompany is probably outsourcing that job to a specialist anyway.
Regional connectivity - you can argue about equally well whether it should be free peering, cable company buying transit serv
The article says they asked developers to only be brutally honest. Basically, that means they're asking them to bash anything even marginally negative about the products, and the negative comments will be the primary focus of the article, because that's really much more fun than writing about "Some of the hype is really really true and some of it's a bit premature", and you're almost never going to write a realistic article that says the real thing is EVEN MORE EXCITING than the hype already says it is. Occasionally the hype-writers won't have done a good enough job hyping, and occasionally the hype-writers have different preferences than the developers, so the developers may be excited about how developer-friendly and cleanly extensible the motion and shading tools are, as opposed to how scary the monsters are, how creepy the background music is, and how awesome the BFG-9000 Rocket-Grenade is for blasting scary monsters.
But not real often. Especially because you're either talking to the developers during the death march to get the game out the door by pre-Christmas rush time or just post-shipping when they're detoxing from months of caffeine abuse but definitely before the profit-sharing checks from any successful games have gotten there. So of course they'll be grouchy. And that's what you want, because it's fun to write that stuff.
Reliability, Security, Spamblocking are hard
on
The Book of Postfix
·
· Score: 1
I supposed it depends on what you mean by "needlessly complicated". Basic mail delivery that works 95% of the time across a reliable Internet is pretty easy.
Some complexity is necessary, because mail servers are trying to solve hard problems, like getting the reliability from 95% to 99.999%, detecting failure conditions and responding appropriately, providing various levels of security for the users and for the system, and blocking whatever new trick the spammers came up with this week to get around the new trick you deployed last week, and fixing the reliability problems that happened because somebody else's mailer didn't get along with the anti-spammer trick you installed the week before.
Some complexity is because mail systems used to solve much harder problems (delivery across half a dozen network architectures, such as UUCP, that are mostly less reliable than SMTP over dedicated Internet connections), and they implemented it in highly extensible generalizable ways, like Sendmail config files, which can probably still be used to implement Turing Machines.
Some complexity is because of ugly Baroque programming styles - there's no particular need for a mailer config file to implement Turing Machines, when simple pattern-matching table-driven mailers like UPAS did the work without all that ugliness, and there's no need for file formats that not only steal bytes but even bits because the output might occasionally be a bit shorter, like the ASN.1 used in X.509 security certs.
Some complexity is because of historical leftovers - splitting MTAs and MUAs really does simplify the MTA, especially when the destination address can follow a single DNS-based addressing standard, instead of arbitrary complexities like mixtures of UUCP, Bitnet, and ARPAnet names. And the early BSD operating system insistence that Port 25 only be listenable by root meant that any mailer running SMTP in that environment needed to run at least with setUID-root privileges, exposing the mail server to lots of security risks, so the mail system had to be much more complex to defend itself against lots of little security hacks that would be much less serious if the mailer ran as a non-root user like uucp and used setgid-mail to deliver mail into mailboxes.
Some complexity is because splitting up the MUA and MTA functions means that sometimes the MTA doesn't know as much as it needs, e.g. a firewall email-relay proxy might not have access to the database of valid user names, which makes it harder to do good bouncegrams and good spammer rejection. Furthermore, it frees the MUA and MTA to be produced by different people, which means there's a need for standardization so all of the subtle features work (like user directories and security.) (Just because I said in the previous paragraph that splitting up the MTA and MUA simplified things, that doesn't mean that simplifying things always makes your life simpler....)
Some complexity is because Microsoft-adopted file sharing protocols were the closest available standard-like-thing that some little development shop had around, so they built a mail system that used file sharing instead of sockets, without learning from the experience of the UUCP-based mail systems, and they were building it entirely as a LAN-based system without thinking of how it would scale outside a closed environment, and they built mailboxes in a fragile and unmaintainable format, and when the thing suddenly got itself named "Microsoft Mail", it spent a decade growing into a much larger thing that was a cornerstone of an Evil Plan to lock users into Microsoft Office by aggressive use of feature creep and anti-standardization, and while it's really much much more reliable than it used to be, it's still the Mos Eisely of mail systems.
Slashdot Mirror
They *could* annoy the local telcos, except that (at least in the US), most of them own cellphone companies anyway, and the cellular business lets them compete outside their base geography. Also, while some single people may very well stop using landline phones and only use cell phones, many of those people still have a phone line for DSL, and businesses still use wired phones. Also, about half of the local telcos used to bitch about people using phone lines for modem internet service and messing up the cost model (the other half said "oh, good, we get to sell more phone lines") so we're really just helping them out.
VOIP annoys your local phone company if you're using a cable modem, because they don't get the money - but if you have DSL, they still get to rent the copper lines to your house, and the DSLAM on the end is a lot cheaper than a #5ESS voice switch. They still make money, and if you bought the DSL line partly to run VOIP instead of Napster, well good for you. Also, until the current telco service mostly disappears, VOIP services like Vonage pay by the minute to deliver calls to telco customers, so the local telcos still make money from it (sometimes more than they would from flat-rate lines.)
And the 911 agitation isn't mostly from the local telcos - it's mostly from emergency service bureaus, whose architecture is heavily dependent on the telco infrastructure and the underlying design assumptions (like phones being in well-defined places), who will have to spend a lot of money to develop more flexible architectures unless they can bully the VOIP businesses into doing that (and they don't have budget sources to get the money they'd need.) It's also coming from the wiretapping fans in the FBI, HomelandSecurity, and some police agencies, who not only want to prevent current targets from becoming un-tappable, but who want to gain lots more detailed surveillance capabilities with less judicial oversight (inconveniences like warrants, etc.) - they've been successful at getting cellphones to report position information by whining about how ambulances won't be able to find your grandmother when she's fallen and can't get up, and are doing the same with VOIP.
Connections between corporate offices have also been moving to VOIP, especially for international connections. You might not use them to talk to customers, but for internal calls they're fine. A few years ago the choices were between adding a voice board to a router (connecting to the PBX with T1), or adding an IP board to the PBX (usually more expensive, but better integrated for support), but now IP PBXs are becoming more common.
Connections to the outside world are gradually becoming more widely used, and everybody in the telco business is trying to figure out how to make money on it even though the prices keep getting radically lower.
VOIP has also been in use in many corporate environments for office-to-office communications, especially internationally, even if it's not used to connect to the telco for outbound calls or inbound customer calls. Back in the mid-80s, everybody ripped out their inter-PBX tie lines because it was cheaper to buy telco phone service by the minute and reduce the management effort; these days, people are putting those things back in, because the economics often justify it, even though long-distance phone minutes keep getting cheaper.
A decade ago the company I was working for started putting out lots of happy happy joy joy stuff about taking responsibility for your own career management and managing change, and recycling Clintonesque rhetoric about "Change is Good". Half my department got laid off a couple of months later, by the same happy happy joy joy PR people. A couple of years later, my next company's PR people started putting out 3-inch-diameter buttons saying "We're Navigating Change" with a ship picture in the background, and matching mouse pads and note paper and friendly brochures about how change can be stressful but we can be highly effective people if we manage it well and drink the company Kool-Aid. The layoff that time was only about 10%, not including me. A couple of months later my pen leaked in my pocket, and I decided that I'd rather wear the stupid button and cover the ink spot during the meeting I was having that afternoon, so it had some use...
So you have to start by reinstalling known good copies on a reformatted disk slice, and gradually recover things as you prove them safe. It's much easier if you've done a heavy-duty job of configuration management and kept a really solid wall between your development and production systems, but that's surprisingly hard to get anybody to do well enough.
I once found a directory /.something with cracker data on one of my lab honeypots - the cracker had modified "ls" and "ps" so his files and processes wouldn't be found, including all his little setuid toys. Didn't occur to him that I'd be using "find" as a regular administrative tool that he'd need to hack, or looking at /proc wondering why there seemed to be extra processes there. (After all, it's a *lab* machine - I was experimenting with it.) You'd probably find some of those things if you were using Knoppix to check, but you might not, since the evil processes were running with innocuous-looking names and the directory names started with dots.
What he doesn't really go into his how to build your production systems in a way that *ASSUMES* you're going to get attacked, maintains a clean environment for developing them in, and gives you the tools to rebuild rapidly from trustable versions. On the other hand, he does show how his example's victim's system was thoroughly broken into, getting from the production system to the development system, because it really *is* hard to do a good job of separating them adequately in a real environment, so even if you think you have a clean-room, you might not.
This used to be a real annoyance when I had a Sun lab a decade or so ago - the server was a big SparcStation 2 with a great screen on it, and most of the clients were IPXs or Sparcstation 1s, and if somebody had running one of the really cool fractal screensavers as their X environment, and logged in to the server to do their applications, the whole network could dog out if they went to lunch or went home for the night without logging out first. The equivalent I put up with these days is that I run some Protein-Folding-At-Home variant on my desktop, and while I use a display-a-picture-every-few-minutes screensaver, my wife runs some flying-starfield screensaver, so if she was the last one to log on, there are fewer CPU cycles available to fold proteins with.
By the way, NEVER run grid-computing applications on laptops - they aren't made for the constant heat load, and obviously if you're using them on batteries, you'll find that they're not made for heavy frequent battery drain either (I learned this the hard way commuting by train back when I was running the GIMPS Great Internet Mersenne Prime Searcher....)
Just as long as there's no Dancing Paperclip of Death or helpful friendly dog named Bob to go fetch phone numbers for me, it'll be ok....
Yeah, Skype supports a couple of platforms, but they're a fundamentally closed system (by policy, not necessarily by technology) which mostly ignores standards, and is only gradually figuring out how to integrate with the outside world - they do some things very well, and bought some good codecs, but they're a consumer-to-consumer solution, not a business solution.
Microsoft, BTW, gets great credit for giving out Netmeeting for free, N years ago, following the H.323 standards. It wasn't perfect, but it really did work, and that helped motivate other vendors to do the compatibility job they should have been doing all along. (I think some of the Linux video apps work with it, like Gnomemeeting.) MS Windows Messenger apparently uses SIP, though I haven't tried it. (My company uses a Jabber-based IM system internally instead, so I use that for work IM, and I find IM sufficiently annoying that I haven't installed any of the other IM products, ESPECIALLY anything that would let me get AOL AIM messages from my mother-in-law :-)
Video, VOIP, and Instant Messaging are really all the same thing - there's some kind of presence server that you register with, and you set up media channels between the end users. H.323, SIP, Jabber, Skinny, and N different proprietary things are just different variations on how to do this, and there's the usual marketdroid struggle for interoperability vs. control. The VOIP people mostly want interoperability, and are working their way toward SIP while trying to maintain backward compatibility if they have older solutions to worry about. Video has two markets - corporate video conferencing, dominated by people like Polycom, who I think are H.323-based migrating to SIP, who make money selling hardware and like interoperability, and video-chat applications which are mostly related to the consumer IM world, where the aggressively non-interoperable control freaks dominate because they're run by consumer ISPs (AOL vs. MSN vs. smallfry) who make money from selling you their ISP service. Most of them have some kind of Windows client that non-subscribers can use to contact subscribers, like the Netscape AOL Messenger frobs, but the reason they won't work with each other is that they try very hard to block anybody who does re-engineer their protocols. (And as noted, I don't want IMs from my mother-in-law, so other than trying out AIM in my lab a couple of years ago, I haven't installed it :-)
LAN QoS can matter, but usually doesn't. Most offices have 100 Mbps Ethernet to the desktop these days, with some level of switching behind it, and while you should put your big data servers on different segments than your phone switches, that's usually enough. Windows XP has enough QoS capabilities that you can get it to prioritize outbound VOIP over outbound data, and while that doesn't fix the inbound problem, it's a good start. Sometimes you can still get into trouble, but as long as you've got some control over your infrastructure, you can usually avoid it. Worst case is you throw in a wireless LAN to handle your voice users and leave the wired network for data.
WAN infrastructures are much more interesting, because they're usually much narrower than LANs. One approach is to ignore the problem - use the VOIP for a PBX, replacing your old dedicated clunker PBX, and use telco facilities to reach the outside world. (Yeah, boring...) Another is to look at all the new services from data carriers - many Tier 1 internet vendors support QoS within their networks (which is enough for your PBX services), and almost everybody is pushing some MPLS solution, either to get a few more years out of their Frame/ATM infrastructure, or to use their IP network to muscle in on the Frame/ATM carriers' business, and most of those have QoS.
SIP is designed to work with multiple levels of proxies, so it's easy to design for scalability. If you want a building to be able to talk when its connection to your headquarters data center is down, you do need to have a local server, but that can be implemented as a simple PC with VOIP software on it, or Cisco's SRST feature running on your router. The reason it's a big problem in Cisco-land is that most of the Cisco IP telephony environment really runs their old "Skinny" protocol, with H.323 and SIP only on the edges, so it's harder to make it scale without a lot of extra hackery (i.e. without paying for a bunch of extra licenses and adding a few extra trunks between diverse servers.) (There's also the minor issue of router horsepower, since Cisco tends to use small CPUs and do most routing work in ASICs; not a problem if you're using a PC-based system where CPU and RAM are dirt cheap.) You could avoid much of this problem if you built a system out of Asterisk, or if Microsoft does a good job of integrating Sylantro and has it priced in a way that works.
It's really no surprise that Microsoft would get involved, since almost every business office is already using their products, and they've got surprisingly deep experience with the older H.323 standards (NetMeeting was one of the first widely deployed H.323 systems in the video world, and yes, that's Microsoft pushing standards-based solutions against the proprietary vendors.) Sylantro, who they're making this announcement with, is a major player in the VOIP-for-Telcos market using SIP standards, so they're not just doing a simple roll-your-own. You'll also notice that Microsoft Windows Messenger is based on SIP - so they've already got a desktop client that's just waiting for a server that's designed for phones and not just mainly for IM. We'll see how well and how fast they execute, and how well they can integrate with the rest of the market, but if they were to attach this thing along side of an Exchange server at a reasonable price, they could achieve World Domination fairly quickly, just as Skype has in the consumer-toy market.
Telcos know that the traditional local+long-distance voice market is doomed, and they're adapting to it. The local carriers still have a business model managing the wires out to your house, regardless of whether they're charging $15/month to hook up the wire to a voice switch or charging $15/month to hook it up to a DSLAM (especially if they're providing the DSLAM or at least the upstream network to the ISP.) And they know they're going to need to replace their old #5ESS and Nortel DMS switches with VOIP switches (i.e. big SIP servers), but that's feasible because the new stuff is a LOT cheaper. Long distance companies are either becoming IP and private line carriers (AT&T, MCI/UUnet, Qwest), or becoming cellphone companies (Sprint/Nextel), or both, and selling out to local telcos (AT&T to SBC, MCI to Verizon and/or Qwest).
There's a lot of transitional business connecting up the old telco services to the VOIP services, some of which is coming from the long-distance or local telcos, and some of which is coming from upstart VOIP providers. The long distance companies will have mostly retired the old #4ESS switches within five years or so, replacing them with VOIP services of various types, and they're desperately trying to figure out how to do it in a way that's scalable - it's much easier to replace a PBX with VOIP than to replace a network that handles 300 million calls a day. The two obvious disruptive models to the remains of the long-distance business are that the local telcos get approval to connect to each other using VOIP, dropping the underlying cost of long-distance to basically zero, or that a decentralized solution emerges along Free-World-Dialup lines, e.g. business PBXs and home phones use spare connections to terminate calls from the VOIP space into the local-telco space. The big moneymaker for the long-distance business these days is still call centers, which have a lot of complexity and added value managing inbound calls and therefore get to charge a lot more for doing that. It's not cl
- Fixed - The antenna's nailed up somewhere, and doesn't move, and you can even aim a directional antenna. This part works pretty solidly.
- Portable - you can move one of the endpoints to a different location and it'll still work, as long as it's close enough to the tower, so you can take your laptop to your customer's office or home or the coffeeshop and sit down and work, and you can drive your car somewhere and park, but it won't work while you're driving. This part mostly works.
- Mobile - you can use it while you're actually moving around, driving at highway speeds or sitting on a train, and it'll adapt to changing radio parameters, switch between towers like a cell phone, etc. This part is at best bleeding edge right now, and I don't think any carriers are going to be supporting it for at least a year or two except perhaps in limited trials.
You need full mobile to do cell-phone replacement.There are still issues about using licensed vs. unlicensed spectrum that are going to affect how much interference you can expect (some carriers translate this to "I can do an SLA for licensed bandwidth but not really for unlicensed.")
It's an absolutely stunning technology to use as a backup for wired service, e.g. you've got a copper T1 and an 802.16 wireless service, so even if a backhoe or earthquake takes out your street, the wireless still works, and if it's raining to hard so the wireless is noisy, the T1 still works, and most of the time you can use both connections. For big business offices, you can get diverse fiber access or diverse T3 copper, configured as a ring so a single backhoe can't take out both sides, but it most of the US it's really hard to get that at T1 sizes or smaller, so a small business or a small office of a big business can't get good diversity from the telco (some applications, particularly voice, don't perform well over satellite, and previous generations of cellphone wireless data are often too slow for most businesses, and freespace optical isn't widely deployed.) In some cases, a small office can get some diversity by using a cable modem as the second connection - but that's mostly available in residential areas, not business areas.
If you're running on SDSL, or only running one call at a time, you might have enough data transmission quality to get decent results, but if you're trying to put multiple voice calls on DSL, especially consumer asymmetric DSL, you often won't have a good enough data connection for it. The problem is that while the connection from your premises to the DSLAM may have enough bandwidth (if you're using a Vonage box or something similar to prioritize the voice), but the connection from the DSLAM up to the internet itself is typically oversubscribed, and there may or may not be enough bandwidth for your voice calls on that segment. For instance, that 128kbps upstream may have only 32kbps guaranteed between the DSLAM and the outside world, and while you'll usually get it, sometimes you won't, and your voice packets are now competing with your data packets and everybody else's packets.
Thanks! That's a really extensive network they've got. Looks like my downloads were coming direct from London via Abovenet, rather than from some caching server in the US, which makes the performance even more impressive.
In general, this is the best download performance I've seen - usually anything large that I'm downloading other than bittorrents will either saturate a small server with a small number of downloaders, or a large number of downloaders on a large pipe, but this just blazed away.
That doesn't mean that it isn't worth occasionally getting those recordings, especially for obscure composers or pieces that don't get recorded very often, but for major pieces it's going to make a lot of difference. On the other hand, university orchestras may be more interesting than most of the commercial orchestras, because they've got more flexibility to fool around.
Both types of skills are important, and they're radically different. I worked for Bell Labs just after college, and one of the most valuable things they did for new employees was make us take a writing course. Sure, my grammar and spelling were impeccable, and after enough years of studying English, Latin, German, Greek, Southerner, and Academe-speak, I could write in whatever kind of correct, precise, and complex sentence structure seemed entertaining or beautiful at the time, and spelling checkers were also helpful to make up for any typing mistakes. But organizing content for your audience, both to convey information and to clarify your own thinking are different skills than expressing each sentence. Writing for engineers and managers to read are two different problems, but both are much more like writing for newspapers than writing academic papers, and they spent a lot of time emphasizing NOT to write like a grad student. You want to hit the critical points up front, with more detail as your reader progresses farther (if he does), and especially for on-line use it's important to have some idea of your reader's attention span to know how deep an argument you can make and how often to repeat points. The more complex the subject matter, the more it's likely to be worthwhile simplifying the sentence structures, splitting things up into lists, or whatever it'll take so that the reader's attention can be focused on the content and not wasted on your subtle and precise use of the subjunctive mood. (That's still partly true in literature as well, but writing for someone who's going to take an afternoon reading your essay is much different from writing for someone who wants to pick up a manual and find out how to do something, or for someone who wants to know which projects to prioritize and which projects don't need a hardware budget until next quarter.)
Spelling flames - how quaint...
I'm not talking about deliberate use of slang or 1337-sp3k3 or ghetto what-up-dog speak or overabuse of bad punning or even Ebonics and other dialects and pidgins. I'm talking about sloppiness, lack of differentiation between homonyms, bad spelling, and the like. English is sufficiently flexible and mushy and evolving that differentiations such as the one between "like" and "as" are going to evolve, if in fact the language was really ever as precise as your 9th grade English teacher told you it was (you remember her - the one who insisted on grading the class on a precise Bell Curve even if class tracking meant that the whole class was in the top 10% of students to start with?)
You're geeks, get some tools, and if correctness isn't instinctively wired into your fingers when you're typing, fix it by using spellcheckers and grammar checkers and whatever else you've got! (I hate to say it, but Microsoft Word does this really well...) There's no excuse for "definately" when it's not a correct spelling and your spell checker can find it for you. If you've got a grammar checker, use it too, and pay attention when it nags you about incorrect word choices (if it's bright enough to do that, which many of them aren't), though you'll also have to ignore more advice from the grammar checker than the spell checker. You may have to spend a while teaching your spell checker that "31337" is spelled just fine, thank you, but that's what the "Add" menu-item is for, as well as the "ignore words with numbers in them" features.
If you don't spell things correctly and use vaguely correct grammar and word choices, Babelfish is going to have a tough time translating them for non-English-speaking readers.
My mom used to really rant any time the "Winston tastes good like a cigarette should" commercial came on, because it should be "as", not "like" - but that's been part of language evolution.
However, the EFF and ACLU seldom get involved with things unless somebody asks them or things are brought to their attention through other channels. No idea if that's happened here.
Normally it's not good practice to burn your bridges when leaving a job, but if the company blows them up when you're standing on them that principle doesn't really apply. A more serious problem is whether the immoral bastards were making enough money that you can recover anything if you sue them...
Also, there's dubious ethics and dubious legality. If you know your employer is acting in ways that are illegal, and you continue to support those activities, then you may or may not have a share in the guilt, depending on the various rules about corporation vs. employee responsibility and whether the actuions are covered by civil or criminal law. (To the extent mentioned in Chip's article, it sounds like most of the issues are either anti-spam law, which is mostly just civil and not criminal, or possible torts against the people whose systems they abused, plus of course their treatment of him where he's not the guilty party.)
Dubious ethics is a different problem from dubious legality - if you think they're unethical, you've got a personal responsibility to either work against those actions (if that's realistic in that company) or get out. I used to work for the part of my company that sold services and computers to the military. Took me a while to decide I shouldn't be doing that and find another job, but at least it was a big enough company that that was an option, and I've changed jobs a few times since then.
It wouldn't have helped the US avoid falsely accusing Iraq of making WMDs, partly because it's not good enough to tell a "baby milk factory" or "pharmaceuticals factory" from a "chemical weapons factory". But the big problem was that the US government *wanted* the conclusion to be "Iraq has SCARY WMDs" to convince the US public to let them invade again, and anything that simply flies over and says "no, didn't see anything suspicious on the outside of those factory buildings" isn't going to either change the propaganda policy or tell the military planners not to target a factory-shaped building.
On the other hand, better UAVs would help improve targeting for the things they did want to blow up, or at least let them see whether groups of people were wearing uniform-colored cloths or not.
Scalia indicates that he doesn't see why cable modems and DSL should be treated differently (and he also thinks that DNS has some reason to be tied to your ISP, though he somewhat gets that email and web service are distinct from internet service, which the Portland case didn't get.) But they're fundamentally different services - Cable is IP, DSL isn't.
DSL is really ATM underneath, providing a Layer 2 point-to-point virtual circuit between two devices, and any IP services are provided by the endpoints. So if the telco is providing the DSLAM (as opposed to renting dry copper wires to a CLEC like Covad and renting cage space in the telco wire center for the CLEC's DSLAM), they can support any ISP that wants to either buy a private line to their wire center or else buy an ATM pipe to terminate the virtual circuit on, and it's the ISP's job to provide a router that terminates the Layer 2 virtual circuit and connects to the Internet and optional services like email. In some cases, the telco also provides internet service, or does co-branding partnerships like SBC Yahoo; in other cases the telco only sells to ISPs and doesn't do their own. Also, the telco can either sell the DSL connection to the end user, putting it on their telco bill, or the telco can sell it to the ISP, who bundles it with Internet service and bills the end user.
Cable modem is different - it's an IP technology, which is inherently open unless you try hard to make it closed. It's Ethernet-like shared cables at the bottom, and the right architecture is to provide IP routing from the head end on up, connecting to other ISPs at a few regional peering locations. There's normally no good technical reason for an ISP to put connectivity into each head end office, though they might make a deal for some really special application; connecting at the peering points is almost always the right choice, though that connection might just be a data pipe or it might involve colocating some servers at the cable company's bigger data centers. That's not always how it's implemented - some cable companies use annoying and stupid protocols like PPPoE to gain a bit more control over the user, and do various filtering things to limit their usage.
The ISP coalition that argued so-called "cable openness" in the Portland case and before was really trying to argue for *closing* the cable service and giving themselves special access. The biggest problem was that by buying Internet service from the cable company, the customer feels like he's a customer of the cable company and should get services like email from them along with his Pay-Per-View movies, and the ISPs hadn't figured out how to reinvent themselves as Email and Web service providers rather than bundled-package providers. The real things that would constitute an "open" cable service and still let the ISPs make money would look something like:
But not real often. Especially because you're either talking to the developers during the death march to get the game out the door by pre-Christmas rush time or just post-shipping when they're detoxing from months of caffeine abuse but definitely before the profit-sharing checks from any successful games have gotten there. So of course they'll be grouchy. And that's what you want, because it's fun to write that stuff.