> How we doing on warranties and longevity of SSD?
The electronics themselves, or the data on them? Big, huge difference. Sandforce2 (1200 series) drives in particular are going through a data holocaust at the moment. The problem isn't the electronics failing, the problem is that Sandforce's braindamaged firmware gets the drive into a state that causes the firmware itself to crash after a few minutes, or causes the drive to go into "panic" mode and intentionally brick itself (taking your data with it) for your "protection" (nobody at OCZ has ever been able to give a good explanation about how, exactly, having your drive brick itself into "panic" mode as a "precautionary" measure so you have to send it in and get a replacement with your data gone forever is somehow a desirable feature).
Don't believe me? Go to ocz.com's support forum, find the one for Vertex2/Agility2 drives, and read the daily tales of woe with no solution besides "wipe the drive and try again" (assuming it's not in Panic Mode & has to be returned for official reflashing). Apparently, other brands using the same controller (Patriot, etc) are no better. Sandforce makes vendors treat their chipset like a black box, they dropped the ball, and just kind of left everyone unfortunate enough to own a drive based on one of their controller chips hanging like a corpse from the gallows of a wild-west town.
Maybe, maybe not. Often, the drive itself isn't physically broken, it just gets itself into a state where the (consumer) firmware can't fix itself. So, they reflash the drive at the factory with custom firmware whose only purpose is to rewrite the sector and config data, then reflash it back to the consumer firmware and ship it.
Why don't they just include the capability in all the drives? Usually, so they can use smaller flash chips in the controller. Occasionally, because they're relying on security by obscurity to keep enterprise drives securely encrypted (read: someone with the right firmware could either defeat the encryption outright by recovering the key, or would at least have a much easier time brute-forcing the key by concentrating on likely values and/or testing them on spots likely to show results quickly.
I believe that there are also situations where the drives as shipped to consumers aren't capable of physically erasing and rewriting their track info (what was traditionally called a "low-level format"), but can do it if they temporarily attach an external controller that's able to exert finer control over the mechanical components. Probably 70-80% of the drives sent for data recovery end up getting fixed through either custom recovery firmware alone, or with a little extra help from a custom daughterboard or external controller that can control things like head positioning and reads/writes more precisely than the stock controller & firmware can. When something DOES mechanically break, it's actually not all that hard for somebody with the right replacement parts to do the repair.
The problem is that the whole process is wrapped up in closely-held trade secrets, shrouded in secrecy, and has a workflow geared mainly towards serving large enterprise customers & law enforcement agencies who'll pay almost anything necessary to get data recovered, and get it recovered *now*. There's no workflow or business model for people who could live with waiting 6-12 weeks to get back a replacement drive with whatever data could be recovered copied to it for a halfway sane price. It's overnight-at-unlimited-cost, or data-gone-forever, with no real middle ground between the two extremes.
My first two failed drives were a 40-meg Quantum (Amiga 2000) circa 1989 (stiction that set in when I was on vacation for two weeks) and a 750-meg Western Digital sometime around 1994.
My remaining failed drives were my infamous 5.6-gig IBM Deathstar, my 300-gig Velociraptor, and my 120-gig OCZ Vertex2 SSD (technically didn't fail per se, just got its config corrupted by a power failure during a write that required reformatting, but THAT failure pissed me off more than any because Sandforce/OCZ could have EASILY given us a "safe recovery" mode that allowed the raw data to be downloaded under Linux for offline recovery, instead of just saying "oops, sux2bU, you should have been doing hourly backups".
Here's a warning to anybody with a Sandforce 1200 ("Sandforce 2") based SSD, especially one from OCZ -- head over to OCZ.com, go to the Vertex2/Agility2 forum, and count the number of new posts every day from people who've had a drive commit data-suicide due to firmware bugs. If Seagate or Hitachi had that kind of failure rate and data-loss carnage, they'd be *out of business*. The worst part is that you can't even use RAID1 mirroring to save yourself, because the same bug that corrupts one drive would likely corrupt both simultaneously and leave you equally SOL. Every story is a tiny bit different, but most can be summed up as, "Something corrupted my drive's internal config data, and now it crashes/hangs/goes away/bluescreens after approximately 3 minutes".
> Sounds like a pile of shitty hardware vendors and shitty handset vendors. Pointing at the kernel ABIs is incorrect.
Great strategy. It worked brilliantly as a way to bring open-source winmodem drivers to Linux. Oh, wait... it didn't, did it? We basically had proprietary binary drivers for Lucent winmodems that worked under a few specific distros, and IBM eventually did the same for THEIR audio/modem chipset for Thinkpads.
Yeah, someone finally did develop a true open-source HSP driver for his college thesis a couple of years ago and released it to the community, but for all intents and purposes, there were never open-source Linux winmodem drivers until almost a decade after they ceased to actually *matter* to anybody. It won't do us much good to get true open-source wimax drivers for a phone like the Nexus S 7 years after Sprint has switched to LTE.
This IS the #1 fundamental problem of American Android users, because it's the one problem we can't fix ourselves. Bootloaders get cracked, and just about any phone can be JTAG-reflashed if you're really determined. But without a way to use a radio modem (or camera, or GPS, or ???).ko compiled for 3.x under a 3.y kernel, we'll be forever running into brick walls every time a new version of Android gets released, and forced to choose between ${new-version} and fast data/gps/camera/etc.
Not really. The lack of a stable ABI *is* a major problem, because it means that every time a new version of Android gets released that needs a newer kernel than the latest "official" one available for the phone, every proprietary loadable kernel module (for things like 4G data on carriers like Sprint) ends up breaking. As far as I know, not even the Nexus S 4G has buildable driver source available for its wimax interface, which is why every guerrilla ICS ROM for it has broken 4G. It's even worse for HTC phones, because they don't even release their drivers as proper loadable kernel modules -- they just compile them straight into a monolithic binary blob, then rip out the proprietary bits and dump the unbuildable kernel source on the curb.
This is the #1 problem Google really needs to solve -- binary driver breakage every time the kernel gets upgraded. Maybe they could create a stable thunking layer that allows a.ko built for a 3.(n+X) kernel to keep working on a 3.(n+Y) kernel, so every new Android release won't subject us to the usual cycle of 4G data that's instantly and semi-eternally broken. Or maybe just force the phone makers to blindly compile and release new unsupported proprietary.ko files for drivers with the latest kernel within 5 days of Google's official source drop, with the usual disclaimers that the new.ko files are untested, unwarranted, will cause birth defects, and might make you hunting for chocolate at 3am.
The moral of the story: if your personal entertainment is more valuable than your data or hardware, don't lock the OS down too tightly. Just give yourself remote access to the system, a way to sync files back to your server, some kind of DDNS app, and give the thief every incentive to not bother reinstalling Windows so you can have fun with him remotely and make him regret having ever messed with you.
Not quite... only *successful* landlords who actually make money are that way. The truth is, it's way more profitable to be a slumlord than to have affluent tenants. If you're a slumlord, you can rent out a shack that costs you $400/month to own for $200/week and pocket 99% of it. If you own a nice house or condo that costs you $1,600/month (mortgage, taxes, and insurance) to own, you'll be lucky to rent it out to someone "nice" for $2,000/month. Same $400/month nominal profit. The difference is, if you're a slumlord, there's no expectation of real maintenance. If something breaks, you can tell your week-to-week tenant to take a hike if he's not happy, and give the next tenant a $10/week discount. In contrast, the hipster renting your nice condo is going to demand instant (including weekend) repairs if *anything* goes wrong. A single clogged toilet has just wiped away your profit for March. A burned-out starter capacitor in the central AC is going to wipe it away for July (the slumlord will have to fix it too unless he wants an unrentable unit, but he can take his sweet time and pay someone to fix it off the books for $60 cash instead of as a $500 weekend overtime repair job).
Lots of aspiring middle-class investors found this out the hard way after they ended up being stuck with properties they intended to flip. They went into landlord-seeing-dollar-signs mode, and quickly found out that most of the time, if you own a nice property bought at the most insane peak of the real estate boom, you'll be lucky to LOSE "only" a few hundred dollars per month per year after you've collected the rent and paid the bills. The only landlords who genuinely make real money are the slumlords who own a few dozen or hundred units in cracktown and rent them out to poor people with no credit (because it's expensive to be poor).
The difference is, quite a few banks will allow you to use a debit card to overdraw your checking account. A couple of years ago, someone got my debit card number and managed to empty and overdraw my checking account by about $1,800 within about 3 hours. It took the bank 3 days to provisionally credit me back to zero so I could at least cash a check from my parents and have cash to live on until they finished their full investigation and credited back all the fraudulent charges. In the meantime, I had scheduled payments bouncing and racking up $29.95 NSF charges that required another round of fighting with the bank to get removed.
When your credit card gets fraudulently used to rack up charges, you can calmly wait until the statement arrives, highlight the fraudulent ones, and wait for them to fix it. When your debit card gets used to take your checking account negative, you're (at least temporarily) fucked. Because so much in the financial industry happens on autopilot and gets blindly triggered by events that can cascade and snowball into a meltdown, you can literally have your credit score killed for months by the fallout from a major debit card incident.
Put another way, anybody who thinks debit cards are a "better" alternative to credit cards is seriously naive. You're much better off just treating a credit card like a debit card & paying it off monthly, and using your debit card ONLY as an ATM card.
> Free speech must be absolute or else it is worth nothing.
Er, I suppose you're unaware of something called "Common Law", which is every bit as established and valid in the US as Constitutional Law. If you're writing/speaking about a political cause or politician, you have a very strong (in fact, a nearly-absolute) affirmative defense. If you're writing/speaking about a celebrity or corporation, you have a slightly weaker affirmative defense that's still pretty strong. If you're writing/speaking about a private citizen who's done nothing to merit public scrutiny, you're going to get your ass sued... and sued into oblivion if what you wrote/said is demonstrably slanderous/libelous on top of constituting harassment.
The constitution applies to conduct by the government. Common law applies to actions between individuals. Common law has a long, well-established tradition of recognizing that there's a line between "things that are false" (slander/libel) and "things that might be factually true, but are none of your business or anybody else's". In a case like this, intent matters. She might not be able to sue him for slander or libel, but harassment is a definite possibility.
The justification for ordering specific performance (removal of the blog, refraining from future public comment about the woman over the internet) is based upon another well-established legal principle: Equity. Equity is an extraordinary relief granted by courts in situations where monetary judgments are not sufficient to make the injured party whole.
If the woman became a public figure, the man might have had an affirmative defense. However, by all appearances, she wasn't.
It would also make us universally-despised by just about everyone on Earth, and the moral equivalent of Genghis Khan. In case you've forgotten, we're supposed to be the good guys. We make occasional mistakes, and occasionally a psychopath slips through the chain of command, but for the most part, we do try to be a force for good. It might be mostly out of enlightened self-interest rather than genuine altruism, but at the end of the day, most of us can go to sleep at night with a fairly clean national conscience.
Team America: World Police is obviously satire, but it's a lot closer to the truth than most of us really like to admit.
And how many of them were NOT T-mobile branded, but nevertheless capable of HSPA+?
The only non-Tmobile-branded phones I'm aware of that are capable being coaxed into doing 1700/2100 plain-vanilla (non-HSPA+) UMTS at all are Samsung's GSM Galaxy-S phones (AT&T Captivate & international i9000). I'm sure there are a few others, but they're rare. Likewise, most foreign phones can now limp along and do 1900MHz plain-vanilla UMTS on AT&T, but very few that can also do 850MHz UMTS. I don't think there are ANY non-AT&T-branded phones that can do HSUPA on AT&T.
As a practical matter, if you care about getting the fastest data speeds possible, America's two nominally-GSM networks are almost as de-facto proprietary as Sprint and Verizon. And the tragic punchline is that when AT&T, Verizon, and (now) Sprint roll out LTE, they're going to be equally incompatible with each other and everyone else on earth despite LTE nominally being a global standard.
Buying your own phone doesn't matter with Verizon or Sprint. Non-Sprint phones can never be activated under a Sprint account (they can roam, but never be the phone for a real Sprint account). Verizon will let you do it if you twist their arm and escalate it high enough (possibly due to a consent decree inherited from AT&T years ago), but they won't actually *help* you, and you'll never get EVDO to work, only 1xRTT due to radio firmware funkiness unique to Verizon. There's no actual engineering reason why it HAS to be this way (it's purely a matter of software and business process; the hardware is identical), but unfortunately, that's the way it is.
In theory you could buy an unsubsidized phone for AT&T or T-Mobile, but in most cases you'd only be able to use GPRS and EDGE on T-Mobile (most foreign phones can't do 1700/2100 HSPA+), and I'm pretty sure most imported phones can't do HSUPA on AT&T (and often, the only models that can do 850MHz UMTS are the ones intended for Australia, which are so expensive when imported to the US that you could almost buy a Verizon phone and pay for the service for two years for what you'd pay for the imported phone alone).
The unfortunate truth is that America's mobile phone market is as structurally fragmented and messed up as Japan's, and only slightly more likely to untangle itself over the next 25 years into something resembling tortured interoperability.
VCRs are the best example of all. A couple of years ago, I started digitizing my old tapes in earnest, and quickly discovered that the tapes I recorded back in middle school & high school (late 80s/early 90s) on a Canon VCR that cost about $900 (one of the first-generation VHS Hi-Fi models with helical scan tape-handling and HQ) were almost pristine. The tapes I recorded in the late 90s on a $150 VCR from K-Mart purchased sometime around 1998 were almost unplayable without full-frame timebase corrector, and STILL required unbelievable amounts of post-processing to make them tolerable. The old VCR actually had better monochrome detail, and better color separation, than the new one did. The old one obviously had "floating red dress syndrome", like every other NTSC VCR in existence, but the new one couldn't even get yellow and blue consistently right.
I can't remember the name of the AVIsynth filter I had to use, but there was one combo that separated each field into Y, U, and V, then had to shift the U and V components horizontally to properly line up with the Y (translation: if you view the image as a black & white image with color overlaid by transparencies, the stack didn't quite line up by default, and you had to bump them around relative to each other to get the alignment right). The tapes from the 1980s VCR didn't have this problem. The tapes from the 1998 VCR did.
The worst tapes of all were the few that got made on a third VCR purchased sometime around 2002. They're almost beyond salvation. I gave up trying to restore them, and just settled for making them halfway watchable.
For what it's worth, the VCR used for playback & digitizing is a Panasonic S-VHS VCR from ~2005 that has its own single-line TBC. It cost about as much as that first Canon VCR when it was purchased way back in 1987.
The story with CD players is almost the same. My brother has a CD player he got for Christmas in middle school circa 1984. I think my parents paid almost a thousand dollars for it. It still works, and works flawlessly. In my closet, I have 3 CD players purchased since 2000, none of which managed to go for more than two or three years before physically breaking.
The only thing that sucks about the first-generation CD player is the audio quality -- I guess back then, DACs and RAM were super expensive, so they did wacky things like use sample-and-hold circuits to use a single DAC with two audio channels. That's part of the reason why first-gen CD players had left-right separation issues and frequency response that ended up being way less than what the redbook audio standard suggested they would. However, the only CDs for which it really makes an audible difference are those from the late 90s... earlier than that, and the source media was substandard. Later than that, and the loudness war & rebirth of clipping & THD made it the least of its problems.
West Nile Virus? Yawn. Scary name, probably the most innocuous virus you can get infected by in Florida. For the overwhelming majority of people who get it, it's basically flu without a runny nose (ie, fever, muscle aches, and malaise). You obviously don't want to go out and TRY to get it, but the media hysteria over it was WAY out of proportion to the actual risk.
I wouldn't say that. If anything, HeadFirst books are awesome for experienced programmers learning something that's outside their usual comfort zone, because they trick you into reading useful things that you'd otherwise be inclined to yawn and skip over (missing something important in the process).
I don't know about you, but when I get home from work on most days, I'm fairly burnt and fried. I need a certain degree of entertainment and engagement, and a dry textbook about some programming (or other) topic is going to leave my eyes glazing over within about 20-30 minutes. The HeadFirst books are *precisely* the kind of books that justify printing as books, because they add substantial value to their content in the form of coherent editing, humor, and entertainment.
Yes, you can learn most programming topics from online docs... but that doesn't mean it's the most efficient way to go about doing it. Your time is a scarce, valuable resource. It's not a crime for things that are useful to be entertaining & humorous as well, especially if it makes the act of learning more enjoyable.
OK, I'll bite and mention one specific thing that's been horribly broken ever since the transition to digital TV -- it's fscking impossible to have multiple TVs tuned to the same channel in adjacent rooms and have them all be in sync, because each one decodes the MPEG-2/MPEG-4 bitstream at a slightly different speed, with different amounts of buffering and processing.
What? Distribute the same source to all the TVs? If you use component video and analog audio, it might... MIGHT... work. But the moment you go digital, it all goes straight to hell, because every component along the digital chain adds its own latency, and even uncompressed video still gets subjected to different amounts of buffering and scaling delays by each TV (in theory, component video can have scaling delays too, but 100% digital seems to be the absolute worst of all when it comes to getting 3 different TVs being fed the same input signal to display the same output in realtime).
What's really needed is some way to broadcast a heartbeat signal through the entire house (probably via power line) every 100ms (5 or 6 50/60hz fields), add a flag into MPEG-2/4 video and raw HDMI that arbitrary tags the first out of every 5/6 fields/frames as "field/frame zero" (the next 5 or 6 are untagged), then have the output devices ("TVs") buffer output fields/frames (and their synchronized audio) in a ring buffer until they see the pulse. In other words, the TV might buffer frame 0, buffer frame 1, buffer frame 2, then see the pulse and output frame 0. From that point, it would continue buffering new frames/fields, and showing the next buffered field/frame with its own timing. It still might not quite be 100%, but at least it would be an improvement over what we have now, where 3 different TVs in adjacent rooms with their own cable or DirecTV boxes can actually be SECONDS apart (especially when a DVR is involved).
Clearly, you've never suffered the horrors of FedEx Ground. I've caught them RED HANDED skipping delivery attempts, and gotten them to admit (off camera, unfortunately) that drivers who skip stops are known to be an "occasional" problem. A few years ago, I was home for the day getting my roof replaced. FedEx Ground claimed that there was "nobody home" and said they "left a note". At that point, there were no fewer than 7 people roaming around, including at least 1 or 2 in the front yard (possibly including myself). The NEXT day, I left a webcam pointed at the driveway & recording. 6pm arrived, no package, no note... and they claimed there was. When I confronted the FedEx manager, he first got irate, then broke down and grudgingly admitted that there "might" be a problem with the driver and said he'd "talk" to him.
The impression I've gotten from various sites is that due to the way FedEx Ground (a.k.a. "RPS") works is that the packages end up at a depot, and drivers (who own their own trucks and are basically free agents) grab the ones they want to try and deliver. Apparently, there's an official process for making unwilling drivers attempt to deliver other packages, but they don't push it unless somebody escalates. In the meantime, they'll automatically log a package left at the depot as a failed delivery attempt.
The worst delivery record of all (in terms of packages that FedEx Ground either doesn't try to deliver) are packages that require a signature. FedEx Ground drivers get paid by the successful delivery, so when there are LOTS of packages waiting to be delivered, they intentionally bypass as many that require signature releases as they can, especially if you live in a gated community and they aren't certain you'll be home. It wouldn't be so bad if their depots were at least open until 9 and on weekends for pickup, but they're not. Getting them to pull a package from a truck so you can pick it up (within a fairly restricted range of hours) almost takes an act of god. UPS, in comparison, will let you camp out at their facility the day of a missed delivery and grab the package off the truck when the driver gets back to the depot.
UPS might not be perfect, but they're infinitely better than FedEx Ground.
Unless something has massively changed in the very recent past, Clang doesn't analyze Java (directly). EVEN IF you somehow managed to coax gcc into outputting something Clang can analyze, it's questionable whether the output would even be relevant. At best, you'd be scanning for vulnerabilities due to bugs in Android itself (which obviously exist, but are unlikely to be easily found as low-hanging fruit). At worst, you'd be completely wasting your time looking for vulnerabilities that might hypothetically exist if it ran under Hotspot, and totally miss any real vulnerabilities that might exist due to Dalvik.
They exist (though they're extremely immature at the Android end of the spectrum), but they're breathtakingly expensive. I'm not allowed to cite specific products or prices, but we're talking "annual licensing fees comparable to the salary of a full-time human employee for 3-6 months" expensive.
OK, I got interrupted halfway through the post, and accidentally made it look like I was attributing 100% to the CPU alone. The full argument I intended to make was that if you compare a 16MHz 680x0-ish PalmOS phone circa 2002 to any ~100MHz Windows Mobile phone circa 2003 or 2004, the PalmOS phone will almost always "feel" faster, because the PalmOS phone used separate peripherals for everything, but the nominally-faster WinMo phone tried to use the CPU for everything. It's the combination of CISC (enabling 16MHz to go farther and do more) and coprocessors (spreading around the workload) that makes the difference. I started making a two-part argument, then forgot to make the second half. The inclusion of the Atom in examples was just a brain fart;-)
Personally, I think the ultimate endgame of RISC-vs-CISC will be along the lines of being able to program your own custom CISC opcodes using RISC-like microcode, so every program (or at least every program with OS-level access to the underlying CPU) can have its own hyper-optimized instruction set whose microcode gets executed (more or less) asynchronously to the main system clock (ie, the main clock fires it off and determines when it checks for the result, but what happens in between is up to the local virtual clock). Trying to make it work for userspace apps in a shared runtime environment (like Windows) will be an absolute nightmare in terms of both arbitration and security. but I think it's the direction x86 CPUs are eventually going to drift just because there aren't many other directions where they can go that will enable them to keep up their historical levels of exponential performance growth.
Which means we go back to the same strategies we did in the 80s and early 90s -- coprocessors. Or, put another way, multiple cores, stacked GPUs, DMA, hardware DSPs. And (gasp), the Second Coming of CISC.
At the end of the day, RISC was a way to get cheaper megahertz (and later, gigahertz). Now that we've largely maxed out clock speed to the point where it's almost counterproductive, CISC is just about the only place we have left to go. Instead of wasting 50 cycles loading values into registers. operating on those registers, evaluating the outcome, and branching based upon it, you can have complex variable-length opcodes that use billions of transistors and have sinful amounts of silicon dedicated to niche operations that would have been absurd to even contemplate 25 years ago with far fewer clock cycles.
There's a reason why a 16MHz 68000 can still run circles around a 100MHz ARM, and why a 1GHz Pentium-M beats a 1GHz Atom or Arm to a bloody pulp -- the CISC chips get more done behind the scenes with every public clock cycle. The fact that behind the curtain, they're secretly executing chains of RISC instructions with private, semi-asynchronous clocks as fast as they can & just presenting the public facade of a CISC architecture responding to a system-wide clock is a quibble. The point is that every time the public system clock ticks, they're getting WAY more done than a conventional RISC architecture could ever fantasize about. In effect, a modern AMD64 (or Core2) CPU is like a container full of virtual, disposable/pooled RISC processors that get instantiated to execute a single public opcode while privately dancing to the beat of their own drummer.
TimerTask might never have been officially "supported", but the practice of using it was widespread to the point of making it into at least one major book on Android programming as an example.
Yes, Android has always been entitled to kill background services when RAM is needed, and has reserved the right to do it for any reason, or no particular reason at all. The unhappy surprise was Gingerbread's aggressive enthusiasm for killing background services for reasons seemingly closer to "just because it feels like it".
In Froyo, it was reasonable to assume that Android wouldn't kill off a background service unless there was a bona-fide need to free up resources, or the service appeared to be leaking resources or spinning its wheels doing busy-waits and keeping the phone awake for extended periods of time. As of Gingerbread, it literally DOES appear to kill off long-lived, but otherwise tame and sleepy, background processes just because it thinks they've been running for "too long".
There's a bigger problem -- to this day, there's no easy way using the bare API to say, "at XXX, wake up the phone, attempt to connect to a network, make this complete http request, and keep the phone awake until its response has been received, digested, and handled. Then go back to sleep if you feel like it." You can't directly pass a PartialWakeLock acquired by an Alarm's BroadcastReceiver to the service, but if you merely try to start the service so it can acquire its own partial wake lock, there's no guarantee the phone will remain awake long enough for the service to finish initializing. There are various ways to kludge around it using static objects, but Android's own development team has admitted that they're ugly hacks. That's why so many people used long-lived services with TimerTasks -- they worked. Not 100%, but if you could live with the service running only while the phone was awake, and you did your part to have well-behaved and polite Threads, they worked pretty well (and definitely worked better than most guerrilla attempts to make Alarm-triggered network activity work properly).
What Android's API *really* needs badly is something like PendingHttpRequest, where you could set up a HTTP(S) GET/POST, specify the args, define intents to fire when it succeeds or fails, and throw it into a metaphorical pile for Android to execute as a bach along with PendingHttpRequests from other apps/services within 1, 5, 10, 15, 20, 30, 60, 90, 120, 180, 240, 360, 480, 720, 1080, or 1440 minutes. THEN, let ANDROID deal with bringing up the network, firing them off, retrying if appropriate, and shutting everything down when it's through. Kind of like the general idea behind SetInexactRepeat, but incorporating wakelocks and network-connectivity management into the equation as well. The problem we have now is that everyone is forced to reinvent the wheel, and just about everyone does it badly.
Network connectivity in a narcoleptic Android device is a really hard problem for individual developers to solve. Wakelocks are a dance through a minefield. The need to make a single successful http request at some not-particularly-critical point in the future when the phone has reliable network connectivity is a common use case, and we'd all be better off if there were a nice, clean, easy way to just throw the URL, args, and handler intent at Android and say, "here's the request. Make it properly, and let me know when it's done."
We hoarded Trinitron monitors up to the point where a LCD capable of 2560x1920 became semi-affordable to people who could previously afford a CAD-quality 21" Trinitron. For people used to having 1920x1280, 1920x1080 was a really harsh, bitter pill to swallow, especially when you factored dead/stuck pixels into the equation. I bought my first LCD around 2007, and had a daily love-hate relationship with it up until the happy, healing day I threw it in the trash on a pretense over a dying inverter and replaced it with a 30" 2560x1920 (now flanked by a pair of 22" portrait-orientation 1080x1920 displays)
> SSH from a phone? Why on earth would you do that except as a last resort?
Because it's Saturday night, you're at a bar with your friends, and the server decided to get bitchy on you. ConnectBot means not having to trek back to your car, boot the laptop, tether, and connect up to fix something you can troubleshoot in about 30 seconds.
And yes, ConnectBot sucks donkey balls with onscreen virtual keyboards, partly because Android doesn't allow you to have a default system-wide IME, but specify specific IMEs for specific programs (I'm a Graffiti guy, but have to switch manually to some other keyboard to use Connectbot because Graffiti doesn't have any concept of cursor-up). It's not ConnectBot's fault, but that doesn't make the situation suck any less.
Slashdot Mirror
> How we doing on warranties and longevity of SSD?
The electronics themselves, or the data on them? Big, huge difference. Sandforce2 (1200 series) drives in particular are going through a data holocaust at the moment. The problem isn't the electronics failing, the problem is that Sandforce's braindamaged firmware gets the drive into a state that causes the firmware itself to crash after a few minutes, or causes the drive to go into "panic" mode and intentionally brick itself (taking your data with it) for your "protection" (nobody at OCZ has ever been able to give a good explanation about how, exactly, having your drive brick itself into "panic" mode as a "precautionary" measure so you have to send it in and get a replacement with your data gone forever is somehow a desirable feature).
Don't believe me? Go to ocz.com's support forum, find the one for Vertex2/Agility2 drives, and read the daily tales of woe with no solution besides "wipe the drive and try again" (assuming it's not in Panic Mode & has to be returned for official reflashing). Apparently, other brands using the same controller (Patriot, etc) are no better. Sandforce makes vendors treat their chipset like a black box, they dropped the ball, and just kind of left everyone unfortunate enough to own a drive based on one of their controller chips hanging like a corpse from the gallows of a wild-west town.
Maybe, maybe not. Often, the drive itself isn't physically broken, it just gets itself into a state where the (consumer) firmware can't fix itself. So, they reflash the drive at the factory with custom firmware whose only purpose is to rewrite the sector and config data, then reflash it back to the consumer firmware and ship it.
Why don't they just include the capability in all the drives? Usually, so they can use smaller flash chips in the controller. Occasionally, because they're relying on security by obscurity to keep enterprise drives securely encrypted (read: someone with the right firmware could either defeat the encryption outright by recovering the key, or would at least have a much easier time brute-forcing the key by concentrating on likely values and/or testing them on spots likely to show results quickly.
I believe that there are also situations where the drives as shipped to consumers aren't capable of physically erasing and rewriting their track info (what was traditionally called a "low-level format"), but can do it if they temporarily attach an external controller that's able to exert finer control over the mechanical components. Probably 70-80% of the drives sent for data recovery end up getting fixed through either custom recovery firmware alone, or with a little extra help from a custom daughterboard or external controller that can control things like head positioning and reads/writes more precisely than the stock controller & firmware can. When something DOES mechanically break, it's actually not all that hard for somebody with the right replacement parts to do the repair.
The problem is that the whole process is wrapped up in closely-held trade secrets, shrouded in secrecy, and has a workflow geared mainly towards serving large enterprise customers & law enforcement agencies who'll pay almost anything necessary to get data recovered, and get it recovered *now*. There's no workflow or business model for people who could live with waiting 6-12 weeks to get back a replacement drive with whatever data could be recovered copied to it for a halfway sane price. It's overnight-at-unlimited-cost, or data-gone-forever, with no real middle ground between the two extremes.
My first two failed drives were a 40-meg Quantum (Amiga 2000) circa 1989 (stiction that set in when I was on vacation for two weeks) and a 750-meg Western Digital sometime around 1994.
My remaining failed drives were my infamous 5.6-gig IBM Deathstar, my 300-gig Velociraptor, and my 120-gig OCZ Vertex2 SSD (technically didn't fail per se, just got its config corrupted by a power failure during a write that required reformatting, but THAT failure pissed me off more than any because Sandforce/OCZ could have EASILY given us a "safe recovery" mode that allowed the raw data to be downloaded under Linux for offline recovery, instead of just saying "oops, sux2bU, you should have been doing hourly backups".
Here's a warning to anybody with a Sandforce 1200 ("Sandforce 2") based SSD, especially one from OCZ -- head over to OCZ.com, go to the Vertex2/Agility2 forum, and count the number of new posts every day from people who've had a drive commit data-suicide due to firmware bugs. If Seagate or Hitachi had that kind of failure rate and data-loss carnage, they'd be *out of business*. The worst part is that you can't even use RAID1 mirroring to save yourself, because the same bug that corrupts one drive would likely corrupt both simultaneously and leave you equally SOL. Every story is a tiny bit different, but most can be summed up as, "Something corrupted my drive's internal config data, and now it crashes/hangs/goes away/bluescreens after approximately 3 minutes".
> Sounds like a pile of shitty hardware vendors and shitty handset vendors. Pointing at the kernel ABIs is incorrect.
Great strategy. It worked brilliantly as a way to bring open-source winmodem drivers to Linux. Oh, wait... it didn't, did it? We basically had proprietary binary drivers for Lucent winmodems that worked under a few specific distros, and IBM eventually did the same for THEIR audio/modem chipset for Thinkpads.
Yeah, someone finally did develop a true open-source HSP driver for his college thesis a couple of years ago and released it to the community, but for all intents and purposes, there were never open-source Linux winmodem drivers until almost a decade after they ceased to actually *matter* to anybody. It won't do us much good to get true open-source wimax drivers for a phone like the Nexus S 7 years after Sprint has switched to LTE.
This IS the #1 fundamental problem of American Android users, because it's the one problem we can't fix ourselves. Bootloaders get cracked, and just about any phone can be JTAG-reflashed if you're really determined. But without a way to use a radio modem (or camera, or GPS, or ???) .ko compiled for 3.x under a 3.y kernel, we'll be forever running into brick walls every time a new version of Android gets released, and forced to choose between ${new-version} and fast data/gps/camera/etc.
Not really. The lack of a stable ABI *is* a major problem, because it means that every time a new version of Android gets released that needs a newer kernel than the latest "official" one available for the phone, every proprietary loadable kernel module (for things like 4G data on carriers like Sprint) ends up breaking. As far as I know, not even the Nexus S 4G has buildable driver source available for its wimax interface, which is why every guerrilla ICS ROM for it has broken 4G. It's even worse for HTC phones, because they don't even release their drivers as proper loadable kernel modules -- they just compile them straight into a monolithic binary blob, then rip out the proprietary bits and dump the unbuildable kernel source on the curb.
This is the #1 problem Google really needs to solve -- binary driver breakage every time the kernel gets upgraded. Maybe they could create a stable thunking layer that allows a .ko built for a 3.(n+X) kernel to keep working on a 3.(n+Y) kernel, so every new Android release won't subject us to the usual cycle of 4G data that's instantly and semi-eternally broken. Or maybe just force the phone makers to blindly compile and release new unsupported proprietary .ko files for drivers with the latest kernel within 5 days of Google's official source drop, with the usual disclaimers that the new .ko files are untested, unwarranted, will cause birth defects, and might make you hunting for chocolate at 3am.
> Not sure how to do this with a laptop though.
"He stole my laptop. I stole his dignity" :-D
http://www.inquisitr.com/101482/mark-bao-laptop-stolen-revenge/
"Pwn3d by owner" http://www.gadgetsdna.com/defcon-zoz-got-his-stolen-computer-back/7640/
The moral of the story: if your personal entertainment is more valuable than your data or hardware, don't lock the OS down too tightly. Just give yourself remote access to the system, a way to sync files back to your server, some kind of DDNS app, and give the thief every incentive to not bother reinstalling Windows so you can have fun with him remotely and make him regret having ever messed with you.
Not quite... only *successful* landlords who actually make money are that way. The truth is, it's way more profitable to be a slumlord than to have affluent tenants. If you're a slumlord, you can rent out a shack that costs you $400/month to own for $200/week and pocket 99% of it. If you own a nice house or condo that costs you $1,600/month (mortgage, taxes, and insurance) to own, you'll be lucky to rent it out to someone "nice" for $2,000/month. Same $400/month nominal profit. The difference is, if you're a slumlord, there's no expectation of real maintenance. If something breaks, you can tell your week-to-week tenant to take a hike if he's not happy, and give the next tenant a $10/week discount. In contrast, the hipster renting your nice condo is going to demand instant (including weekend) repairs if *anything* goes wrong. A single clogged toilet has just wiped away your profit for March. A burned-out starter capacitor in the central AC is going to wipe it away for July (the slumlord will have to fix it too unless he wants an unrentable unit, but he can take his sweet time and pay someone to fix it off the books for $60 cash instead of as a $500 weekend overtime repair job).
Lots of aspiring middle-class investors found this out the hard way after they ended up being stuck with properties they intended to flip. They went into landlord-seeing-dollar-signs mode, and quickly found out that most of the time, if you own a nice property bought at the most insane peak of the real estate boom, you'll be lucky to LOSE "only" a few hundred dollars per month per year after you've collected the rent and paid the bills. The only landlords who genuinely make real money are the slumlords who own a few dozen or hundred units in cracktown and rent them out to poor people with no credit (because it's expensive to be poor).
The difference is, quite a few banks will allow you to use a debit card to overdraw your checking account. A couple of years ago, someone got my debit card number and managed to empty and overdraw my checking account by about $1,800 within about 3 hours. It took the bank 3 days to provisionally credit me back to zero so I could at least cash a check from my parents and have cash to live on until they finished their full investigation and credited back all the fraudulent charges. In the meantime, I had scheduled payments bouncing and racking up $29.95 NSF charges that required another round of fighting with the bank to get removed.
When your credit card gets fraudulently used to rack up charges, you can calmly wait until the statement arrives, highlight the fraudulent ones, and wait for them to fix it. When your debit card gets used to take your checking account negative, you're (at least temporarily) fucked. Because so much in the financial industry happens on autopilot and gets blindly triggered by events that can cascade and snowball into a meltdown, you can literally have your credit score killed for months by the fallout from a major debit card incident.
Put another way, anybody who thinks debit cards are a "better" alternative to credit cards is seriously naive. You're much better off just treating a credit card like a debit card & paying it off monthly, and using your debit card ONLY as an ATM card.
> Free speech must be absolute or else it is worth nothing.
Er, I suppose you're unaware of something called "Common Law", which is every bit as established and valid in the US as Constitutional Law. If you're writing/speaking about a political cause or politician, you have a very strong (in fact, a nearly-absolute) affirmative defense. If you're writing/speaking about a celebrity or corporation, you have a slightly weaker affirmative defense that's still pretty strong. If you're writing/speaking about a private citizen who's done nothing to merit public scrutiny, you're going to get your ass sued... and sued into oblivion if what you wrote/said is demonstrably slanderous/libelous on top of constituting harassment.
The constitution applies to conduct by the government. Common law applies to actions between individuals. Common law has a long, well-established tradition of recognizing that there's a line between "things that are false" (slander/libel) and "things that might be factually true, but are none of your business or anybody else's". In a case like this, intent matters. She might not be able to sue him for slander or libel, but harassment is a definite possibility.
The justification for ordering specific performance (removal of the blog, refraining from future public comment about the woman over the internet) is based upon another well-established legal principle: Equity. Equity is an extraordinary relief granted by courts in situations where monetary judgments are not sufficient to make the injured party whole.
If the woman became a public figure, the man might have had an affirmative defense. However, by all appearances, she wasn't.
It would also make us universally-despised by just about everyone on Earth, and the moral equivalent of Genghis Khan. In case you've forgotten, we're supposed to be the good guys. We make occasional mistakes, and occasionally a psychopath slips through the chain of command, but for the most part, we do try to be a force for good. It might be mostly out of enlightened self-interest rather than genuine altruism, but at the end of the day, most of us can go to sleep at night with a fairly clean national conscience.
Team America: World Police is obviously satire, but it's a lot closer to the truth than most of us really like to admit.
And how many of them were NOT T-mobile branded, but nevertheless capable of HSPA+?
The only non-Tmobile-branded phones I'm aware of that are capable being coaxed into doing 1700/2100 plain-vanilla (non-HSPA+) UMTS at all are Samsung's GSM Galaxy-S phones (AT&T Captivate & international i9000). I'm sure there are a few others, but they're rare. Likewise, most foreign phones can now limp along and do 1900MHz plain-vanilla UMTS on AT&T, but very few that can also do 850MHz UMTS. I don't think there are ANY non-AT&T-branded phones that can do HSUPA on AT&T.
As a practical matter, if you care about getting the fastest data speeds possible, America's two nominally-GSM networks are almost as de-facto proprietary as Sprint and Verizon. And the tragic punchline is that when AT&T, Verizon, and (now) Sprint roll out LTE, they're going to be equally incompatible with each other and everyone else on earth despite LTE nominally being a global standard.
Buying your own phone doesn't matter with Verizon or Sprint. Non-Sprint phones can never be activated under a Sprint account (they can roam, but never be the phone for a real Sprint account). Verizon will let you do it if you twist their arm and escalate it high enough (possibly due to a consent decree inherited from AT&T years ago), but they won't actually *help* you, and you'll never get EVDO to work, only 1xRTT due to radio firmware funkiness unique to Verizon. There's no actual engineering reason why it HAS to be this way (it's purely a matter of software and business process; the hardware is identical), but unfortunately, that's the way it is.
In theory you could buy an unsubsidized phone for AT&T or T-Mobile, but in most cases you'd only be able to use GPRS and EDGE on T-Mobile (most foreign phones can't do 1700/2100 HSPA+), and I'm pretty sure most imported phones can't do HSUPA on AT&T (and often, the only models that can do 850MHz UMTS are the ones intended for Australia, which are so expensive when imported to the US that you could almost buy a Verizon phone and pay for the service for two years for what you'd pay for the imported phone alone).
The unfortunate truth is that America's mobile phone market is as structurally fragmented and messed up as Japan's, and only slightly more likely to untangle itself over the next 25 years into something resembling tortured interoperability.
VCRs are the best example of all. A couple of years ago, I started digitizing my old tapes in earnest, and quickly discovered that the tapes I recorded back in middle school & high school (late 80s/early 90s) on a Canon VCR that cost about $900 (one of the first-generation VHS Hi-Fi models with helical scan tape-handling and HQ) were almost pristine. The tapes I recorded in the late 90s on a $150 VCR from K-Mart purchased sometime around 1998 were almost unplayable without full-frame timebase corrector, and STILL required unbelievable amounts of post-processing to make them tolerable. The old VCR actually had better monochrome detail, and better color separation, than the new one did. The old one obviously had "floating red dress syndrome", like every other NTSC VCR in existence, but the new one couldn't even get yellow and blue consistently right.
I can't remember the name of the AVIsynth filter I had to use, but there was one combo that separated each field into Y, U, and V, then had to shift the U and V components horizontally to properly line up with the Y (translation: if you view the image as a black & white image with color overlaid by transparencies, the stack didn't quite line up by default, and you had to bump them around relative to each other to get the alignment right). The tapes from the 1980s VCR didn't have this problem. The tapes from the 1998 VCR did.
The worst tapes of all were the few that got made on a third VCR purchased sometime around 2002. They're almost beyond salvation. I gave up trying to restore them, and just settled for making them halfway watchable.
For what it's worth, the VCR used for playback & digitizing is a Panasonic S-VHS VCR from ~2005 that has its own single-line TBC. It cost about as much as that first Canon VCR when it was purchased way back in 1987.
The story with CD players is almost the same. My brother has a CD player he got for Christmas in middle school circa 1984. I think my parents paid almost a thousand dollars for it. It still works, and works flawlessly. In my closet, I have 3 CD players purchased since 2000, none of which managed to go for more than two or three years before physically breaking.
The only thing that sucks about the first-generation CD player is the audio quality -- I guess back then, DACs and RAM were super expensive, so they did wacky things like use sample-and-hold circuits to use a single DAC with two audio channels. That's part of the reason why first-gen CD players had left-right separation issues and frequency response that ended up being way less than what the redbook audio standard suggested they would. However, the only CDs for which it really makes an audible difference are those from the late 90s... earlier than that, and the source media was substandard. Later than that, and the loudness war & rebirth of clipping & THD made it the least of its problems.
West Nile Virus? Yawn. Scary name, probably the most innocuous virus you can get infected by in Florida. For the overwhelming majority of people who get it, it's basically flu without a runny nose (ie, fever, muscle aches, and malaise). You obviously don't want to go out and TRY to get it, but the media hysteria over it was WAY out of proportion to the actual risk.
I wouldn't say that. If anything, HeadFirst books are awesome for experienced programmers learning something that's outside their usual comfort zone, because they trick you into reading useful things that you'd otherwise be inclined to yawn and skip over (missing something important in the process).
I don't know about you, but when I get home from work on most days, I'm fairly burnt and fried. I need a certain degree of entertainment and engagement, and a dry textbook about some programming (or other) topic is going to leave my eyes glazing over within about 20-30 minutes. The HeadFirst books are *precisely* the kind of books that justify printing as books, because they add substantial value to their content in the form of coherent editing, humor, and entertainment.
Yes, you can learn most programming topics from online docs... but that doesn't mean it's the most efficient way to go about doing it. Your time is a scarce, valuable resource. It's not a crime for things that are useful to be entertaining & humorous as well, especially if it makes the act of learning more enjoyable.
OK, I'll bite and mention one specific thing that's been horribly broken ever since the transition to digital TV -- it's fscking impossible to have multiple TVs tuned to the same channel in adjacent rooms and have them all be in sync, because each one decodes the MPEG-2/MPEG-4 bitstream at a slightly different speed, with different amounts of buffering and processing.
What? Distribute the same source to all the TVs? If you use component video and analog audio, it might... MIGHT... work. But the moment you go digital, it all goes straight to hell, because every component along the digital chain adds its own latency, and even uncompressed video still gets subjected to different amounts of buffering and scaling delays by each TV (in theory, component video can have scaling delays too, but 100% digital seems to be the absolute worst of all when it comes to getting 3 different TVs being fed the same input signal to display the same output in realtime).
What's really needed is some way to broadcast a heartbeat signal through the entire house (probably via power line) every 100ms (5 or 6 50/60hz fields), add a flag into MPEG-2/4 video and raw HDMI that arbitrary tags the first out of every 5/6 fields/frames as "field/frame zero" (the next 5 or 6 are untagged), then have the output devices ("TVs") buffer output fields/frames (and their synchronized audio) in a ring buffer until they see the pulse. In other words, the TV might buffer frame 0, buffer frame 1, buffer frame 2, then see the pulse and output frame 0. From that point, it would continue buffering new frames/fields, and showing the next buffered field/frame with its own timing. It still might not quite be 100%, but at least it would be an improvement over what we have now, where 3 different TVs in adjacent rooms with their own cable or DirecTV boxes can actually be SECONDS apart (especially when a DVR is involved).
Clearly, you've never suffered the horrors of FedEx Ground. I've caught them RED HANDED skipping delivery attempts, and gotten them to admit (off camera, unfortunately) that drivers who skip stops are known to be an "occasional" problem. A few years ago, I was home for the day getting my roof replaced. FedEx Ground claimed that there was "nobody home" and said they "left a note". At that point, there were no fewer than 7 people roaming around, including at least 1 or 2 in the front yard (possibly including myself). The NEXT day, I left a webcam pointed at the driveway & recording. 6pm arrived, no package, no note... and they claimed there was. When I confronted the FedEx manager, he first got irate, then broke down and grudgingly admitted that there "might" be a problem with the driver and said he'd "talk" to him.
The impression I've gotten from various sites is that due to the way FedEx Ground (a.k.a. "RPS") works is that the packages end up at a depot, and drivers (who own their own trucks and are basically free agents) grab the ones they want to try and deliver. Apparently, there's an official process for making unwilling drivers attempt to deliver other packages, but they don't push it unless somebody escalates. In the meantime, they'll automatically log a package left at the depot as a failed delivery attempt.
The worst delivery record of all (in terms of packages that FedEx Ground either doesn't try to deliver) are packages that require a signature. FedEx Ground drivers get paid by the successful delivery, so when there are LOTS of packages waiting to be delivered, they intentionally bypass as many that require signature releases as they can, especially if you live in a gated community and they aren't certain you'll be home. It wouldn't be so bad if their depots were at least open until 9 and on weekends for pickup, but they're not. Getting them to pull a package from a truck so you can pick it up (within a fairly restricted range of hours) almost takes an act of god. UPS, in comparison, will let you camp out at their facility the day of a missed delivery and grab the package off the truck when the driver gets back to the depot.
UPS might not be perfect, but they're infinitely better than FedEx Ground.
Unless something has massively changed in the very recent past, Clang doesn't analyze Java (directly). EVEN IF you somehow managed to coax gcc into outputting something Clang can analyze, it's questionable whether the output would even be relevant. At best, you'd be scanning for vulnerabilities due to bugs in Android itself (which obviously exist, but are unlikely to be easily found as low-hanging fruit). At worst, you'd be completely wasting your time looking for vulnerabilities that might hypothetically exist if it ran under Hotspot, and totally miss any real vulnerabilities that might exist due to Dalvik.
They exist (though they're extremely immature at the Android end of the spectrum), but they're breathtakingly expensive. I'm not allowed to cite specific products or prices, but we're talking "annual licensing fees comparable to the salary of a full-time human employee for 3-6 months" expensive.
OK, I got interrupted halfway through the post, and accidentally made it look like I was attributing 100% to the CPU alone. The full argument I intended to make was that if you compare a 16MHz 680x0-ish PalmOS phone circa 2002 to any ~100MHz Windows Mobile phone circa 2003 or 2004, the PalmOS phone will almost always "feel" faster, because the PalmOS phone used separate peripherals for everything, but the nominally-faster WinMo phone tried to use the CPU for everything. It's the combination of CISC (enabling 16MHz to go farther and do more) and coprocessors (spreading around the workload) that makes the difference. I started making a two-part argument, then forgot to make the second half. The inclusion of the Atom in examples was just a brain fart ;-)
Personally, I think the ultimate endgame of RISC-vs-CISC will be along the lines of being able to program your own custom CISC opcodes using RISC-like microcode, so every program (or at least every program with OS-level access to the underlying CPU) can have its own hyper-optimized instruction set whose microcode gets executed (more or less) asynchronously to the main system clock (ie, the main clock fires it off and determines when it checks for the result, but what happens in between is up to the local virtual clock). Trying to make it work for userspace apps in a shared runtime environment (like Windows) will be an absolute nightmare in terms of both arbitration and security. but I think it's the direction x86 CPUs are eventually going to drift just because there aren't many other directions where they can go that will enable them to keep up their historical levels of exponential performance growth.
Which means we go back to the same strategies we did in the 80s and early 90s -- coprocessors. Or, put another way, multiple cores, stacked GPUs, DMA, hardware DSPs. And (gasp), the Second Coming of CISC.
At the end of the day, RISC was a way to get cheaper megahertz (and later, gigahertz). Now that we've largely maxed out clock speed to the point where it's almost counterproductive, CISC is just about the only place we have left to go. Instead of wasting 50 cycles loading values into registers. operating on those registers, evaluating the outcome, and branching based upon it, you can have complex variable-length opcodes that use billions of transistors and have sinful amounts of silicon dedicated to niche operations that would have been absurd to even contemplate 25 years ago with far fewer clock cycles.
There's a reason why a 16MHz 68000 can still run circles around a 100MHz ARM, and why a 1GHz Pentium-M beats a 1GHz Atom or Arm to a bloody pulp -- the CISC chips get more done behind the scenes with every public clock cycle. The fact that behind the curtain, they're secretly executing chains of RISC instructions with private, semi-asynchronous clocks as fast as they can & just presenting the public facade of a CISC architecture responding to a system-wide clock is a quibble. The point is that every time the public system clock ticks, they're getting WAY more done than a conventional RISC architecture could ever fantasize about. In effect, a modern AMD64 (or Core2) CPU is like a container full of virtual, disposable/pooled RISC processors that get instantiated to execute a single public opcode while privately dancing to the beat of their own drummer.
TimerTask might never have been officially "supported", but the practice of using it was widespread to the point of making it into at least one major book on Android programming as an example.
Yes, Android has always been entitled to kill background services when RAM is needed, and has reserved the right to do it for any reason, or no particular reason at all. The unhappy surprise was Gingerbread's aggressive enthusiasm for killing background services for reasons seemingly closer to "just because it feels like it".
In Froyo, it was reasonable to assume that Android wouldn't kill off a background service unless there was a bona-fide need to free up resources, or the service appeared to be leaking resources or spinning its wheels doing busy-waits and keeping the phone awake for extended periods of time. As of Gingerbread, it literally DOES appear to kill off long-lived, but otherwise tame and sleepy, background processes just because it thinks they've been running for "too long".
There's a bigger problem -- to this day, there's no easy way using the bare API to say, "at XXX, wake up the phone, attempt to connect to a network, make this complete http request, and keep the phone awake until its response has been received, digested, and handled. Then go back to sleep if you feel like it." You can't directly pass a PartialWakeLock acquired by an Alarm's BroadcastReceiver to the service, but if you merely try to start the service so it can acquire its own partial wake lock, there's no guarantee the phone will remain awake long enough for the service to finish initializing. There are various ways to kludge around it using static objects, but Android's own development team has admitted that they're ugly hacks. That's why so many people used long-lived services with TimerTasks -- they worked. Not 100%, but if you could live with the service running only while the phone was awake, and you did your part to have well-behaved and polite Threads, they worked pretty well (and definitely worked better than most guerrilla attempts to make Alarm-triggered network activity work properly).
What Android's API *really* needs badly is something like PendingHttpRequest, where you could set up a HTTP(S) GET/POST, specify the args, define intents to fire when it succeeds or fails, and throw it into a metaphorical pile for Android to execute as a bach along with PendingHttpRequests from other apps/services within 1, 5, 10, 15, 20, 30, 60, 90, 120, 180, 240, 360, 480, 720, 1080, or 1440 minutes. THEN, let ANDROID deal with bringing up the network, firing them off, retrying if appropriate, and shutting everything down when it's through. Kind of like the general idea behind SetInexactRepeat, but incorporating wakelocks and network-connectivity management into the equation as well. The problem we have now is that everyone is forced to reinvent the wheel, and just about everyone does it badly.
Network connectivity in a narcoleptic Android device is a really hard problem for individual developers to solve. Wakelocks are a dance through a minefield. The need to make a single successful http request at some not-particularly-critical point in the future when the phone has reliable network connectivity is a common use case, and we'd all be better off if there were a nice, clean, easy way to just throw the URL, args, and handler intent at Android and say, "here's the request. Make it properly, and let me know when it's done."
We hoarded Trinitron monitors up to the point where a LCD capable of 2560x1920 became semi-affordable to people who could previously afford a CAD-quality 21" Trinitron. For people used to having 1920x1280, 1920x1080 was a really harsh, bitter pill to swallow, especially when you factored dead/stuck pixels into the equation. I bought my first LCD around 2007, and had a daily love-hate relationship with it up until the happy, healing day I threw it in the trash on a pretense over a dying inverter and replaced it with a 30" 2560x1920 (now flanked by a pair of 22" portrait-orientation 1080x1920 displays)
> SSH from a phone? Why on earth would you do that except as a last resort?
Because it's Saturday night, you're at a bar with your friends, and the server decided to get bitchy on you. ConnectBot means not having to trek back to your car, boot the laptop, tether, and connect up to fix something you can troubleshoot in about 30 seconds.
And yes, ConnectBot sucks donkey balls with onscreen virtual keyboards, partly because Android doesn't allow you to have a default system-wide IME, but specify specific IMEs for specific programs (I'm a Graffiti guy, but have to switch manually to some other keyboard to use Connectbot because Graffiti doesn't have any concept of cursor-up). It's not ConnectBot's fault, but that doesn't make the situation suck any less.