>Why not just start and end work one hour earlier?
Because for most of us, our working hours are set by faceless drones in New York hellbent on making the human race start work between 8 and 9am. They don't care when the sun rises or sets, they just care that the clock says 8 or 9. It's easier to convince our elected officials to permanently make Eastern time GMT-4 than to try and convince our faceless overlords in New York to let us start work at 10.
> In Los Angeles, some freeways are jammed from 6 AM to 10 AM and then again from 3 PM to 7 PM or later. > Staggering business hours won't help there.
Ditto, for Miami, and most other cities. The fact is, "staggering work hours" won't work, because work hours are ALREADY staggered about as much as they're ever going to be.
Instead of abolishing DST, let's abolish "winter time" and stay on DST all year. The single biggest factor behind gridlock in South Florida is the time the sun goes down. When the sun goes down at 7 or 8pm, people drift home from work starting around 3pm and continuing until 7 or 8, so just about everyone ends up getting home within 30-60 minutes. The day after DST ends (and the sun goes down ~6pm), literally EVERYONE runs for the door at 5pm to try and beat the sunset, and ends up causing gridlock that persists until 8pm while everyone sits in their cars for 150% as long.
You know, it amazes me that whomever ended up owning Sierra Online's IP never officially resurrected their "VGA-era" remakes for iPhone and Android (if not Palm). I personally experienced "Day of the Tentacle" for the first time running under ScummVM on a Treo (we were having a hurricane, I knew we were going to lose power, and loaded it up in preparation so I'd have something to play when the lights went out), and it ran fairly well. If Sierra had any foresight (and whomever ended up inheriting them had any brain), they probably digitized everything at 640x480 & downsampled them from that point anyway (or still have the original art ready to re-digitize at 480x848), and with just a few tweaks, they'd sell like crazy (even people who know they can rip and run them with ScummVM would probably just say 'screw it' and pay a buck or two to save the trouble).
Ya know, one of the most psychologically-disturbing programming projects I worked on involved C++ and AVR microcontrollers. Why? Because for some reason that eludes me at the moment (it's been a few years... I think it had something to do with objects created with 'new' prematurely falling out of scope and either a libavrc or a toolchain bug), you couldn't actually use "new" to create objects -- you had to get a pointer from malloc(sizeof(DesiredObject)) and cast it to a pointer to an object of the desired type. Intellectually, I could deal with it. Emotionally, it was a total mindfuck. Everyone said it was just the way you had to do it (for the time being, at least), but it just plain felt *wrong*, if not downright *immoral*.
Maybe I was just being stubborn, but it was a huge turn-off. It convinced me that C++ just wasn't an appropriate language to use for 8-bit microcontroller programming (well, that, and the fact that from what I remember, there was no official way to implement external SRAM in a way that the gcc libAVRc toolchain could gracefully take advantage of it... if you wanted to use anything besides on-die SRAM, you were basically on your own & sailing through uncharted territory).
In most places, you had to pay some stupid token surcharge, like $0.25/month, to get DTMF dialing. I say "stupid", because the phone company's equipment actually had to be programmed to IGNORE DTMF from any customer who didn't pay the extra fee. Most people paid it, but there were some people who refused... especially late in the 80s, when people started to buy their own phones & the phones themselves could pulse-dial from a keypad.
There were also lots of places where paying extra for DTMF service didn't actually save any dialing time vs pulse-dialing. If you paid the DTMF surcharge, then had your phone autodial a number, you'd hear the phone company's equipment pulsing the last few digits after it sent the tone burst.
> There is greater distance between our population centers and most of our workers commute longer distances.
You're not exactly *wrong*, but that's far from telling the whole truth. The fact is, plenty of Europeans live out in the 'burbs too, once you get away from London and Paris. The difference is that in Europe (and Asia), they'll build a rail line through virgin farmland, then rezone the area around the station to encourage high-density development around each one. So, people who live out in the suburban boonies (so to speak) drive 5-10 miles to the nearest train station, park, walk past the dense quasi-urban development around their own station, and ride the train to another staion 20-50 miles away that's within walking distance of their office.
In the US, we do stupid things like build suburban rail stations, then leave the surrounding area zoned for low-density single family homes and strip malls because our idiot planners don't want to "encourage sprawl" by allowing high-density development in suburbia. So, instead of having high-value concentrated commercial development (and a few fairly expensive residential buildings) within easy walking distance of OUR rail stations, we end up with low-density development oozed across a thousand square miles, and $50-100 million transit stations adjacent to nothing besides a parking lot and single-family homes.
It's not practical to expect most American suburbanites to move, but it's ENTIRELY reasonable to expect new commercial development to cluster around transit lines with a little help from aggressive up-zoning around their stations. It doesn't happen overnight, but it DOES happen within a generation or two (just look at area surrounding many of Miami's Metrorail stations south of downtown, the Washington Metro in Virginia, BART in San Francisco itself, etc).
The problem is, the one model for transit-optimized commercial development that's been shown to work and be viable in the US goes against everything traditional urbanists regard as holy & sacred, because it accepts the fact that most people are going to live 5-10 miles from the nearest rail station & drive there, and settles for putting their DESTINATIONS within convenient walking distance of stations (usually, with the expectation that existing urban areas will just be commercially-abandoned, written off as slums, and replaced by the shiny new commercial hubs built around the new transit stations on former farmland out in the boonies).
There's also the fact that urbanists have a fetish for "downtown" development, as opposed to rubber-stamping dozens and dozens of mini skyscraper clusters and vertical stacks of big-box stores ( like http://www.berkowitzdevelopment.com/dadeland.htm ) every mile or two all the way from downtown out to BFE.
Sounds like Metrorail in Miami. The last time gas prices spiked, they cut back service to 30 minutes in the afternoon, evening, and weekends. The feds told them point blank that they could forget about getting money for Metrorail expansion anytime soon if THAT was how they were going to squander a multi-billion dollar heavy rail transit system.
Then again, we're talking about the most incompetent and/or corrupt transit agencies in America... one that was LITERALLY soliciting bids for the disposal of its existing railcars before it even secured funding and bids for their replacements, for no reason besides "they were built for 30 years of service, and went into service 28 years ago". A transit agency that rakes in MILLIONS of dollars per year in transit sales tax revenue that was approved by voters promised large-scale Metrorail expansion, then squandered on buses, illuminated street signs, and pretty much everything BESIDES actual new track.
Or designing them with additional sidewalks and bike paths connecting the cul-de-sacs so they still work as intended (keeping cars from driving through the neighborhood) without interrupting pedestrian and bicycle flow.
"push" email is fundamentally different from "push" web content.
Incoming phone calls & SMS messages don't get "broadcasted" to phones in the area -- the individual phones actively poll the network for incoming calls & SMS every couple of seconds. The phone broadcasts its poll request to the tower, and the tower replies back with a ~160-byte reply that indicates whether there's an incoming phone call, or the content of a text message, or a code that lets the phone know that there's content being pushed that's available to be fetched.
I'm not 100% sure about GSM networks, but on CDMA networks, the phone can poll for incoming calls/SMS faster & with less power than it takes to establish a full-blown active EVDO data session. I believe a similar situation exists with respect to legacy GSM vs UMTS/HSPA. SO... instead of taking the time and power to establish a data connection so the mail app can poll the mail server, push email allows the mail server to notify the mobile network that one or more new messages have arrived. The next time the phone polls the network for incoming calls, it gets a reply that means, "no incoming calls, no incoming SMS, but there's at least one new email waiting on the server". The phone gets the reply, sees the "new email" flag, and THEN launches the mail client, which brings up a full data connection and updates itself from the server.
In other words, instead of having to keep waking up the phone, establishing a full data connection, and keeping the phone awake long enough to poll the mail server, you can keep the phone mostly asleep, and wait until the network notifies you that there's a new message before going to the trouble of contacting the mail server itself.
"Push" in this context is also different from using persistent UDP sockets (the way IMAP NOTIFY does).
When in doubt as to whether or not something is "genuinely" push or not, it helps to look at the pushed payload itself. If the pushed payload is just a notification that something is waiting on the server, it's probably "real" push. On the other hand, if you're actively polling a server for the message itself, it's probably not "real" push.
Most of the time, there's not a whole lot the original owner can do if it's a consumer-grade hard drive. I believe some enterprise laptop hard drives are encrypted by a key that can be blown away (rendering the data on the drive into digital noise) regardless of whether or not the drive is working properly, but it's rare for consumer (or enterprise drives used in servers, for that matter) to make use of the feature because it reduces your odds of ever performing successful data-recovery on the drive down to approximately "zero" if the drive fails due to a controller failure.
Given a choice between a tiny risk of unauthorized disclosure, and the overwhelming risk of permanent data loss, most people will roll the dice with unauthorized disclosure... especially anybody who's had literally dozens of hard drives die since the late 80s (and noticed that the failure rate seems to be INCREASING over the past few years), but never had one actually get *stolen*.
For obvious reasons, "secure erase" by blowing away a whole-disk encryption key isn't something you want to be TOO easy to initiate (ideally, it should only be possible to do with a jumper in place that's not there by default), because otherwise you'd have the ULTIMATE denial-of-service trojan attack vector.
The problem is that in most cases (with the possible exception of the oringinal Evo 4G), an extended battery means forgetting about a gel-type case to keep the phone from guaranteed destruction if it falls more than 3 inches.
I wish we could have TWO batteries... a non-replaceable one that's ~2200mAH and fills every nook and cranny of the phone's interior with lithium ion gel, and a commodity one that's ~1600mAH that can be easily swapped in and out. You'd need slightly more complicated charging logic from a 500mAH power source (charge the fixed battery first, drain the removable battery to 25% before using the fixed battery) and a bigger charger to do both at once, but then we'd have phones that were about a millimeter thicker, but could go for 30+ hours with aggressive use before dying.
> The iPhone - and it really was the first in this category - got people to charge their phone every single night
No, it got people to carry chargers everywhere, and panic if the restaurant doesn't have a power outlet at the table. Apple legitimized undersized, wimpy batteries. If manufacturers weren't hellbent on making sure that every new Android phone is a fraction of a millimeter thinner than the latest iPhone, and just gave us another 3x5 inches of millimeter-thick 3500mAH battery goodness, we could go back to having phones that can be used aggressively all day, all evening, and still have enough power in the morning to last until noon. But no, we're forced to settle for pregnant lumps with half the area and double the thickness that render the phone incapable of fitting in any reasonable case, so we're stuck gambling between the phone's destruction and a dead battery.
There IS a middle ground between Apple (battery that maximizes capacity per area, but can't be user-replaced easily) and Android (lumpy battery that's a commodity, but undersized) -- put two batteries in the phone. One, that's iPhone-like and not (easily) replaceable, and one that's like typical commodity batteries. Set up the charging logic to always drain the commodity battery first, and charge the fixed battery first. That way, we'd get ~30 hours of use from the fully-charged pair, but could keep swapping $3 (from China) secondary batteries all day for another 3-6 hours of power if necessary.
Actually, that one's not quite as ridiculous as it sounds, assuming the technology isn't much different from home thermostats. AFAIK, home thermostats in an old home with only a furnace might have as few as two wires: one that's approximately 24Vac, and one that gets connected to it whenever the furnace should turn on. A newer home with an air conditioner might have two or more additional contacts for the a/c compressor & blower, and possibly 24vac of its own. I believe that most use battery power for the digital logic, but use the 24vac to energize the relay coils. I believe most home digital thermostats were historically battery-powered because the logic doesn't draw much power, and because it prevented the programming from getting lost whenever the power were shut off at the breaker.
Fast forward to 2012. For literally a few cents, you can buy an 8-bit microcontroller with real eeprom and flash, and a linear power supply to convert 24vac into 5vdc is far from being rocket science. Instead of relying upon continuous power to keep the settings alive, you can just write them to flash, and read them back when power gets restored. I believe this is more or less the nature of their patent.
Assuming I'm mostly right, this is a pretty lame patent. Unfortunately, it probably does meet the technical standards for being granted. I can only assume that Honeywell grabbed it because the market for home thermostats has traditionally been so small, few other companies have even bothered with it (I mean, let's be honest... how often do most people REALLY replace their thermostats?), so nobody else even thought about filing a patent for it first.
Of course, there's the qualifier you breezed right over: "To promote the Progress of Science and useful Arts...." Although (AFAIK) the Supreme Court has never entertained a challenge based upon the premise that a given law *impedes* progress, it's not inconceivable. The catch is, the Supreme Court can't be forced to hear a case, and it's unlikely to do so unless we someday end up with a retired patent lawyer on the bench.
> I love how they state on their website that the mean time for failure is something like 130 years.
Oh, that's because the hardware ITSELF will last for 130 years. The half-life of any data you STORE on it is about 7 weeks. If the offices of both Sandforce and OCZ were replaced by smoldering nuclear craters tomorrow morning, I'd smile and say, "at least they can't screw anybody else now" (well, once the remaining inventory stocked by Amazon & Newegg was gone).
> Using RAID 1 during those circumstances is like building two houses next to a volcano instead of just one.
Yep. Just ask anybody who bought a pair of OCZ Velocity2 Sandforce-based drives and mirrored them in the hope of avoiding data loss... and had both of them simultaneously commit suicide thanks to the wonderful bug that triggers the "3 minutes to deathcrash" condition (never fear, though... the drive itself is "fine" -- just Securely Erase (tm) it, and it'll be good for a few more weeks until it kills all the data on it again).
Sandforce is the worst steaming pile of shit that has ever existed in a mainstream product. Their controllers have fucked so many users, they can't even get ENTHUSIASTS (who lose sleep at night worrying that their controller might be.05% slower than somebody else's) to care about their benchmarks anymore. The only reason I won't be chucking mine is because I might need it for the class action suit against OCZ and/or Sandforce someday.
> there are plenty of online Linux vendors that would have been MORE than happy to have his business
And how many of them sell notebooks with a Thinkpad-quality keyboard and pointer stick? Laptops are not commodities. For people who care passionately about their laptop's keyboard & pointer stick, there is but one laptop, and its name is Thinkpad. Nothing else comes remotely close.
Seriously. Go to a Thinkpad forum sometime. There are literally 24+page threads debating whether Alps, Chicony, or NMB-built keyboards are the best. I've owned two non-Thinkpads in my life, and I ended up despising both of them because their keyboards sucked (one didn't feel right, one flexed).
> Google is basically saying that the CDMA Nexus phones are no better than any other non-nexus device when it comes to "official" developer support.
That's not necessarily true. The Nexus S might not have had the full source to its wimax and CDMA drivers, but at least it HAS working binary drivers for the latest and greatest kernel needed for the latest version of Android.And it has a bootloader that can be unambiguously unlocked. If you don't think either one is important, just ask somebody unfortunate enough to own a late-model CDMA Motorola phone (like the Photon).
I'd rather have a Sprint Galaxy Nexus with up-to-the-minute proprietary kernel modules than be stuck with only their non-Nexus consumer models that have no hope of running newer versions of Android without giving up 4G, GPS, the camera, and other features that are handled by the Qualcomm chipset.
Damn. If they call off all future CDMA Nexus devices with unlocked bootloaders and up-to-the-minute kernel modules, that's going to really, really, massively suck:(
In theory, you might be able to hack a Sprint iPhone4S to do 1xRTT on Verizon (or even get an AT&T or T-Mobile iPhone 4S to do 1xRTT on Verizon), but you'll never get a non-Sprint phone to work on Sprint without spoofing the MEID of an old Sprint phone (very, VERY illegal), and due to slight difference that are entirely due to software, a non-Verizon phone's radio modem firmware can't authenticate itself to do EVDO on Verizon.
There's no technical reason why a non-Verizon phone's radio modem can't be programmed to gracefully handle both Sprint AND Verizon... they just don't do it, because Sprint/AT&T/T-Mobile have no interest in making THEIR phones interoperable with Verizon, and Qualcomm has never had the balls to push back on Sprint & Verizon both to use unified radio firmware.
In a slightly less-evil world, Americans would at least be able to go to qualcomm.com, hit the link to "download OEM drivers", grab a file like "cdma2k-spcsvzw_2-6-37-1a.ko" to get the generic Sprint+Verizon radio modem driver for a 2.6.37 kernel, drop it into AOSP, and run with it after grabbing some more files and config info specific to Sprint or Verizon. Then grab a file like "wimax-clear_2-6-37-1d.ko" to add support for Sprint wimax (or something similar for Verizon LTE).
The big problem Sprint and Verizon customers have NOW is the fact that Linux doesn't have a stable ABI, so every new kernel (required by every new version of Android) breaks the kernel modules that came before it. So if the latest kernel officially supported by your phone's manufacturer is 2.6.42, and ICS needs a 3.0.1 kernel, you're basically SOL until the manufacturer releases its official upgrade (if ever) with new kernel modules that the AOSP folks can rip out and repurpose for AOSP purposes in CDMA phones.
What Google REALLY needs to do is give us a hardware abstraction layer that works kind of like NDISWrapper, so they could say, "3.0.1 is our official kernel driver interface for the next few years", and newer Android builds would insert a thunking layer between the 3.0.1.ko module and the newer kernel (possibly, make it optional, so newer kernel modules could be used, but the older ones would still work in a pinch). THEN, whenever a new version of Android came out with a new kernel and different ABI, we could keep using the old.ko modules ripped from the stock ROM and get it to work with the newer version.
The hardware abstraction layer in Windows is a large part of the reason why you can still use XP drivers with Windows 7, and in a pinch you can sometimes still coax Win2k, or even NT4 drivers into working. In contrast, with Linux, you can't even use a kernel module compiled for 2.6.29 with 2.6.32. In the PC realm, this is a pain, but PCs are generally open enough to allow you to work around it and choose open hardware with a little bit of advance planning. In the mobile phone realm, you're just plain fucked, because every mobile phone is basically analogous to a wireless winmodem stapled onto a proprietary USB webcam and bitbanged degenerate SCSI controller.
ATSC also uses 8-VSB modulation instead of COFDM. 8-VSB has serious problems with multipath, and is damn near impossible to receive in a moving vehicle.
I believe DVB also supports h.264 as a codec, in addition to ATSC'S MPEG-2
The biggest shortcoming of ATSC was its lack of support for 1080p60 with long GOPs. It's not viable for live broadcast, but with offline non-realtime compression, you CAN do 1080p60 in 19.2mbit/sec. Just ask anybody who used to rip DVDs & re-encode them with ridiculously long GOPs and variable bitrate encoding so you could fit half of a DVD on a CD-R with minimal quality loss.
Relying on a long-lived background service doesn't work anymore. As of Gingerbread, Android will kill background services it thinks have been running for "too long", even if they're spending 99.999% of their time waiting politely and allowing the phone to sleep as necessary. Officially, you're now damned if you do, and damned if you don't.
Sorry, but Android networking is nowhere close to being that straightforward once you throw deep sleep behavior and powered-down network interfaces into the equation. Just to give one blatant example, my Motorola Photon routinely gets itself into situations where it powers down all the network interfaces, and takes an ETERNITY to re-establish the network unless I launch the stock browser long enough to manually wake it back up. I've had it showing "Zzz" for the wireless network, and observed HUNDREDS of failed requests by Apache HttpClient in a row that didn't budge the phone, and only saw the network re-connect after I manually launched the stock browser. It's almost like they hardwired Webkit to manually launch a network connection if necessary, then forgot to do the same with HttpClient. (I captured the logcat output to SD using CatLog).
If you check for connectivity, and give up without a fight or even trying to make the request anytime you see it's down, it's quite likely that you're going to go for a REALLY long time before seeing network connectivity when the phone is in deep sleep mode, even if it's allegedly connected to wi-fi and sitting next to a tower.
THIS is why we need something like "AlarmManagedHttpRequest" that gets fired on schedule, but doesn't begin executing until the phone is guaranteed to have made every reasonable effort to establish network connectivity first, and keeps the phone awake until the request either succeeds or fails. It's a straightforward thing to do at the Android framework level, but it's extremely hard to kludge safely and ROBUSTLY using the existing public API.
Yes, you can schedule your task through AlarmManager. You can even be polite and use InexactRepeat to batch requests. There are two specific problems:
1. You aren't allowed to do anything time-consuming (like make a http request) in the BroadcastReceiver that runs when AlarmManager fires off the Intent. You have to start a background service to do it. Unfortunately, Android makes no guarantees that it will even execute the BackgroundService onCreate() method before exiting the BroadcastReceiver, and Android can (and will) put the phone back to sleep the nanosecond the BroadcastReceiver's intent handler finishes running. Pure multithreaded joy.
2. The only way to guarantee that the phone can't go to sleep until the http request gets made is to grab a PartialWakeLock in your BroadcastReceiver, and release it from the background service. The thing is, you can't pass the PartialWakeLock to the background service in the call that starts it up, you can't call methods of that background service without getting a connector, and you can't tell Android to keep the BroadcastReceiver's handler running (and the phone awake) until you get that connector. So... you basically have one option left: create a class with a static PartialWakeLock (or HashMap of PartialWakeLock objects), store it there, and pray to ${deity} that Android doesn't decide to kill the class off and garbage-collect it before the service gets created, because if it does, your phone now has a zombie wakelock that can't be released.
It's a catch-22. There is LITERALLY no way for an intent fired off by AlarmManager to guarantee a successful attempt to make a http request without doing dangerous and ugly things with static references to PartialWakeLock objects. It's one of those "ohshit" API decisions that seemed like a collection of good individual ideas, then kind of fell down in one embarrassingly common real-world use case... and something anybody who writes an Android app that needs to occasionally communicate with a server in the background gets confronted with in short order.
Making matters worse, Gingerbread now kills even well-behaved background services if it thinks they've been running for "too long", even if they spend 99.999% of their existence politely using TimerTask and Java's Thread API to yield and sleep. So, the one semi-solution that used to work politely and reliably (start the service, then spend most of the time sleeping) now breaks, with no reliable and safe alternative.
What Android desperately needs is a nice, API-level convenience method that lets you create a http(s) request, complete with args, then hand it to the OS and say, "You don't have to do this *right this millisecond*, but at some point within the next ___ seconds/minutes, please wake up the phone (if necessary), establish network connectivity, make the request, then fire {this-intent} with the server's response (or failure info)" (and optionally, if the request fails, try making a test request to something like 8.8.8.8 and/or 8.8.4.4 to make sure the phone's internet access is REALLY working before assuming failure, so the program only has to deal with the failure of its own web service, instead of having to deal with the failure of the phone itself to sustain a robust network connection).
Believe it or not, right now, there's NO good, reliable, graceful way to do the equivalent of having a cron job fire off a http request when the phone is asleep. There are ways to kludge it, but they're all either unreliable (the phone will go back to sleep before it even has a chance to MAKE the http request, the network might be down because it hasn't finished reconnecting yet, etc) or dangerous (holding partial wakelocks in static variables, with no way to guarantee their release if something crashes).
Android gives developers lots of power, but it also imposes enormous amounts of responsibility that maybe 1% are really equipped to handle. In the real world, the network failure strategy of most Android applications can be summed up as "relentlessly keep beating away at the URL in the hope it might eventually work". Oh, most semi-new Android devs don't SET OUT to be irresponsible... the problem is, anybody who tries to make a single network call and fail politely and exit if it doesn't work quickly discovers that an average Sprint user will have the app die within 10 minutes (thanks to the stupid way Sprint phones thrash between 3G and 4G in quite a few real-world indoor usage scenarios). So they adopt "keep trying over and over again" as a strategy, because it makes their app work on Sprint phones, but kills the battery of anybody who's somewhere like a subway tunnel when the phone decides to make its next http request. If Google gave developers a nice, bulletproof way to politely make asynchronous http requests that can be gracefully scheduled and batched, instead of trying to hack together buggy solutions that almost work, we'd all be better off.
Slashdot Mirror
>Why not just start and end work one hour earlier?
Because for most of us, our working hours are set by faceless drones in New York hellbent on making the human race start work between 8 and 9am. They don't care when the sun rises or sets, they just care that the clock says 8 or 9. It's easier to convince our elected officials to permanently make Eastern time GMT-4 than to try and convince our faceless overlords in New York to let us start work at 10.
> In Los Angeles, some freeways are jammed from 6 AM to 10 AM and then again from 3 PM to 7 PM or later.
> Staggering business hours won't help there.
Ditto, for Miami, and most other cities. The fact is, "staggering work hours" won't work, because work hours are ALREADY staggered about as much as they're ever going to be.
Instead of abolishing DST, let's abolish "winter time" and stay on DST all year. The single biggest factor behind gridlock in South Florida is the time the sun goes down. When the sun goes down at 7 or 8pm, people drift home from work starting around 3pm and continuing until 7 or 8, so just about everyone ends up getting home within 30-60 minutes. The day after DST ends (and the sun goes down ~6pm), literally EVERYONE runs for the door at 5pm to try and beat the sunset, and ends up causing gridlock that persists until 8pm while everyone sits in their cars for 150% as long.
Utterly brilliant ad -- "We stick our graphics where the sun don't shine" -- http://www.atarimania.com/pubs/hi_res/pub_infocom.jpg
You know, it amazes me that whomever ended up owning Sierra Online's IP never officially resurrected their "VGA-era" remakes for iPhone and Android (if not Palm). I personally experienced "Day of the Tentacle" for the first time running under ScummVM on a Treo (we were having a hurricane, I knew we were going to lose power, and loaded it up in preparation so I'd have something to play when the lights went out), and it ran fairly well. If Sierra had any foresight (and whomever ended up inheriting them had any brain), they probably digitized everything at 640x480 & downsampled them from that point anyway (or still have the original art ready to re-digitize at 480x848), and with just a few tweaks, they'd sell like crazy (even people who know they can rip and run them with ScummVM would probably just say 'screw it' and pay a buck or two to save the trouble).
Ditto, for the c64 version :-)
Ya know, one of the most psychologically-disturbing programming projects I worked on involved C++ and AVR microcontrollers. Why? Because for some reason that eludes me at the moment (it's been a few years... I think it had something to do with objects created with 'new' prematurely falling out of scope and either a libavrc or a toolchain bug), you couldn't actually use "new" to create objects -- you had to get a pointer from malloc(sizeof(DesiredObject)) and cast it to a pointer to an object of the desired type. Intellectually, I could deal with it. Emotionally, it was a total mindfuck. Everyone said it was just the way you had to do it (for the time being, at least), but it just plain felt *wrong*, if not downright *immoral*.
Maybe I was just being stubborn, but it was a huge turn-off. It convinced me that C++ just wasn't an appropriate language to use for 8-bit microcontroller programming (well, that, and the fact that from what I remember, there was no official way to implement external SRAM in a way that the gcc libAVRc toolchain could gracefully take advantage of it... if you wanted to use anything besides on-die SRAM, you were basically on your own & sailing through uncharted territory).
In most places, you had to pay some stupid token surcharge, like $0.25/month, to get DTMF dialing. I say "stupid", because the phone company's equipment actually had to be programmed to IGNORE DTMF from any customer who didn't pay the extra fee. Most people paid it, but there were some people who refused... especially late in the 80s, when people started to buy their own phones & the phones themselves could pulse-dial from a keypad.
There were also lots of places where paying extra for DTMF service didn't actually save any dialing time vs pulse-dialing. If you paid the DTMF surcharge, then had your phone autodial a number, you'd hear the phone company's equipment pulsing the last few digits after it sent the tone burst.
> There is greater distance between our population centers and most of our workers commute longer distances.
You're not exactly *wrong*, but that's far from telling the whole truth. The fact is, plenty of Europeans live out in the 'burbs too, once you get away from London and Paris. The difference is that in Europe (and Asia), they'll build a rail line through virgin farmland, then rezone the area around the station to encourage high-density development around each one. So, people who live out in the suburban boonies (so to speak) drive 5-10 miles to the nearest train station, park, walk past the dense quasi-urban development around their own station, and ride the train to another staion 20-50 miles away that's within walking distance of their office.
In the US, we do stupid things like build suburban rail stations, then leave the surrounding area zoned for low-density single family homes and strip malls because our idiot planners don't want to "encourage sprawl" by allowing high-density development in suburbia. So, instead of having high-value concentrated commercial development (and a few fairly expensive residential buildings) within easy walking distance of OUR rail stations, we end up with low-density development oozed across a thousand square miles, and $50-100 million transit stations adjacent to nothing besides a parking lot and single-family homes.
It's not practical to expect most American suburbanites to move, but it's ENTIRELY reasonable to expect new commercial development to cluster around transit lines with a little help from aggressive up-zoning around their stations. It doesn't happen overnight, but it DOES happen within a generation or two (just look at area surrounding many of Miami's Metrorail stations south of downtown, the Washington Metro in Virginia, BART in San Francisco itself, etc).
The problem is, the one model for transit-optimized commercial development that's been shown to work and be viable in the US goes against everything traditional urbanists regard as holy & sacred, because it accepts the fact that most people are going to live 5-10 miles from the nearest rail station & drive there, and settles for putting their DESTINATIONS within convenient walking distance of stations (usually, with the expectation that existing urban areas will just be commercially-abandoned, written off as slums, and replaced by the shiny new commercial hubs built around the new transit stations on former farmland out in the boonies).
There's also the fact that urbanists have a fetish for "downtown" development, as opposed to rubber-stamping dozens and dozens of mini skyscraper clusters and vertical stacks of big-box stores ( like http://www.berkowitzdevelopment.com/dadeland.htm ) every mile or two all the way from downtown out to BFE.
Sounds like Metrorail in Miami. The last time gas prices spiked, they cut back service to 30 minutes in the afternoon, evening, and weekends. The feds told them point blank that they could forget about getting money for Metrorail expansion anytime soon if THAT was how they were going to squander a multi-billion dollar heavy rail transit system.
Then again, we're talking about the most incompetent and/or corrupt transit agencies in America... one that was LITERALLY soliciting bids for the disposal of its existing railcars before it even secured funding and bids for their replacements, for no reason besides "they were built for 30 years of service, and went into service 28 years ago". A transit agency that rakes in MILLIONS of dollars per year in transit sales tax revenue that was approved by voters promised large-scale Metrorail expansion, then squandered on buses, illuminated street signs, and pretty much everything BESIDES actual new track.
Or designing them with additional sidewalks and bike paths connecting the cul-de-sacs so they still work as intended (keeping cars from driving through the neighborhood) without interrupting pedestrian and bicycle flow.
"push" email is fundamentally different from "push" web content.
Incoming phone calls & SMS messages don't get "broadcasted" to phones in the area -- the individual phones actively poll the network for incoming calls & SMS every couple of seconds. The phone broadcasts its poll request to the tower, and the tower replies back with a ~160-byte reply that indicates whether there's an incoming phone call, or the content of a text message, or a code that lets the phone know that there's content being pushed that's available to be fetched.
I'm not 100% sure about GSM networks, but on CDMA networks, the phone can poll for incoming calls/SMS faster & with less power than it takes to establish a full-blown active EVDO data session. I believe a similar situation exists with respect to legacy GSM vs UMTS/HSPA. SO... instead of taking the time and power to establish a data connection so the mail app can poll the mail server, push email allows the mail server to notify the mobile network that one or more new messages have arrived. The next time the phone polls the network for incoming calls, it gets a reply that means, "no incoming calls, no incoming SMS, but there's at least one new email waiting on the server". The phone gets the reply, sees the "new email" flag, and THEN launches the mail client, which brings up a full data connection and updates itself from the server.
In other words, instead of having to keep waking up the phone, establishing a full data connection, and keeping the phone awake long enough to poll the mail server, you can keep the phone mostly asleep, and wait until the network notifies you that there's a new message before going to the trouble of contacting the mail server itself.
"Push" in this context is also different from using persistent UDP sockets (the way IMAP NOTIFY does).
When in doubt as to whether or not something is "genuinely" push or not, it helps to look at the pushed payload itself. If the pushed payload is just a notification that something is waiting on the server, it's probably "real" push. On the other hand, if you're actively polling a server for the message itself, it's probably not "real" push.
Most of the time, there's not a whole lot the original owner can do if it's a consumer-grade hard drive. I believe some enterprise laptop hard drives are encrypted by a key that can be blown away (rendering the data on the drive into digital noise) regardless of whether or not the drive is working properly, but it's rare for consumer (or enterprise drives used in servers, for that matter) to make use of the feature because it reduces your odds of ever performing successful data-recovery on the drive down to approximately "zero" if the drive fails due to a controller failure.
Given a choice between a tiny risk of unauthorized disclosure, and the overwhelming risk of permanent data loss, most people will roll the dice with unauthorized disclosure... especially anybody who's had literally dozens of hard drives die since the late 80s (and noticed that the failure rate seems to be INCREASING over the past few years), but never had one actually get *stolen*.
For obvious reasons, "secure erase" by blowing away a whole-disk encryption key isn't something you want to be TOO easy to initiate (ideally, it should only be possible to do with a jumper in place that's not there by default), because otherwise you'd have the ULTIMATE denial-of-service trojan attack vector.
The problem is that in most cases (with the possible exception of the oringinal Evo 4G), an extended battery means forgetting about a gel-type case to keep the phone from guaranteed destruction if it falls more than 3 inches.
I wish we could have TWO batteries... a non-replaceable one that's ~2200mAH and fills every nook and cranny of the phone's interior with lithium ion gel, and a commodity one that's ~1600mAH that can be easily swapped in and out. You'd need slightly more complicated charging logic from a 500mAH power source (charge the fixed battery first, drain the removable battery to 25% before using the fixed battery) and a bigger charger to do both at once, but then we'd have phones that were about a millimeter thicker, but could go for 30+ hours with aggressive use before dying.
> The iPhone - and it really was the first in this category - got people to charge their phone every single night
No, it got people to carry chargers everywhere, and panic if the restaurant doesn't have a power outlet at the table. Apple legitimized undersized, wimpy batteries. If manufacturers weren't hellbent on making sure that every new Android phone is a fraction of a millimeter thinner than the latest iPhone, and just gave us another 3x5 inches of millimeter-thick 3500mAH battery goodness, we could go back to having phones that can be used aggressively all day, all evening, and still have enough power in the morning to last until noon. But no, we're forced to settle for pregnant lumps with half the area and double the thickness that render the phone incapable of fitting in any reasonable case, so we're stuck gambling between the phone's destruction and a dead battery.
There IS a middle ground between Apple (battery that maximizes capacity per area, but can't be user-replaced easily) and Android (lumpy battery that's a commodity, but undersized) -- put two batteries in the phone. One, that's iPhone-like and not (easily) replaceable, and one that's like typical commodity batteries. Set up the charging logic to always drain the commodity battery first, and charge the fixed battery first. That way, we'd get ~30 hours of use from the fully-charged pair, but could keep swapping $3 (from China) secondary batteries all day for another 3-6 hours of power if necessary.
Actually, that one's not quite as ridiculous as it sounds, assuming the technology isn't much different from home thermostats. AFAIK, home thermostats in an old home with only a furnace might have as few as two wires: one that's approximately 24Vac, and one that gets connected to it whenever the furnace should turn on. A newer home with an air conditioner might have two or more additional contacts for the a/c compressor & blower, and possibly 24vac of its own. I believe that most use battery power for the digital logic, but use the 24vac to energize the relay coils. I believe most home digital thermostats were historically battery-powered because the logic doesn't draw much power, and because it prevented the programming from getting lost whenever the power were shut off at the breaker.
Fast forward to 2012. For literally a few cents, you can buy an 8-bit microcontroller with real eeprom and flash, and a linear power supply to convert 24vac into 5vdc is far from being rocket science. Instead of relying upon continuous power to keep the settings alive, you can just write them to flash, and read them back when power gets restored. I believe this is more or less the nature of their patent.
Assuming I'm mostly right, this is a pretty lame patent. Unfortunately, it probably does meet the technical standards for being granted. I can only assume that Honeywell grabbed it because the market for home thermostats has traditionally been so small, few other companies have even bothered with it (I mean, let's be honest... how often do most people REALLY replace their thermostats?), so nobody else even thought about filing a patent for it first.
Of course, there's the qualifier you breezed right over: "To promote the Progress of Science and useful Arts...." Although (AFAIK) the Supreme Court has never entertained a challenge based upon the premise that a given law *impedes* progress, it's not inconceivable. The catch is, the Supreme Court can't be forced to hear a case, and it's unlikely to do so unless we someday end up with a retired patent lawyer on the bench.
> I love how they state on their website that the mean time for failure is something like 130 years.
Oh, that's because the hardware ITSELF will last for 130 years. The half-life of any data you STORE on it is about 7 weeks. If the offices of both Sandforce and OCZ were replaced by smoldering nuclear craters tomorrow morning, I'd smile and say, "at least they can't screw anybody else now" (well, once the remaining inventory stocked by Amazon & Newegg was gone).
> Using RAID 1 during those circumstances is like building two houses next to a volcano instead of just one.
Yep. Just ask anybody who bought a pair of OCZ Velocity2 Sandforce-based drives and mirrored them in the hope of avoiding data loss... and had both of them simultaneously commit suicide thanks to the wonderful bug that triggers the "3 minutes to deathcrash" condition (never fear, though... the drive itself is "fine" -- just Securely Erase (tm) it, and it'll be good for a few more weeks until it kills all the data on it again).
Sandforce is the worst steaming pile of shit that has ever existed in a mainstream product. Their controllers have fucked so many users, they can't even get ENTHUSIASTS (who lose sleep at night worrying that their controller might be .05% slower than somebody else's) to care about their benchmarks anymore. The only reason I won't be chucking mine is because I might need it for the class action suit against OCZ and/or Sandforce someday.
> there are plenty of online Linux vendors that would have been MORE than happy to have his business
And how many of them sell notebooks with a Thinkpad-quality keyboard and pointer stick? Laptops are not commodities. For people who care passionately about their laptop's keyboard & pointer stick, there is but one laptop, and its name is Thinkpad. Nothing else comes remotely close.
Seriously. Go to a Thinkpad forum sometime. There are literally 24+page threads debating whether Alps, Chicony, or NMB-built keyboards are the best. I've owned two non-Thinkpads in my life, and I ended up despising both of them because their keyboards sucked (one didn't feel right, one flexed).
> Google is basically saying that the CDMA Nexus phones are no better than any other non-nexus device when it comes to "official" developer support.
That's not necessarily true. The Nexus S might not have had the full source to its wimax and CDMA drivers, but at least it HAS working binary drivers for the latest and greatest kernel needed for the latest version of Android.And it has a bootloader that can be unambiguously unlocked. If you don't think either one is important, just ask somebody unfortunate enough to own a late-model CDMA Motorola phone (like the Photon).
I'd rather have a Sprint Galaxy Nexus with up-to-the-minute proprietary kernel modules than be stuck with only their non-Nexus consumer models that have no hope of running newer versions of Android without giving up 4G, GPS, the camera, and other features that are handled by the Qualcomm chipset.
Damn. If they call off all future CDMA Nexus devices with unlocked bootloaders and up-to-the-minute kernel modules, that's going to really, really, massively suck :(
In theory, you might be able to hack a Sprint iPhone4S to do 1xRTT on Verizon (or even get an AT&T or T-Mobile iPhone 4S to do 1xRTT on Verizon), but you'll never get a non-Sprint phone to work on Sprint without spoofing the MEID of an old Sprint phone (very, VERY illegal), and due to slight difference that are entirely due to software, a non-Verizon phone's radio modem firmware can't authenticate itself to do EVDO on Verizon.
There's no technical reason why a non-Verizon phone's radio modem can't be programmed to gracefully handle both Sprint AND Verizon... they just don't do it, because Sprint/AT&T/T-Mobile have no interest in making THEIR phones interoperable with Verizon, and Qualcomm has never had the balls to push back on Sprint & Verizon both to use unified radio firmware.
In a slightly less-evil world, Americans would at least be able to go to qualcomm.com, hit the link to "download OEM drivers", grab a file like "cdma2k-spcsvzw_2-6-37-1a.ko" to get the generic Sprint+Verizon radio modem driver for a 2.6.37 kernel, drop it into AOSP, and run with it after grabbing some more files and config info specific to Sprint or Verizon. Then grab a file like "wimax-clear_2-6-37-1d.ko" to add support for Sprint wimax (or something similar for Verizon LTE).
The big problem Sprint and Verizon customers have NOW is the fact that Linux doesn't have a stable ABI, so every new kernel (required by every new version of Android) breaks the kernel modules that came before it. So if the latest kernel officially supported by your phone's manufacturer is 2.6.42, and ICS needs a 3.0.1 kernel, you're basically SOL until the manufacturer releases its official upgrade (if ever) with new kernel modules that the AOSP folks can rip out and repurpose for AOSP purposes in CDMA phones.
What Google REALLY needs to do is give us a hardware abstraction layer that works kind of like NDISWrapper, so they could say, "3.0.1 is our official kernel driver interface for the next few years", and newer Android builds would insert a thunking layer between the 3.0.1 .ko module and the newer kernel (possibly, make it optional, so newer kernel modules could be used, but the older ones would still work in a pinch). THEN, whenever a new version of Android came out with a new kernel and different ABI, we could keep using the old .ko modules ripped from the stock ROM and get it to work with the newer version.
The hardware abstraction layer in Windows is a large part of the reason why you can still use XP drivers with Windows 7, and in a pinch you can sometimes still coax Win2k, or even NT4 drivers into working. In contrast, with Linux, you can't even use a kernel module compiled for 2.6.29 with 2.6.32. In the PC realm, this is a pain, but PCs are generally open enough to allow you to work around it and choose open hardware with a little bit of advance planning. In the mobile phone realm, you're just plain fucked, because every mobile phone is basically analogous to a wireless winmodem stapled onto a proprietary USB webcam and bitbanged degenerate SCSI controller.
ATSC also uses 8-VSB modulation instead of COFDM. 8-VSB has serious problems with multipath, and is damn near impossible to receive in a moving vehicle.
I believe DVB also supports h.264 as a codec, in addition to ATSC'S MPEG-2
The biggest shortcoming of ATSC was its lack of support for 1080p60 with long GOPs. It's not viable for live broadcast, but with offline non-realtime compression, you CAN do 1080p60 in 19.2mbit/sec. Just ask anybody who used to rip DVDs & re-encode them with ridiculously long GOPs and variable bitrate encoding so you could fit half of a DVD on a CD-R with minimal quality loss.
Argh. Accidentally wiped out a major edit, too.
Relying on a long-lived background service doesn't work anymore. As of Gingerbread, Android will kill background services it thinks have been running for "too long", even if they're spending 99.999% of their time waiting politely and allowing the phone to sleep as necessary. Officially, you're now damned if you do, and damned if you don't.
Sorry, but Android networking is nowhere close to being that straightforward once you throw deep sleep behavior and powered-down network interfaces into the equation. Just to give one blatant example, my Motorola Photon routinely gets itself into situations where it powers down all the network interfaces, and takes an ETERNITY to re-establish the network unless I launch the stock browser long enough to manually wake it back up. I've had it showing "Zzz" for the wireless network, and observed HUNDREDS of failed requests by Apache HttpClient in a row that didn't budge the phone, and only saw the network re-connect after I manually launched the stock browser. It's almost like they hardwired Webkit to manually launch a network connection if necessary, then forgot to do the same with HttpClient. (I captured the logcat output to SD using CatLog).
If you check for connectivity, and give up without a fight or even trying to make the request anytime you see it's down, it's quite likely that you're going to go for a REALLY long time before seeing network connectivity when the phone is in deep sleep mode, even if it's allegedly connected to wi-fi and sitting next to a tower.
THIS is why we need something like "AlarmManagedHttpRequest" that gets fired on schedule, but doesn't begin executing until the phone is guaranteed to have made every reasonable effort to establish network connectivity first, and keeps the phone awake until the request either succeeds or fails. It's a straightforward thing to do at the Android framework level, but it's extremely hard to kludge safely and ROBUSTLY using the existing public API.
Alarm Manager is part of the PROBLEM.
Yes, you can schedule your task through AlarmManager. You can even be polite and use InexactRepeat to batch requests. There are two specific problems:
1. You aren't allowed to do anything time-consuming (like make a http request) in the BroadcastReceiver that runs when AlarmManager fires off the Intent. You have to start a background service to do it. Unfortunately, Android makes no guarantees that it will even execute the BackgroundService onCreate() method before exiting the BroadcastReceiver, and Android can (and will) put the phone back to sleep the nanosecond the BroadcastReceiver's intent handler finishes running. Pure multithreaded joy.
2. The only way to guarantee that the phone can't go to sleep until the http request gets made is to grab a PartialWakeLock in your BroadcastReceiver, and release it from the background service. The thing is, you can't pass the PartialWakeLock to the background service in the call that starts it up, you can't call methods of that background service without getting a connector, and you can't tell Android to keep the BroadcastReceiver's handler running (and the phone awake) until you get that connector. So... you basically have one option left: create a class with a static PartialWakeLock (or HashMap of PartialWakeLock objects), store it there, and pray to ${deity} that Android doesn't decide to kill the class off and garbage-collect it before the service gets created, because if it does, your phone now has a zombie wakelock that can't be released.
It's a catch-22. There is LITERALLY no way for an intent fired off by AlarmManager to guarantee a successful attempt to make a http request without doing dangerous and ugly things with static references to PartialWakeLock objects. It's one of those "ohshit" API decisions that seemed like a collection of good individual ideas, then kind of fell down in one embarrassingly common real-world use case... and something anybody who writes an Android app that needs to occasionally communicate with a server in the background gets confronted with in short order.
Making matters worse, Gingerbread now kills even well-behaved background services if it thinks they've been running for "too long", even if they spend 99.999% of their existence politely using TimerTask and Java's Thread API to yield and sleep. So, the one semi-solution that used to work politely and reliably (start the service, then spend most of the time sleeping) now breaks, with no reliable and safe alternative.
What Android desperately needs is a nice, API-level convenience method that lets you create a http(s) request, complete with args, then hand it to the OS and say, "You don't have to do this *right this millisecond*, but at some point within the next ___ seconds/minutes, please wake up the phone (if necessary), establish network connectivity, make the request, then fire {this-intent} with the server's response (or failure info)" (and optionally, if the request fails, try making a test request to something like 8.8.8.8 and/or 8.8.4.4 to make sure the phone's internet access is REALLY working before assuming failure, so the program only has to deal with the failure of its own web service, instead of having to deal with the failure of the phone itself to sustain a robust network connection).
Believe it or not, right now, there's NO good, reliable, graceful way to do the equivalent of having a cron job fire off a http request when the phone is asleep. There are ways to kludge it, but they're all either unreliable (the phone will go back to sleep before it even has a chance to MAKE the http request, the network might be down because it hasn't finished reconnecting yet, etc) or dangerous (holding partial wakelocks in static variables, with no way to guarantee their release if something crashes).
Android gives developers lots of power, but it also imposes enormous amounts of responsibility that maybe 1% are really equipped to handle. In the real world, the network failure strategy of most Android applications can be summed up as "relentlessly keep beating away at the URL in the hope it might eventually work". Oh, most semi-new Android devs don't SET OUT to be irresponsible... the problem is, anybody who tries to make a single network call and fail politely and exit if it doesn't work quickly discovers that an average Sprint user will have the app die within 10 minutes (thanks to the stupid way Sprint phones thrash between 3G and 4G in quite a few real-world indoor usage scenarios). So they adopt "keep trying over and over again" as a strategy, because it makes their app work on Sprint phones, but kills the battery of anybody who's somewhere like a subway tunnel when the phone decides to make its next http request. If Google gave developers a nice, bulletproof way to politely make asynchronous http requests that can be gracefully scheduled and batched, instead of trying to hack together buggy solutions that almost work, we'd all be better off.