> TV channels being a finite resource, a free market of channels couldn't exist, thus regulation is required.
Except for the fact that in most countries, terrestrial broadcast TV is now commercially-irrelevant, and satellite capacity is mostly a function of available capital to launch satellites and how big of a dish customers will tolerate (bigger dish = ability to shoehorn more satellites into a given arc of equatorial orbit). A 75-ohm coax cable can carry several hundred HD channels, and thousands of SD channels. Upgrade to fiber, and you're basically talking about enough raw bandwidth to let every customer have multiple on-demand HD channels of his own. 25 years ago, orbital slots were in high demand. Now, with spot beams roughly 100km diameter, all you need is a more expensive satellite and/or bigger dish with greater selectivity & gain to make any perceived "shortage" of channels or orbital slots an academic abstraction.
> As long as you have a means to obtain the correct M.IP profile 0 data (which consists of some IP configuration, > your NAI and HA and AAA passwords), your EVDO will work.
Hmmm. This is the best explanation of the reason why Sprint phones (even hacked ones) generally can't do EVDO on Verizon (unless they're identical twins of a Verizon phone that gets flashed to Verizon firmware, like the old Sprint PPC6700 and Verizon xv6700 WinMO phones ~5 years ago).
Do you know offhand, is the M.IP profile data a "userspace" config now (in the Android/iPhone era)? From what I recall a few years ago from the discussions at XDA (back around 2007, in the WinMo era), the main problem was that the config data is/was part of the radio modem firmware, the radio modem firmware is distributed in encrypted form, the phone's bootloader won't flash it unless the cert & signature validates, and there was some technical reason why it was impossible to rip the radio modem firmware from an unrelated Verizon phone (with the same radio modem chipset) and flash it to even a fully-hacked Sprint phone.
In other words, you could trick the bootloader into making a Sprint phone look like its Verizon identical twin so it would allow you to reflash the radio modem, but you wouldn't have been able to pull it off with two phones that differed even slightly (like the Epic4G and Fascinate), even if most of the "core" hardware were identical (and the radios were absolutely identical). I think it only worked for the 6700 because the Sprint and Verizon phones were literally identical in every meaningful way hardware-wise.
I've always thought something like that would make an awesome plot for a Sci-Fi movie -- people use transporters to go everywhere, multiple times per day, but the reality is that you end up with two conscious copies of the same person, and the old one gets automatically destroyed once the copy and replication is complete. The new copy steps out at the other end feeling like the teleportation worked flawlessly, and the old person (itself a multi-Nth copy of the person who was born years earlier) stands in the booth wondering why it's not working, until he gets killed and vaporized (with people who've seen the process believing it's part of the teleportation process, instead of a purely destructive clean-up act, and very few genuinely understanding what's really going on... because nobody would ever step into such a booth knowing that they themselves were going to effectively die, even if their "consciousness" lived on after replication elsewhere).
Now, imagine a teleporter whose "destructor" system fails after working well enough to injure (instead of kill) someone who just teleported, and leaves him convinced that terrorists are systematically murdering people -- and has no idea that it's now teleportation machines are *intended* to work, and eventually manages to teleport home from work after a visit to the hospital, only to run into himself#2.n, who just uneventfully teleported home from work after a perfectly normal day that included about a half-dozen teleportations that worked "without incident".
Now, stir in some extra details to make it a real story... engineers who stumbled on the truth while trying to reverse-engineer the process for a start-up competitor (who were summarily committed to a mental institution, because at that point, teleporters had been used by everyone multiple times per day since birth, and the whole *idea* that teleportation == death was viewed as ludicrous... were hospitalized, then truly went insane after being forcibly teleported multiple times per day at the mental hospital (knowing each time what was really happening to them). Add a legal system completely unprepared to deal with both the consequences of having two copies of the same person, and a society where all other forms of transportation had effectively ceased to exist and teleportation was literally the only way to travel more than a few thousand feet (even elevators were replaced by teleporters by that time, and stairs were increasingly uncommon).
Just to add, even if a US judge were to block carrier SIM-locking, it would be almost meaningless in the US due to the way Sprint, Verizon, T-Mobile, and AT&T run.
Sprint's network will literally refuse to talk to a phone that attempts to identify itself as a subscriber phone with a MEID that isn't in Sprint's official database of Sprint-branded phones.
Verizon authenticates EVDO via firmware extensions that don't exist in Sprint phones, so Verizon's network will refuse to negotiate EVDO connections with a theoretically-unlocked Sprint phone.
T-Mobile's frequency bands aren't supported by default in most GSM phones (most new chipsets can do them, but few phones have support for 1700MHz uplinks enabled, the Samsung Galaxy S i9000 sold internationally is one of the very, very few exceptions).
Most European phones can roam on AT&T, but AFAIK, HSUPA is a semi-proprietary extension to UMTS that's mostly unique to AT&T and not used in Europe(?), so even European phones capable of doing 3G on AT&T will be limping along at less than the max data rate (not 100% sure about this one, but I've seen it widely reported that only AT&T-branded phones can achieve the maximum HSUPA data rates)
> Can someone unlocked a US-based iPhone in Chile?
You'd be wasting your time, if the intent is to use it in the US.
A non-Sprint iPhone will never work on Sprint as a customer phone (but can roam on Sprint if your carrier has agreements with them). Sprint just won't allow it, period.
A non-Verizon iPhone will never do EVDO on Verizon, even if you can get it to limp along with CDMA2000 voice and 1xRTT.
A non-AT&T iPhone will almost certainly never do HSUPA on AT&T, and would almost certainly cost way more than just buying an AT&T iPhone.
In theory, an unlocked iPhone could be used with T-Mobile, but (drumroll, please) will never do anything better than EDGE. There's no hard technical reason why an AT&T, Sprint, or Verizon iPhone can't do 1700/2100 HSPA+ on T-Mobile (their MSM6600 chipset is certainly capable of it), but an an end user you'll never, ever get it to work because the radio firmware is separate, with its own heavily-encrypted bootloader, and no iPhone sold anywhere on earth has 1700/2100 HSPA+ enabled in its radio modem firmware.
It's sad. Apple basically has one hardware design for all of its iPhones, but the three US models are intentionally as non-interoperable with each others' networks as their firmware can make them be.
It could also be a case of, "My iPhone or Android phone broke in November, and instead of spending more than it's worth to fix it, I'm just going to limp along with my old phone for a few weeks and get a brand new "best of breed" Android phone for Christmas"
> After it's "broken" the warranty and everything goes out the window.
They say it is, but it's a deliberate lie (which, unfortunately, is not itself illegal in the US). Escalate to a manager, mention the Magnuson-Moss Warranty Act, and you'll have no problems. Under the MMWA, they can only refuse warranty coverage if they can prove that the failure was DIRECTLY caused by rooting and/or reflashing.
Put another way, if reflashing your phone to stock firmware fixes the problem, they can anally-rape you with service charges for wasting their time.
If your custom ROM took two GPIO pins that were connected together (and normally tristated) & burned them out by making both "outputs" & setting one high & one low, they can legitimately deny warranty coverage for anything related to those two pins (though you could possibly argue back that directly connecting them without even a resistor in between was itself a design flaw, unless they could prove they had a legitimate engineering reason for doing it (like charlieplexing multiple LED elements from a small number of actual GPIO pins).
Under MMWA, there are very few reasons why they can legally deny warranty coverage, but they aren't obligated to troubleshoot your custom ROM for you. Like PC manufacturers who are free to reimage your hard drive as part of a repair, phone mfrs. are free to reflash it to stock firmware with a JTAG (or give you a new/repaired phone with stock firmware), and aren't obliged to preserve your firmware.
Half of Nokia's problem was the fact that they basically wrote off the US as a market, without grasping that its mindshare and influence was several orders of magnitude greater than the number of phones sold might otherwise suggest. Symbian for all intents and purposes didn't exist in the US (I think Sony-Ericsson had a few that could do 3G on AT&T, and limp along with EDGE on T-Mobile, if you paid $800 to import one) , and as a practical matter neither did Nokia phones capable of doing anything better than GPRS from around 2004 until around 2009. As far as American tech review sites were concerned, Nokia didn't exist anymore. Because in America, they didn't.
> Many Android phones, such as those from Samsung, are also "rootable" (the other 1% of the jailbreak) > without any hacks.
Rootable, but not necessarily reflashable with AOSP or Cyanogen unless you're willing to sacrifice 4G data. For some inane reason (most likely having to do with Clear, its lawyers, and/or Sprint's status as an arms-length thirdparty customer instead of 95% of their reason for existing in the first place), Sprint and Samsung have never made it particularly easy to get 4G working in any unblessed configuration -- not even the allegedly 100% open Nexus S. It's not quite *impossible*, but 4G (wimax) data always seems to be the first thing that breaks and the last thing that gets fixed every time a newer kernel than Samsung has officially released is required to run a newer version of Android.
You also can't use it for meaningful data in the US. They (and Trolltech) stupidly decided to use a GSM chip that can't do EDGE, and only supports 1900/2100UMTS, instead of spending about $5 more to get the pin-compatible next version up that supported EDGE (and, I believe, 850/1900MHz UMTS), which means they're GPRS paperweights in the US.
Re:So much for our "technology"
on
How Doctors Die
·
· Score: 1
> Imagine how bad overpopulation would be if we all lived to be 150.
We'll "all" *never* live to be 150. At best, a percentage of those who currently make it to 100 might make it to 150, and most of those who make it to 40 would probably make it to 80 or 90. Even if cancer gets decisively vanquished like polio, people are still going to have fatal car wrecks, fall from ladders & roofs, die from snakebites, get shot by street thugs, and have medical emergencies in awkward places.
If anything, given that most western countries now reproduce below the rate of replacement, extending the death date by a couple of decades would do little more than maintain the population status quo. Fewer kids, but more great-great-...-grandparents.
> If you want to push the metric system, start with the meteorologists, weather broadcasts and such. > If people are eased into thinking of the temperature in metric the other systems will be that much easier.
Good god, temperature is the *worst* part of the metric system. I mean, WTF. How often does anybody genuinely *care* that the freezing point of distilled water at sea level is exactly zero degrees, and the boiling point of the same is exactly 100? When was the last time somebody making a cup of tea put a thermometer into the tea kettle to measure the water's temperature as it approached 100C?
For answering the specific question, "How hot (or cold) is it outside?" Fahrenheit is damn near perfect. 0F isn't just cold... it's the point where it genuinely starts to become *dangerously* cold. Likewise, 100F isn't just "hot" -- it's the point where it becomes *dangerously* hot. The temperature at which puddles turn into ice, and your lips crack from wind, can vary by several real-world degrees... but 0F is always going to be really, really, bitterly cold, and 100F is approximately the point where people start throwing up and passing out from heatstroke. In weather terms, 0C is almost meaningless... it might feel bitterly cold, or (in Antarctica during the summer, where it's basically a cold desert with minimal humidity) it might be warm enough to go outside wearing shorts (for a few minutes, anyway) -- at least, if there's no major wind chill.
No, it's a pocket laptop with pervasive mobile wireless internet connectivity that happens to be capable of making voice phone calls, if that's really what you want to do.
> The shocking thing is that even though it was a beta, Galaxy S was arguably the best android phone on the market for at least 6 months.
Maybe the I9000, but the Sprint Epic 4G sure as hell wasn't. The GPS was utterly dysfunctional until Froyo (finally) arrived (~9 months after release), and only marginally better thereafter. We were stuck with 2.1 for eternity, and couldn't run AOSP Froyo without giving up 4G.
Ah, I didn't see the detail about being a visitor to the US. I thought he was advocating it as a cost-saving strategy for Americans who think they won't use "a lot" of data with an Android phone just because they haven't used much data in the past with a non-Android phone.
$2/day isn't very cheap if you're actually using it daily. For about $20/month more, you could get a full blown Android plan with subsidized phone and more or less unlimited everything besides daytime voice minutes (450 peak minutes), with 3G speeds and 4G where available. Factor the $20/month extra into the roughly $200-400 discount on a best of breed Android phone like the SGS2/Evo3D/Photon, and at worst you're breaking even and getting way more for your money.
Before you say "I wouldn't be using it daily"... yes, once you get a best of breed Android phone, you will, because you'll discover all kinds of things that were dysfunctional internet-wise on older phones that suddenly work well, and you'll find yourself using them anytime you're stuck in a line somewhere, waiting for something, or just bored. Plus, it's EXTREMELY difficult to make an Android phone not sip (if not inhale) data 24/7. It can be done, but it's something you have to actively work to make happen. Any data plan where your billing unit is "minute where at least one byte of data gets transferred" will positively bankrupt you with an Android phone if you forget to disable data, because so many apps endlessly sip data nonstop in the background. Not enough data to really make a difference with a normal plan, even one that's capped at 2 gigs... but plenty to run up a gigantic bill if you're getting metered by the "data-minute" rather than by the megabyte.
The patent he's referring to is almost the poster child for everything that's wrong with America's patent system. It was granted at the point when the patent office officially disregarded prior art that wasn't itself patented, and the main "innovation" (PWM-wise) was the addition of a blue LED to the red and green one -- something endlessly discussed on Usenet for years, but not physically practical until blue LEDs became commercially-available for the first time in the late 90s.
Nobody seriously believes it would ever survive a real challenge in court, but due to the way America's patent system works, it'll probably never get invalidated before it expires on its own.
The biggest single meaningful reform we could get to the patent system would be to allow a group of self-selected stakeholders to collectively gang up on a patent holder and share the cost of a proactive lawsuit to get it overturned & invalidated, or at least a rule that if you sue somebody for infringement, THEY can force you to pursue the lawsuit to its final judgment (so you can't just drop the suit and risk having your ability to sue OTHERS invalidated if things start going badly), and if the patent holder gets a case dismissed with prejudice against them, apply the same prejudice to all future lawsuits regarding the same patent.
This would raise the stakes enormously, and force patent holders to pick and choose their battles carefully. One ill-conceived lawsuit against an independently-wealthy (or legally-trained & willing to make it his personal crusade pro-se) Aspie determined to teach "you" (the hypothetical patent troll, not the poster above) a lesson, and your patent could get flushed down the toilet over a $10,000 shakedown attempt against someone who's practically judgment-proof compared to the patent's theoretical value. Big companies would still play chess with each other, but empowering "small fry" to say, "no, I'm not going to ALLOW you to just drop the issue and go home with your ball. You picked the fight, and now I'm going to beat you to a pulp fair & square" would raise the stakes considerably and make life for patent trolls a lot more difficult.
Pure geekgasm, I present my Christmas tree as posted to Youtube 3 years ago (I haven't had time to do a new video since then, but the lights still entertain me and my guests; view my Youtube channel, and you can find the old version of the video and the rough draft of the next year's) -- http://www.youtube.com/watch?v=U5qR9_8KGPU
Note: the website mentioned at the beginning of the video expired last year, so don't try going there. It's probably a trojan-filled pr0n site by now.
Technical specs: each light has an Atmel ATTiny25 with RGB LED, resistors, decoupling capacitor, and 5v linear buck regulator so I can power the string with 13.6v. The string has 3 wires: Vcc, Ground, and serial. The light modules have their own interpreted language that includes things like "fade to $color at $rate, then (stall/pause a while/pause briefly/continue)" and row-column addressing (so I can apply an opcode to every light in a row, every light in a column, a single light, or all lights on the tree). The serial bus itself is actually quite slow (~300bps), with most commands requiring 2 or 3 bytes. The complicated effects were created by writing commands into SRAM, then stepping through them globally so everything sync'ed up.
Total cost of the string you see on the tree: about $1,200 worth of parts, plus the better part of 3 or 4 months soldering and assembling them. The circuit itself, and the onboard firmware, evolved over 3 years. The song in the video took me about 3 weeks to do, and occupied pretty much all of my free time for most of December. The controller itself is a laptop conected through a USB-serial interface to a controller box I made that bitbangs the string's actual serial protocol. The control app is written in Java.
Just to make sure you have this straight:
Java app running on laptop sends opcodes like "Write this value into address $x", or "fade quickly to color #7 and stall", or "set program counter to address 63 and stall", or "begin executing code at current program counter address", for module $y (or all modules in row $y, or all modules in column $y, or all modules) to controller box.
Controller box bitbangs 9-27 bit datagram. Each "byte" is 9 bits, with MSB flagging the last byte. One byte is address (192 possible lights, 7 rows, 8 columns, one value that means "everything")
Modules receive opcodes, and act upon them. Meanwhile, the module itself is executing opcodes already written to SRAM or stored in flash. Note that these are opcodes *I* defined, not Atmel assembly-language opcodes.
The faceted diffusers actually came from a few sets of LED lights I bought at Lowe's, removed, and squeezed onto the (slightly filed-down) ends of the circuit board for each light, with the module itself protected by black heatshrink tubing.
Major design lesson I learned from this project: never, ever depend upon being able to clamp a programming clip onto a SOIC IC. Put real testpoints on the board. SOIC clips suck, they're a pain to clip on, and aren't terribly reliable (about 1/3 of the chips had to be flashed multiple times before it completed writing without errors).
If someone like Atmel were to condense my design down to a hunk of silicon with an ATtiny25 driving three RGB elements and make a "smart LED" with 3 leads (Vcc and Gnd, reversed to put it in "programming" mode, plus a third pin to use for unidirectional serial or bidirectional 1wire, programmed with a protocol like Atmel's debugwire), and each LED were 9v-tolerant with onboard regulator, a string of these lights could probably be manufactured for about 70c per light commercially.
In all honesty, Microsoft would have been a good marriage for RIM. Up until very, VERY recently, "Blackberry" was a messaging platform, not an OS per se. It has NO REASON to BE an "OS" per se. "Blackberry" (the messaging platform) could live perfectly well as a corporate-friendly isolated virtual machine running under Android and/or Windows Phone, maybe partitioned off in another core with its own private RAM. Microsoft already owns the hearts and minds of America (and most of the world's) IT Elite (not necessarily the footsoldiers, but it's solidly got the CIO mindshare). It had the perfect marriage between Exchange, Blackberry, and Windows Phone sitting in plain view, ready to grab.
In the long run, we all know where RIM is going to end up if they don't screw things up totally: a corporate-friendly Android semi-fork with IT-approved management, security, and partitioning. Good for RIM and Android, epic fail for Microsoft. If Microsoft has any sense at all, they'll be doing everything possible to court RIM's favor to try and create a situation where RIM/Blackberry is closely associated with Android & Windows Phone, and NOT associated with iPhone. In a perfect world for users, RIM will support all three platforms as equal peers and strive for platform-agnosticism.
Sprint's not evil, they're just kind of bumbling and screw up a lot (like Team America). Verizon is a metaphorical evil genie, and AT&T is the bastard love child of Satan and Saddam Hussein.;-)
Sprint has been known to send nastygrams to subscribers who *egregiously* go over 5gb, month after month after month, and occasionally fires customers who are out of contract and do it... but it's pretty rare. You have to abuse Sprint and data pretty badly and be a total pain to get dumped as a customer, especially if you're on a full-priced individual Android plan. The people who really end up on Sprint's hit list are the ones who somehow managed to stack discounts over the years and now pay something ridiculous, like $80/month for a half-dozen lines, and somehow manage to use unbelievable numbers of minutes and megabytes from all of them month after month.
Pretty much any drive using a Sandforce 1200 controller (and probably all Sandforce controller chips, for that matter) is vulnerable to the "8mb drive" bug, even one made by Intel. I believe Intel either called off their partnership with Sandforce, or put it on hold indefinitely, precisely because they weren't about to blindly put their faith in a black-box controller chip they couldn't try to fix themselves if something went wrong.
The big problem with Sandforce is their insistence on keeping everything about their controller chips a black-box secret locked behind NDAs, and the way they insist on tying the hands of even their largest customers so they can't try to fix bugs themselves. It's several orders of magnitude harder to replicate and troubleshoot a black-box failure than to find a bug when you have the source in front of you and can examine its official logic directly. I believe this is the main reason why OCZ itself ended up walking away from them and buying Indilinx -- they got tired of playing Russian Roulette with every new generation of Sandforce drive controller that seemed to end up having the same fundamental problems as the drives that came before it.
Sandforce2 (1200) failures have nothing to do with MLC-vs-SLC, and everything to do with buggy firmware that can corrupt its config data and crash a few minutes after startup if it gets powered down (or put into sleep mode) "wrongly" with the scratch data in a partially-updated or corrupt state. Everyone was so obsessed with long-term data retention life and rewrite cycles that even WORSE failure modes ended up falling through the cracks and becoming the real problem, instead.
Does it really matter whether the flash on a drive can survive 1000, 10000, or a million rewrite cycles if it keeps corrupting itself and has to be reformatted every few weeks or months due to a firmware bug Sandforce can't/won't fix?
Don't count on it. My Vertex2/120 got into "3-minutes-to-bluescreen" mode last week. It had the latest firmware. The worst part is that you can't even run ddrescue on it, because whatever it is that ddrescue does causes the drive's firmware to crash instantly. I can read files off of it ~3 minutes at a time, but OCZ/Sandforce can't be bothered to give us a recovery util to let us just rip the raw sectors in a dd-like manner for offline recovery. The official party line is that the drives aren't broken, because they can be made operational again via erasure and reformatting. Of course, that does nothing to get the data back.
I'm so totally over this piece of $hit drive it's not funny. If I hadn't paid so much for it, I'd smash it to bits with a hammer and post the video to Youtube for lulz. The worst part is that there's nothing anywhere to suggest that it will be any more reliable after I've erased and reformatted it, and RAID1 mirroring with a second identical drive won't do a thing to help avoid this same failure mode.
Slashdot Mirror
> TV channels being a finite resource, a free market of channels couldn't exist, thus regulation is required.
Except for the fact that in most countries, terrestrial broadcast TV is now commercially-irrelevant, and satellite capacity is mostly a function of available capital to launch satellites and how big of a dish customers will tolerate (bigger dish = ability to shoehorn more satellites into a given arc of equatorial orbit). A 75-ohm coax cable can carry several hundred HD channels, and thousands of SD channels. Upgrade to fiber, and you're basically talking about enough raw bandwidth to let every customer have multiple on-demand HD channels of his own. 25 years ago, orbital slots were in high demand. Now, with spot beams roughly 100km diameter, all you need is a more expensive satellite and/or bigger dish with greater selectivity & gain to make any perceived "shortage" of channels or orbital slots an academic abstraction.
> As long as you have a means to obtain the correct M.IP profile 0 data (which consists of some IP configuration,
> your NAI and HA and AAA passwords), your EVDO will work.
Hmmm. This is the best explanation of the reason why Sprint phones (even hacked ones) generally can't do EVDO on Verizon (unless they're identical twins of a Verizon phone that gets flashed to Verizon firmware, like the old Sprint PPC6700 and Verizon xv6700 WinMO phones ~5 years ago).
Do you know offhand, is the M.IP profile data a "userspace" config now (in the Android/iPhone era)? From what I recall a few years ago from the discussions at XDA (back around 2007, in the WinMo era), the main problem was that the config data is/was part of the radio modem firmware, the radio modem firmware is distributed in encrypted form, the phone's bootloader won't flash it unless the cert & signature validates, and there was some technical reason why it was impossible to rip the radio modem firmware from an unrelated Verizon phone (with the same radio modem chipset) and flash it to even a fully-hacked Sprint phone.
In other words, you could trick the bootloader into making a Sprint phone look like its Verizon identical twin so it would allow you to reflash the radio modem, but you wouldn't have been able to pull it off with two phones that differed even slightly (like the Epic4G and Fascinate), even if most of the "core" hardware were identical (and the radios were absolutely identical). I think it only worked for the 6700 because the Sprint and Verizon phones were literally identical in every meaningful way hardware-wise.
I've always thought something like that would make an awesome plot for a Sci-Fi movie -- people use transporters to go everywhere, multiple times per day, but the reality is that you end up with two conscious copies of the same person, and the old one gets automatically destroyed once the copy and replication is complete. The new copy steps out at the other end feeling like the teleportation worked flawlessly, and the old person (itself a multi-Nth copy of the person who was born years earlier) stands in the booth wondering why it's not working, until he gets killed and vaporized (with people who've seen the process believing it's part of the teleportation process, instead of a purely destructive clean-up act, and very few genuinely understanding what's really going on... because nobody would ever step into such a booth knowing that they themselves were going to effectively die, even if their "consciousness" lived on after replication elsewhere).
Now, imagine a teleporter whose "destructor" system fails after working well enough to injure (instead of kill) someone who just teleported, and leaves him convinced that terrorists are systematically murdering people -- and has no idea that it's now teleportation machines are *intended* to work, and eventually manages to teleport home from work after a visit to the hospital, only to run into himself#2.n, who just uneventfully teleported home from work after a perfectly normal day that included about a half-dozen teleportations that worked "without incident".
Now, stir in some extra details to make it a real story... engineers who stumbled on the truth while trying to reverse-engineer the process for a start-up competitor (who were summarily committed to a mental institution, because at that point, teleporters had been used by everyone multiple times per day since birth, and the whole *idea* that teleportation == death was viewed as ludicrous... were hospitalized, then truly went insane after being forcibly teleported multiple times per day at the mental hospital (knowing each time what was really happening to them). Add a legal system completely unprepared to deal with both the consequences of having two copies of the same person, and a society where all other forms of transportation had effectively ceased to exist and teleportation was literally the only way to travel more than a few thousand feet (even elevators were replaced by teleporters by that time, and stairs were increasingly uncommon).
Fun stuff ;-)
Just to add, even if a US judge were to block carrier SIM-locking, it would be almost meaningless in the US due to the way Sprint, Verizon, T-Mobile, and AT&T run.
Sprint's network will literally refuse to talk to a phone that attempts to identify itself as a subscriber phone with a MEID that isn't in Sprint's official database of Sprint-branded phones.
Verizon authenticates EVDO via firmware extensions that don't exist in Sprint phones, so Verizon's network will refuse to negotiate EVDO connections with a theoretically-unlocked Sprint phone.
T-Mobile's frequency bands aren't supported by default in most GSM phones (most new chipsets can do them, but few phones have support for 1700MHz uplinks enabled, the Samsung Galaxy S i9000 sold internationally is one of the very, very few exceptions).
Most European phones can roam on AT&T, but AFAIK, HSUPA is a semi-proprietary extension to UMTS that's mostly unique to AT&T and not used in Europe(?), so even European phones capable of doing 3G on AT&T will be limping along at less than the max data rate (not 100% sure about this one, but I've seen it widely reported that only AT&T-branded phones can achieve the maximum HSUPA data rates)
> Can someone unlocked a US-based iPhone in Chile?
You'd be wasting your time, if the intent is to use it in the US.
A non-Sprint iPhone will never work on Sprint as a customer phone (but can roam on Sprint if your carrier has agreements with them). Sprint just won't allow it, period.
A non-Verizon iPhone will never do EVDO on Verizon, even if you can get it to limp along with CDMA2000 voice and 1xRTT.
A non-AT&T iPhone will almost certainly never do HSUPA on AT&T, and would almost certainly cost way more than just buying an AT&T iPhone.
In theory, an unlocked iPhone could be used with T-Mobile, but (drumroll, please) will never do anything better than EDGE. There's no hard technical reason why an AT&T, Sprint, or Verizon iPhone can't do 1700/2100 HSPA+ on T-Mobile (their MSM6600 chipset is certainly capable of it), but an an end user you'll never, ever get it to work because the radio firmware is separate, with its own heavily-encrypted bootloader, and no iPhone sold anywhere on earth has 1700/2100 HSPA+ enabled in its radio modem firmware.
It's sad. Apple basically has one hardware design for all of its iPhones, but the three US models are intentionally as non-interoperable with each others' networks as their firmware can make them be.
It could also be a case of, "My iPhone or Android phone broke in November, and instead of spending more than it's worth to fix it, I'm just going to limp along with my old phone for a few weeks and get a brand new "best of breed" Android phone for Christmas"
> After it's "broken" the warranty and everything goes out the window.
They say it is, but it's a deliberate lie (which, unfortunately, is not itself illegal in the US). Escalate to a manager, mention the Magnuson-Moss Warranty Act, and you'll have no problems. Under the MMWA, they can only refuse warranty coverage if they can prove that the failure was DIRECTLY caused by rooting and/or reflashing.
Put another way, if reflashing your phone to stock firmware fixes the problem, they can anally-rape you with service charges for wasting their time.
If your custom ROM took two GPIO pins that were connected together (and normally tristated) & burned them out by making both "outputs" & setting one high & one low, they can legitimately deny warranty coverage for anything related to those two pins (though you could possibly argue back that directly connecting them without even a resistor in between was itself a design flaw, unless they could prove they had a legitimate engineering reason for doing it (like charlieplexing multiple LED elements from a small number of actual GPIO pins).
Under MMWA, there are very few reasons why they can legally deny warranty coverage, but they aren't obligated to troubleshoot your custom ROM for you. Like PC manufacturers who are free to reimage your hard drive as part of a repair, phone mfrs. are free to reflash it to stock firmware with a JTAG (or give you a new/repaired phone with stock firmware), and aren't obliged to preserve your firmware.
Half of Nokia's problem was the fact that they basically wrote off the US as a market, without grasping that its mindshare and influence was several orders of magnitude greater than the number of phones sold might otherwise suggest. Symbian for all intents and purposes didn't exist in the US (I think Sony-Ericsson had a few that could do 3G on AT&T, and limp along with EDGE on T-Mobile, if you paid $800 to import one) , and as a practical matter neither did Nokia phones capable of doing anything better than GPRS from around 2004 until around 2009. As far as American tech review sites were concerned, Nokia didn't exist anymore. Because in America, they didn't.
> Many Android phones, such as those from Samsung, are also "rootable" (the other 1% of the jailbreak)
> without any hacks.
Rootable, but not necessarily reflashable with AOSP or Cyanogen unless you're willing to sacrifice 4G data. For some inane reason (most likely having to do with Clear, its lawyers, and/or Sprint's status as an arms-length thirdparty customer instead of 95% of their reason for existing in the first place), Sprint and Samsung have never made it particularly easy to get 4G working in any unblessed configuration -- not even the allegedly 100% open Nexus S. It's not quite *impossible*, but 4G (wimax) data always seems to be the first thing that breaks and the last thing that gets fixed every time a newer kernel than Samsung has officially released is required to run a newer version of Android.
> Yep - can't root my Moko FreeRunner.
You also can't use it for meaningful data in the US. They (and Trolltech) stupidly decided to use a GSM chip that can't do EDGE, and only supports 1900/2100UMTS, instead of spending about $5 more to get the pin-compatible next version up that supported EDGE (and, I believe, 850/1900MHz UMTS), which means they're GPRS paperweights in the US.
> Imagine how bad overpopulation would be if we all lived to be 150.
We'll "all" *never* live to be 150. At best, a percentage of those who currently make it to 100 might make it to 150, and most of those who make it to 40 would probably make it to 80 or 90. Even if cancer gets decisively vanquished like polio, people are still going to have fatal car wrecks, fall from ladders & roofs, die from snakebites, get shot by street thugs, and have medical emergencies in awkward places.
If anything, given that most western countries now reproduce below the rate of replacement, extending the death date by a couple of decades would do little more than maintain the population status quo. Fewer kids, but more great-great-...-grandparents.
> If you want to push the metric system, start with the meteorologists, weather broadcasts and such.
> If people are eased into thinking of the temperature in metric the other systems will be that much easier.
Good god, temperature is the *worst* part of the metric system. I mean, WTF. How often does anybody genuinely *care* that the freezing point of distilled water at sea level is exactly zero degrees, and the boiling point of the same is exactly 100? When was the last time somebody making a cup of tea put a thermometer into the tea kettle to measure the water's temperature as it approached 100C?
For answering the specific question, "How hot (or cold) is it outside?" Fahrenheit is damn near perfect. 0F isn't just cold... it's the point where it genuinely starts to become *dangerously* cold. Likewise, 100F isn't just "hot" -- it's the point where it becomes *dangerously* hot. The temperature at which puddles turn into ice, and your lips crack from wind, can vary by several real-world degrees... but 0F is always going to be really, really, bitterly cold, and 100F is approximately the point where people start throwing up and passing out from heatstroke. In weather terms, 0C is almost meaningless... it might feel bitterly cold, or (in Antarctica during the summer, where it's basically a cold desert with minimal humidity) it might be warm enough to go outside wearing shorts (for a few minutes, anyway) -- at least, if there's no major wind chill.
> It's a phone.
No, it's a pocket laptop with pervasive mobile wireless internet connectivity that happens to be capable of making voice phone calls, if that's really what you want to do.
> The shocking thing is that even though it was a beta, Galaxy S was arguably the best android phone on the market for at least 6 months.
Maybe the I9000, but the Sprint Epic 4G sure as hell wasn't. The GPS was utterly dysfunctional until Froyo (finally) arrived (~9 months after release), and only marginally better thereafter. We were stuck with 2.1 for eternity, and couldn't run AOSP Froyo without giving up 4G.
Ah, I didn't see the detail about being a visitor to the US. I thought he was advocating it as a cost-saving strategy for Americans who think they won't use "a lot" of data with an Android phone just because they haven't used much data in the past with a non-Android phone.
$2/day isn't very cheap if you're actually using it daily. For about $20/month more, you could get a full blown Android plan with subsidized phone and more or less unlimited everything besides daytime voice minutes (450 peak minutes), with 3G speeds and 4G where available. Factor the $20/month extra into the roughly $200-400 discount on a best of breed Android phone like the SGS2/Evo3D/Photon, and at worst you're breaking even and getting way more for your money.
Before you say "I wouldn't be using it daily"... yes, once you get a best of breed Android phone, you will, because you'll discover all kinds of things that were dysfunctional internet-wise on older phones that suddenly work well, and you'll find yourself using them anytime you're stuck in a line somewhere, waiting for something, or just bored. Plus, it's EXTREMELY difficult to make an Android phone not sip (if not inhale) data 24/7. It can be done, but it's something you have to actively work to make happen. Any data plan where your billing unit is "minute where at least one byte of data gets transferred" will positively bankrupt you with an Android phone if you forget to disable data, because so many apps endlessly sip data nonstop in the background. Not enough data to really make a difference with a normal plan, even one that's capped at 2 gigs... but plenty to run up a gigantic bill if you're getting metered by the "data-minute" rather than by the megabyte.
The patent he's referring to is almost the poster child for everything that's wrong with America's patent system. It was granted at the point when the patent office officially disregarded prior art that wasn't itself patented, and the main "innovation" (PWM-wise) was the addition of a blue LED to the red and green one -- something endlessly discussed on Usenet for years, but not physically practical until blue LEDs became commercially-available for the first time in the late 90s.
Nobody seriously believes it would ever survive a real challenge in court, but due to the way America's patent system works, it'll probably never get invalidated before it expires on its own.
The biggest single meaningful reform we could get to the patent system would be to allow a group of self-selected stakeholders to collectively gang up on a patent holder and share the cost of a proactive lawsuit to get it overturned & invalidated, or at least a rule that if you sue somebody for infringement, THEY can force you to pursue the lawsuit to its final judgment (so you can't just drop the suit and risk having your ability to sue OTHERS invalidated if things start going badly), and if the patent holder gets a case dismissed with prejudice against them, apply the same prejudice to all future lawsuits regarding the same patent.
This would raise the stakes enormously, and force patent holders to pick and choose their battles carefully. One ill-conceived lawsuit against an independently-wealthy (or legally-trained & willing to make it his personal crusade pro-se) Aspie determined to teach "you" (the hypothetical patent troll, not the poster above) a lesson, and your patent could get flushed down the toilet over a $10,000 shakedown attempt against someone who's practically judgment-proof compared to the patent's theoretical value. Big companies would still play chess with each other, but empowering "small fry" to say, "no, I'm not going to ALLOW you to just drop the issue and go home with your ball. You picked the fight, and now I'm going to beat you to a pulp fair & square" would raise the stakes considerably and make life for patent trolls a lot more difficult.
Pure geekgasm, I present my Christmas tree as posted to Youtube 3 years ago (I haven't had time to do a new video since then, but the lights still entertain me and my guests; view my Youtube channel, and you can find the old version of the video and the rough draft of the next year's) -- http://www.youtube.com/watch?v=U5qR9_8KGPU
Note: the website mentioned at the beginning of the video expired last year, so don't try going there. It's probably a trojan-filled pr0n site by now.
Technical specs: each light has an Atmel ATTiny25 with RGB LED, resistors, decoupling capacitor, and 5v linear buck regulator so I can power the string with 13.6v. The string has 3 wires: Vcc, Ground, and serial. The light modules have their own interpreted language that includes things like "fade to $color at $rate, then (stall/pause a while/pause briefly/continue)" and row-column addressing (so I can apply an opcode to every light in a row, every light in a column, a single light, or all lights on the tree). The serial bus itself is actually quite slow (~300bps), with most commands requiring 2 or 3 bytes. The complicated effects were created by writing commands into SRAM, then stepping through them globally so everything sync'ed up.
Total cost of the string you see on the tree: about $1,200 worth of parts, plus the better part of 3 or 4 months soldering and assembling them. The circuit itself, and the onboard firmware, evolved over 3 years. The song in the video took me about 3 weeks to do, and occupied pretty much all of my free time for most of December. The controller itself is a laptop conected through a USB-serial interface to a controller box I made that bitbangs the string's actual serial protocol. The control app is written in Java.
Just to make sure you have this straight:
Java app running on laptop sends opcodes like "Write this value into address $x", or "fade quickly to color #7 and stall", or "set program counter to address 63 and stall", or "begin executing code at current program counter address", for module $y (or all modules in row $y, or all modules in column $y, or all modules) to controller box.
Controller box bitbangs 9-27 bit datagram. Each "byte" is 9 bits, with MSB flagging the last byte. One byte is address (192 possible lights, 7 rows, 8 columns, one value that means "everything")
Modules receive opcodes, and act upon them. Meanwhile, the module itself is executing opcodes already written to SRAM or stored in flash. Note that these are opcodes *I* defined, not Atmel assembly-language opcodes.
The faceted diffusers actually came from a few sets of LED lights I bought at Lowe's, removed, and squeezed onto the (slightly filed-down) ends of the circuit board for each light, with the module itself protected by black heatshrink tubing.
Major design lesson I learned from this project: never, ever depend upon being able to clamp a programming clip onto a SOIC IC. Put real testpoints on the board. SOIC clips suck, they're a pain to clip on, and aren't terribly reliable (about 1/3 of the chips had to be flashed multiple times before it completed writing without errors).
If someone like Atmel were to condense my design down to a hunk of silicon with an ATtiny25 driving three RGB elements and make a "smart LED" with 3 leads (Vcc and Gnd, reversed to put it in "programming" mode, plus a third pin to use for unidirectional serial or bidirectional 1wire, programmed with a protocol like Atmel's debugwire), and each LED were 9v-tolerant with onboard regulator, a string of these lights could probably be manufactured for about 70c per light commercially.
In all honesty, Microsoft would have been a good marriage for RIM. Up until very, VERY recently, "Blackberry" was a messaging platform, not an OS per se. It has NO REASON to BE an "OS" per se. "Blackberry" (the messaging platform) could live perfectly well as a corporate-friendly isolated virtual machine running under Android and/or Windows Phone, maybe partitioned off in another core with its own private RAM. Microsoft already owns the hearts and minds of America (and most of the world's) IT Elite (not necessarily the footsoldiers, but it's solidly got the CIO mindshare). It had the perfect marriage between Exchange, Blackberry, and Windows Phone sitting in plain view, ready to grab.
In the long run, we all know where RIM is going to end up if they don't screw things up totally: a corporate-friendly Android semi-fork with IT-approved management, security, and partitioning. Good for RIM and Android, epic fail for Microsoft. If Microsoft has any sense at all, they'll be doing everything possible to court RIM's favor to try and create a situation where RIM/Blackberry is closely associated with Android & Windows Phone, and NOT associated with iPhone. In a perfect world for users, RIM will support all three platforms as equal peers and strive for platform-agnosticism.
Sprint's not evil, they're just kind of bumbling and screw up a lot (like Team America). Verizon is a metaphorical evil genie, and AT&T is the bastard love child of Satan and Saddam Hussein. ;-)
Sprint has been known to send nastygrams to subscribers who *egregiously* go over 5gb, month after month after month, and occasionally fires customers who are out of contract and do it... but it's pretty rare. You have to abuse Sprint and data pretty badly and be a total pain to get dumped as a customer, especially if you're on a full-priced individual Android plan. The people who really end up on Sprint's hit list are the ones who somehow managed to stack discounts over the years and now pay something ridiculous, like $80/month for a half-dozen lines, and somehow manage to use unbelievable numbers of minutes and megabytes from all of them month after month.
From Sprint subscribers, too. T-Mobile's our lifeboat and sanctuary if Sprint becomes evil someday.
Pretty much any drive using a Sandforce 1200 controller (and probably all Sandforce controller chips, for that matter) is vulnerable to the "8mb drive" bug, even one made by Intel. I believe Intel either called off their partnership with Sandforce, or put it on hold indefinitely, precisely because they weren't about to blindly put their faith in a black-box controller chip they couldn't try to fix themselves if something went wrong.
The big problem with Sandforce is their insistence on keeping everything about their controller chips a black-box secret locked behind NDAs, and the way they insist on tying the hands of even their largest customers so they can't try to fix bugs themselves. It's several orders of magnitude harder to replicate and troubleshoot a black-box failure than to find a bug when you have the source in front of you and can examine its official logic directly. I believe this is the main reason why OCZ itself ended up walking away from them and buying Indilinx -- they got tired of playing Russian Roulette with every new generation of Sandforce drive controller that seemed to end up having the same fundamental problems as the drives that came before it.
Sandforce2 (1200) failures have nothing to do with MLC-vs-SLC, and everything to do with buggy firmware that can corrupt its config data and crash a few minutes after startup if it gets powered down (or put into sleep mode) "wrongly" with the scratch data in a partially-updated or corrupt state. Everyone was so obsessed with long-term data retention life and rewrite cycles that even WORSE failure modes ended up falling through the cracks and becoming the real problem, instead.
Does it really matter whether the flash on a drive can survive 1000, 10000, or a million rewrite cycles if it keeps corrupting itself and has to be reformatted every few weeks or months due to a firmware bug Sandforce can't/won't fix?
Don't count on it. My Vertex2/120 got into "3-minutes-to-bluescreen" mode last week. It had the latest firmware. The worst part is that you can't even run ddrescue on it, because whatever it is that ddrescue does causes the drive's firmware to crash instantly. I can read files off of it ~3 minutes at a time, but OCZ/Sandforce can't be bothered to give us a recovery util to let us just rip the raw sectors in a dd-like manner for offline recovery. The official party line is that the drives aren't broken, because they can be made operational again via erasure and reformatting. Of course, that does nothing to get the data back.
I'm so totally over this piece of $hit drive it's not funny. If I hadn't paid so much for it, I'd smash it to bits with a hammer and post the video to Youtube for lulz. The worst part is that there's nothing anywhere to suggest that it will be any more reliable after I've erased and reformatted it, and RAID1 mirroring with a second identical drive won't do a thing to help avoid this same failure mode.