> Geez...where and when do you drive where you have a hundred miles of creep along, stand still traffic??
Try driving from Miami to Tampa or Orlando the day before Christmas, Thanksgiving, or July 4th Weekend. I-75 across the Everglades ("Alligator Alley"), and the Turnpike between Yeehaw Junction and Kissimmee can both get really bad. I've had plenty of 7-hour drives to Tampa & Orlando, and know lots of people who'd *kill* for decent passenger rail (read: trains that leave after 6pm, and arrive before midnight) between Miami and Tampa/Orlando. Part of the problem with Alligator Alley & the Turnpike north of Yeehaw Junction is the fact that they have ~40 miles between exits in spots where there's almost always an accident with fatalities every major holiday. Anytime that happens, the road basically gets shut down in one or both directions, and nobody can go *anywhere* for hours (creating gridlock that persists even longer afterward).
> High speed rail isn't practical for 90% of the country.
Not practical for 90% of America's land area? Yeah. Not practical for 90% of its population? I disagree. The places where people actually *live* are pretty concentrated and linear due to things like geography and older transportation infrastructure that made inland areas economically-viable to begin with.
By now, just about everybody knows the obvious places where passenger rail makes sense, and most of them pass within a hundred miles of roughly 90% of America's population. Where sensibility breaks down is when HSR advocates demand 100% True HSR Now, instead of settling for 125-150mph max speeds with Acela-like diesel trains along core HSR mainlines and 80-110mph ISR along slightly-improved existing corridors to multiply the areas with direct transfer-free service. At the end of the day, a train that averages 60mph from Miami to West Palm Beach, 90-110mph from WPB to Auburndale, and 100-150mph for the final haul into Tampa or Orlando would be *wildly* popular with Floridians and visitors alike. Force those same passengers to get off the train and transfer at Auburndale (or take a similar 60-100mph trip along the coast to Cape Canaveral, then transfer there), and they won't care whether the remainder of the trip is theoretically 180mph, because the slightly faster speed for the last half hour won't make up for the delay and hassle of having to physically switch trains. Likewise, slower direct service with trains leaving every 20-30 minutes during peak times (so higher-paying passengers can literally just show up at the station "whenever" and get on the next train instead of having to worry about a rigid schedule) will win out over faster trains that run less frequently. It doesn't matter if HSR can make the trip in 2:38 instead of 3:30 if you miss the 6pm HSR and the next one doesn't leave until 7, compared to slower trains that take 50 minutes longer, but depart every 20-30 minutes. Waiting time, stress, and anxiety DO matter to passengers and influence their travel decisions.
In a state like Florida, trains (HSR or otherwise) have another advantage over flying: weather delays are almost nonexistent unless there's literally a hurricane in progress. It's kind of cool to be on a train during a torrential summer downpour. You look out the window, and realize that the weather outside is completely irrelevant to the train. It's not going to skid off the tracks or crash on takeoff/landing due to a microburst. IMHO, it's also a good reason to favor 150mph diesel that can run on regular tracks over 180mph electric that needs overhead wires that will be damaged by every hurricane that comes within a hundred miles, and shredded by every hurricane that makes a direct hit.
Part of the problem IS unfortunately Amtrak itself, which has gotten into the habit of stirring the political pot by framing the debate as corridor-vs-long distance, and totally ignoring the fact that boosting corridor service will largely solve the long-distance cost problem by keeping most of the stations and infrastructure that need to be staffed all day, even if it currently serves one or two trains in each direction, busy with other trains to spread around the cost. Worst-case, Amtrak limits most of its cross-country stops to areas with thriving corridor service, and treats the stretches in between like "uncontrolled airspace" where the trains run, but don't stop (or at least don't stop at fully-staffed stations).
Going back to the Florida example (because it's one I'm intimately familiar with). If Florida builds HSR-grade tracks from Orlando to Tampa and improves the existing tracks down to Miami and up to Jacksonville, Amtrak no longer has to staff and run its own stations down to the janitor and parking lot attendant. It could probably even outsource the baggage-handling to whomever runs the Florida trains, and run with just one or two actual Amtrak employees per major station (maybe none at all at a smaller station like Hollywood or Deerfield Beach). Add similar
Yeah, but the train *wouldn't* derail at 180mph. It might ultimately derail, but by the time most of the cars left the tracks, they'd be much, much slower. Remember, by law, American passenger trains have to be capable of surviving a head-on collision with a mile-long freight train at full speed. That's a use case where you have two opposing forces sharing right of way with nowhere for the force to spread. By comparison, a bomb blast is a momentary disruption that might knock a couple cars off the tracks, but then they'll be skidding sideways along the tracks and slowing down the cars behind them. A stopped vehicle across the tracks? A 150mph Acela-like train would cut through them like a hot knife through butter, or send it flying like a soccer ball. Or both. When American passenger trains hit stalled vehicles at high speeds, most of the people who end up dying are people who WEREN'T on the train. The passengers on the train get a scary high-speed ride through a tunnel of fire. It's the poor guy standing on the sidewalk waiting to cross the street who gets sliced in half by the flying debris.
Terrorists don't attack planes because they're used for travel... they attack planes because they can cause a LOT of collateral damage with a fairly small investment (boxcutters, a half-dozen plane tickets). CAN a train be attacked? Of course, Would it be an efficient use of a terrorist organization's limited resources? No. If your goal is to hurt/kill people and get it on international news, just about anything is a softer target.
> To replace driving you need a public transporation system
Or convenient rental cars at the station, preferably with agents on board the trains so you can do the rental car paperwork before you arrive and be driving out of the station's parking garage 5-10 minutes later.
> blowing up track is easy
You've obviously never seen how modern track is constructed -- steel rails roughly 6" thick attached to reinforced concrete ties. If you planted explosives around it, most of the blast would be into the open area around them. It would be almost like trying to bomb a Jersey barrier on a freeway.
> To replace planes you need it to be cheaper, safer, and actually faster.
Or nicer and more convenient. Flying is cheap, nasty, stressful public transportation at its worst. First class rail travel is very, very nice. The truth is, trains aren't for poor people. Compare the price of taking Eurostar from London to Paris, and you'll quickly see that it's a really nice premium transportation mode for people who want to arrive in a good mood after having a nice trip, instead of being herded like cattle and treated like schoolchildren. I take Amtrak from Miami to Orlando all the time. I'd take it a lot more if they actually had trains that left around 6:30pm and arrived before midnight. It costs about $200 round trip for a first-class ticket with a room, and it's worth every penny. Plus, unlike a plane, my phone works the whole way, the food's a hell of a lot better, and I have tethered internet access at all times (but not 4G... Sprint's 4G doesn't do tower hand-offs properly, and is therefore useless in moving vehicles. But that's another Slashdot rant...) And I don't have to discontinue use of approved electronic devices for half the trip, either. I have my own john that I might or might not use, but it's there if I feel like it. If I want to take a nap for 4 hours, I can.
Seriously, try first-class travel on a train sometime. It's really, really nice. Even my *parents* like trains now, and they've *always* hated trains. They grew up in an era where wealthy people flew, and poor people took trains.Things have changed. Now, trains are the nice, pleasant way to travel.
Not really. A small bomb can take down a plane. The same bomb might kill a few dozen passengers in a crowded railcar, but wouldn't have much effect beyond it. Comparisons to the Spanish train bombing aren't appropriate, because American trains literally weigh about 5 times as much as European trains. It sucks in the sense that it makes them slower and more expensive to operate, but it's nice in the sense that a rolling bank vault isn't very vulnerable to anything.
If you're in a jet that gets split apart and manage to survive in the broken-off tail section, you're still going to die... you'll just have 3 or 4 terrifying minutes of life that your fellow passengers didn't get to have. If you're on a train that somehow gets derailed, and it catches on fire, you can kick out a window and crawl away. At 20,000 feet, that's a little harder to do.
The truth is, if you're a terrorist, American passenger trains make shitty targets with really low bang-per-buck. You'd do better driving a SUV into a crowded McDonald's, or throwing grenades around inside a mall. Planes are vulnerable because they're relatively easy to take down, they're hard to escape from, and if you gain control over them, you can fly them into buildings. Trains fail (as terrorist targets) on all three counts.
IMHO, the ideal California compromise would be a HSR mainline from LA to San Jose, using the existing Caltrain tracks into SF and double-tracking existing freight corridors used by Amtrak from SJ to Sacramento, and from LA to San Diego, with some additional corridor improvements so trains running on non-HSR track could average 100mph, and Acela-type Talgo trains that max out around 150mph, but can legally run on both freight and dedicated HSR track. You'd still get end-to-end transfer-free convenience, at roughly half the up-front construction cost of "true" HSR every inch of the way from San Diego to Sacramento. As ridership increases, California could build proper HSR tracks in San Diego and Orange County, then finish up the last segment 20-25 years later and save costs by combining it with a freeway (re-)construction project (using the same right of way and crews to build both simultaneously). Ditto, for the area from SJ to Sacramento. Eventually it would all be "true" HSR, but by initially limiting the most expensive part to just LA-SJ (the part that would get the most traffic), the total cost (when you add up the interest on the construction bonds) would be a fraction of what it would cost to do it 100% HSR from day one... and the network would be far more useful than one that went ONLY from LA to SJ/SF (requiring transfers to go beyond either city).
The Bay Area itself is admittedly a mess, and I'm not even going to speculate on how that area's problems could be solved (though the idea of beefing up BART trains so they could legally share tracks with electrified HSR, and retrofitting BART's tracks to accommodate both BART-gauge and standard-gauge trains so HSR could use BART's tracks and the Transbay tunnel is intriguing)
In the real world, every time you make passengers change trains, you lose half of your potential market, but increasing the speed from 110mph to "true" HSR 150-180mph only increases the market by about 10%. In round numbers, that means you might have 100,000 people who'll pay a given fare to take the train from San Diego to San Francisco if they can make the trip without transfers (even if half the trip is sub-HSR speed), but only 50,000 people who'll pay the same fare if they have to change trains in LA, and only 10,000/day more who'll be induced to make the trip if the speed is increased to HSR the whole way (and the operating expenses & capital cost increase by 4-20 times in the process). These are somewhat round numbers, but they're all pretty solid statistics that FDOT has compiled in multiple studies over the past 25 years, and other states seem to mostly agree with them. The problem is, pragmatism isn't sexy, and people don't understand that even Amtrak's creaky trains running on decrepit track could make most of their trips in half the time if they were just aggressively dispatched with priority given to the passenger trains).
> High-speed rail, almost without exception, relies on dedicated lines, not shared lines with freight like existing, less-than-high-speed, passenger rail in the US
To a degree, yes. But not completely. There's also a lot to be said for the convenience of transfer-free end to end service, even if it means the train has to be towed along shared tracks the last 25-50 miles to its final destination (this is common in France; they have summer TGV routes where the train runs at 180mph to the end of the line, then gets towed the last 25-100 miles to its final destination someplace where there's not quite enough business to justify the cost of building HSR all the way to the bitter end). In a place like Florida, it's *necessary* to build brand new tracks for HSR between Auburndale (halfway between Orlando and Tampa) and Tampa because the existing freight tracks are heavily used, but it's silly to build brand new 100% HSR all the way to Miami at this point because the existing tracks have barely any freight traffic (enough that eliminating it entirely would be very expensive, but not so much that good dispatching that gave priority to passenger trains couldn't overcome 99.9% of the delays that currently plague Amtrak along the same route).
For roughly the same cost as building "true" 180mph HSR from Orlando to Tampa, FDOT could temporarily scrap the electrification & HSR-only trains, build new tracks along I-4 with geometry suitable for 180-225mph trains someday, then buy and double-track the existing corridor to 110mph standards, connect it to the new HSR line north of Auburndale (along I-4) and launch Miami-Tampa-Orlando service from day one (running 80mph from Miami to WPB, 110mph from WPB to Auburndale, and 150mph along the shiny new HSR tracks for the last 40-60 miles into Tampa or Orlando). It would mean the Tampa-Orlando trains would have to be Acela-type and max out around 150mph ("true" 180mph HSR trains can't legally share tracks with freight trains, or even passenger trains legally capable of sharing tracks with freight trains), but it would also mean that Florida would end up with a useful passenger rail network instead of a largely useless amusement park ride. Move the proposed Orlando station from the central concourse of the airport to a spot adjacent to the airport (with peoplemover to the main terminal & rental car center) so trains can avoid a 5 mile detour (yeah, MCO really IS that big) and continue north to downtown Orlando after the airport station, and Florida will ALSO have a rail line suitable for daily long-distance exurban commuters to Tampa and Orlando from Lakeland. FDOT could even put additional stations between Tampa and Orlando with platforms that are "offline", so intercity trains could blast through at full speed without stopping, but commuters from the Lakeland area could have additional convenient stops to attract even more riders and business.
Another crucial element: rental cars at the major stations. Miami and Orlando have that part taken care of, and Tampa will too (as long as FDOT doesn't completely fuck up). Even better would be enabling passengers to do the rental-car paperwork on the train itself, and walk off the train with their keys in hand (or at least the codes to a wall of electronic safes containing the keys at the station) and be driving out of the parking garage 10 minutes after arrival.
Just to clarify, SSL is assumed to be getting used in addition to everything I described. Also, I forgot to mention the other reason for double-hashing -- to ensure that WE never come into direct contact with the user's plaintext password, either. Why? Like it or not, most users use the same set of passwords for nearly everything they touch. So... a compromise ends up having lots of potential collateral damage as well. In this case, even if our own server got completely pwn3d, and attackers gained the ability to directly intercept incoming requests, all they'd get are the hashed passwords that were salted with the same value. The users would be in no worse of a position than they'd have been in if we salted everyone's passwords with the same publicly-known value.
Does anybody know why it's a bad idea to salt passwords with usernames (or hashes of usernames)? Say, something like...
$username = "linus"
$password = "tux4me"
client asks server for salt to use with $username
server returns md5("common2allUsers" . $username). Client doesn't do this directly to make it less publicly obvious that the first salt is "common2allUsers". Salt is algorithmically-determined by username to avoid revealing whether or not a given username is valid to attackers. Server uses md5 for speed, since this particular hash is partly just obfuscation and security theater.
Server looks up $usersalt associated with $username in database. If $username doesn't exist, server pretends salt is 'badU53r' and proceeds with lookup anyway to reduce vulnerability to timing analysis attacks.
$storedSaltedHash = sha256($usersalt . $passhash)
Server looks up userid associated with $username and $storedSaltedHash
Rationale for hashing before sending to server: to obfuscate the password in case it ends up being revealed in a log somewhere.
Rationale for hashing the hash again: to use a unique hash for every user, without revealing the hash or enabling attackers to harvest usernames.
I believe *all* new Sprint Android phone activations going forward have the $10 fee, 4G-capable or not.
Believe it or not, the problem you're having on the bus probably has NOTHING to do with coverage. It appears that Clear's towers all assign their own dynamic IP addresses, and won't route traffic from other towers more than one hop away. The net result is that if you try using Sprint4G (which uses Clear's towers) in a moving vehicle, you're going to drop the connection every 1-3 miles. You can prove it to yourself with this little experiment:
Find an area where you know beyond doubt that 4G coverage is rock-solid and two towers are both near the same major road, then walk from one tower to the next & keep an eye on the signal-strength bars. Starting near tower #1, disable 4G, then re-enable 4G to make sure you get an IP address from the tower next to you. Now, launch some task that constantly uses data, like Pandora, and start walking toward the next tower. You'll see the bars go from 3, to 2, to 1, back to 2, then *right* when you're close enough to spit on tower #2... your connection will drop. If you stop walking immediately, toggle 4G off and on (to force an immediate reconnect, instead of passively waiting ~5 minutes for it to reconnect on its own), it will scan for about a second and reconnect almost instantly with 3 bars. I've repeated this experiment multiple times in various locations around Fort Lauderdale, to the point where I'm now pretty much convinced that this behavior is by design and more or less as I've described it.
Frankly, it pisses me off, because it means that Sprint 4G is basically useless in a moving vehicle -- car, train, or otherwise. Especially when you consider that most Android apps either crap out or crash when the phone forcibly switches between 4G, 3G, and wi-fi. I don't know whether Verizon's LTE exhibits the same behavior, but it really does make T-Mobile look a lot more attractive than Sprint.
Oh, there's another catch with Sprint/Clear 4G, and this one will bite you if you use it at home in an area where most of the tower's OTHER users are transient. If their router notices that you're using more bandwidth than other individual users OF THAT SPECIFIC TOWER, your throughput will be *massively* throttled. Note that the statistics are *per tower*, and NOT "total network usage". That's what kills you. You're using that one specific tower, racking up bandwidth blackmarks all day... other users (shopping at the nearby mall) are only using it for an hour or two, so even if they're streaming YoutubeHD nonstop, they're unlikely to come anywhere near the bandwidth you're slowly racking up all day.
Sigh. The good old days, when the main difference between the Vic-20's user manual and the Vic-20 programmer's reference guide was the amount of detail in the memory map and the mini 6502 assembly-language reference guide. And, by extension, the era when a single person actually COULD have a pretty good understanding of the entire computer and how it all worked together. Now, you can't even find a coherent explanation of how Intel power management works if you spend the weekend hunting online, let alone get it neatly presented in anything that resembles a user manual sold with a high-end laptop (well, not if you want any more detail than being told you can choose between "max battery life" and "max performance").
Hell, I remember getting Borland Turbo C++ in college. The UPS guy almost needed a forklift to get the box up to my dorm room. Literally, 2 or 3 cubic feet of books, plus ~50 floppy disks (I could be wrong, but I think later versions that included support for both DOS & Windows came with almost 200 floppies and took most of the day to install).
I remember buying Photoshop 3 for the student price of $89 my senior year, and feeling cheated because it only came with a ~300 page manual. I don't think Photoshop CS5 even HAS bound documentation.
The problem is that you wouldn't just have to pay for the parts... you'd have to pay companies to resurrect parts based on components that haven't commercially existed in 25-30 years. Endeavour wasn't built from scratch -- it was built from spare parts intended for use with the other shuttles. Frankly, I'm surprised NASA hasn't had to cannibalize any of the shuttles (including the two destroyed ones) for spare parts to keep the others going. Just to give an example, if a window on Endeavour doesn't pass a pre-flight inspection (or some other part purpose-built for the Shuttle), NASA basically has one option: take it from an already-retired Shuttle, and replace the window in the museum-bound Shuttle with regular glass. Ditto for things like hinges, straps, and even wiring connectors.
It's the same problem that exists with the idea of resurrecting the Saturn V. The computer hardware has gotten cheaper, but the rest of the parts are based on a supply chain that hasn't existed in decades... and more than a few couldn't legally be manufactured anymore because they don't meet current environmental regulations.
Why? Retrieving Hubble would make no sense at all.
99.9% of its cost was just getting it into orbit to begin with. If anything, it would make MORE sense to give it one last hard shove AWAY from the Earth once it's about to become uncontrollable, so that N years from now, somebody can go salvage, refurbish, and put it back into service. Maybe tow it to the moon, Mars, or somewhere else. Or turn it into an orbiting shrine or tourist attraction someday.
Then again, I was rather relieved when NASA got the loony idea of asking the Russians to sign off on its plans to deorbit the ISS after its official service life is over in 2014, and the Russians politely (but firmly) made it known that they intend to keep it in orbit (with duct tape & WD-40, if necessary) until the day they literally can't stop it from falling into the Pacific. We might be insane enough to buy into the accounting profession's madness that an asset whose full lifecycle cost has officially been zeroed-out is now without value and must be disposed of immediately, but the Russians still recognize that they have a really, really expensive asset in a valuable location that cost an unholy amount of money to get there, and they're going to wring every last ${currency-unit} they can out of it before writing it off and abandoning it.
> I own a Galaxy S and since the Nexus S is basically the same phone
If your Galaxy S is GSM and you don't use T-Mobile 4G, you're mostly right. If your Galaxy S is CDMA, and particularly an Epic4G, you're mostly fucked.
The loadable kernel modules are what will kill you. Linux doesn't have a stable ABI, which means that drivers (.ko modules) compiled for an older kernel won't necessarily (read: won't) work on a newer kernel (think Win98->WinXP, but worse... like being unable to use a driver made for XP Pro/32 under Vista Business/32. Officially, the Linux kernel could break binary compatibility over the equivalent of going from XPsp1 to XPsp2. Samsung gets partial credit for releasing drivers as proper loadable kernel modules (so they can at least be used with recompiled versions of the same kernel), but source-wise, their drivers are as bad as HTC's -- they aren't directly buildable because they have unsatisfied dependencies. The difference is that HTC at least releases new kernels in a timely manner, so the community can grab them and move forward instead of being stalled for 6 months waiting for 4G drivers that work on a 2.6.32 kernel (needed for Froyo) to metaphorically fall from the sky.
All we ask is for Samsung to at least practice benign neglect and say, "Look, bitch to Sprint if you want an official 2.2 upgrade, but in the meantime, here's a zipfile of everything proprietary that you can't compile yourself, recompiled against 2.6.32. Same drivers, same bugs, but automatically rebuilt for 2.6.32's ABI. Have fun."
Of course, Samsung won't do that, because it would mean that by the time the official carrier upgrade makes it out (if ever), it would be *totally* eclipsed by community builds that do more with fewer bugs (because the community versions would have a real-world 4-6 month head start, and several orders of magnitude more hours of developer time behind them). The truth is, though, the carriers would actually have a reasonable excuse to give less technical end users who complained about having to wait: "Our upgrade doesn't make you blow away everything and start over from scratch every time. It lets you upgrade in-place, and should be relatively seamless." Diff'rent strokes for diff'rent folks.
You're assuming that there's actually a company phone book that a legitimate user would have ready access to. Quick... where's YOUR company phone book? Does it even exist in printed form, or (like most companies), is it all "online" now? Chicken, meet egg. Kafka's sitting on the bench over there, simultaneously groaning and laughing. And if it DOES exist in printed form, what's the likelihood that a remote employee at a hotel (or family member's house) with his laptop actually has a copy with him right then? No, "supposed to have it according to policy" doesn't count. When push comes to shove, statistically "nobody" will have it with them.
The truth is, real users NEVER know who to get in touch with, because until something goes wrong, they literally don't bother or care. Worse, most of the time, real users will get frustrated, say 'fuck it', and abandon the login attempt LONG before motivated attackers will. Printing the contact info on the back of something won't help, because it's the last place the user will look. Really. They've looked at it hundreds of times, but they didn't "see" it, because it didn't matter to them, it faded into the background noise and became effectively invisible. When crunch time comes, they won't even bother to look there, because they "know" it's not. If it were, they'd remember seeing it (so they theorize). The only way to ensure that a user with potentially-compromised account calls IMMEDIATELY is to make sure he knows beyond doubt that it's a possibility, and to put the number right in front of the user's face where he can't ignore it.
If anything, concealing the contact info opens the door to inverse phishing attacks. When a corporate user can't connect and has no idea who to call, guess where he's going to go first to try and find out? Google. Yes, Google. All the attacker needs is a reasonable-looking web site that looks suitably outsourced to India and VoIP service for a toll-free number, and our example pissed, frustrated corporate user will voluntarily spill his guts and tell the nice person who answers the phone whatever he wants to know. I know, because I've dealt with situations where it happened.
At the end of the day, would you feel safer a) making it easy for both attackers AND legitimate users to get in contact with security helpdesk staff with extensive training that includes hours of role-playing to recognize and deal with social engineering attempts, or b) hoping an employee who was forced to watch a lame, pompous, self-congratulatory exercise in legal masturbation posing as a "security training video" doesn't get misled into calling an attacker and spill his guts to someone staffing the phone lines for an organized crime syndicate?
> proper security measures is what makes things easy to use, not hard.
Amen. My job involves application security, and the biggest single problem I see is that most developers have no real understanding of what they're trying to defend against or why, and when told they have to make an application "more secure", their usual reaction is to make it as awkward and user-unfriendly as they can on the theory that it somehow makes the application more secure. Most of the time, their misguided efforts end up making matters even worse.
Case in point: an account gets locked out because too many attempts have been made to log in with invalid credentials. OK, fine. That's good. What's NOT good is giving the user some response like, "The server is having problems, please try again later." 1) by displaying that different message, they've just let the attacker know that something significant has happened, and that if the attacker was blindly trying usernames and passwords, he's probably just found a valid username by locking it out. 2) By telling the user to "try later", you're giving them false hope that the problem will somehow resolve itself on its own. If a user's account has been compromised, the LAST thing you want him to do is to forget about it until "later". You want him to call the helpdesk NOW. The ONLY case where intentionally lying to the user might be acceptable is if you're dealing with access to something EXTREMELY sensitive whose security is backed up by real-world people with guns who are going to come running to investigate moments after the user sees the "system error" lie (in which case the user, if legitimate, will have someone right there to assist him immediately anyway).
So, how would you make the login more user-friendly WITHOUT creating new vulnerabilities? Easy: here's the response you give when someone attempts to log in with an invalid username, a valid username with invalid password, or a valid username & password that have been locked out:
"The username and password you entered is not associated with a user account, or the account might have been disabled due to excessive failed login attempts. Please try again. If you believe your account might have been locked out, please call 888-999-2222 for assistance."
There. Isn't that much nicer? You aren't revealing whether or not the account is valid or what went wrong, but you're making sure the user understands that lockout is a possibility if he screws up too many times, and you're telling him who to contact NOW if he thinks it's locked out. You've made it crystal-clear to him that IF the account is locked out, he can retry forever and won't be getting back in, so if he thinks it HAS been locked out, he might as well call RIGHT NOW and get it over with. There's no need to lie to the user, waste his time, piss him off, or ultimately delay communication that someone might be trying to compromise user accounts. You're respecting the value of his time, and telling him how to get in touch with somebody who can solve his problem NOW (or at least explain why it can't be solved now). Note the exact phone number, and not vague instructions like "contact your network administrator" or "call the helpdesk". Why? For one thing, assuming the user even has the slightest idea WHO to call, he probably doesn't know the damn phone number. Too many programmers get the wacky idea that they're somehow enhancing security by making it harder to get in touch with someone who can fix the problem. In reality, the opposite is true. Real users don't know, and don't care. Attackers, on the other hand, will do hours of research to find out.
Actually, it's worse. Android maintains an arbitrary distinction between "coarse" location invariably meaning "network/tower-based", and "fine" location invariably meaning "GPS-based". The problem is, lots of Android phones have GPS that's basically dysfunctional indoors (*cough* entire Samsung Galaxy S family with official firmware), and network-based location doesn't work in places where you might have no 3G signal, but have wi-fi (like a foreign country with roaming disabled). In reality, Android's location services should make use of all sources of location information available to it, but blur and dither it to reduce its accuracy when the user requests "coarse" location.
Oh, and god help anyone with a tablet. Network location service doesn't exist unless you buy an outrageously overpriced tablet tied to a 2-year 3G contract, and you can count the number of Android devices that ship with kernels with Bluetooth HID and SPP compiled in on a single hand, with fingers to spare... so unless it comes with GPS, you can forget about using it with an external bluetooth GPS module.
> Kill anyone holding, having or transporting ANYTHING prohibited. The person carrying or the intended recipient. > Kill any guard or screener who allows contraband into the prison. It will calm down shortly.
Right. And we'll start with the innocent four year old whose mother told him they're just going to see daddy, and continue with the guy who gets sent by some organized crime organization (not necessarily with his knowledge or free consent) on a suicide mission to deliver something for another prisoner who's a witness in a trial against someone in that organization (and kill him, too, since he was the intended recipient).
The fundamental problem with simple zero-tolerance "solutions" is the fact that life is complicated, and they inevitably result in outcomes that are absurd at best and wholesale evil at worst.
Oh, and if you're going to kill prison guards who allow something to slip through without ironclad proof that it was absolutely intentional, you're going to have a bit of a problem recruiting actual guards. Would YOU go to work every day, at any salary, knowing that the penalty for the slightest mistake was execution?
RFC 2765 deals with mapping public IPv4 addresses into the IPv6 address space. My example maps private IPv4 addresses into the lower 64 bits of IPv6, and encodes the forwarding info into the IPv6 address itself in a deterministic, but completely adhoc, manner.
I'm used to getting it criticized. Yes, I know::192:168:100:101 really represents a 64-bit binary value that has nothing to do with the four bytes having 192, 168, 100, and 101 as their respective values. The point is, it's human-readable, and the behind-the-scenes math to make it work is utterly trivial for the router itself to handle for the sake of making the life of whomever has to configure it more convenient.
Likewise, I know it stomps on the official scheme cooked up by IETF for assigning the lower 64 bits based on MAC address... and counter that it doesn't really matter, because what happens on the end user's side of the cable modem is ultimately his own business, and the business of nobody else. If I have a single desktop PC and feel like making its ipv6 address 2001:aaaa:bbbb:cccc::1, it might offend someone who takes issue with it not following the official rules... but at the end of the day, all that matters is that nothing else on my side of the cable modem is using::1 at the same time.
It also has the benefit of making ipv6 addresses look a lot less scary to the crowd who's going to be the second group to implement it at home... Slashdot users. Mention ipv6 among any group of technically-savvy users, and what's the first thing everyone bitches about? IP addresses that are impossible for humans to remember. But if you take the upper 64 bits as they're assigned, and assign the lower 64 bits in a way that DOES make sense to non-autistic humans, it doesn't look nearly as bad. Everyone can remember a few ipv4 addresses, including the fixed one that costs $5-10/month extra and is shared by everything at the house. Likewise, most people can remember the private IP addresses used at home, because the user got to pick a range that made personal sense, and assigned specific addresses in a way that's meaningful and memorable to the individual. Turn a.b.c.d -> 10.0.0.x into aaaa:bbbb:cccc:dddd:10:0:0:x, and the big, bad 128-bit address doesn't look nearly as scary anymore. It might not be "authentic" in a strict binary sense, but if it gets 4 times as many Slashdot users to upgrade to ipv6 next year as would have otherwise done it, those users will influence more Slashdot users, who'll influence less-technical users, who'll ultimately end up configuring their parents' new router on Christmas.
At the end of the day, the biggest single obstacle to IPv6 adoption is resistance by just about everyone at the top of the IT Hierarchy who's not personally involved with IETF. When you have something that scares the bejesus out of people who administer networks, write enterprise software, and design military robots (or at least causes excessive frustration and dread), its likelihood of adoption by anyone lower on the food chain is nonexistent. Grandma isn't going to tweet about upgrading her home network to IPv6 and ask when we're going to do our own. Before anyone's going to succeed at selling IPv6 to the unwashed masses, they've got to sell it to the tech elite.
As long as you don't count microwave ovens and high-power commercial radio transmitters, just to name two really obvious uses that aren't going away anytime soon...
It was broadly invented by an Englishman, but formalized by the French. Its core problem was always the fact that, like ipv6, its most ardent advocates were concerned less with making it painlessly interoperable with the commercial status quo than with imposing their own rigorous academic purity upon everyone else. From what I've read, Ben Franklin and Thomas Jefferson were 100% behind making the US metric, but recognized that it was dead in the water back at home unless SI agreed to make 25mm=1 inch (preferring 24mm, but writing THAT dream off as a lost cause and hoping to at least get SI to buy into 25mm on the theory that 25mm was a nice fraction of 100, versus an even nicer common multiple of 8). They were right. When SI adopted 1mm = 1/25.4th of an inch, the states turned up their noses at it, and the early US federal government wasn't about to squander its political capital on a squabble over inches-vs-meters.
In retrospect, I believe that if it were possible to individually show the members of SI what was going to happen over the next 200 years (British Empire, Pax Americana), and the mess that going with 1mm=1/25.4th inch would make compared to 1mm=1/25th or 1/24th inch, they might have been more willing to cooperate.
Then I would have worked on getting them to just leave temperature measurements alone, because the 0C and 100C points are true only under specific conditions, and are largely irrelevant to the public on a daily basis anyway. Water only freezes at 0C when it's distilled and STP. Nobody boils water with a thermometer when cooking dinner or making a cup of tea. In contrast, Fahrenheit's scale is nearly ideal for answering the question, "How hot (or cold) is it outside today?" Below 0? Not just cold... *dangerously* cold, as in frostbite. 32F/0C? Meh. Cold, but you could get by with a sweater if you aren't spending lots of time outdoors and it's neither wet nor windy. 100F/39C? Not just hot... *dangerously* hot. Maybe they could have tweaked it a bit to define 100C as being exactly equal to normal human body temperature since the two are so close anyway (98.6 vs 100) and defined the other end as 0C=0F, but other than that, Fahrenheit is almost perfect as it is. For science, we use Kelvin anyway, where the actual degree values for everything besides absolute zero are completely arbitrary anyway. Kelvin could have been defined relative to Fahrenheit just as easily as it was defined relative to Celsius.
Interestingly, had they gone with 1mm=1/24th inch, a kilogram would have ended up being almost exactly two pounds, and a gallon would have ended up being almost exactly 4 liters.
> You've missed the point. With IPv6, you don't need NAT. NAT is a response to the limited address space available with IPv4.
Maybe. But the response is part of the problem, too. If the forces behind IPv6 were more willing to humor the unwashed masses and let them have something that was drop-in, plug and play compatible with ipv4 (putting forth a public ipv6 face, while maintaining a private ip4v network and transparently working in the background to make everything beyond the router look like it always has), there would probably be less resistance. Then, users could discover on their own, at their own rate, that they don't have to jump through hoops anymore, and go native.
Example:
suppose your ISP assigns 2001:aaaa:bbbb:cccc:: to you. Your home network currently uses 192.168.100.x, with some fixed addresses (router=192.168.100.1, desktop pc = 192.168.100.2, DHCP block from 192.168.100.101-192.168.100.199).
drop in a hypothetical router and give it IPv6 address 2001:aaaa:bbbb:cccc:192:168:100:1 (yeah, an egregious abuse of address space for the sake of human-readability and change-resistance, but humor me). On the LAN side, the router pretends to be a typical ipv4 home router. It assigns ipv4 addresses in the private range as usual. With a twist. Anything coming from your desktop PC automagically gets rewritten to appear as if it were coming from 2001:aaaa:bbbb:cccc:192:168:100:2. Anything inbound addressed to 2001:aaaa:bbbb:cccc:dddd:192:168:100:2 gets rewritten and forwarded to 192.168.100.2 on the inside. By default, all your network traffic from the house gets collapsed onto 2001:aaaa:bbbb:cccc:dddd:192:168:100:1 (because all the PCs on the inside are still routing it through 192.168.100.1 as the default gateway). Traffic to and from ipv4 hosts works like NAT'ed traffic always has.
Yes, it's unnecessary. But it enables end users to defer having to deal with ipv6 directly until they have a personal, compelling reason to specifically care about it. Think of it like training wheels for a kid's bike. Eventually they get in the way and are voluntarily removed, but in the meantime they enable kids to safely start enjoying bikes at a much younger age.
(I know that what Comcast is doing is something along these lines, but I have yet to see anything take it a step further and implement transparent deterministic automapping between ipv6 and sort-of-NAT'ed-private-ipv4-addresses).
Sprint is big because they were the first carrier in the US to own spectrum in every metro area, so even back in 1999, you could go just about anywhere halfway urban and use Sprint without getting raped by roaming fees. The signal quality might have been awful, but back then, making a call with an AT&T phone in Dallas (where AT&T didn't exist) could easily cost $5 or more.
Verizon is big because they acquired Primeco, Alltel, and a whole bunch of regional Telcos in the late 90s. At one time, Verizon had TDMA customers from a company they acquired, but they gave them all new phones and switched the old network over to CDMA. That would be a lot more expensive and harder to do today (back then, a phone was a phone, and just about any new CDMA phone would have been nicer than an older TDMA phone. TDMA phones were pretty dire by modern standards, and couldn't do things that were standard features on CDMA phones from the late 90s).
Both went with CDMA because the alternative at the time was TDMA (which GSM uses). TDMA requires more spectrum and has worse quality than CDMA. Legacy GSM is TDMA with additional meta-info stapled on top to allow international interoperability. CDMA is so much more efficient than TDMA, engineers from Nokia actually went on record as saying it was a physical impossibility and fraud (it turns out, they had to eat their words, because one of their fundamental assumptions ended up being wrong, and CDMA's spectral efficiency ended up being real after all). In fact, 3G GSM is actually CDMA, too (but with 5MHz channels instead of 2.5MHz channels).
Trivia: T-Mobile was actually started by Sprint. After the PCS auctions in the early 90s, Sprint owned more 1900MHz spectrum than they knew what to do with... or could afford. So, to raise capital, they bundled off the minimum spectrum possible to run a viable GSM network, and started a company called Voicestream. Amusingly, they chose GSM instead of CDMA precisely because they didn't want the new company to ever really be able to compete with them, and they figured that the best way to do it was to saddle it with a foreign phone standard that wasn't as efficient as CDMA. This is why, prior to the AWS spectrum actions circa 2006, T-Mobile couldn't even do EDGE in most markets. They were so spectrum constrained, they didn't have enough to set aside enough for even a single EDGE channel in most areas. See, a GPRS connection is equivalent to a voice call spectrum-wise and can coexist interchangeably with voice calls on the same switch. T-Mobile owes its EDGE network and current 1900MHz spectrum to the AT&T-Cingular merger; as a condition of approval, Cingular and AT&T were required to sell surplus 1900MHz spectrum to T-Mobile.
More trivia: AT&T almost switched to CDMA, too. The only thing that stopped them was their merger with Cingular, who had already committed to switching from TDMA to GSM and spent lots of money preparing for it (up to that point, AT&T hadn't really spent much at all). Back then, AT&T was actually a pretty small (but geographically-scattered) regional carrier with little more than the family name to call its own. Cingular (formerly BellsouthMobility) was the powerhouse that swallowed AT&T, then changed its name (the same way that SBC bought AT&T, took the name, then BellSouth bought them and took the name).
There's actually no technical reason why Sprint and Verizon phones can't use R-UIM cards (R-UIM is a CDMA superset of SIM... you can use a R-UIM card in a GSM phone, but you can't use a SIM card in a CDMA phone). Sprint and Verizon are just assholes who don't want to deal with the tech support headaches. Plus, both Sprint and Verizon love the fact that they can buy every phone used on their network at wholesale, then sell them at discounts from their inflated retail prices and call them "subsidized" while locking customers into 2-year contracts.
Final trivia: Verizon doesn't like to admit it, but if you really press the issue, they MUST allow you to use any CDMA phone
Slashdot Mirror
> Geez...where and when do you drive where you have a hundred miles of creep along, stand still traffic??
Try driving from Miami to Tampa or Orlando the day before Christmas, Thanksgiving, or July 4th Weekend. I-75 across the Everglades ("Alligator Alley"), and the Turnpike between Yeehaw Junction and Kissimmee can both get really bad. I've had plenty of 7-hour drives to Tampa & Orlando, and know lots of people who'd *kill* for decent passenger rail (read: trains that leave after 6pm, and arrive before midnight) between Miami and Tampa/Orlando. Part of the problem with Alligator Alley & the Turnpike north of Yeehaw Junction is the fact that they have ~40 miles between exits in spots where there's almost always an accident with fatalities every major holiday. Anytime that happens, the road basically gets shut down in one or both directions, and nobody can go *anywhere* for hours (creating gridlock that persists even longer afterward).
> High speed rail isn't practical for 90% of the country.
Not practical for 90% of America's land area? Yeah. Not practical for 90% of its population? I disagree. The places where people actually *live* are pretty concentrated and linear due to things like geography and older transportation infrastructure that made inland areas economically-viable to begin with.
By now, just about everybody knows the obvious places where passenger rail makes sense, and most of them pass within a hundred miles of roughly 90% of America's population. Where sensibility breaks down is when HSR advocates demand 100% True HSR Now, instead of settling for 125-150mph max speeds with Acela-like diesel trains along core HSR mainlines and 80-110mph ISR along slightly-improved existing corridors to multiply the areas with direct transfer-free service. At the end of the day, a train that averages 60mph from Miami to West Palm Beach, 90-110mph from WPB to Auburndale, and 100-150mph for the final haul into Tampa or Orlando would be *wildly* popular with Floridians and visitors alike. Force those same passengers to get off the train and transfer at Auburndale (or take a similar 60-100mph trip along the coast to Cape Canaveral, then transfer there), and they won't care whether the remainder of the trip is theoretically 180mph, because the slightly faster speed for the last half hour won't make up for the delay and hassle of having to physically switch trains. Likewise, slower direct service with trains leaving every 20-30 minutes during peak times (so higher-paying passengers can literally just show up at the station "whenever" and get on the next train instead of having to worry about a rigid schedule) will win out over faster trains that run less frequently. It doesn't matter if HSR can make the trip in 2:38 instead of 3:30 if you miss the 6pm HSR and the next one doesn't leave until 7, compared to slower trains that take 50 minutes longer, but depart every 20-30 minutes. Waiting time, stress, and anxiety DO matter to passengers and influence their travel decisions.
In a state like Florida, trains (HSR or otherwise) have another advantage over flying: weather delays are almost nonexistent unless there's literally a hurricane in progress. It's kind of cool to be on a train during a torrential summer downpour. You look out the window, and realize that the weather outside is completely irrelevant to the train. It's not going to skid off the tracks or crash on takeoff/landing due to a microburst. IMHO, it's also a good reason to favor 150mph diesel that can run on regular tracks over 180mph electric that needs overhead wires that will be damaged by every hurricane that comes within a hundred miles, and shredded by every hurricane that makes a direct hit.
Part of the problem IS unfortunately Amtrak itself, which has gotten into the habit of stirring the political pot by framing the debate as corridor-vs-long distance, and totally ignoring the fact that boosting corridor service will largely solve the long-distance cost problem by keeping most of the stations and infrastructure that need to be staffed all day, even if it currently serves one or two trains in each direction, busy with other trains to spread around the cost. Worst-case, Amtrak limits most of its cross-country stops to areas with thriving corridor service, and treats the stretches in between like "uncontrolled airspace" where the trains run, but don't stop (or at least don't stop at fully-staffed stations).
Going back to the Florida example (because it's one I'm intimately familiar with). If Florida builds HSR-grade tracks from Orlando to Tampa and improves the existing tracks down to Miami and up to Jacksonville, Amtrak no longer has to staff and run its own stations down to the janitor and parking lot attendant. It could probably even outsource the baggage-handling to whomever runs the Florida trains, and run with just one or two actual Amtrak employees per major station (maybe none at all at a smaller station like Hollywood or Deerfield Beach). Add similar
Yeah, but the train *wouldn't* derail at 180mph. It might ultimately derail, but by the time most of the cars left the tracks, they'd be much, much slower. Remember, by law, American passenger trains have to be capable of surviving a head-on collision with a mile-long freight train at full speed. That's a use case where you have two opposing forces sharing right of way with nowhere for the force to spread. By comparison, a bomb blast is a momentary disruption that might knock a couple cars off the tracks, but then they'll be skidding sideways along the tracks and slowing down the cars behind them. A stopped vehicle across the tracks? A 150mph Acela-like train would cut through them like a hot knife through butter, or send it flying like a soccer ball. Or both. When American passenger trains hit stalled vehicles at high speeds, most of the people who end up dying are people who WEREN'T on the train. The passengers on the train get a scary high-speed ride through a tunnel of fire. It's the poor guy standing on the sidewalk waiting to cross the street who gets sliced in half by the flying debris.
Terrorists don't attack planes because they're used for travel... they attack planes because they can cause a LOT of collateral damage with a fairly small investment (boxcutters, a half-dozen plane tickets). CAN a train be attacked? Of course, Would it be an efficient use of a terrorist organization's limited resources? No. If your goal is to hurt/kill people and get it on international news, just about anything is a softer target.
> Unfortunately, Canada is turning into a technological backwater as far as mobile data goes...
Hey, at least YOUR Galaxy S Android phones get to have Froyo ;-)
> To replace driving you need a public transporation system
Or convenient rental cars at the station, preferably with agents on board the trains so you can do the rental car paperwork before you arrive and be driving out of the station's parking garage 5-10 minutes later.
> blowing up track is easy
You've obviously never seen how modern track is constructed -- steel rails roughly 6" thick attached to reinforced concrete ties. If you planted explosives around it, most of the blast would be into the open area around them. It would be almost like trying to bomb a Jersey barrier on a freeway.
> To replace planes you need it to be cheaper, safer, and actually faster.
Or nicer and more convenient. Flying is cheap, nasty, stressful public transportation at its worst. First class rail travel is very, very nice. The truth is, trains aren't for poor people. Compare the price of taking Eurostar from London to Paris, and you'll quickly see that it's a really nice premium transportation mode for people who want to arrive in a good mood after having a nice trip, instead of being herded like cattle and treated like schoolchildren. I take Amtrak from Miami to Orlando all the time. I'd take it a lot more if they actually had trains that left around 6:30pm and arrived before midnight. It costs about $200 round trip for a first-class ticket with a room, and it's worth every penny. Plus, unlike a plane, my phone works the whole way, the food's a hell of a lot better, and I have tethered internet access at all times (but not 4G... Sprint's 4G doesn't do tower hand-offs properly, and is therefore useless in moving vehicles. But that's another Slashdot rant...) And I don't have to discontinue use of approved electronic devices for half the trip, either. I have my own john that I might or might not use, but it's there if I feel like it. If I want to take a nap for 4 hours, I can.
Seriously, try first-class travel on a train sometime. It's really, really nice. Even my *parents* like trains now, and they've *always* hated trains. They grew up in an era where wealthy people flew, and poor people took trains.Things have changed. Now, trains are the nice, pleasant way to travel.
Not really. A small bomb can take down a plane. The same bomb might kill a few dozen passengers in a crowded railcar, but wouldn't have much effect beyond it. Comparisons to the Spanish train bombing aren't appropriate, because American trains literally weigh about 5 times as much as European trains. It sucks in the sense that it makes them slower and more expensive to operate, but it's nice in the sense that a rolling bank vault isn't very vulnerable to anything.
If you're in a jet that gets split apart and manage to survive in the broken-off tail section, you're still going to die... you'll just have 3 or 4 terrifying minutes of life that your fellow passengers didn't get to have. If you're on a train that somehow gets derailed, and it catches on fire, you can kick out a window and crawl away. At 20,000 feet, that's a little harder to do.
The truth is, if you're a terrorist, American passenger trains make shitty targets with really low bang-per-buck. You'd do better driving a SUV into a crowded McDonald's, or throwing grenades around inside a mall. Planes are vulnerable because they're relatively easy to take down, they're hard to escape from, and if you gain control over them, you can fly them into buildings. Trains fail (as terrorist targets) on all three counts.
IMHO, the ideal California compromise would be a HSR mainline from LA to San Jose, using the existing Caltrain tracks into SF and double-tracking existing freight corridors used by Amtrak from SJ to Sacramento, and from LA to San Diego, with some additional corridor improvements so trains running on non-HSR track could average 100mph, and Acela-type Talgo trains that max out around 150mph, but can legally run on both freight and dedicated HSR track. You'd still get end-to-end transfer-free convenience, at roughly half the up-front construction cost of "true" HSR every inch of the way from San Diego to Sacramento. As ridership increases, California could build proper HSR tracks in San Diego and Orange County, then finish up the last segment 20-25 years later and save costs by combining it with a freeway (re-)construction project (using the same right of way and crews to build both simultaneously). Ditto, for the area from SJ to Sacramento. Eventually it would all be "true" HSR, but by initially limiting the most expensive part to just LA-SJ (the part that would get the most traffic), the total cost (when you add up the interest on the construction bonds) would be a fraction of what it would cost to do it 100% HSR from day one... and the network would be far more useful than one that went ONLY from LA to SJ/SF (requiring transfers to go beyond either city).
The Bay Area itself is admittedly a mess, and I'm not even going to speculate on how that area's problems could be solved (though the idea of beefing up BART trains so they could legally share tracks with electrified HSR, and retrofitting BART's tracks to accommodate both BART-gauge and standard-gauge trains so HSR could use BART's tracks and the Transbay tunnel is intriguing)
In the real world, every time you make passengers change trains, you lose half of your potential market, but increasing the speed from 110mph to "true" HSR 150-180mph only increases the market by about 10%. In round numbers, that means you might have 100,000 people who'll pay a given fare to take the train from San Diego to San Francisco if they can make the trip without transfers (even if half the trip is sub-HSR speed), but only 50,000 people who'll pay the same fare if they have to change trains in LA, and only 10,000/day more who'll be induced to make the trip if the speed is increased to HSR the whole way (and the operating expenses & capital cost increase by 4-20 times in the process). These are somewhat round numbers, but they're all pretty solid statistics that FDOT has compiled in multiple studies over the past 25 years, and other states seem to mostly agree with them. The problem is, pragmatism isn't sexy, and people don't understand that even Amtrak's creaky trains running on decrepit track could make most of their trips in half the time if they were just aggressively dispatched with priority given to the passenger trains).
> High-speed rail, almost without exception, relies on dedicated lines, not shared lines with freight like existing, less-than-high-speed, passenger rail in the US
To a degree, yes. But not completely. There's also a lot to be said for the convenience of transfer-free end to end service, even if it means the train has to be towed along shared tracks the last 25-50 miles to its final destination (this is common in France; they have summer TGV routes where the train runs at 180mph to the end of the line, then gets towed the last 25-100 miles to its final destination someplace where there's not quite enough business to justify the cost of building HSR all the way to the bitter end). In a place like Florida, it's *necessary* to build brand new tracks for HSR between Auburndale (halfway between Orlando and Tampa) and Tampa because the existing freight tracks are heavily used, but it's silly to build brand new 100% HSR all the way to Miami at this point because the existing tracks have barely any freight traffic (enough that eliminating it entirely would be very expensive, but not so much that good dispatching that gave priority to passenger trains couldn't overcome 99.9% of the delays that currently plague Amtrak along the same route).
For roughly the same cost as building "true" 180mph HSR from Orlando to Tampa, FDOT could temporarily scrap the electrification & HSR-only trains, build new tracks along I-4 with geometry suitable for 180-225mph trains someday, then buy and double-track the existing corridor to 110mph standards, connect it to the new HSR line north of Auburndale (along I-4) and launch Miami-Tampa-Orlando service from day one (running 80mph from Miami to WPB, 110mph from WPB to Auburndale, and 150mph along the shiny new HSR tracks for the last 40-60 miles into Tampa or Orlando). It would mean the Tampa-Orlando trains would have to be Acela-type and max out around 150mph ("true" 180mph HSR trains can't legally share tracks with freight trains, or even passenger trains legally capable of sharing tracks with freight trains), but it would also mean that Florida would end up with a useful passenger rail network instead of a largely useless amusement park ride. Move the proposed Orlando station from the central concourse of the airport to a spot adjacent to the airport (with peoplemover to the main terminal & rental car center) so trains can avoid a 5 mile detour (yeah, MCO really IS that big) and continue north to downtown Orlando after the airport station, and Florida will ALSO have a rail line suitable for daily long-distance exurban commuters to Tampa and Orlando from Lakeland. FDOT could even put additional stations between Tampa and Orlando with platforms that are "offline", so intercity trains could blast through at full speed without stopping, but commuters from the Lakeland area could have additional convenient stops to attract even more riders and business.
Another crucial element: rental cars at the major stations. Miami and Orlando have that part taken care of, and Tampa will too (as long as FDOT doesn't completely fuck up). Even better would be enabling passengers to do the rental-car paperwork on the train itself, and walk off the train with their keys in hand (or at least the codes to a wall of electronic safes containing the keys at the station) and be driving out of the parking garage 10 minutes after arrival.
Just to clarify, SSL is assumed to be getting used in addition to everything I described. Also, I forgot to mention the other reason for double-hashing -- to ensure that WE never come into direct contact with the user's plaintext password, either. Why? Like it or not, most users use the same set of passwords for nearly everything they touch. So... a compromise ends up having lots of potential collateral damage as well. In this case, even if our own server got completely pwn3d, and attackers gained the ability to directly intercept incoming requests, all they'd get are the hashed passwords that were salted with the same value. The users would be in no worse of a position than they'd have been in if we salted everyone's passwords with the same publicly-known value.
Clarification: Android app, not browser-based webapp. ;-)
Does anybody know why it's a bad idea to salt passwords with usernames (or hashes of usernames)? Say, something like...
$username = "linus"
$password = "tux4me"
client asks server for salt to use with $username
server returns md5("common2allUsers" . $username). Client doesn't do this directly to make it less publicly obvious that the first salt is "common2allUsers". Salt is algorithmically-determined by username to avoid revealing whether or not a given username is valid to attackers. Server uses md5 for speed, since this particular hash is partly just obfuscation and security theater.
client calculates $passhash = sha-1($commonSalt . $password)
client sends $username and $passhash to server.
Server looks up $usersalt associated with $username in database. If $username doesn't exist, server pretends salt is 'badU53r' and proceeds with lookup anyway to reduce vulnerability to timing analysis attacks.
$storedSaltedHash = sha256($usersalt . $passhash)
Server looks up userid associated with $username and $storedSaltedHash
Rationale for hashing before sending to server: to obfuscate the password in case it ends up being revealed in a log somewhere.
Rationale for hashing the hash again: to use a unique hash for every user, without revealing the hash or enabling attackers to harvest usernames.
Drawbacks: 1) increased server workload. 2) ???
I believe *all* new Sprint Android phone activations going forward have the $10 fee, 4G-capable or not.
Believe it or not, the problem you're having on the bus probably has NOTHING to do with coverage. It appears that Clear's towers all assign their own dynamic IP addresses, and won't route traffic from other towers more than one hop away. The net result is that if you try using Sprint4G (which uses Clear's towers) in a moving vehicle, you're going to drop the connection every 1-3 miles. You can prove it to yourself with this little experiment:
Find an area where you know beyond doubt that 4G coverage is rock-solid and two towers are both near the same major road, then walk from one tower to the next & keep an eye on the signal-strength bars. Starting near tower #1, disable 4G, then re-enable 4G to make sure you get an IP address from the tower next to you. Now, launch some task that constantly uses data, like Pandora, and start walking toward the next tower. You'll see the bars go from 3, to 2, to 1, back to 2, then *right* when you're close enough to spit on tower #2... your connection will drop. If you stop walking immediately, toggle 4G off and on (to force an immediate reconnect, instead of passively waiting ~5 minutes for it to reconnect on its own), it will scan for about a second and reconnect almost instantly with 3 bars. I've repeated this experiment multiple times in various locations around Fort Lauderdale, to the point where I'm now pretty much convinced that this behavior is by design and more or less as I've described it.
Frankly, it pisses me off, because it means that Sprint 4G is basically useless in a moving vehicle -- car, train, or otherwise. Especially when you consider that most Android apps either crap out or crash when the phone forcibly switches between 4G, 3G, and wi-fi. I don't know whether Verizon's LTE exhibits the same behavior, but it really does make T-Mobile look a lot more attractive than Sprint.
Oh, there's another catch with Sprint/Clear 4G, and this one will bite you if you use it at home in an area where most of the tower's OTHER users are transient. If their router notices that you're using more bandwidth than other individual users OF THAT SPECIFIC TOWER, your throughput will be *massively* throttled. Note that the statistics are *per tower*, and NOT "total network usage". That's what kills you. You're using that one specific tower, racking up bandwidth blackmarks all day... other users (shopping at the nearby mall) are only using it for an hour or two, so even if they're streaming YoutubeHD nonstop, they're unlikely to come anywhere near the bandwidth you're slowly racking up all day.
Sigh. The good old days, when the main difference between the Vic-20's user manual and the Vic-20 programmer's reference guide was the amount of detail in the memory map and the mini 6502 assembly-language reference guide. And, by extension, the era when a single person actually COULD have a pretty good understanding of the entire computer and how it all worked together. Now, you can't even find a coherent explanation of how Intel power management works if you spend the weekend hunting online, let alone get it neatly presented in anything that resembles a user manual sold with a high-end laptop (well, not if you want any more detail than being told you can choose between "max battery life" and "max performance").
Hell, I remember getting Borland Turbo C++ in college. The UPS guy almost needed a forklift to get the box up to my dorm room. Literally, 2 or 3 cubic feet of books, plus ~50 floppy disks (I could be wrong, but I think later versions that included support for both DOS & Windows came with almost 200 floppies and took most of the day to install).
I remember buying Photoshop 3 for the student price of $89 my senior year, and feeling cheated because it only came with a ~300 page manual. I don't think Photoshop CS5 even HAS bound documentation.
The problem is that you wouldn't just have to pay for the parts... you'd have to pay companies to resurrect parts based on components that haven't commercially existed in 25-30 years. Endeavour wasn't built from scratch -- it was built from spare parts intended for use with the other shuttles. Frankly, I'm surprised NASA hasn't had to cannibalize any of the shuttles (including the two destroyed ones) for spare parts to keep the others going. Just to give an example, if a window on Endeavour doesn't pass a pre-flight inspection (or some other part purpose-built for the Shuttle), NASA basically has one option: take it from an already-retired Shuttle, and replace the window in the museum-bound Shuttle with regular glass. Ditto for things like hinges, straps, and even wiring connectors.
It's the same problem that exists with the idea of resurrecting the Saturn V. The computer hardware has gotten cheaper, but the rest of the parts are based on a supply chain that hasn't existed in decades... and more than a few couldn't legally be manufactured anymore because they don't meet current environmental regulations.
Why? Retrieving Hubble would make no sense at all.
99.9% of its cost was just getting it into orbit to begin with. If anything, it would make MORE sense to give it one last hard shove AWAY from the Earth once it's about to become uncontrollable, so that N years from now, somebody can go salvage, refurbish, and put it back into service. Maybe tow it to the moon, Mars, or somewhere else. Or turn it into an orbiting shrine or tourist attraction someday.
Then again, I was rather relieved when NASA got the loony idea of asking the Russians to sign off on its plans to deorbit the ISS after its official service life is over in 2014, and the Russians politely (but firmly) made it known that they intend to keep it in orbit (with duct tape & WD-40, if necessary) until the day they literally can't stop it from falling into the Pacific. We might be insane enough to buy into the accounting profession's madness that an asset whose full lifecycle cost has officially been zeroed-out is now without value and must be disposed of immediately, but the Russians still recognize that they have a really, really expensive asset in a valuable location that cost an unholy amount of money to get there, and they're going to wring every last ${currency-unit} they can out of it before writing it off and abandoning it.
> I own a Galaxy S and since the Nexus S is basically the same phone
If your Galaxy S is GSM and you don't use T-Mobile 4G, you're mostly right. If your Galaxy S is CDMA, and particularly an Epic4G, you're mostly fucked.
The loadable kernel modules are what will kill you. Linux doesn't have a stable ABI, which means that drivers (.ko modules) compiled for an older kernel won't necessarily (read: won't) work on a newer kernel (think Win98->WinXP, but worse... like being unable to use a driver made for XP Pro/32 under Vista Business/32. Officially, the Linux kernel could break binary compatibility over the equivalent of going from XPsp1 to XPsp2. Samsung gets partial credit for releasing drivers as proper loadable kernel modules (so they can at least be used with recompiled versions of the same kernel), but source-wise, their drivers are as bad as HTC's -- they aren't directly buildable because they have unsatisfied dependencies. The difference is that HTC at least releases new kernels in a timely manner, so the community can grab them and move forward instead of being stalled for 6 months waiting for 4G drivers that work on a 2.6.32 kernel (needed for Froyo) to metaphorically fall from the sky.
All we ask is for Samsung to at least practice benign neglect and say, "Look, bitch to Sprint if you want an official 2.2 upgrade, but in the meantime, here's a zipfile of everything proprietary that you can't compile yourself, recompiled against 2.6.32. Same drivers, same bugs, but automatically rebuilt for 2.6.32's ABI. Have fun."
Of course, Samsung won't do that, because it would mean that by the time the official carrier upgrade makes it out (if ever), it would be *totally* eclipsed by community builds that do more with fewer bugs (because the community versions would have a real-world 4-6 month head start, and several orders of magnitude more hours of developer time behind them). The truth is, though, the carriers would actually have a reasonable excuse to give less technical end users who complained about having to wait: "Our upgrade doesn't make you blow away everything and start over from scratch every time. It lets you upgrade in-place, and should be relatively seamless." Diff'rent strokes for diff'rent folks.
You're assuming that there's actually a company phone book that a legitimate user would have ready access to. Quick... where's YOUR company phone book? Does it even exist in printed form, or (like most companies), is it all "online" now? Chicken, meet egg. Kafka's sitting on the bench over there, simultaneously groaning and laughing. And if it DOES exist in printed form, what's the likelihood that a remote employee at a hotel (or family member's house) with his laptop actually has a copy with him right then? No, "supposed to have it according to policy" doesn't count. When push comes to shove, statistically "nobody" will have it with them.
The truth is, real users NEVER know who to get in touch with, because until something goes wrong, they literally don't bother or care. Worse, most of the time, real users will get frustrated, say 'fuck it', and abandon the login attempt LONG before motivated attackers will. Printing the contact info on the back of something won't help, because it's the last place the user will look. Really. They've looked at it hundreds of times, but they didn't "see" it, because it didn't matter to them, it faded into the background noise and became effectively invisible. When crunch time comes, they won't even bother to look there, because they "know" it's not. If it were, they'd remember seeing it (so they theorize). The only way to ensure that a user with potentially-compromised account calls IMMEDIATELY is to make sure he knows beyond doubt that it's a possibility, and to put the number right in front of the user's face where he can't ignore it.
If anything, concealing the contact info opens the door to inverse phishing attacks. When a corporate user can't connect and has no idea who to call, guess where he's going to go first to try and find out? Google. Yes, Google. All the attacker needs is a reasonable-looking web site that looks suitably outsourced to India and VoIP service for a toll-free number, and our example pissed, frustrated corporate user will voluntarily spill his guts and tell the nice person who answers the phone whatever he wants to know. I know, because I've dealt with situations where it happened.
At the end of the day, would you feel safer a) making it easy for both attackers AND legitimate users to get in contact with security helpdesk staff with extensive training that includes hours of role-playing to recognize and deal with social engineering attempts, or b) hoping an employee who was forced to watch a lame, pompous, self-congratulatory exercise in legal masturbation posing as a "security training video" doesn't get misled into calling an attacker and spill his guts to someone staffing the phone lines for an organized crime syndicate?
> proper security measures is what makes things easy to use, not hard.
Amen. My job involves application security, and the biggest single problem I see is that most developers have no real understanding of what they're trying to defend against or why, and when told they have to make an application "more secure", their usual reaction is to make it as awkward and user-unfriendly as they can on the theory that it somehow makes the application more secure. Most of the time, their misguided efforts end up making matters even worse.
Case in point: an account gets locked out because too many attempts have been made to log in with invalid credentials. OK, fine. That's good. What's NOT good is giving the user some response like, "The server is having problems, please try again later." 1) by displaying that different message, they've just let the attacker know that something significant has happened, and that if the attacker was blindly trying usernames and passwords, he's probably just found a valid username by locking it out. 2) By telling the user to "try later", you're giving them false hope that the problem will somehow resolve itself on its own. If a user's account has been compromised, the LAST thing you want him to do is to forget about it until "later". You want him to call the helpdesk NOW. The ONLY case where intentionally lying to the user might be acceptable is if you're dealing with access to something EXTREMELY sensitive whose security is backed up by real-world people with guns who are going to come running to investigate moments after the user sees the "system error" lie (in which case the user, if legitimate, will have someone right there to assist him immediately anyway).
So, how would you make the login more user-friendly WITHOUT creating new vulnerabilities? Easy: here's the response you give when someone attempts to log in with an invalid username, a valid username with invalid password, or a valid username & password that have been locked out:
"The username and password you entered is not associated with a user account, or the account might have been disabled due to excessive failed login attempts. Please try again. If you believe your account might have been locked out, please call 888-999-2222 for assistance."
There. Isn't that much nicer? You aren't revealing whether or not the account is valid or what went wrong, but you're making sure the user understands that lockout is a possibility if he screws up too many times, and you're telling him who to contact NOW if he thinks it's locked out. You've made it crystal-clear to him that IF the account is locked out, he can retry forever and won't be getting back in, so if he thinks it HAS been locked out, he might as well call RIGHT NOW and get it over with. There's no need to lie to the user, waste his time, piss him off, or ultimately delay communication that someone might be trying to compromise user accounts. You're respecting the value of his time, and telling him how to get in touch with somebody who can solve his problem NOW (or at least explain why it can't be solved now). Note the exact phone number, and not vague instructions like "contact your network administrator" or "call the helpdesk". Why? For one thing, assuming the user even has the slightest idea WHO to call, he probably doesn't know the damn phone number. Too many programmers get the wacky idea that they're somehow enhancing security by making it harder to get in touch with someone who can fix the problem. In reality, the opposite is true. Real users don't know, and don't care. Attackers, on the other hand, will do hours of research to find out.
Actually, it's worse. Android maintains an arbitrary distinction between "coarse" location invariably meaning "network/tower-based", and "fine" location invariably meaning "GPS-based". The problem is, lots of Android phones have GPS that's basically dysfunctional indoors (*cough* entire Samsung Galaxy S family with official firmware), and network-based location doesn't work in places where you might have no 3G signal, but have wi-fi (like a foreign country with roaming disabled). In reality, Android's location services should make use of all sources of location information available to it, but blur and dither it to reduce its accuracy when the user requests "coarse" location.
Oh, and god help anyone with a tablet. Network location service doesn't exist unless you buy an outrageously overpriced tablet tied to a 2-year 3G contract, and you can count the number of Android devices that ship with kernels with Bluetooth HID and SPP compiled in on a single hand, with fingers to spare... so unless it comes with GPS, you can forget about using it with an external bluetooth GPS module.
> Kill anyone holding, having or transporting ANYTHING prohibited. The person carrying or the intended recipient.
> Kill any guard or screener who allows contraband into the prison. It will calm down shortly.
Right. And we'll start with the innocent four year old whose mother told him they're just going to see daddy, and continue with the guy who gets sent by some organized crime organization (not necessarily with his knowledge or free consent) on a suicide mission to deliver something for another prisoner who's a witness in a trial against someone in that organization (and kill him, too, since he was the intended recipient).
The fundamental problem with simple zero-tolerance "solutions" is the fact that life is complicated, and they inevitably result in outcomes that are absurd at best and wholesale evil at worst.
Oh, and if you're going to kill prison guards who allow something to slip through without ironclad proof that it was absolutely intentional, you're going to have a bit of a problem recruiting actual guards. Would YOU go to work every day, at any salary, knowing that the penalty for the slightest mistake was execution?
RFC 2765 deals with mapping public IPv4 addresses into the IPv6 address space. My example maps private IPv4 addresses into the lower 64 bits of IPv6, and encodes the forwarding info into the IPv6 address itself in a deterministic, but completely adhoc, manner.
I'm used to getting it criticized. Yes, I know ::192:168:100:101 really represents a 64-bit binary value that has nothing to do with the four bytes having 192, 168, 100, and 101 as their respective values. The point is, it's human-readable, and the behind-the-scenes math to make it work is utterly trivial for the router itself to handle for the sake of making the life of whomever has to configure it more convenient.
Likewise, I know it stomps on the official scheme cooked up by IETF for assigning the lower 64 bits based on MAC address... and counter that it doesn't really matter, because what happens on the end user's side of the cable modem is ultimately his own business, and the business of nobody else. If I have a single desktop PC and feel like making its ipv6 address 2001:aaaa:bbbb:cccc::1, it might offend someone who takes issue with it not following the official rules... but at the end of the day, all that matters is that nothing else on my side of the cable modem is using ::1 at the same time.
It also has the benefit of making ipv6 addresses look a lot less scary to the crowd who's going to be the second group to implement it at home... Slashdot users. Mention ipv6 among any group of technically-savvy users, and what's the first thing everyone bitches about? IP addresses that are impossible for humans to remember. But if you take the upper 64 bits as they're assigned, and assign the lower 64 bits in a way that DOES make sense to non-autistic humans, it doesn't look nearly as bad. Everyone can remember a few ipv4 addresses, including the fixed one that costs $5-10/month extra and is shared by everything at the house. Likewise, most people can remember the private IP addresses used at home, because the user got to pick a range that made personal sense, and assigned specific addresses in a way that's meaningful and memorable to the individual. Turn a.b.c.d -> 10.0.0.x into aaaa:bbbb:cccc:dddd:10:0:0:x, and the big, bad 128-bit address doesn't look nearly as scary anymore. It might not be "authentic" in a strict binary sense, but if it gets 4 times as many Slashdot users to upgrade to ipv6 next year as would have otherwise done it, those users will influence more Slashdot users, who'll influence less-technical users, who'll ultimately end up configuring their parents' new router on Christmas.
At the end of the day, the biggest single obstacle to IPv6 adoption is resistance by just about everyone at the top of the IT Hierarchy who's not personally involved with IETF. When you have something that scares the bejesus out of people who administer networks, write enterprise software, and design military robots (or at least causes excessive frustration and dread), its likelihood of adoption by anyone lower on the food chain is nonexistent. Grandma isn't going to tweet about upgrading her home network to IPv6 and ask when we're going to do our own. Before anyone's going to succeed at selling IPv6 to the unwashed masses, they've got to sell it to the tech elite.
> Vacume tubes
As long as you don't count microwave ovens and high-power commercial radio transmitters, just to name two really obvious uses that aren't going away anytime soon...
It was broadly invented by an Englishman, but formalized by the French. Its core problem was always the fact that, like ipv6, its most ardent advocates were concerned less with making it painlessly interoperable with the commercial status quo than with imposing their own rigorous academic purity upon everyone else. From what I've read, Ben Franklin and Thomas Jefferson were 100% behind making the US metric, but recognized that it was dead in the water back at home unless SI agreed to make 25mm=1 inch (preferring 24mm, but writing THAT dream off as a lost cause and hoping to at least get SI to buy into 25mm on the theory that 25mm was a nice fraction of 100, versus an even nicer common multiple of 8). They were right. When SI adopted 1mm = 1/25.4th of an inch, the states turned up their noses at it, and the early US federal government wasn't about to squander its political capital on a squabble over inches-vs-meters.
In retrospect, I believe that if it were possible to individually show the members of SI what was going to happen over the next 200 years (British Empire, Pax Americana), and the mess that going with 1mm=1/25.4th inch would make compared to 1mm=1/25th or 1/24th inch, they might have been more willing to cooperate.
Then I would have worked on getting them to just leave temperature measurements alone, because the 0C and 100C points are true only under specific conditions, and are largely irrelevant to the public on a daily basis anyway. Water only freezes at 0C when it's distilled and STP. Nobody boils water with a thermometer when cooking dinner or making a cup of tea. In contrast, Fahrenheit's scale is nearly ideal for answering the question, "How hot (or cold) is it outside today?" Below 0? Not just cold... *dangerously* cold, as in frostbite. 32F/0C? Meh. Cold, but you could get by with a sweater if you aren't spending lots of time outdoors and it's neither wet nor windy. 100F/39C? Not just hot... *dangerously* hot. Maybe they could have tweaked it a bit to define 100C as being exactly equal to normal human body temperature since the two are so close anyway (98.6 vs 100) and defined the other end as 0C=0F, but other than that, Fahrenheit is almost perfect as it is. For science, we use Kelvin anyway, where the actual degree values for everything besides absolute zero are completely arbitrary anyway. Kelvin could have been defined relative to Fahrenheit just as easily as it was defined relative to Celsius.
Interestingly, had they gone with 1mm=1/24th inch, a kilogram would have ended up being almost exactly two pounds, and a gallon would have ended up being almost exactly 4 liters.
> You've missed the point. With IPv6, you don't need NAT. NAT is a response to the limited address space available with IPv4.
Maybe. But the response is part of the problem, too. If the forces behind IPv6 were more willing to humor the unwashed masses and let them have something that was drop-in, plug and play compatible with ipv4 (putting forth a public ipv6 face, while maintaining a private ip4v network and transparently working in the background to make everything beyond the router look like it always has), there would probably be less resistance. Then, users could discover on their own, at their own rate, that they don't have to jump through hoops anymore, and go native.
Example:
suppose your ISP assigns 2001:aaaa:bbbb:cccc:: to you. Your home network currently uses 192.168.100.x, with some fixed addresses (router=192.168.100.1, desktop pc = 192.168.100.2, DHCP block from 192.168.100.101-192.168.100.199).
drop in a hypothetical router and give it IPv6 address 2001:aaaa:bbbb:cccc:192:168:100:1 (yeah, an egregious abuse of address space for the sake of human-readability and change-resistance, but humor me). On the LAN side, the router pretends to be a typical ipv4 home router. It assigns ipv4 addresses in the private range as usual. With a twist. Anything coming from your desktop PC automagically gets rewritten to appear as if it were coming from 2001:aaaa:bbbb:cccc:192:168:100:2. Anything inbound addressed to 2001:aaaa:bbbb:cccc:dddd:192:168:100:2 gets rewritten and forwarded to 192.168.100.2 on the inside. By default, all your network traffic from the house gets collapsed onto 2001:aaaa:bbbb:cccc:dddd:192:168:100:1 (because all the PCs on the inside are still routing it through 192.168.100.1 as the default gateway). Traffic to and from ipv4 hosts works like NAT'ed traffic always has.
Yes, it's unnecessary. But it enables end users to defer having to deal with ipv6 directly until they have a personal, compelling reason to specifically care about it. Think of it like training wheels for a kid's bike. Eventually they get in the way and are voluntarily removed, but in the meantime they enable kids to safely start enjoying bikes at a much younger age.
(I know that what Comcast is doing is something along these lines, but I have yet to see anything take it a step further and implement transparent deterministic automapping between ipv6 and sort-of-NAT'ed-private-ipv4-addresses).
Sprint is big because they were the first carrier in the US to own spectrum in every metro area, so even back in 1999, you could go just about anywhere halfway urban and use Sprint without getting raped by roaming fees. The signal quality might have been awful, but back then, making a call with an AT&T phone in Dallas (where AT&T didn't exist) could easily cost $5 or more.
Verizon is big because they acquired Primeco, Alltel, and a whole bunch of regional Telcos in the late 90s. At one time, Verizon had TDMA customers from a company they acquired, but they gave them all new phones and switched the old network over to CDMA. That would be a lot more expensive and harder to do today (back then, a phone was a phone, and just about any new CDMA phone would have been nicer than an older TDMA phone. TDMA phones were pretty dire by modern standards, and couldn't do things that were standard features on CDMA phones from the late 90s).
Both went with CDMA because the alternative at the time was TDMA (which GSM uses). TDMA requires more spectrum and has worse quality than CDMA. Legacy GSM is TDMA with additional meta-info stapled on top to allow international interoperability. CDMA is so much more efficient than TDMA, engineers from Nokia actually went on record as saying it was a physical impossibility and fraud (it turns out, they had to eat their words, because one of their fundamental assumptions ended up being wrong, and CDMA's spectral efficiency ended up being real after all). In fact, 3G GSM is actually CDMA, too (but with 5MHz channels instead of 2.5MHz channels).
Trivia: T-Mobile was actually started by Sprint. After the PCS auctions in the early 90s, Sprint owned more 1900MHz spectrum than they knew what to do with... or could afford. So, to raise capital, they bundled off the minimum spectrum possible to run a viable GSM network, and started a company called Voicestream. Amusingly, they chose GSM instead of CDMA precisely because they didn't want the new company to ever really be able to compete with them, and they figured that the best way to do it was to saddle it with a foreign phone standard that wasn't as efficient as CDMA. This is why, prior to the AWS spectrum actions circa 2006, T-Mobile couldn't even do EDGE in most markets. They were so spectrum constrained, they didn't have enough to set aside enough for even a single EDGE channel in most areas. See, a GPRS connection is equivalent to a voice call spectrum-wise and can coexist interchangeably with voice calls on the same switch. T-Mobile owes its EDGE network and current 1900MHz spectrum to the AT&T-Cingular merger; as a condition of approval, Cingular and AT&T were required to sell surplus 1900MHz spectrum to T-Mobile.
More trivia: AT&T almost switched to CDMA, too. The only thing that stopped them was their merger with Cingular, who had already committed to switching from TDMA to GSM and spent lots of money preparing for it (up to that point, AT&T hadn't really spent much at all). Back then, AT&T was actually a pretty small (but geographically-scattered) regional carrier with little more than the family name to call its own. Cingular (formerly BellsouthMobility) was the powerhouse that swallowed AT&T, then changed its name (the same way that SBC bought AT&T, took the name, then BellSouth bought them and took the name).
There's actually no technical reason why Sprint and Verizon phones can't use R-UIM cards (R-UIM is a CDMA superset of SIM... you can use a R-UIM card in a GSM phone, but you can't use a SIM card in a CDMA phone). Sprint and Verizon are just assholes who don't want to deal with the tech support headaches. Plus, both Sprint and Verizon love the fact that they can buy every phone used on their network at wholesale, then sell them at discounts from their inflated retail prices and call them "subsidized" while locking customers into 2-year contracts.
Final trivia: Verizon doesn't like to admit it, but if you really press the issue, they MUST allow you to use any CDMA phone