From what I've read, Maemo suffers from the same problem that's always plagued Windows Mobile -- it's a great OS for a pocket-sized laptop, but it's not exactly the greatest user environment for making and receiving actual, voice phone calls.
Compare the way Android handles incoming phone calls to the way Windows Mobile and Linux in general do. When Android notices an incoming phone call, it instantly suspends the foreground app and devotes its full attention to handling that incoming call immediately. In start contrast, Windows Mobile and Linux (in general) regard an incoming call as just another event, neither more nor less inherently important than anything else. Well, ok... maybe a LITTLE more important, but with both WinMo and a traditional Linux kernel, you ARE going to end up with situations where an incoming call ends up going to voicemail because the system decided it was just too busy doing something else to deal with the call right that instant.
If the user thinks incoming calls are no big deal, they'll prefer the way WinMo and Linux work. If a user thinks an incoming call that ends up going to voicemail despite his best efforts is a catastrophe, he'll prefer the way Android works. I don't personally know Linus, but I've definitely gotten the impression that he falls into the "do whatever it takes to make the phone first and foremost work flawlessly as a phone" camp. Who knows, it might have even been something as trivial as Linus picking up a friend's N900 with one hand, trying to bring up the phone directory using only his thumb, being unable to guess how to make it happen in 2 seconds, and deciding it just wasn't the paradigm he was looking for.
> Of course it's bad: cell phone service in the US is expensive,
For people who make 5 minutes worth of outgoing calls per month? Yeah. For people who use slingbox to stream videos from their livingroom DVRs, or use their home PC via remote desktop from a laptop tethered to their cell phone? It's dirt cheap. You could probably fit every European who's used Slingbox for more than 5 minutes in the dining room of a small McDonalds. Americans bitch about the threat of getting dropped as a customer for using more than 5GB of wireless data per month. I shudder to think of how much 5 gigabytes of wireless data use would even COST anywhere in Europe.
> has poor coverage,
Compared to Finland, Belgium, or the Netherlands? Maybe. Compare T-mobile's 3G coverage in the rural parts of Britain to Sprint & Verizon's 3G coverage in rural parts of the US, and it's almost dead even. Factor out any patch of land more than a hundred miles from the nearest city with at least 100 residents (ie, most of the western US desert), and the US probably comes out ahead. If you want to be fair and compare "apples to apples", compare T-Mobile's 3G coverage map for Florida to T-Mobile's 3G coverage map for Britain. Especially in the more suburban and rural areas, their Florida 3G coverage would probably make more than a few of their British customers jealous.
> is monopolistic,
Change it to "a pair of duopolies", and I'll generally agree.
> and is less technologically advanced than it is in Europe.
No, it's not. Today, with UMTS (in areas with 3G coverage), Europeans finally get to enjoy the soft hand-offs, diveristy tuning, and superior audio fidelity of CDMA that American Sprint and Verizon customers have been enjoying for more than a decade. Amplified speakers didn't start making "GSM Noise" until, er, GSM became common here.
For the most part, the only thing that really sucks about American cell phone companies is the fact that they're such assholes about trying to turn every handset into a mini-monopoly.
> And how is Android not open? The entire thing is FOSS
(cringes, wrings hands for a while, coughs a bit, then sighs)
"Android" might be "open", but people fighting on the Android front lines and trying to run open builds without the blessing of HTC and their carrier might politely beg to differ. To date, nobody has been able to independently build a fully working 2.6.29 kernel for ANY CDMA Hero phone that shipped with Android 1.5 (Sprint Hero, Sprint Samsung Moment, Verizon Droid Eris). Without a 2.6.29 kernel, major parts of Android 2.x won't work properly. Work is underway, but the fact is, right now... today... my Sprint Hero is running a hacked-up build that can be described as a liquefied Cupcake injected into the clay mock-up of an Eclair facade. And I'm "lucky" -- my other CDMA Android 1.5-shackled brethren can't even do *that*.
Right now, the cruel reality is that people who buy many Android phones are kind of like consumers who bought a very, very proprietary Packard Bell or HP computer in the mid/late-90s. If the manufacturer didn't feel like supporting Windows NT or Linux, you were basically screwed. You couldn't just download OEM drivers, because they didn't exist -- the company who sold the computer WAS the OEM. Open-source drivers didn't exist, because the hardware itself was built around proprietary ASICs designed for that specific manufacturer.
OK, let me make the analogy a little better: it's 2000, and you need to buy a new laptop. Your ISP allows you to choose between exactly two laptops, both sold only by the ISP itself with a 2-year contract that has a substantial penalty for early termination. Your ISP personally knows the MAC address of the network interface for every computer it sells, and refuses to accept network traffic from any network interface whose MAC address isn't in its holy database. It's not necessarily *impossible* to spoof an official MAC address with an unapproved laptop, but it happens to be a major federal offense that can be prosecuted as an act of terrorism, narcotics distribution, or organized crime. The laptops are only available with an old, obsolete distro of Linux that's proprietary to the laptop's manufacturer, and the hardware drivers are all compiled straight into the kernel (which happens to be 2.2, even though 2.4 has been considered mature enough to use for at least the past 6 months). Oh, the source? You won't see it until 4-6 months after you buy the laptop -- if you're lucky -- and the code for the proprietary hardware will be obfuscated & devoid of comments.
Welcome to the brave new world of Americans who buy Android phones in 2010, where "open" phones have to be hacked & rooted to allow upgrades, and it's easier to upgrade an old phone to a newer version of Windows Mobile than it is to upgrade a 4 month old Android phone to a newer version of Android.
Oh pleaze. For all the buzz about "the desktop going away", the number of desktop computers seems to just keep growing. Homes that had one PC now have two. Or three. Individuals who had their own now have their own desktop PC and a laptop (or at least a netbook, which contrary to its name seems to end up spending at least as much "on" time doing stuff a few thousand feet above sea level, inside flying aluminum cylinders that are one of the last frontiers where internet access is still rare and expensive). Most of the people "making do" with a laptop as their only computer are people who formerly had no computer at all. The people who owned computers 15+ years ago won't give up their desktop until laptops routinely come with dual 24" displays and quad+core CPUs.
Cloud computing is the new paperless office. As more than a few have observed over the years, the paperless office was officially welcomed 15 years ago, yet 21st-century offices still seem to somehow generate at least twice as much printed output per employee as they ever did in the dark ages. The main difference is that back then, the paper copies were carefully stored in file folders for future reference. Now, they're stored in the SAN, and four dozen copies get casually printed on demand so everyone can pretend to read them at the weekly status meeting & use them to scribble notes on before tossing them all in the big blue bin after lunch. I'm quite confident that when the day arrives that I have a hundred terrabytes of data stored "in the cloud", I'll have at least ten times as much physically present within my home.
Desktops aren't going away anytime soon, any more than TVs with eight-foot screens are going to be displaced by personal media tablets. They might end up mutating into our own personal faux-clouds, perpetually connected to our PadPCs and phones, but at the end of the day, when you need to edit video (from the 25 years of videotapes you're still trying to digitize before they rot into grey digital goo), sort out 400,000 family photos digitized and captured over the years, do your taxes, and write cool software for your new phone to sell online for enough profit to buy a stale gumball from a vending machine, you're going to have one hell of a home PC that will make the most high-end PC available today look like a Commodore 64. With liquid nitrogen cooling to keep it from causing a mini fireball (it only throws off 10 watts of heat thanks to miniaturization & efficiency, but those 10 watts are concentrated in an area the size of a poppy seed).
You forget, Americans are cowboys and pioneers -- neither of which are known for having respect for tradition or concern for what's happening after next year. Europeans hold meetings for 5 years, plan things in micro-managed detail, and roll them out over the next decade in a neat & orderly fashion, with the intent of keeping things unchanged for the next 10-100 years afterward. Americans do things the most expedient way possible to make it work *now* while spending as little money as possible, on the assumption that it's all going to be obsolete, trashed and replaced within a few years anyway. C'est la vie. Diff'rent strokes for diff'rent folks.
Case in point: WiMax (Sprint) vs LTE (Verizon, and eventually just about everyone else on earth). Sprint has nothing against LTE per se, besides the fact that they want a 4G network to brag about and claw ahead of T-Mobile and Verizon right now, and LTE would have meant having to wait another year or two. One reason why Sprint is so determined to get WiMax *now* was due to Qualcomm's decision to abandon EV-DV in favor of EV-DO(rev. A & B) "for now" and LTE "for later". The problem with EV-DO is that you can't have simultaneous voice and data with EV-DO, and Sprint knows quite well that T-Mobile is going to have a field day making sure everyone in America knows that Sprint & Verizon can't do voice and data at the same time. EV-DV would have allowed both, and Sprint wanted to skip EV-DO more or less entirely and go straight to it. Unfortunately, Qualcomm wasn't willing to go further developing EV-DV without the interest of at least one other major carrier (US, South American, Asian, or otherwise), and everyone else was content to live with EV-DO for now until LTE was ready.
Is it good or bad? The truth is, in America, it's neither good nor bad... it just "is". On one hand, by the time T-Mobile's new 3G service has filled in the worst of its remaining gaps and is the equal peer of Sprint & Verizon's current EV-DO service, Sprint will be bragging about its own new, faster, technically-superior network, and mercilessly beating up on Verizon with ads criticizing them for being unable to "talk and surf at the same time". On the other hand, 5-10 years from now, Sprint's decision will probably look kind of short-sighted when everyone else is using LTE... especially if there ends up being no graceful evolutionary path to migrate WiMax users to LTE, with both standards coexisting in the same spectrum for a decade or more.
Well, there's one problem with REQUIRING both 850 and 1700/2100 -- it costs more to make a phone capable of doing both. From what I've read, at worst, the only difference between a phone built for 1700/2100 and a phone built for 1900/2100 is a few passive component values determined at build time. At best, it's purely a matter of firmware and regulatory approval. On the other hand, a phone that does BOTH 850MHz *and* 1700&|1900/2100 needs two radio subsystems.
Going purely by engineering cost-benefit and completely disregarding matters of politics, the most sensible compromise would probably be for the FCC to require that any phone capable of 1900/2100UMTS *also* be capable of 1700/2100UMTS. As a practical matter, it would affect mainly AT&T and Apple. AT&T, because international compatibility is one of their selling points, so most of their phones support 850 and 1900/2100. Apple, because their phones have to work with AT&T and also work outside the US.
To keep things fair for AT&T, the FCC could try to come up with some rule that basically says, "If you make a phone that does 850MHz plus 1700/1900/2100, then turn around and try to disable the 850MHz via software or the omission of literally a few cents worth of passive components, it won't be approved". The problem is defining it in a way that would prevent a company like HTC from trivially disabling 850MHz support just to pacify T-Mobile, but wouldn't require that 850Mhz support be added to a handset that otherwise has no reason to support it. It's kind of like defining porn... any halfwit can look at something blatant, like a circuit board with missing components and a chipset spec'ed to do 850 and realize that something's rotten in Denmark, but it becomes a serious judgment call if eliminating those components genuinely enables some kind of improvement.
As for Sprint-vs-Verizon, THEIR forced incompatibility is just stupid. All the FCC would need to do in THAT case is prohibit Sprint from refusing to activate non-Sprint phones, and require both Sprint and Verizon to support phones with R-UIM cards. It wouldn't even have to go so far as to require that Sprint & Verizon sell phones that use R-UIM cards... just require that they allow otherwise-compatible phones that use them, and require that they sell the cards to customers who want to buy them. Knowing Sprint & Verizon, at first they'd probably charge $999 per R-UIM card or require a 10 year contract to get one. In the long run, neither Sprint nor Verizon really want to support them, but if they were both forced to do it, eventually they'd start using them to compete with each other. For now, they're still enjoying the final months of a decade-long data duopoly. With a little luck, by this time next year, T-Mobile will be a viable alternative to them in most parts of the US.
The problem with NGage is that 1) it sucked as a phone, and 2) it sucked even more as a videogame
Unfortunately, because it sucked and failed so spectacularly, mainstream companies like Samsung, HTC, and Motorola are all afraid to even let us have a phone with a real gamepad, let alone a (*shudder*) "gaming phone". Or, at least, their real customers (Sprint, Verizon, AT&T, and T-Mobile) don't want to risk selling anything that diverges from their current bland iSlab-like button-free touch-hell conformity.
I don't know how long it's going to be until we get to have a high-powered phone that doesn't completely suck for games, but I'm pretty sure about two things: it'll be Chinese, and it'll be running Android.
Why Chinese? Lower barriers to entry and staggeringly huge domestic market that will enable a company smaller than Nokia, HTC, Samsung, or Motorola to pull it off. Bringing a phone to market is no small feat, but doing it in a country that hasn't yet developed the vogue western fetish for industrial self-mutilation in the holy name of IP Law, with a billion local customers and widespread culture of commercializing mashups is almost guaranteed to be easier than doing it somewhere like the US, where half the carriers lord over their customers with an iron fist, and the other half bend over backwards to ensure that their phones won't work on a competitor's network.
Why Android? The same low barriers to entry. You can't sell phones running Windows Mobile unless you're big enough to get Microsoft's attention as a potential partner, and convince their receptionist that you're valuable enough to merit their expensive legal department's negotiation time. You can't sell phones running OS X unless your company happens to be Apple. LiMo is a serious possibility in China, but I don't even think LiMo's backers really expect it to prevail over Android forever.
So, there you have it. With a little luck, someday soon, a humble factory somewhere in a smoky Chinese city is going to make a really awesome phone with an 852x480 display to die for, the fastest multicore mobile CPU they can get their hands on, gigabytes of flash & sram, and a real gamepad. It will make its way around stores in China for months, until a few find their way into the US and someone from Gizmodo or another site happens to see one... at which point it will become the hottest import item in American cellphone history, simply because it will be so completely UNLIKE any of the bland, generic mass-market glass slabs sold by Tmo, AT&T, Sprint, or Verizon. 12 months later, iPhone fans will all be crying and making death threats against Steve Jobs, because even the iPhone 4+n will sport the heresy of a slide-out gamepad with (*gasp*) real buttons.
> Each of those versions would require separate FCC approval.
Not quote. There's no technical reason why a single phone approved by the FCC couldn't be used on both Sprint and Verizon, or on AT&T and T-Mobile... it's mainly the carriers' fault.
Basically, the FCC requires any phone with unique hardware and radio firmware to be tested & approved. Sprint won't allow its customers to use Verizon-branded phones, and Verizon won't sell phones that aren't built to be "Uniquely Verizon". Thus, it would almost be beyond pointless for a manufacturer to pay to get FCC approval for a generic CDMA phone, because Sprint wouldn't allow it to be used, and Verizon wouldn't buy a million of them to resell to its customers.
The AT&T/T-Mobile situation is a little blurrier. It appears that right now, AT&T has a company policy of refusing to sell phones capable of 1700/2100 UMTS, and T-Mobile has a company policy of refusing to sell phones capable of 850MHz UMTS. Neither company will actually stop a customer from buying one himself and sticking the SIM card into it, but the market (right now) for unsubsidized handsets in the US is somewhere between "barely relevant" and "all but nonexistent". As a practical matter, there are exactly two American customers that manufacturers like HTC, Samsung, Nokia, and Motorola care about: AT&T and T-Mobile.
Need more proof of corporate policy dictating handset frequency availability? Watch the FCC submissions logs. I can almost guarantee that there will be two distinct versions of the iPhone 4 submitted to the FCC -- one that does 850MHz and 1900/2100 UMTS, and one that does 1700/2100 and 1900/2100. What's really sad is that they'll both probably have the same hardware, and differ only in their radio firmware. It'll suck for everyone... Europeans will have to decide whether they'd rather roam on AT&T or T-Mobile when they visit the US, and American iPhones will effectively be locked to AT&T or T-Mobile -- at least, for anyone buying one to use in the US with 3G data.
> Blame North America for trying to be different there
It has nothing to do with "trying to be different", and everything to do with pre-existing services.
1900MHz was mostly owned by Sprint in America several *years* before UMTS was even an acronym, let alone a real service that existed anywhere in the world -- Europe or otherwise. T-Mobile owned a few slivers here and there (mostly in smaller cities), but most of THOSE slivers represented their *entire spectrum* within that market, and the frequencies were already being used for their existing GSM customers. In other words, from the perspective of any single carrier, there WAS no incremental transition path.
Interesting fact: T-Mobile's 1900 spectrum came from Voicestream. Voicestream was actually created by Sprint as a way to sell off excess 1900MHz spectrum it didn't need. However, Sprint wanted to make sure it would never be a serious competitor, so the spun-off company literally owned the bare minimum spectrum necessary for GSM voice service to work. At one point a few years ago, their spectrum shortage was so severe, there were actually markets where they weren't allowed to sign up new customers for a few months due to saturation problems.
Sprint? They owned lots of 1900MHz spectrum, but they had a similar problem to T-Mobile: there are a few markets around the US where they just don't own enough 1900MHz spectrum to deploy 1900/2100UMTS (with 5MHz channels) alongside their existing 2.5MHz CDMA2000 customers. Plus, when the 1700/2100 auctions took place 3 years ago, Sprint was low on funds, and would have had to buy 1700MHz spectrum they have no need for in addition to the 2100MHz spectrum.
Even if AT&T Wireless (and the companies it acquired along the way, like BellSouth Mobility/Cingular) had known that 1900UMTS was coming when the 1900MHz spectrum was originally auctioned off in the 90s, they wouldn't have been able to afford it, because they would have been bidding against Sprint -- a company whose entire business plan could have been summed up as, "Pay whatever it takes to own a chunk of spectrum everywhere in America". Not to mention the fact that when the 1900 spectrum was auctioned off, 2100MHz was still owned by the US military.
> from what I've read, until the iPhone came around developing apps for other phones was a huge PITA. > Android has since come out and provided probably the most open solution, but to say that other cell > phone makers made it EASY (to develop, deploy, etc...) prior to the release of the iPhone doesn't go > along with what I have read. Feel free to show me different though.
Er, ever hear about this obscure, fringe OS found on a few PDA phones called "Windows Mobile"? Granted, Windows Mobile phones have historically been dysfunctional as *phones* when powered up for the first time after purchase, but thirdparty apps like S2U2 and Winterface have done a lot to make them reasonably good. The day I decided to write my first Windows Mobile app, it took me maybe an hour to go from 'nothing' to 'running on my phone' (half of which was spent downloading the SDK from MSDN). A couple of days later, I had an app playing avi videos on my phone with a complete UI.
Microsoft might be generally incapable of creating a phone UI for people who want to dial with their fingers (instead of a stylus) and carry the phone in their back pockets, but Microsoft's role in going to war with the carriers to ensure that we could have a phone with completely unrestricted API that was beyond the carriers' control is hugely under-appreciated. Not even Verizon could permanently cripple its Windows Mobile phones (Microsoft sighed and let them ship with features disabled in the registry... but anyone with 3 brain cells and the slightest bit of motivation could figure out how to re-enable them 10 minutes after purchase).
The only "3G" capability I personally care about is a tablet's ability to tether to my rooted Android phone via 802.11 or Bluetooth and leech its internet connectivity for free when a better Wifi access point isn't within range. The day I can add a tablet to my phone's data plan as a second device for less than $5/month, I *might* contemplate paying more money to Sprint for the convenience. Until then, I have ~5GB/month to burn through, and a wirelessly-tethered PadPC would be a great way to work towards achieving that goal.
GPS would be nice... but really, I already have an Android phone with perfectly good GPS of its own. If the tablet can wirelessly tether to my phone to leech its data, there's no reason why I can't just install a host app on my phone that lets the tablet leech its location services, too. Let's be honest... how often am I *really* going to find myself in a situation where I have my tablet, but my phone isn't within Wifi or bluetooth range? Even in my car, my phone is going to be somewhere nearby, more or less perpetually aware of its location anyway.
I won't buy a tablet that's locked down to run only "approved" software. Nor, for that matter, will I buy a tablet that effectively prevents me from updating its OS as I see fit (I might bend the rule if I can root it and do what I please despite the manufacturer's best efforts, but it would still be a major strike against it).
I want at least four real, tactile hardkeys that aren't matrixed & can be read in any combination -- two on each side (when held in landscape orientation), positioned where my thumb would naturally land. Why four? As long as they're independently readable, you can chord them and use them to shift each other (example: press and hold left1, press right 2 twice, press and hold right 2, release left 1, release right two).
I want "touch strips" on the 4 bezels for easy scrolling... but I want them to be completely independent of the main digitizer so they can be selectively ignored when appropriate.
Spec-wise, give me a 1280x800 or 1366x768 color screen with wide viewing angle. It's small enough to be easily handled, but high enough to comfortably read the text content of two Manning-sized pdf pages side by side (in landscape orientation) if they're zoomed in slightly to eliminate most of the whitespace around each page's text.
What would I use a tablet for? Mostly ebook reading at home, as an interactive GPS navigator in the car, as a photo album, and a ghetto web browser when I'm watching TV in the living room. Paired with a bluetooth IR remote control beacon, it would probably make a nice home theater remote control, and be great for home automation in general.
Give me a full-sized usb slot that can host USB thumb drives... and boot from them, if I happen to build my own Linux for it. Give me two bootable SD card slots as well... one for the OS, one for my data. If space is really an issue, make one of them microSD. Just make sure that at least one of the full-sized SD slots is physically located somewhere appropriate for SDIO peripherals.
For god's sake... put a camera on the front. It doesn't have to have gigapixel resolution... 640-852 x 480 resolution is fine. That one feature, if nothing else, won't just make it cool for videoconferencing... it will practically guarantee that every deaf person in America will end up owning one within a matter of months. Not to mention useful perks like face recognition for autoconfiguration.
Give it some kind of kickstand, so I can prop it on a table, plug it into my laptop's USB port to use as a second monitor when I'm visiting my parents. Or use it with a bluetooth/usb keyboard and/or mouse with it and run it as a low end laptop in its own right, or maybe as a RDP client. Just make sure the USB port is located on one side or the top, so it won't get in the way when I pop out the kickstand and prop it up on the desk/table next to my laptop.
> There's also questions relating to what happens when a v6 address hits higher-level software due to their no longer using just digits and dots
Reverse-NAT. Basically, you have a translation gateway sitting between the IPv6 network and IPv4 network that allocates an IPv4 address from its pool, and makes a note to associate it with the real IPv6 address. For example, 2001:6969::100 might be mapped by it to 192.95.17.9. You'd tell your IPv4-aware app to connect to 192.95.17.9. The translator sees the outbound datagram, recognizes its address as a mapped alias, rewrites the datagram in IPv6 format with a destination address of 2001:6969::100, and sends it on its way. Inbound datagrams from 2001:6969::100 get rewritten from IPv6 format to IPv4 format the same way, with 192.95.17.9 as the faux source address. There are three main problems that have to be addressed: availability, persistence, and global-applicability.
The first is scalability and security (listed together because the more secure you make it, the less scalable it's going to be in real-world use). It's not really practical to do this kind of translation at the backbone or enterprise level, because 1) the mapping table would rapidly become huge to the point where it literally became an architectural chokepoint, and 2) it would be trivially easy to launch denial-of-service attacks against everyone who depended on that translator by simply flooding it with requests to overflow its buffers. You COULD try to partition it off and implement security, but this is one of those times when it's easier and more reliable for everyone overall to just limit the scope of collateral damage and move responsibility for the 4-6 translation to a more local layer... like a home router, or even the operating system's network stack. When every microsecond counts, you just can't stop to scrutinize every request passing through the router. At least, not cheaply. My own prediction is that this function will fall to the future equivalent of a home or small office's router. If denial of service attacks become a real problem, you'll probably see low-end routers simply divide the network into two groups: those with IP addresses for which translation will be done (ie, older embedded devices that can't easily have the network stack replaced), and those that are on their own and will be simply ignored if they ask for translation help (ie, any PC running Windows, Linux, OS-X, etc) -- with possible partitioning of mapping resources for the few devices left that genuinely need the router to do the job for them.
OK, the next problem: persistence. Put another way, if the router or software stack maps 2001:6969::100 to 192.95.17.9, how long does it need to remember that mapping... and how will it actually store it if necessary? I'm going to guess that the first home translating routers will basically treat this task the way port mapping to internal private addresses gets handled now: you'll have to go to the router's admin app, and manually set up any 4-to-6 mappings you need to have persist. Everything else (like web surfing) will just be done dynamically, with persistence that's at least long enough to last between datagrams, but not necessarily day to day. Say, 10-30 hours. A pain, but then again... how many different raw IP addresses do you REALLY deal with directly behind any given router today? Remember, we're talking about raw addresses that have to persist indefinitely for your future reliable use, not the cached results of a dns lookup.
That brings up the third, and stickiest problem that has no good solution right now: global applicability. For the classic acid test, just look at h.323. It's been a nightmare to NAT ever since day one, because it encodes (what it believes to be) its IP address in the data itself. The problem being, without an intelligent application-level gateway, the recipient PC ends up seeing a return address that can't actually be reached directly. Personally, I think this is another one of those issues that will get swept under the rug out
After reading more over the past couple of days, I'm increasingly convinced that this is what's likely to happen:
1. It will become nearly impossible to get a real, publicly-routable static IPv4 address for your own exclusive use if you're a residential customer.
2. Anyone with cable or DSL and a pulse will be able to get a/60 IPv6, probably a/56, possibly a whole/48. That same group might (especially at first) get fractional ownership (say, 16-32 permanently-forwarded ports) of a semi-static IPv4 address (one whose stability isn't guaranteed, but will mainly change every few weeks as the ISP defrags its allocation database).
3. Residential customers who've gone to the trouble of getting a static IP *today*, and small businesses, will normally get a/48 (at worst, a/56), and fractional ownership of a public IPv4 address that might change once or twice per year... but if it does, the changeover time will be scheduled and known in advance.
4. 4to6 gateway-routers will largely hide the IPv6 network on the "public" side of residential networks from anyone who doesn't intentionally seek to access it "natively". The first "real" IPv6 applications will be online games, for the simple reason that they're the #1 commercial reason why residential users will care about direct endpoint connectivity. Running next to them will be P2P... especially if it takes a while for the MAFIAA to discover the existence of IPv6 P2P.
5. Publicly-accessible servers will have plenty of IPv4 addresses to go around for the rest of our lives. Why? The same reason why it's easy to get phone numbers in the 212 (Manhattan) or 305 areacodes (Miami) today, even from VoIP services that didn't exist until recently, despite panic 10-15 years ago that the numbers were all going to run out. People abandoned pagers, second phone lines used for faxes & modems, and relaxed numbering rules added thousands of new numbers that previously weren't allowed (ie, 305-nxn-nnnn, where x=0 or 1). At the same time, the newer areacodes became the default unless you went out of your way to get an older one. The same thing is going to happen to public IPv4 addresses. ISPs will slowly start charging more for them (especially for users who want a LOT of them), and over time businesses will start to question why they're even bothering to still pay for IPv4 addresses they haven't really needed since anyone can remember. The charges don't even have to be that high... merely visible as line-items on the bill.
Reclaiming a few legacy Class-A blocks, or even a chunk of class E (in the longer term) might "only add a few weeks" at THIS point, but adding them at a future point when demand itself has either flattened or begun to decline might very well add enough for "decades". I'll even predict a HUGE fight 5-20 years from now when someone notices that more than half the IPv4 pool has been effectively abandoned, and proposes defragging it to clean up and simplify routing... and ends up triggering one last fight between the group that wants to clean it up a bit and the still-angry group that wants to banish it forever and eliminate it immediately. The end result? IPv4 will spend the next hundred years following in the footsteps of America's passenger rail system... limping along, never really being killed, but not really properly maintained, either... just abandoned in chunks as parts become too broken to ignore, but not valuable enough to fix.
IMHO, the people pushing the hardest for "IPv6 now, at any cost!" are revolutionaries in the true sense. They don't WANT a smooth, painless transition that barely gets noticed by end users as IPv4 fades into a long sunset with a yawn. They dream of flipping a magic switch that instantly breaks 99% of the internet as we know it (especially the "unimportant" parts running Microsoft operating systems), and forces everyone to spend a month doing whatever it takes to get back online via the One True Way: IPv6. What t
The OS might support IPv6, but the apps have to support it too, or the OS itself is going to end up doing something like I described above. IPv4 apps aren't going away anytime soon, and any attempt to force the issue by intentionally breaking them will just incite user rebellion. Yes, it's a complicated router-based solution... but routers are cheap. By making the "outside world" look more or less exactly like it does now via a more sophisticated router doing inverse NAT, you're enabling everything on the inside network to remain exactly like it is, for as long as whomever's in charge wants to leave it that way. The network can evolve over time, until the translation becomes more of an annoyance than a convenience. The OS can tell IPv6-unaware apps that the computer's IP address is 192.168.100.101. It can tell IPv6-aware apps that the computer's address is 37a1:de19:7f9b::101. Both can happily coexist.
IMHO, the zeal of IPv6's supporters is one of the things that's killing it. They're not content to merely hand users vast amounts of address space & the freedom to use it... they're going to MAKE them use it, at metaphorical gunpoint if necessary, and FORCE them to like it. Just look at what happened with DHCP6. The IPv6 Elite were determined to be like French Revolutionaries, and banish anything as politically incorrect as NAT, regardless of whether or not people tended to like it because it accidentally solved a problem it was never intended to solve (blunt firewalling and keeping Windows safe from the outside world).
Look at it this way: if routers did something like this, routers could be made that would register with the ISP and accept EITHER an IPv4 address OR an IPv6 site prefix... and configure themselves accordingly. If every router sold for 2 or 3 years did this, the exact day an ISP (or the world) switched from IPv4 to IPv6 would be about as significant as the day most of the TV stations in America switched from NTSC to ATSC -- a yawn-worthy non-event most people wouldn't even notice (because everything on the 'local' side of the box worked exactly the same as it did the day before).
Is there any physical reason why a router couldn't do the following to transparently enable ipv6-oblivious software to effectively "inverse-NAT the rest of the world"?
1) Connect, and note the/48 assigned to the site by the ISP (for this example, let's say (37a1:de19:7f9b/48).
2) To the inside network, the router looks just like any other ipv4 router. For the sake of argument, let's pretend it's allocating ip addresses 192.168.100.100 to 192.168.100.199 via DHCP
3) A desktop PC on the local network asks the router for an IP address. It gets 192.168.100.101.
4) That desktop PC later sends a request to fetch http://www.slashdot.org./ The router intercepts the DNS request.
5) The router does the dns lookup, and discovers that Slashdot's IPv6 address is 2005:1234:5678:1::1.
6) The router makes up a fake ipv4 address. To do so, the router declares 10.0.0.0/8 to be off-limits for use on the local network as a local address so they can be hijacked for this purpose, instead. It picks one -- 10.5.17.88 -- then makes a note to itself that it expires in an hour, and answers the DNS query from the local PC: Slashdot's IP address is 10.5.17.88, with TTL=60 minutes.
8. The router sees the outbound datagram with a 10.0.0.0/8 address. It does a quick lookup from its own local table, and sees that the real ipv6 address is 2005:1234:5678:1::1. It proceeds to send a fake ipv6 request to 2005:1234:5678:1::1 that appears to be from 37a1:de19:7f9b:1:6969:0192:0168:0100:0101. Yeah, the lower 64 bits completely stomp on the intent of every ipv6-related RFC, not to mention inefficiently maps decimal octets to 16-bit values for the sake of human-readability. Deal with it. It works anyway, and makes life a little easier during the transition.;-)
9) Slashdot's server receives the request from 37a1:de19:7f9b:6969:192:168:100:101, and sends the response.
10) The router gets the datagram. It sees the 6969 (a value dictated by the router that might very well be randomly pulled out of a hat), which confirms to it that the lower 64 bits contain the local ipv4 address encoded in human-readable form. It rewrites the datagram, and passes it along to the local network.
11) The local PC gets its response from 10.5.17.88, and never knows the difference.
The router would need a big chunk of ram to keep track of the kludged dns lookup table, and would have to do more than routers do now to keep up the facade of an ipv4 universe for blissfully-oblivious clients on the inside... but it seems like it would nicely solve the problem of ipv6-unaware software by giving end users another decade or two to sidestep the problem. Their "real" ip address (site network) would be ipv6, but everything that's ipv6-unaware would be able to think it was really sitting behind a public ipv4 address.
For an added level of security (making it harder for random traffic from the outside to directly reach inside hosts), instead of picking a value like '6969' for the fourth 16-bit chunk, it could pick a new random value every hour, use it to XOR the lower 64 bits, and use THAT value for the fourth chunk. When incoming requests came in, it would xor the lower 4 16-bit chunks against its current random value, and compare it to the value presented as the fourth chunk. If it didn't match, it would try again with its previous random value. If it found a match, it would pass it along as per step 10. Otherwise, it might variously refuse the connection, return random junk, silently ignore it, and/or blackhole that IP's source network for some period of time to protect itself.
For hosts intended to have direct accessibility from the outside, the fourth chunk might have a different interpretation. For example, using 0xf as the high 4 bits to flag it, and the lower 12 bits of chunk #4 to indicate the port. So if the local PC whose ip a
> I guess we were paying $99 for the QC sticker they put on it before they sent it off through the supply system.
Actually, there's a very good real-world example of a cheap electronic component that nevertheless can be very expensive when its quality is absolutely certified: electrolytic capacitors. Today, in 2010, brand new devices are STILL being manufactured with electrolytic capacitors that have substandard electrolyte. This is a problem that was supposed to have gone away YEARS ago. Why is it still around? Because the bad electrolyte is a tiny, tiny bit cheaper to make... and the capacitors tend to work just fine for at least a few months. In other words, they fail prematurely... but not immediately.
If you're building something that absolutely, positively, must NEVER use an electrolytic capacitor with bad electrolyte, you have no real option besides buying only capacitors that are certified (and can be audited) all the way from you (the company building the device that uses them) to the chemicals used to make the electrolyte itself. It's not enough to buy "a good brand". To get that level of certification, every party along the way -- distributor, wholesaler, supplier -- has to be certified capable of keeping them secure and properly stored. Otherwise, an employee (or manager, or higher) at the supplier could substitute counterfeit capacitors, then sell the genuine ones elsewhere.
The point is, that degree of auditing and handling is insanely expensive, because it involves SO MANY different parties (all of whom want to be reimbursed for the extra trouble). It's made more expensive by the fact that there are (fortunately) very few things that really NEED that kind of quality control. Life support equipment and nuclear power plant control systems are obvious excamples where it's justified, costs be damned.
That said, this particular device isn't life support equipment, regardless of how hard someone might try to make it sound like the tiniest malfunction would lead to death or injury. I think it's safe to say that this particular device's price is all but guaranteed to come down a few thousand dollars if they want to keep selling it.
> If you happen to live in these flood prone locations there are two choices: > a) Fix the entire world to stop rising waters ---- not likely. > b) MOVE to higher ground.
You forgot option 'c' --
c) Make the ground you already own a foot or two higher.
A hundred years ago, the land my house sits on (western Pembroke Pines, Florida) was theoretically (if not actually) underwater a few months per year. It wasn't swamp... it was outright, honest-to-god 'Everglades'. Yet, talking to my neighbors, the neighborhood has never flooded -- or even came close to it -- in ~30 years.
Why?
The big dike a few miles west, and the huge drainage canals everywhere obviously help... but there's another factor: the developer turned the low-lying areas into deep lakes, and used the debris to raise the surrounding area. So... when we have a really bad (read: daily) summer downpour, the water runs into the storm drains, then gets dumped a few hundred feet away in those same lakes.
The work quite well. Last month, large parts of South Florida were flooded for a day or two after massive downpours that dumped more than a foot of rain. We barely even had puddles on the roads.
Media propaganda to the contrary, FEMA doesn't just dump money into low-lying areas. If you build a house in a floodplain and it gets flooded, FEMA (as a condition of making flood insurance available to an area) requires that the local government pass laws requiring rebuilt homes to have their lowest habitable floor a couple of feet above the "500 year" water level. You can buy landfill to raise your lot's height, you can build on pilings, or you can take the insurance money and head for the hills. What you *can't* do is put yourself in the exact same situation you were in beforehand.
Over time, economically valuable parts of low-lying cities will get rebuilt on pilings. Over the next 25-50 years, the roads get rebuilt higher, with better storm drains and stormwater retention ponds.
The controversy in New Orleans is that people in the flooded areas wanted special treatment & exemption from the rules -- to which FEMA firmly said, "No. You'll rebuild on pilings, or you won't rebuild. This isn't oppression by The Man... it's common sense."
My prediction: the poorest, lowest-lying, most destroyed parts of New Orleans that aren't likely to be rebuilt anytime soon will sit vacant for a few years, until property values rise high enough for large corporate developers (Toll Brothers, Lennar, etc) to start quietly buying up large tracts of low-lying land. Once they own enough, they'll do the same thing there that they've done in Florida: dig a deep lake and/or surround the new community with a moat^h^h^h^h linear retention pond, build new concrete storm drains and streets above the historical flood level, then backfill the remaining area & turn it into expensive waterfront suburbia.
Want to know what future coastlines in areas supposedly vulnerable to rising sea levels will look like? Go to South Beach. Most people don't even REALIZE it until you point it out to them, but it's actually surrounded by a huge dike -- the artificial dunes built as part of the beach renourishment program in the 80s and 90s, and the streets along the island's perimeter that have been progressively raised during widening and reconstruction to form de-facto dikes. Ditto, for Miami's bayfront neighborhoods.
The strategy is simple: raise the roads, and let the wealthy property owners on the lower waterfront side worry about raising their own property level when they end up rebuilding -- possibly due to storm damage, more likely due to bulldozing away the older single-family homes and replacing them with skyscrapers. Any time a road in Florida gets widened, it almost always gets rebuilt a foot or two higher than it used to be. Stir, rinse, repeat for a hundred years, and by the time the sea level rises enough to flood areas that are dry today, hardly anyone will even notice. The areas that flood will have been floodin
You're forgetting that GSM/UMTS phones won't do 3G on any network in America unless they happen to support 850/850 or 1700/2200 uplink/downlink. AFAIK, the US is the only country on earth that does 850/850 and 1700/2200 UMTS. I don't even think *Canada* uses those frequencies. For all intents and purposes, the only phones that support 850/850 UMTS are sold by AT&T Wireless, and the only phones that support 1700/2200 are sold by T-Mobile. So much for interoperability. A "global" phone that supports only 1900/2100 UMTS will give you blazingly-fast 19.2kbit/sec GPRS in America (or serve a more useful purpose as a paperweight in windy weather).
It's sad, but right now, Verizon is ironically the most interoperable carrier in America, just because you can theoretically reflash the Sprint twin of a Verizon phone with Verizon firmware and they'll let you use it if you can figure out how to do it on your own, without any help from them. It's a piss poor, sad excuse for interoperability, but just goes to show how dire the wireless situation *is* in the United States.
> Same here. Born in the USSR in mid-80s, and I've first seen a PC (which was also the first programmable computer to me) in 1995. > Cellphones came a lot later, too - I've only got a personal one in 2000.
Don't feel bad... most AMERICANS didn't get THEIR first cell phones until ~1999 (give or take a year), either.:-)
Cell phones EXISTED in the US as early as ~1982, but you had to be *incredibly* wealthy (as in, "Donald Trump wealthy") to own one before 1990, and they were still pretty expensive until the VERY late 90s. Also, "national coverage" was more of a marketing slogan than a reality. As late as 2001, I went to Dallas for the weekend with some friends, and remember at least one who couldn't use his (AT&T Wireless) phone there without paying ridiculously expensive daily and per-minute roaming charges. Back then, if you wanted to travel without getting financially raped & have your phone "just work" wherever (urban) you went, you basically had two choices: Sprint and Verizon. Sprint was (relatively) cheap, but had mediocre coverage in most places (ie, your phone usually had service, but you often had to go outside or stand by a window to make an actual call). Verizon had better coverage, but cost twice as much. T-Mobile was still a patchwork of regional GSM-based companies (Voicestream, Airtouch, etc), and AT&T (before they bought BellSouth Mobility, changed their name to Cingular, and began switching to GSM) merely had nationwide seamless analog roaming & billing agreements with other regional companies... as long as you bought a phone that did analog *AND* TDMA(digital). Lots of people in big cities (like Miami) found out the hard way that smaller, "pocket-sized" TDMA-only "flip phones" didn't work well (or at all) in rural areas (like the 25-40 mile radius "digital dead zone" that used to exist halfway between Miami and Orlando).
I beg to differ. Wire hangers are a universal building supply and tool, proudly serving next to duct tape and WD-40 as a universal tool and replacement part. Unlike any wire you can buy at Home Depot (at least, for less than $1/foot), clothes hangers are made from nice, stiff wire that can be bent into custom shapes without losing much of its strength in the process.
I shudder to think of what I'd have to do if I accidentally dropped something important (like keys) into a dirty toilet and didn't have a supply of wire hangers available to form into adhoc fishhook or tongs. If you're so green, PLEASE don't tell me you actually do something as environmentally incorrect as use wood paddles to stir paint. Use a repurposed metal coathanger, instead! After all, few things are more green than 'adaptive reuse' -- and few things are as suitable for wholesale daily adaptive reuse as metal clothes hangers!:D
> I'm not 100% on this, but I believe the Y2K mess didn't effect Unix-y systems at all. The way Unix time works, > if you're not familiar, is that it just counts the seconds after the epoch. Whether the year is represented as two > of four digits doesn't matter, and doesn't cause problems.
Remember all of the Perl-based CGI wishing you a Happy New Year on January 1, 19100? I have old books in a box somewhere from *1997* with sample code telling users to print "19" then append the year value. It affected lots of programs that used the Perl functions that returned bits and pieces of the date, instead of printing it as a complete whole (which handled things correctly).
^^^ argh. I forgot Slashdot doesn't transparently handle less-than and greater-than characters, even in "Plain old Text" mode. The offending instruction should read "move SR, (ea)" (substituting greater-than and less-than for parentheses).
If I could go back in time and make just one change to the Amiga, it would be to have ensured that the A1000, or at least the 500 & 2000 onward, had a 68010 instead of a 68000. Nothing, and I mean *nothing*, caused more software to crash and burn on Amigas with 68020+ microprocessors than the damn Move SR, instruction (privileged on everything from the 68010 onward, but nonprivileged on the 68000 -- and used by just about every Amiga copy protection scheme.) From what I remember, a 68010 cost a whopping $10 back around 1988. In "Commodore quantities", it probably would have cost a buck or two more than a 68000, and would have made it a lot easier for Commodore to sell higher-end Amigas with greater markup.
Slashdot Mirror
From what I've read, Maemo suffers from the same problem that's always plagued Windows Mobile -- it's a great OS for a pocket-sized laptop, but it's not exactly the greatest user environment for making and receiving actual, voice phone calls.
Compare the way Android handles incoming phone calls to the way Windows Mobile and Linux in general do. When Android notices an incoming phone call, it instantly suspends the foreground app and devotes its full attention to handling that incoming call immediately. In start contrast, Windows Mobile and Linux (in general) regard an incoming call as just another event, neither more nor less inherently important than anything else. Well, ok... maybe a LITTLE more important, but with both WinMo and a traditional Linux kernel, you ARE going to end up with situations where an incoming call ends up going to voicemail because the system decided it was just too busy doing something else to deal with the call right that instant.
If the user thinks incoming calls are no big deal, they'll prefer the way WinMo and Linux work. If a user thinks an incoming call that ends up going to voicemail despite his best efforts is a catastrophe, he'll prefer the way Android works. I don't personally know Linus, but I've definitely gotten the impression that he falls into the "do whatever it takes to make the phone first and foremost work flawlessly as a phone" camp. Who knows, it might have even been something as trivial as Linus picking up a friend's N900 with one hand, trying to bring up the phone directory using only his thumb, being unable to guess how to make it happen in 2 seconds, and deciding it just wasn't the paradigm he was looking for.
> Hardly. Nobody's forcing you to run their binaries on your phone.
Verizon customers with a Droid Eris might beg to differ. http://forum.xda-developers.com/showthread.php?t=617203
> Of course it's bad: cell phone service in the US is expensive,
For people who make 5 minutes worth of outgoing calls per month? Yeah. For people who use slingbox to stream videos from their livingroom DVRs, or use their home PC via remote desktop from a laptop tethered to their cell phone? It's dirt cheap. You could probably fit every European who's used Slingbox for more than 5 minutes in the dining room of a small McDonalds. Americans bitch about the threat of getting dropped as a customer for using more than 5GB of wireless data per month. I shudder to think of how much 5 gigabytes of wireless data use would even COST anywhere in Europe.
> has poor coverage,
Compared to Finland, Belgium, or the Netherlands? Maybe. Compare T-mobile's 3G coverage in the rural parts of Britain to Sprint & Verizon's 3G coverage in rural parts of the US, and it's almost dead even. Factor out any patch of land more than a hundred miles from the nearest city with at least 100 residents (ie, most of the western US desert), and the US probably comes out ahead. If you want to be fair and compare "apples to apples", compare T-Mobile's 3G coverage map for Florida to T-Mobile's 3G coverage map for Britain. Especially in the more suburban and rural areas, their Florida 3G coverage would probably make more than a few of their British customers jealous.
> is monopolistic,
Change it to "a pair of duopolies", and I'll generally agree.
> and is less technologically advanced than it is in Europe.
No, it's not. Today, with UMTS (in areas with 3G coverage), Europeans finally get to enjoy the soft hand-offs, diveristy tuning, and superior audio fidelity of CDMA that American Sprint and Verizon customers have been enjoying for more than a decade. Amplified speakers didn't start making "GSM Noise" until, er, GSM became common here.
For the most part, the only thing that really sucks about American cell phone companies is the fact that they're such assholes about trying to turn every handset into a mini-monopoly.
> And how is Android not open? The entire thing is FOSS
(cringes, wrings hands for a while, coughs a bit, then sighs)
"Android" might be "open", but people fighting on the Android front lines and trying to run open builds without the blessing of HTC and their carrier might politely beg to differ. To date, nobody has been able to independently build a fully working 2.6.29 kernel for ANY CDMA Hero phone that shipped with Android 1.5 (Sprint Hero, Sprint Samsung Moment, Verizon Droid Eris). Without a 2.6.29 kernel, major parts of Android 2.x won't work properly. Work is underway, but the fact is, right now... today... my Sprint Hero is running a hacked-up build that can be described as a liquefied Cupcake injected into the clay mock-up of an Eclair facade. And I'm "lucky" -- my other CDMA Android 1.5-shackled brethren can't even do *that*.
Right now, the cruel reality is that people who buy many Android phones are kind of like consumers who bought a very, very proprietary Packard Bell or HP computer in the mid/late-90s. If the manufacturer didn't feel like supporting Windows NT or Linux, you were basically screwed. You couldn't just download OEM drivers, because they didn't exist -- the company who sold the computer WAS the OEM. Open-source drivers didn't exist, because the hardware itself was built around proprietary ASICs designed for that specific manufacturer.
OK, let me make the analogy a little better: it's 2000, and you need to buy a new laptop. Your ISP allows you to choose between exactly two laptops, both sold only by the ISP itself with a 2-year contract that has a substantial penalty for early termination. Your ISP personally knows the MAC address of the network interface for every computer it sells, and refuses to accept network traffic from any network interface whose MAC address isn't in its holy database. It's not necessarily *impossible* to spoof an official MAC address with an unapproved laptop, but it happens to be a major federal offense that can be prosecuted as an act of terrorism, narcotics distribution, or organized crime. The laptops are only available with an old, obsolete distro of Linux that's proprietary to the laptop's manufacturer, and the hardware drivers are all compiled straight into the kernel (which happens to be 2.2, even though 2.4 has been considered mature enough to use for at least the past 6 months). Oh, the source? You won't see it until 4-6 months after you buy the laptop -- if you're lucky -- and the code for the proprietary hardware will be obfuscated & devoid of comments.
Welcome to the brave new world of Americans who buy Android phones in 2010, where "open" phones have to be hacked & rooted to allow upgrades, and it's easier to upgrade an old phone to a newer version of Windows Mobile than it is to upgrade a 4 month old Android phone to a newer version of Android.
> since yes, the desktop is going away,
Oh pleaze. For all the buzz about "the desktop going away", the number of desktop computers seems to just keep growing. Homes that had one PC now have two. Or three. Individuals who had their own now have their own desktop PC and a laptop (or at least a netbook, which contrary to its name seems to end up spending at least as much "on" time doing stuff a few thousand feet above sea level, inside flying aluminum cylinders that are one of the last frontiers where internet access is still rare and expensive). Most of the people "making do" with a laptop as their only computer are people who formerly had no computer at all. The people who owned computers 15+ years ago won't give up their desktop until laptops routinely come with dual 24" displays and quad+core CPUs.
Cloud computing is the new paperless office. As more than a few have observed over the years, the paperless office was officially welcomed 15 years ago, yet 21st-century offices still seem to somehow generate at least twice as much printed output per employee as they ever did in the dark ages. The main difference is that back then, the paper copies were carefully stored in file folders for future reference. Now, they're stored in the SAN, and four dozen copies get casually printed on demand so everyone can pretend to read them at the weekly status meeting & use them to scribble notes on before tossing them all in the big blue bin after lunch. I'm quite confident that when the day arrives that I have a hundred terrabytes of data stored "in the cloud", I'll have at least ten times as much physically present within my home.
Desktops aren't going away anytime soon, any more than TVs with eight-foot screens are going to be displaced by personal media tablets. They might end up mutating into our own personal faux-clouds, perpetually connected to our PadPCs and phones, but at the end of the day, when you need to edit video (from the 25 years of videotapes you're still trying to digitize before they rot into grey digital goo), sort out 400,000 family photos digitized and captured over the years, do your taxes, and write cool software for your new phone to sell online for enough profit to buy a stale gumball from a vending machine, you're going to have one hell of a home PC that will make the most high-end PC available today look like a Commodore 64. With liquid nitrogen cooling to keep it from causing a mini fireball (it only throws off 10 watts of heat thanks to miniaturization & efficiency, but those 10 watts are concentrated in an area the size of a poppy seed).
You forget, Americans are cowboys and pioneers -- neither of which are known for having respect for tradition or concern for what's happening after next year. Europeans hold meetings for 5 years, plan things in micro-managed detail, and roll them out over the next decade in a neat & orderly fashion, with the intent of keeping things unchanged for the next 10-100 years afterward. Americans do things the most expedient way possible to make it work *now* while spending as little money as possible, on the assumption that it's all going to be obsolete, trashed and replaced within a few years anyway. C'est la vie. Diff'rent strokes for diff'rent folks.
Case in point: WiMax (Sprint) vs LTE (Verizon, and eventually just about everyone else on earth). Sprint has nothing against LTE per se, besides the fact that they want a 4G network to brag about and claw ahead of T-Mobile and Verizon right now, and LTE would have meant having to wait another year or two. One reason why Sprint is so determined to get WiMax *now* was due to Qualcomm's decision to abandon EV-DV in favor of EV-DO(rev. A & B) "for now" and LTE "for later". The problem with EV-DO is that you can't have simultaneous voice and data with EV-DO, and Sprint knows quite well that T-Mobile is going to have a field day making sure everyone in America knows that Sprint & Verizon can't do voice and data at the same time. EV-DV would have allowed both, and Sprint wanted to skip EV-DO more or less entirely and go straight to it. Unfortunately, Qualcomm wasn't willing to go further developing EV-DV without the interest of at least one other major carrier (US, South American, Asian, or otherwise), and everyone else was content to live with EV-DO for now until LTE was ready.
Is it good or bad? The truth is, in America, it's neither good nor bad... it just "is". On one hand, by the time T-Mobile's new 3G service has filled in the worst of its remaining gaps and is the equal peer of Sprint & Verizon's current EV-DO service, Sprint will be bragging about its own new, faster, technically-superior network, and mercilessly beating up on Verizon with ads criticizing them for being unable to "talk and surf at the same time". On the other hand, 5-10 years from now, Sprint's decision will probably look kind of short-sighted when everyone else is using LTE... especially if there ends up being no graceful evolutionary path to migrate WiMax users to LTE, with both standards coexisting in the same spectrum for a decade or more.
Well, there's one problem with REQUIRING both 850 and 1700/2100 -- it costs more to make a phone capable of doing both. From what I've read, at worst, the only difference between a phone built for 1700/2100 and a phone built for 1900/2100 is a few passive component values determined at build time. At best, it's purely a matter of firmware and regulatory approval. On the other hand, a phone that does BOTH 850MHz *and* 1700&|1900/2100 needs two radio subsystems.
Going purely by engineering cost-benefit and completely disregarding matters of politics, the most sensible compromise would probably be for the FCC to require that any phone capable of 1900/2100UMTS *also* be capable of 1700/2100UMTS. As a practical matter, it would affect mainly AT&T and Apple. AT&T, because international compatibility is one of their selling points, so most of their phones support 850 and 1900/2100. Apple, because their phones have to work with AT&T and also work outside the US.
To keep things fair for AT&T, the FCC could try to come up with some rule that basically says, "If you make a phone that does 850MHz plus 1700/1900/2100, then turn around and try to disable the 850MHz via software or the omission of literally a few cents worth of passive components, it won't be approved". The problem is defining it in a way that would prevent a company like HTC from trivially disabling 850MHz support just to pacify T-Mobile, but wouldn't require that 850Mhz support be added to a handset that otherwise has no reason to support it. It's kind of like defining porn... any halfwit can look at something blatant, like a circuit board with missing components and a chipset spec'ed to do 850 and realize that something's rotten in Denmark, but it becomes a serious judgment call if eliminating those components genuinely enables some kind of improvement.
As for Sprint-vs-Verizon, THEIR forced incompatibility is just stupid. All the FCC would need to do in THAT case is prohibit Sprint from refusing to activate non-Sprint phones, and require both Sprint and Verizon to support phones with R-UIM cards. It wouldn't even have to go so far as to require that Sprint & Verizon sell phones that use R-UIM cards... just require that they allow otherwise-compatible phones that use them, and require that they sell the cards to customers who want to buy them. Knowing Sprint & Verizon, at first they'd probably charge $999 per R-UIM card or require a 10 year contract to get one. In the long run, neither Sprint nor Verizon really want to support them, but if they were both forced to do it, eventually they'd start using them to compete with each other. For now, they're still enjoying the final months of a decade-long data duopoly. With a little luck, by this time next year, T-Mobile will be a viable alternative to them in most parts of the US.
The problem with NGage is that 1) it sucked as a phone, and 2) it sucked even more as a videogame
Unfortunately, because it sucked and failed so spectacularly, mainstream companies like Samsung, HTC, and Motorola are all afraid to even let us have a phone with a real gamepad, let alone a (*shudder*) "gaming phone". Or, at least, their real customers (Sprint, Verizon, AT&T, and T-Mobile) don't want to risk selling anything that diverges from their current bland iSlab-like button-free touch-hell conformity.
I don't know how long it's going to be until we get to have a high-powered phone that doesn't completely suck for games, but I'm pretty sure about two things: it'll be Chinese, and it'll be running Android.
Why Chinese? Lower barriers to entry and staggeringly huge domestic market that will enable a company smaller than Nokia, HTC, Samsung, or Motorola to pull it off. Bringing a phone to market is no small feat, but doing it in a country that hasn't yet developed the vogue western fetish for industrial self-mutilation in the holy name of IP Law, with a billion local customers and widespread culture of commercializing mashups is almost guaranteed to be easier than doing it somewhere like the US, where half the carriers lord over their customers with an iron fist, and the other half bend over backwards to ensure that their phones won't work on a competitor's network.
Why Android? The same low barriers to entry. You can't sell phones running Windows Mobile unless you're big enough to get Microsoft's attention as a potential partner, and convince their receptionist that you're valuable enough to merit their expensive legal department's negotiation time. You can't sell phones running OS X unless your company happens to be Apple. LiMo is a serious possibility in China, but I don't even think LiMo's backers really expect it to prevail over Android forever.
So, there you have it. With a little luck, someday soon, a humble factory somewhere in a smoky Chinese city is going to make a really awesome phone with an 852x480 display to die for, the fastest multicore mobile CPU they can get their hands on, gigabytes of flash & sram, and a real gamepad. It will make its way around stores in China for months, until a few find their way into the US and someone from Gizmodo or another site happens to see one... at which point it will become the hottest import item in American cellphone history, simply because it will be so completely UNLIKE any of the bland, generic mass-market glass slabs sold by Tmo, AT&T, Sprint, or Verizon. 12 months later, iPhone fans will all be crying and making death threats against Steve Jobs, because even the iPhone 4+n will sport the heresy of a slide-out gamepad with (*gasp*) real buttons.
> Each of those versions would require separate FCC approval.
Not quote. There's no technical reason why a single phone approved by the FCC couldn't be used on both Sprint and Verizon, or on AT&T and T-Mobile... it's mainly the carriers' fault.
Basically, the FCC requires any phone with unique hardware and radio firmware to be tested & approved. Sprint won't allow its customers to use Verizon-branded phones, and Verizon won't sell phones that aren't built to be "Uniquely Verizon". Thus, it would almost be beyond pointless for a manufacturer to pay to get FCC approval for a generic CDMA phone, because Sprint wouldn't allow it to be used, and Verizon wouldn't buy a million of them to resell to its customers.
The AT&T/T-Mobile situation is a little blurrier. It appears that right now, AT&T has a company policy of refusing to sell phones capable of 1700/2100 UMTS, and T-Mobile has a company policy of refusing to sell phones capable of 850MHz UMTS. Neither company will actually stop a customer from buying one himself and sticking the SIM card into it, but the market (right now) for unsubsidized handsets in the US is somewhere between "barely relevant" and "all but nonexistent". As a practical matter, there are exactly two American customers that manufacturers like HTC, Samsung, Nokia, and Motorola care about: AT&T and T-Mobile.
Need more proof of corporate policy dictating handset frequency availability? Watch the FCC submissions logs. I can almost guarantee that there will be two distinct versions of the iPhone 4 submitted to the FCC -- one that does 850MHz and 1900/2100 UMTS, and one that does 1700/2100 and 1900/2100. What's really sad is that they'll both probably have the same hardware, and differ only in their radio firmware. It'll suck for everyone... Europeans will have to decide whether they'd rather roam on AT&T or T-Mobile when they visit the US, and American iPhones will effectively be locked to AT&T or T-Mobile -- at least, for anyone buying one to use in the US with 3G data.
> Blame North America for trying to be different there
It has nothing to do with "trying to be different", and everything to do with pre-existing services.
1900MHz was mostly owned by Sprint in America several *years* before UMTS was even an acronym, let alone a real service that existed anywhere in the world -- Europe or otherwise. T-Mobile owned a few slivers here and there (mostly in smaller cities), but most of THOSE slivers represented their *entire spectrum* within that market, and the frequencies were already being used for their existing GSM customers. In other words, from the perspective of any single carrier, there WAS no incremental transition path.
Interesting fact: T-Mobile's 1900 spectrum came from Voicestream. Voicestream was actually created by Sprint as a way to sell off excess 1900MHz spectrum it didn't need. However, Sprint wanted to make sure it would never be a serious competitor, so the spun-off company literally owned the bare minimum spectrum necessary for GSM voice service to work. At one point a few years ago, their spectrum shortage was so severe, there were actually markets where they weren't allowed to sign up new customers for a few months due to saturation problems.
Sprint? They owned lots of 1900MHz spectrum, but they had a similar problem to T-Mobile: there are a few markets around the US where they just don't own enough 1900MHz spectrum to deploy 1900/2100UMTS (with 5MHz channels) alongside their existing 2.5MHz CDMA2000 customers. Plus, when the 1700/2100 auctions took place 3 years ago, Sprint was low on funds, and would have had to buy 1700MHz spectrum they have no need for in addition to the 2100MHz spectrum.
Even if AT&T Wireless (and the companies it acquired along the way, like BellSouth Mobility/Cingular) had known that 1900UMTS was coming when the 1900MHz spectrum was originally auctioned off in the 90s, they wouldn't have been able to afford it, because they would have been bidding against Sprint -- a company whose entire business plan could have been summed up as, "Pay whatever it takes to own a chunk of spectrum everywhere in America". Not to mention the fact that when the 1900 spectrum was auctioned off, 2100MHz was still owned by the US military.
> from what I've read, until the iPhone came around developing apps for other phones was a huge PITA.
> Android has since come out and provided probably the most open solution, but to say that other cell
> phone makers made it EASY (to develop, deploy, etc...) prior to the release of the iPhone doesn't go
> along with what I have read. Feel free to show me different though.
Er, ever hear about this obscure, fringe OS found on a few PDA phones called "Windows Mobile"? Granted, Windows Mobile phones have historically been dysfunctional as *phones* when powered up for the first time after purchase, but thirdparty apps like S2U2 and Winterface have done a lot to make them reasonably good. The day I decided to write my first Windows Mobile app, it took me maybe an hour to go from 'nothing' to 'running on my phone' (half of which was spent downloading the SDK from MSDN). A couple of days later, I had an app playing avi videos on my phone with a complete UI.
Microsoft might be generally incapable of creating a phone UI for people who want to dial with their fingers (instead of a stylus) and carry the phone in their back pockets, but Microsoft's role in going to war with the carriers to ensure that we could have a phone with completely unrestricted API that was beyond the carriers' control is hugely under-appreciated. Not even Verizon could permanently cripple its Windows Mobile phones (Microsoft sighed and let them ship with features disabled in the registry... but anyone with 3 brain cells and the slightest bit of motivation could figure out how to re-enable them 10 minutes after purchase).
The only "3G" capability I personally care about is a tablet's ability to tether to my rooted Android phone via 802.11 or Bluetooth and leech its internet connectivity for free when a better Wifi access point isn't within range. The day I can add a tablet to my phone's data plan as a second device for less than $5/month, I *might* contemplate paying more money to Sprint for the convenience. Until then, I have ~5GB/month to burn through, and a wirelessly-tethered PadPC would be a great way to work towards achieving that goal.
GPS would be nice... but really, I already have an Android phone with perfectly good GPS of its own. If the tablet can wirelessly tether to my phone to leech its data, there's no reason why I can't just install a host app on my phone that lets the tablet leech its location services, too. Let's be honest... how often am I *really* going to find myself in a situation where I have my tablet, but my phone isn't within Wifi or bluetooth range? Even in my car, my phone is going to be somewhere nearby, more or less perpetually aware of its location anyway.
I won't buy a tablet that's locked down to run only "approved" software. Nor, for that matter, will I buy a tablet that effectively prevents me from updating its OS as I see fit (I might bend the rule if I can root it and do what I please despite the manufacturer's best efforts, but it would still be a major strike against it).
I want at least four real, tactile hardkeys that aren't matrixed & can be read in any combination -- two on each side (when held in landscape orientation), positioned where my thumb would naturally land. Why four? As long as they're independently readable, you can chord them and use them to shift each other (example: press and hold left1, press right 2 twice, press and hold right 2, release left 1, release right two).
I want "touch strips" on the 4 bezels for easy scrolling... but I want them to be completely independent of the main digitizer so they can be selectively ignored when appropriate.
Spec-wise, give me a 1280x800 or 1366x768 color screen with wide viewing angle. It's small enough to be easily handled, but high enough to comfortably read the text content of two Manning-sized pdf pages side by side (in landscape orientation) if they're zoomed in slightly to eliminate most of the whitespace around each page's text.
What would I use a tablet for? Mostly ebook reading at home, as an interactive GPS navigator in the car, as a photo album, and a ghetto web browser when I'm watching TV in the living room. Paired with a bluetooth IR remote control beacon, it would probably make a nice home theater remote control, and be great for home automation in general.
Give me a full-sized usb slot that can host USB thumb drives... and boot from them, if I happen to build my own Linux for it. Give me two bootable SD card slots as well... one for the OS, one for my data. If space is really an issue, make one of them microSD. Just make sure that at least one of the full-sized SD slots is physically located somewhere appropriate for SDIO peripherals.
For god's sake... put a camera on the front. It doesn't have to have gigapixel resolution... 640-852 x 480 resolution is fine. That one feature, if nothing else, won't just make it cool for videoconferencing... it will practically guarantee that every deaf person in America will end up owning one within a matter of months. Not to mention useful perks like face recognition for autoconfiguration.
Give it some kind of kickstand, so I can prop it on a table, plug it into my laptop's USB port to use as a second monitor when I'm visiting my parents. Or use it with a bluetooth/usb keyboard and/or mouse with it and run it as a low end laptop in its own right, or maybe as a RDP client. Just make sure the USB port is located on one side or the top, so it won't get in the way when I pop out the kickstand and prop it up on the desk/table next to my laptop.
> There's also questions relating to what happens when a v6 address hits higher-level software due to their no longer using just digits and dots
Reverse-NAT. Basically, you have a translation gateway sitting between the IPv6 network and IPv4 network that allocates an IPv4 address from its pool, and makes a note to associate it with the real IPv6 address. For example, 2001:6969::100 might be mapped by it to 192.95.17.9. You'd tell your IPv4-aware app to connect to 192.95.17.9. The translator sees the outbound datagram, recognizes its address as a mapped alias, rewrites the datagram in IPv6 format with a destination address of 2001:6969::100, and sends it on its way. Inbound datagrams from 2001:6969::100 get rewritten from IPv6 format to IPv4 format the same way, with 192.95.17.9 as the faux source address. There are three main problems that have to be addressed: availability, persistence, and global-applicability.
The first is scalability and security (listed together because the more secure you make it, the less scalable it's going to be in real-world use). It's not really practical to do this kind of translation at the backbone or enterprise level, because 1) the mapping table would rapidly become huge to the point where it literally became an architectural chokepoint, and 2) it would be trivially easy to launch denial-of-service attacks against everyone who depended on that translator by simply flooding it with requests to overflow its buffers. You COULD try to partition it off and implement security, but this is one of those times when it's easier and more reliable for everyone overall to just limit the scope of collateral damage and move responsibility for the 4-6 translation to a more local layer... like a home router, or even the operating system's network stack. When every microsecond counts, you just can't stop to scrutinize every request passing through the router. At least, not cheaply. My own prediction is that this function will fall to the future equivalent of a home or small office's router. If denial of service attacks become a real problem, you'll probably see low-end routers simply divide the network into two groups: those with IP addresses for which translation will be done (ie, older embedded devices that can't easily have the network stack replaced), and those that are on their own and will be simply ignored if they ask for translation help (ie, any PC running Windows, Linux, OS-X, etc) -- with possible partitioning of mapping resources for the few devices left that genuinely need the router to do the job for them.
OK, the next problem: persistence. Put another way, if the router or software stack maps 2001:6969::100 to 192.95.17.9, how long does it need to remember that mapping... and how will it actually store it if necessary? I'm going to guess that the first home translating routers will basically treat this task the way port mapping to internal private addresses gets handled now: you'll have to go to the router's admin app, and manually set up any 4-to-6 mappings you need to have persist. Everything else (like web surfing) will just be done dynamically, with persistence that's at least long enough to last between datagrams, but not necessarily day to day. Say, 10-30 hours. A pain, but then again... how many different raw IP addresses do you REALLY deal with directly behind any given router today? Remember, we're talking about raw addresses that have to persist indefinitely for your future reliable use, not the cached results of a dns lookup.
That brings up the third, and stickiest problem that has no good solution right now: global applicability. For the classic acid test, just look at h.323. It's been a nightmare to NAT ever since day one, because it encodes (what it believes to be) its IP address in the data itself. The problem being, without an intelligent application-level gateway, the recipient PC ends up seeing a return address that can't actually be reached directly. Personally, I think this is another one of those issues that will get swept under the rug out
After reading more over the past couple of days, I'm increasingly convinced that this is what's likely to happen:
1. It will become nearly impossible to get a real, publicly-routable static IPv4 address for your own exclusive use if you're a residential customer.
2. Anyone with cable or DSL and a pulse will be able to get a /60 IPv6, probably a /56, possibly a whole /48. That same group might (especially at first) get fractional ownership (say, 16-32 permanently-forwarded ports) of a semi-static IPv4 address (one whose stability isn't guaranteed, but will mainly change every few weeks as the ISP defrags its allocation database).
3. Residential customers who've gone to the trouble of getting a static IP *today*, and small businesses, will normally get a /48 (at worst, a /56), and fractional ownership of a public IPv4 address that might change once or twice per year... but if it does, the changeover time will be scheduled and known in advance.
4. 4to6 gateway-routers will largely hide the IPv6 network on the "public" side of residential networks from anyone who doesn't intentionally seek to access it "natively". The first "real" IPv6 applications will be online games, for the simple reason that they're the #1 commercial reason why residential users will care about direct endpoint connectivity. Running next to them will be P2P... especially if it takes a while for the MAFIAA to discover the existence of IPv6 P2P.
5. Publicly-accessible servers will have plenty of IPv4 addresses to go around for the rest of our lives. Why? The same reason why it's easy to get phone numbers in the 212 (Manhattan) or 305 areacodes (Miami) today, even from VoIP services that didn't exist until recently, despite panic 10-15 years ago that the numbers were all going to run out. People abandoned pagers, second phone lines used for faxes & modems, and relaxed numbering rules added thousands of new numbers that previously weren't allowed (ie, 305-nxn-nnnn, where x=0 or 1). At the same time, the newer areacodes became the default unless you went out of your way to get an older one. The same thing is going to happen to public IPv4 addresses. ISPs will slowly start charging more for them (especially for users who want a LOT of them), and over time businesses will start to question why they're even bothering to still pay for IPv4 addresses they haven't really needed since anyone can remember. The charges don't even have to be that high... merely visible as line-items on the bill.
Reclaiming a few legacy Class-A blocks, or even a chunk of class E (in the longer term) might "only add a few weeks" at THIS point, but adding them at a future point when demand itself has either flattened or begun to decline might very well add enough for "decades". I'll even predict a HUGE fight 5-20 years from now when someone notices that more than half the IPv4 pool has been effectively abandoned, and proposes defragging it to clean up and simplify routing... and ends up triggering one last fight between the group that wants to clean it up a bit and the still-angry group that wants to banish it forever and eliminate it immediately. The end result? IPv4 will spend the next hundred years following in the footsteps of America's passenger rail system... limping along, never really being killed, but not really properly maintained, either... just abandoned in chunks as parts become too broken to ignore, but not valuable enough to fix.
IMHO, the people pushing the hardest for "IPv6 now, at any cost!" are revolutionaries in the true sense. They don't WANT a smooth, painless transition that barely gets noticed by end users as IPv4 fades into a long sunset with a yawn. They dream of flipping a magic switch that instantly breaks 99% of the internet as we know it (especially the "unimportant" parts running Microsoft operating systems), and forces everyone to spend a month doing whatever it takes to get back online via the One True Way: IPv6. What t
The OS might support IPv6, but the apps have to support it too, or the OS itself is going to end up doing something like I described above. IPv4 apps aren't going away anytime soon, and any attempt to force the issue by intentionally breaking them will just incite user rebellion. Yes, it's a complicated router-based solution... but routers are cheap. By making the "outside world" look more or less exactly like it does now via a more sophisticated router doing inverse NAT, you're enabling everything on the inside network to remain exactly like it is, for as long as whomever's in charge wants to leave it that way. The network can evolve over time, until the translation becomes more of an annoyance than a convenience. The OS can tell IPv6-unaware apps that the computer's IP address is 192.168.100.101. It can tell IPv6-aware apps that the computer's address is 37a1:de19:7f9b::101. Both can happily coexist.
IMHO, the zeal of IPv6's supporters is one of the things that's killing it. They're not content to merely hand users vast amounts of address space & the freedom to use it... they're going to MAKE them use it, at metaphorical gunpoint if necessary, and FORCE them to like it. Just look at what happened with DHCP6. The IPv6 Elite were determined to be like French Revolutionaries, and banish anything as politically incorrect as NAT, regardless of whether or not people tended to like it because it accidentally solved a problem it was never intended to solve (blunt firewalling and keeping Windows safe from the outside world).
Look at it this way: if routers did something like this, routers could be made that would register with the ISP and accept EITHER an IPv4 address OR an IPv6 site prefix... and configure themselves accordingly. If every router sold for 2 or 3 years did this, the exact day an ISP (or the world) switched from IPv4 to IPv6 would be about as significant as the day most of the TV stations in America switched from NTSC to ATSC -- a yawn-worthy non-event most people wouldn't even notice (because everything on the 'local' side of the box worked exactly the same as it did the day before).
Is there any physical reason why a router couldn't do the following to transparently enable ipv6-oblivious software to effectively "inverse-NAT the rest of the world"?
1) Connect, and note the /48 assigned to the site by the ISP (for this example, let's say (37a1:de19:7f9b/48).
2) To the inside network, the router looks just like any other ipv4 router. For the sake of argument, let's pretend it's allocating ip addresses 192.168.100.100 to 192.168.100.199 via DHCP
3) A desktop PC on the local network asks the router for an IP address. It gets 192.168.100.101.
4) That desktop PC later sends a request to fetch http://www.slashdot.org./ The router intercepts the DNS request.
5) The router does the dns lookup, and discovers that Slashdot's IPv6 address is 2005:1234:5678:1::1.
6) The router makes up a fake ipv4 address. To do so, the router declares 10.0.0.0/8 to be off-limits for use on the local network as a local address so they can be hijacked for this purpose, instead. It picks one -- 10.5.17.88 -- then makes a note to itself that it expires in an hour, and answers the DNS query from the local PC: Slashdot's IP address is 10.5.17.88, with TTL=60 minutes.
7. The local PC's browser sends a http request to http://10.5.17.88./
8. The router sees the outbound datagram with a 10.0.0.0/8 address. It does a quick lookup from its own local table, and sees that the real ipv6 address is 2005:1234:5678:1::1. It proceeds to send a fake ipv6 request to 2005:1234:5678:1::1 that appears to be from 37a1:de19:7f9b:1:6969:0192:0168:0100:0101. Yeah, the lower 64 bits completely stomp on the intent of every ipv6-related RFC, not to mention inefficiently maps decimal octets to 16-bit values for the sake of human-readability. Deal with it. It works anyway, and makes life a little easier during the transition. ;-)
9) Slashdot's server receives the request from 37a1:de19:7f9b:6969:192:168:100:101, and sends the response.
10) The router gets the datagram. It sees the 6969 (a value dictated by the router that might very well be randomly pulled out of a hat), which confirms to it that the lower 64 bits contain the local ipv4 address encoded in human-readable form. It rewrites the datagram, and passes it along to the local network.
11) The local PC gets its response from 10.5.17.88, and never knows the difference.
The router would need a big chunk of ram to keep track of the kludged dns lookup table, and would have to do more than routers do now to keep up the facade of an ipv4 universe for blissfully-oblivious clients on the inside... but it seems like it would nicely solve the problem of ipv6-unaware software by giving end users another decade or two to sidestep the problem. Their "real" ip address (site network) would be ipv6, but everything that's ipv6-unaware would be able to think it was really sitting behind a public ipv4 address.
For an added level of security (making it harder for random traffic from the outside to directly reach inside hosts), instead of picking a value like '6969' for the fourth 16-bit chunk, it could pick a new random value every hour, use it to XOR the lower 64 bits, and use THAT value for the fourth chunk. When incoming requests came in, it would xor the lower 4 16-bit chunks against its current random value, and compare it to the value presented as the fourth chunk. If it didn't match, it would try again with its previous random value. If it found a match, it would pass it along as per step 10. Otherwise, it might variously refuse the connection, return random junk, silently ignore it, and/or blackhole that IP's source network for some period of time to protect itself.
For hosts intended to have direct accessibility from the outside, the fourth chunk might have a different interpretation. For example, using 0xf as the high 4 bits to flag it, and the lower 12 bits of chunk #4 to indicate the port. So if the local PC whose ip a
> I guess we were paying $99 for the QC sticker they put on it before they sent it off through the supply system.
Actually, there's a very good real-world example of a cheap electronic component that nevertheless can be very expensive when its quality is absolutely certified: electrolytic capacitors. Today, in 2010, brand new devices are STILL being manufactured with electrolytic capacitors that have substandard electrolyte. This is a problem that was supposed to have gone away YEARS ago. Why is it still around? Because the bad electrolyte is a tiny, tiny bit cheaper to make... and the capacitors tend to work just fine for at least a few months. In other words, they fail prematurely... but not immediately.
If you're building something that absolutely, positively, must NEVER use an electrolytic capacitor with bad electrolyte, you have no real option besides buying only capacitors that are certified (and can be audited) all the way from you (the company building the device that uses them) to the chemicals used to make the electrolyte itself. It's not enough to buy "a good brand". To get that level of certification, every party along the way -- distributor, wholesaler, supplier -- has to be certified capable of keeping them secure and properly stored. Otherwise, an employee (or manager, or higher) at the supplier could substitute counterfeit capacitors, then sell the genuine ones elsewhere.
The point is, that degree of auditing and handling is insanely expensive, because it involves SO MANY different parties (all of whom want to be reimbursed for the extra trouble). It's made more expensive by the fact that there are (fortunately) very few things that really NEED that kind of quality control. Life support equipment and nuclear power plant control systems are obvious excamples where it's justified, costs be damned.
That said, this particular device isn't life support equipment, regardless of how hard someone might try to make it sound like the tiniest malfunction would lead to death or injury. I think it's safe to say that this particular device's price is all but guaranteed to come down a few thousand dollars if they want to keep selling it.
> If you happen to live in these flood prone locations there are two choices:
> a) Fix the entire world to stop rising waters ---- not likely.
> b) MOVE to higher ground.
You forgot option 'c' --
c) Make the ground you already own a foot or two higher.
A hundred years ago, the land my house sits on (western Pembroke Pines, Florida) was theoretically (if not actually) underwater a few months per year. It wasn't swamp... it was outright, honest-to-god 'Everglades'. Yet, talking to my neighbors, the neighborhood has never flooded -- or even came close to it -- in ~30 years.
Why?
The big dike a few miles west, and the huge drainage canals everywhere obviously help... but there's another factor: the developer turned the low-lying areas into deep lakes, and used the debris to raise the surrounding area. So... when we have a really bad (read: daily) summer downpour, the water runs into the storm drains, then gets dumped a few hundred feet away in those same lakes.
The work quite well. Last month, large parts of South Florida were flooded for a day or two after massive downpours that dumped more than a foot of rain. We barely even had puddles on the roads.
Media propaganda to the contrary, FEMA doesn't just dump money into low-lying areas. If you build a house in a floodplain and it gets flooded, FEMA (as a condition of making flood insurance available to an area) requires that the local government pass laws requiring rebuilt homes to have their lowest habitable floor a couple of feet above the "500 year" water level. You can buy landfill to raise your lot's height, you can build on pilings, or you can take the insurance money and head for the hills. What you *can't* do is put yourself in the exact same situation you were in beforehand.
Over time, economically valuable parts of low-lying cities will get rebuilt on pilings. Over the next 25-50 years, the roads get rebuilt higher, with better storm drains and stormwater retention ponds.
The controversy in New Orleans is that people in the flooded areas wanted special treatment & exemption from the rules -- to which FEMA firmly said, "No. You'll rebuild on pilings, or you won't rebuild. This isn't oppression by The Man... it's common sense."
My prediction: the poorest, lowest-lying, most destroyed parts of New Orleans that aren't likely to be rebuilt anytime soon will sit vacant for a few years, until property values rise high enough for large corporate developers (Toll Brothers, Lennar, etc) to start quietly buying up large tracts of low-lying land. Once they own enough, they'll do the same thing there that they've done in Florida: dig a deep lake and/or surround the new community with a moat^h^h^h^h linear retention pond, build new concrete storm drains and streets above the historical flood level, then backfill the remaining area & turn it into expensive waterfront suburbia.
Want to know what future coastlines in areas supposedly vulnerable to rising sea levels will look like? Go to South Beach. Most people don't even REALIZE it until you point it out to them, but it's actually surrounded by a huge dike -- the artificial dunes built as part of the beach renourishment program in the 80s and 90s, and the streets along the island's perimeter that have been progressively raised during widening and reconstruction to form de-facto dikes. Ditto, for Miami's bayfront neighborhoods.
The strategy is simple: raise the roads, and let the wealthy property owners on the lower waterfront side worry about raising their own property level when they end up rebuilding -- possibly due to storm damage, more likely due to bulldozing away the older single-family homes and replacing them with skyscrapers. Any time a road in Florida gets widened, it almost always gets rebuilt a foot or two higher than it used to be. Stir, rinse, repeat for a hundred years, and by the time the sea level rises enough to flood areas that are dry today, hardly anyone will even notice. The areas that flood will have been floodin
> Like any GSM/UMTS network in the world?
You're forgetting that GSM/UMTS phones won't do 3G on any network in America unless they happen to support 850/850 or 1700/2200 uplink/downlink. AFAIK, the US is the only country on earth that does 850/850 and 1700/2200 UMTS. I don't even think *Canada* uses those frequencies. For all intents and purposes, the only phones that support 850/850 UMTS are sold by AT&T Wireless, and the only phones that support 1700/2200 are sold by T-Mobile. So much for interoperability. A "global" phone that supports only 1900/2100 UMTS will give you blazingly-fast 19.2kbit/sec GPRS in America (or serve a more useful purpose as a paperweight in windy weather).
It's sad, but right now, Verizon is ironically the most interoperable carrier in America, just because you can theoretically reflash the Sprint twin of a Verizon phone with Verizon firmware and they'll let you use it if you can figure out how to do it on your own, without any help from them. It's a piss poor, sad excuse for interoperability, but just goes to show how dire the wireless situation *is* in the United States.
> Same here. Born in the USSR in mid-80s, and I've first seen a PC (which was also the first programmable computer to me) in 1995.
> Cellphones came a lot later, too - I've only got a personal one in 2000.
Don't feel bad... most AMERICANS didn't get THEIR first cell phones until ~1999 (give or take a year), either. :-)
Cell phones EXISTED in the US as early as ~1982, but you had to be *incredibly* wealthy (as in, "Donald Trump wealthy") to own one before 1990, and they were still pretty expensive until the VERY late 90s. Also, "national coverage" was more of a marketing slogan than a reality. As late as 2001, I went to Dallas for the weekend with some friends, and remember at least one who couldn't use his (AT&T Wireless) phone there without paying ridiculously expensive daily and per-minute roaming charges. Back then, if you wanted to travel without getting financially raped & have your phone "just work" wherever (urban) you went, you basically had two choices: Sprint and Verizon. Sprint was (relatively) cheap, but had mediocre coverage in most places (ie, your phone usually had service, but you often had to go outside or stand by a window to make an actual call). Verizon had better coverage, but cost twice as much. T-Mobile was still a patchwork of regional GSM-based companies (Voicestream, Airtouch, etc), and AT&T (before they bought BellSouth Mobility, changed their name to Cingular, and began switching to GSM) merely had nationwide seamless analog roaming & billing agreements with other regional companies... as long as you bought a phone that did analog *AND* TDMA(digital). Lots of people in big cities (like Miami) found out the hard way that smaller, "pocket-sized" TDMA-only "flip phones" didn't work well (or at all) in rural areas (like the 25-40 mile radius "digital dead zone" that used to exist halfway between Miami and Orlando).
> Who among us remembers slot cars? And who among us is willing to admit it?
Who said they ever went away? http://www.youtube.com/watch?v=nc39leiusGY
Hmmm... I think I just decided what my nephew is getting for Christmas when he's at least 4 or 5 :)
> Case in point: wire hangers.
I beg to differ. Wire hangers are a universal building supply and tool, proudly serving next to duct tape and WD-40 as a universal tool and replacement part. Unlike any wire you can buy at Home Depot (at least, for less than $1/foot), clothes hangers are made from nice, stiff wire that can be bent into custom shapes without losing much of its strength in the process.
I shudder to think of what I'd have to do if I accidentally dropped something important (like keys) into a dirty toilet and didn't have a supply of wire hangers available to form into adhoc fishhook or tongs. If you're so green, PLEASE don't tell me you actually do something as environmentally incorrect as use wood paddles to stir paint. Use a repurposed metal coathanger, instead! After all, few things are more green than 'adaptive reuse' -- and few things are as suitable for wholesale daily adaptive reuse as metal clothes hangers! :D
> I'm not 100% on this, but I believe the Y2K mess didn't effect Unix-y systems at all. The way Unix time works,
> if you're not familiar, is that it just counts the seconds after the epoch. Whether the year is represented as two
> of four digits doesn't matter, and doesn't cause problems.
Remember all of the Perl-based CGI wishing you a Happy New Year on January 1, 19100? I have old books in a box somewhere from *1997* with sample code telling users to print "19" then append the year value. It affected lots of programs that used the Perl functions that returned bits and pieces of the date, instead of printing it as a complete whole (which handled things correctly).
^^^ argh. I forgot Slashdot doesn't transparently handle less-than and greater-than characters, even in "Plain old Text" mode. The offending instruction should read "move SR, (ea)" (substituting greater-than and less-than for parentheses).
If I could go back in time and make just one change to the Amiga, it would be to have ensured that the A1000, or at least the 500 & 2000 onward, had a 68010 instead of a 68000. Nothing, and I mean *nothing*, caused more software to crash and burn on Amigas with 68020+ microprocessors than the damn Move SR, instruction (privileged on everything from the 68010 onward, but nonprivileged on the 68000 -- and used by just about every Amiga copy protection scheme.) From what I remember, a 68010 cost a whopping $10 back around 1988. In "Commodore quantities", it probably would have cost a buck or two more than a 68000, and would have made it a lot easier for Commodore to sell higher-end Amigas with greater markup.