... and if it does, there's an equally-plausible likelihood that sea levels will (at least temporarily) fall as the ice floats into the sea, and seawater flows onto the submerged coastline formerly occupied by ice. That's not to say it'll have no net effect, and won't eventually melt faster than it would have melted otherwise, but rather to point out that even "fast" means "decades" instead of "centuries".
Not to mention the crazy fantasies some environmentalists have that people would actually just *allow* rising sea levels to destroy any valuable property, or that civil engineers are just going to disappear from the earth.
We're talking about a gradual rise of a couple of feet over the span of hundreds of years, not a fsck'ing tsunami. Major hurricanes bad enough to destroy anything smaller than a skyscraper badly enough to require demolition and rebuilding happen about once per century. As those non-skyscrapers get destroyed, they'll just be rebuilt on taller pilings (or get rebuilt as skyscrapers). Either way, the surrounding terrain can be built up with fill dirt (possibly dredged and pumped from offshore, like the sand used to rebuild Miami's beaches every few years).
In the case of skyscrapers that can't be raised, they'd do what they did in places like Chicago -- turn the second floor into the first floor, turn the first floor into the basement, and spread another 8 feet of dirt around the building's base. In a city like Miami, the roads would get rebuilt a foot higher every few decades (like they have anyway... take a peek at West Road in South Beach sometime, and compare its height to the height of any adjacent building that's more than 10 years old)... gradually turning the surrounding area in poor neighborhoods into a soggy, swampy slum where water flooded front and back yards after most rainstorms. Wealthy areas would get built higher, and in the meantime they'd have more expensive actively-pumped drainage systems added to deal with the annoyance of roads that flood after every summer rainstorm.
Eventually the poor (increasingly swampy) neighborhoods would get bought up during a future real estate boom, bulldozed away, covered by a few feet of new fill dirt to raise them higher than the road again, and covered with expensive new homes. The really, really, hopelessly-poor areas would eventually get bought up and turned into limestone mines (providing cheap fill dirt for buyers in the remainder of the city), and eventually Miami would have a big urban inland lake between I-95 and roughly NW 17 Avenue, bounded by Metrorail and State Road 112 to the south, and ending a mile or two south of the county line. In cities like Washington DC (where the buildings have historical significance and can't be casually rebuilt), they'd just dam & levee the Potomac, and upgrade drainage systems from passive ditches to actively-pumped storm drains.
There are plenty of places that exist RIGHT NOW that would be submerged underwater for all or most of the year if it weren't for active drainage and civil engineering. The only thing rising sea levels would change is the need to do the same thing in areas that historically were capable of being kept dry by less aggressive means.
It's the same reason why, year after year, the NHC issues dire warnings about inland flooding from storm surge due to hurricanes in Florida that ultimately fail to pan out once you get more than a block or two inland -- they're all based on models of a natural coastline that hasn't actually existed in decades, and fail to take into consideration the existence of large-scale urban stormwater management systems.
> Kind of like the nazis? Put people into labor camps and work them to death.
No, this is Slashdot. Remove their brains (effectively killing them), then turn their still-respirating corpses into biomechanical robots and send them to work camps.
Good god, are you even in middle school yet? Even 10 years ago, realtime-3D was mostly sleight of hand and programming hat tricks (think: Battle Arena Toshinden, probably the best example of a game that did a spectacularly good job of pretending to be 3D).
The 2600's hardware was seriously weak, but the biggest problem with its games were the fact that it had an astronomical learning curve. Take a simple question, like "what was the 2600's resolution?" The truth is, there IS NO simple answer to it. The 2600 has different "kinds" of pixels, and different ways to express pixel hue and luminance, and few of its "rules" were hard limits so much as timing limits you ran into when you just couldn't bitbang things fast enough.
It's hard enough to explain the 2600's theory of operation to someone with an EE degree. It wasn't enough to know "how to program" -- you had to get "down and dirty" with its hardware to a degree that's almost impossible with modern PC hardware. Literally, impossible... in most cases, the OS (Windows OR Linux) won't even *let* you get that close to it. At least, not unless you tried writing your game as a loadable kernel module, or you somehow managed to pwn Windows and get it to execute your program as Ring 0 kernel code. Go ahead... open a 320x240 legacy VGA screen filled with a single color pixel, then try bitbanging raw assembly by busy-waiting and counting clock cycles to change the contents of that one color register in realtime as the imaginary CRT your LCD panel is emulating scans each line. That's basically how many of the 2600's video effects worked.
On a modern PC, it won't work. Literally, won't work. Why not? Because modern multicore x86 architecture isn't realtime-deterministic, and hasn't been for years. Oh, the OUTCOME of a given sequence of assembly language, in the form of a specific value stuffed into a specific register or stored in a specific memory location when the dust settles, is certainly deterministic... but what happens between point "a" and "b" isn't.
On the Atari 2600, you could count the number of cycles each assembly instruction took to execute, and calculate which pixel would be getting drawn on the screen at the moment it happened (I think it was 3 pixels per clock cycle). Contrast that with a modern PC, where multiple cores, pipelines, speculative and out-of-order execution, and a hybrid architecture that decomposes traditional x86 CISC operations into bundles of virtual RISC code "behind the scenes" mean that everything that happens "along the way" is subject to the CPU's "mood".
The games that aged well were the ones that were games first, and graphics demos as an afterthought... Warlords, Circus Atari, Space Invaders, Asteroids, er... well, you know what I mean. What's kind of sad is that the games that IMHO aged the best were the ones I got for Christmas along with the 2600 itself. It seems like almost every game I got between Christmas 1981 and the arrival of my Vic-20 a year later was a disappointment and letdown, partly because Atari's ad agency was too good at hyping them up and making you think they wouldn't be lame and kind of suck. I mean, Defender and Missile Command weren't bad, and Berzerk was OK, but it seems like most of the best-looking games were fun for about 20 minutes. I think I had more fun watching Pitfall's hi-res rope swing back and forth than I ever did actually *playing* it.
A few good games came out after I'd fled for greener Vic-20 pastures a year later (Ms. Pac Man comes to mind), but Atari's quality seriously went down the shithole that summer, especially post-Pacman -- the point when all Atari's management could see were dollar signs and a license to print money, and they had their developers cranking out shit games with undersized cartridges and minimal quality control -- relying entirely upon a rapidly-slipping brand name and marketing -- to keep the cash flowing. By the time they got their mojo back with Ms Pacman, most of us had moved on to greener pastures -- the Vic 20, C64, and the Atari computers, in particular. Or we got a Colecovision. Or both.
It's too bad Coleco's licensing was so short-sighted and such a clusterfuck mess... if any vintage console has real market potential today as a "joystick with embedded videogame and cartridges", it's the Colecovision. Unfortunately, the licensing deals they made in haste and heat guaranteed that Colecovision games will never legally see the light of day in new hardware built this century. I don't think whomever owns Coleco's IP today could even legally still sell Smurfs, let alone Donkey Kong.
It needs to be network-agnostic (so it doesn't just give Google a more total and complete monopoly over Android advertising than they have already), but it needs to be a black box beyond the application's direct realtime control. Otherwise, apps that request "advertising" permission, but not "network" permission, could still use it as a very slow back-channel for leaking information by using things like the rate of ad changes and/or the sequence in which specific ads are requested to encode a bit or two at a time into each ad request that they could then run offline data-analytics on to reconstruct the data hours, days, or weeks later.
But yeah, they really didn't think through the practical combos of permissions when they came up with them. As it stands, it's practically impossible to even FIND an app anymore that doesn't require network, location, phone state, wifi, and personal identity. Even an innocent, well-behaved app needs the network for fetching ads, location for targeting, phone state (so they can go offline and/or pause when you're in the middle of a voice call), wifi (so they can do SSID-based location sniffing since GPS is dysfunctional indoors and tower-based doesn't work well in the US due to differences in the way CDMA vs GSM towers define "location" (CDMA voice and 1xRTT are soft-matrixed among multiple towers, so there isn't really one specific tower to unambiguously call "the tower you're using" like there is with GSM).
What would be nice are some new, refined permissions. For example, a permission that allows apps to power up wifi enough to "sniff the air for SSIDs" without actually establishing a connection. Or a permission that allows a unified location service provider to use the best source of location information available to it, but reduce the precision of the location to something like 1/64th to 1/256th of a degree (with optional, user-defined "blackout zones" (like a 1/2 mile radius around your house or office) where your location is increasingly skewed towards some alternate nearby location up to a mile away as you approach it.
"Black box advertising" would also open up another possibility -- ads targeted to users in a precise geographical area that don't actually disclose the exact location of the user. For example, suppose a business wants to show 3 different ads depending on location.... one to users in a few specific polygon-defined neighborhoods, one to users who are in a larger polygon-defined area that doesn't include one of the more specific ones, and everyone else. With black-box ad permissions that seal it off from the app, the ad client could be served all three ads, then locally choose to show the precise one intended by the advertiser without disclosing which one was actually shown. Or reporting the count to a thirdparty auditor that lets advertisers know how many people saw it, without ever allowing the advertiser to get anywhere near things like IP addresses and unique IDs that could be data-mined to recover the anonymized info.
OK, real-world semi-rhetorical question. What's worse... drivers that are tailored to a specific kernel, but leave end users with a phone that has dysfunctional GPS, camera, 4G, gyro, and whatever else was broken by the new kernel for 5-9 months until the phone's manufacturer grudgingly releases its official update, or drivers that will continue to work with the new version of Android many, many months before the official release ever sees the light of day?
Let's be honest... the Linux ABI breaks because half the kernel maintainers WANT new kernels to break old loadable kernel modules as badly and frequently as possible, and the other half of the kernel's maintainers got tired of fighting with them 10 years ago.
The sad truth is, Qualcomm owns the patents that run America's mobile phone networks, and nVidia makes most of the chips inside the Android phones sold by those same networks. Neither company is going to embrace open drivers anytime soon, and the only thing the current ABI-instability accomplishes is the wholesale DIS-empowerment of end users with Android phones, by keeping us dependent upon our carriers and phone manufacturers for new drivers.
Putting it back into a nVidia context... would you trade 0.2% of your video driver performance if it meant being able to upgrade your kernel at will, instead of having to wait for an official release of a newer one built for your specific kernel?
> This already exists, it's called RMS (Root mean square).
The problem is, a given amount of power doesn't produce the same perceived loudness across the entire audio spectrum. The LU calculation deprives the music industry of its former ability to game the system by focusing the most energy on the narrow band of frequencies that are perceived as being the loudest.
RMS is a nice, simple concept that works well for measuring amplifier power of a 1KHz sine wave at a given max percentage THD, but it's too easy to game when using it to predict loudness. Unless you want popular music to devolve to little more than powerchords striving to emulate the "The Deep Note" (http://www.youtube.com/watch?v=HtIOhYqrr00) and throwing everything they have at the range of human hearing that gives them the most loudness per watt, we need something a little better than RMS.
Except pre-recorded music that doesn't sound like shit on quality stereo gear.
This is actually an example of *good* legislation. The whole reason the "loudness war" happened in the first place was pressure from upper management on recording engineers (who, by and large, knew why doing it was bad, and who were mostly forced to go along with it if they wanted to remain employed) to make their next CD a little louder than everybody else's, until we got to the point where a 2004 pop CD was quantized to levels once exclusively the realm of a Telarc *DIGITAL CANON* in a recording of 1812 Overture whose main purpose was to show off your kilowatt-RMS amp and array of subwoofers. What the government did in this case was let the engineers off the hook. When management asks them to "pump up the volume", they can say, "Sure, I can do that. But no radio station in the country will play it, and all the money we're spending to promote the artist will be for naught. Do you still want me to do it, or would you like me to master a recording that sounds good and that radio stations will be able to play?"
I want immersive, clipping-free digital audio back like we had when I was in college. If it literally takes an act of Congress to ensure that 95% of the audio on a 16-bit CD quantizes to an absolute value of 0x3FFF or less, so be it. Now get off my lawn, or I'll have to remind your parents what digital canons sound like when you have a kilowatt (RMS) amp and a pair of 18-inch JL Audio subs in the trunk...
Or do the next best thing... come up with some kind of binary thunking layer to allow binary drivers to do an end-run around Linux's endlessly-changing ABI and allow a binary driver written for an older kernel to limp along under a newer one for the time being. And team up with Google to do it, so every fscking new version of Android won't catastrophically break every.ko driving a Qualcomm chip.
Someone seriously needs to take charge of this and just do it. I mean, for god's sake, if NDISWRAPPER can make *WINDOWS* drivers usable with Linux, how fscking hard can it be to build your own drivers in a way that everything they do interfaces with the kernel at arm's length through your own totally 100% open-source thunking layer, so that whenever a new kernel comes out, end users can recompile the thunking layer and keep using the older loadable kernel module? Hell, at this point, I suspect even Linus would grudgingly cooperate and throw some suggestions at such a project... not exactly *encouraging* it, but peeking at it once it a while just to make sure they don't accidentally do something totally bad.
Once... just fscking ONCE... I'd like to be able to upgrade to a new version of Android without having the camera, GPS, 4G, and half the phone's other features catastrophically break until someone manages to get their hands on leaked drivers from either a phone with compatible hardware and newer version of Android than mine, or leaked drivers that are being beta tested for my own phone's official release.
The succession rules aren't there to ensure that there's someone "who can lead America" -- they're there to ensure that there isn't a melee and free-for-all power grab among those same officials (or the military, or whomever) if this were to happen. They exist to guarantee that if person #4 on the list shows up to claim power away from person #6, person #6 will hopefully do the honorable thing (possibly at the prodding of the police and military) and gracefully hand power over to person #4.
We can live without elected federal leaders for a while, as long as whomever is nominally in charge plays by the rules and fills the role of "placeholder" until elections are held soon thereafter. We had a technically unelected president for almost two years back in the early 1970s (Gerald Ford). Few really liked him, and fewer still loved him, but he knew it, and in retrospect did a decent & honorable job of keeping the lights on in Washington and not rocking the boat until it was time to step aside. Frankly, a placeholder president would have zero mandate to do much of anything besides try to not piss off too many people during his or her short term of office.
If a small nuclear bomb were detonated in front of the Oval Office and took out most of the highest officials, the real chaos wouldn't be due to the lack of a President, but because the lives of everyone left in Washington (most of whom would survive just fine, and who are the ones who personally run America's bureaucracy on a daily basis), would be totally fucked up for weeks.
Anybody who lived in Miami after Andrew, or New Orleans after Katrina, knows what I'm talking about. First, you go through personal survival. Then you become obsessed with saving those you care about, or verifying that they're OK and don't need your help. Then you spend the next 2 months doing nothing besides drive to and from work in the most ungodly traffic jams you've ever seen in your life, shopping endlessly (with lines stretching to the back of the store) and dealing with random wacky shortages of just about everything, and trying to clean up the mess around you. That's part of the reason why the government's "nuclear plans" always involved rescuing the immediate family members of important officials once the officials themselves were safe (or simultaneously). You can't run the country when you're busy trying to rescue your own kids, or standing in line for 3 hours at Wal Mart just to get in the door.
Now, think back to September 12 through 18, 2001 -- the week after 9/11. Remember the people who just freaked out around you? Multiply that by 10, and you have the likely best case scenario to hope for.
A dead president, and deciding who's supposed to temporarily fill his or her shoes for a few weeks or months, would be the *least* of our problems.
> While MVC is a good programming model, I think most frameworks are just there to make the programmers work in a more common fashion > so that they can be more disposable.
No, MVC is good, and exists, because it's the best way anybody has found so far to allow a programmer who's not much of an artist to collaborate with an artist who's not much of a programmer to produce a substantial web application (or possibly a desktop/mobile application) without stepping on each other's feet every inch of the way, and without involving the bureaucracy of an official project manager and formal development methodologies to try and herd the cats daily and coax the productive work of three people working at full individual productivity out of eight who spend most of their time fixing the mess caused when the other 7 make mistakes or get in the way, or having meetings so they can actively try to have fewer such mistakes.
Why do the Chinese companies NOT provide/implement ADB drivers? Is it just laziness, or do they have some official motive for keeping ADB out of end users' hands? Also, wouldn't refusal to implement ADB mean those chips couldn't be used to build any Google-licensed device, because Google officially REQUIRES ADB support as a condition of licensing? I know 99% of the tablets made with them aren't Google-blessed, but why would a chipset maker COMPLETELY write off the market for official Google-blessed devices just to omit something like ADB that, compared to the rest of Android, isn't terribly hard to implement?
As much fun as it is to bash Microsoft, the sad truth is that the most TiVO-ized and locked down hardware on Earth usually runs some bastardized de-facto fork of Linux. Once Microsoft gets your money, they tend to not care if you want to blow away their OS and replace it with something else. Contrast that with the behavior of... say... Motorola, who's hellbent on shoving locked-down TiVO-ized hardware down its users' throats (though some of us haven't given up hope that Google will eventually make them non-Evil and force them to unlock their bootloaders).
I'm not sure whether IOS, Maemo, or Windows Phone handle it any better, but Android seems to have a real problem dealing specifically with scenarios where the phone has "a network connection", but no actual connectivity that works to "the internet". It's like things check to make sure the phone is "connected", then make blind assumptions based upon it without bothering to consider the possibility that the phone might be connected to:
* a wi-fi access point that's disclaimer-walled. You know, those annoying wi-fi access points that are free, but won't allow you to actually USE them until you swat away their disclaimer page, so that unless you remember to delete the connection to "AT&T Wayport" from some McDonald's, you'll find yourself randomly losing network connectivity while driving if you happen to stop at a red light within 200 feet of a McDonalds.
* Sprint/Clear Wimax that's "active", but has backhaul problems. Clear in particular seems to be kind of bad about taking wimax sites down when they're having backhaul problems, or fixing them on weekends. The tower by my office went into convulsions twice last summer for 3 days at a time, and I had to kill wimax to get my phone to be non-dysfunctional.
* Sprint EVDO that's point-blank dysfunctional during their "Network Vision" upgrade. Right now, and for the past ~2-3 weeks, Sprint's EVDO has been COMPLETELY dysfunctional, point blank, throughout most of South Florida. Most towers are "connectable", but at least half of them seem to have no actual upstream backhaul connection, no actual downstream backhaul connection, or both, at any given time. I've seen Speedtest give me things like 800-2000 down with zero up, and practically written a blues song for Youtube called "Five Bars and 50k(bps)" in honor of Sprint's pre-upgraded EVDO norm of having rock-solid connections to towers that only get 40-80kbps down (but 250-400kbps up) because they only have two T-1 lines servicing an entire cell site.
* The original reason I used to keep wi-fi disabled (before Sprint's 3G became totally dysfunctional and slow after "I-day" last fall), and a variant of the "disclaimer-wall" problem -- the phone will connect to wi-fi, then try too hard to maintain the connection when it has (what used to be) perfectly good 3G connectivity. Oh god, it used to piss me off when I'd get "no network" errors because I walked down the block and my phone was still trying to remain connected to my house's access point instead of using the tower whose blinking red light was visible from the sidewalk about a thousand feet away.
Anyway, you get the picture... there are lots of scenarios where simple probing of the phone's network state will suggest that the phone can get online, but in reality... it can't. And things like internet-updated widgets in particular seem to handle those conditions very badly. On New Year's Eve, my phone became dysfunctional to the point where I could barely even launch the CAMERA app starting ~10 minutes before midnight, and continuing until approximately 12:30am. I finally figured out that it was because there were running apps that were hellbent on fetching data despite the fact that Sprint's network was about to collapse from having 50,000 party-goers in the vicinity of a tower whose EVDO data service was sharing the equivalent of an economy DSL connection.
Google really needs to build some kind of active network monitoring capability into Android, and have it occasionally ping a globally-accessible IP address like 8.8.8.8 to confirm that actual network connectivity exists whenever something asks "is there a network connection" within a few seconds of a failed network data attempt. Yes, I know individual apps could do it themselves... but they don't, and won't. More importantly, this is something that SHOULD be handled globally by the OS for the benefit of the apps running under it, unless Google wants to find themselves getting pinged 40 times per minute by a half-dozen network-using apps running on a single phone, each of which takes it upon themselves to individually confirm network connectivity by pinging 8.8.8.8 or 8.8.4.4.
I've read lots of posts that said they "had" to use dualcore "because of LTE", but why, exactly, did the LTE-equipped US models non-negotiably *HAVE* to be dualcore? Is there some insurmountable engineering reason why they couldn't have just slapped a separate LTE radio module onto them, like Sprint has done with all of their high-end phones for the past 3 years to add wimax to them? I mean, did they make prototype SGS3 phone with Exynos, MDM6600, and Beceem LTE chip, then discover that the combination had a major problem with feedback or harmonics that nuked EVDO or LTE? Or was it just a matter of Samsung trying to save a few bucks by going with a cheaper dualcore SOC that has onboard LTE instead of spending more to build it with an Exynos and a separate LTE radio modem?
You also get to enjoy endless grief. My parents have a real TiVO HD with a pair of CableCards & live in an affluent city where they're far from uncommon. It hasn't worked properly ONE SINGLE TIME since they bought the TiVO and had the Cablecards installed. There's ALWAYS two channels that show up as "unsubscribed" at any given time. They call Comcast, file a trouble ticket, and the problem eventually gets fixed... and two OTHER channels go away and become "unsubscribed".
My dad is CONVINCED they actually have some kind of rack with fixed card capacity and a card or port per channel, their rack is maxed out, they have two more channels than available ports/cards, and that they just keep unplugging and swapping around two channels at a time (disabling their reception by everyone with cablecards) hoping they'll eventually find two that nobody cares about so they can avoid spending a few thousand dollars buying another rack just to accommodate two more cards/ports..
> Unless they hire a bunch of the top guys from XDA, their software will continue to be absolute shyte no one wants on their phone:(
You mean, like the guy behind Cyanogen? He's been a Samsung employee for about a year now. It's not a coincidence that Samsung has suddenly become one of the first-ported platforms for new versions of Cyanogen. Hiring him was a brilliant move for Samsung, because it allowed them to outsource the long-term development of their phone operating system for EOL'ed phones to an army of highly-skilled unpaid volunteers. Since he's an official Samsung employee, they can even let him have access to sourcecode, SDKs, and datasheets that companies like Qualcomm won't allow them to release to the general public. Thus, when a new version of Android gets released, he can personally churn out a new kerneland kernel modules for everything Samsung has soucecode access to within a matter of days He doesn't have time to indiscriminately REWRITE much beyond a few carefully-chosen phone models, but for any task that mainly comes down to dropping in the new kernel source and running make, Samsung phones are literally weeks to months ahead of HTC phones now.
That said, it's a good thing Samsung doesn't lock bootloaders and has Cyanogen's founder working for them, because their own in-house operating system development efforts have historically sucked donkey dick. Sprint's history of Samsung phones is littered with the corpses of unloved phones released with operating systems that were already considered old the PREVIOUS YEAR. The SPH-i300 shipped with PalmOS 3.5... when all the new apps at Palmgear needed 4. The SPH-i500 shipped with glorious 4.1, when all the new apps at Palmgear needed 5. Every phone had the potential to be great, but ended up getting ruined by arriving a year late and a few excessively value-engineered dollars short of tolerability.
An Android "hearing aid" app won't work, because the operating system and bluetooth add too much latency. Hearing aids are one of the most hardcore "realtime" embedded applications you can get, because hearing aids are an application where real users have close to zero tolerance for latency. Latencies in the TENS of milliseconds are distressing to hearing aid users, and latencies that would be annoying for a voice cellular call are *intolerable* for hearing aid purposes.
You *might* be able to root and reflash an Android phone into a dedicated hearing aid device... but an app on a regular phone? Never.
Try this as an experiment: write an Android app that samples the bluetooth mic, applies some trivial audio filter to the waveform, and plays it back through the bluetooth headphone. Now try walking around with it running -- you'll rip the headset off within 10 seconds, because the latency will drive you crazy.
One insurmountable problem: latency. No mainstream operating system optimized for general desktop or phone use -- Windows, Mac, OR Linux -- is suitable for realtime audio processing. Period, end of story. And if you took a rooted Android phone and rebuilt its kernel to give as much priority as possible to the audio processing subsystem, it would nuke the battery in an hour and you'd end up with a device that sucked as both a hearing aid AND an Android phone.
Maybe... MAYBE... if you wanted to help poor people, you could come up with a way to reflash old Android phones to a realtime-optimized kernel that repurposed the hardware exclusively for hearing aid purposes, but you'd still be stuck with wired headphones and microphones because bluetooth has too much latency. And miserably short battery life, even with an extended battery. Remember, you can't use power management with a hearing aid... people don't stop needing to hear just because the screen is turned off.
In any case, forget about trying to run a "hearing aid app" on an Android phone being used AS an Android phone and entertainment device. It won't work.
As a practical matter, some drugs really *are* "too cheap to counterfeit, and are expensive in the US only because we allow "use" patents, while other countries (like India) only recognize "manufacturing process" patents. So, drugs like finasteride (Propecia & Proscar) and atomoxetine (Strattera) are expensive in the US, and practically free in India.
Some drugs, like Tamiflu, *are* genuinely expensive to manufacture, easy to counterfeit, and *likely* to be fake.
Others are genuine, but expired or stored improperly (and possibly repackaged).
For the most part, drugs in the first category are perfectly fine, and most drugs from the third category are too. You just have to use common sense & do some homework to figure out which drugs are likely to fall into category 2 (hint: controlled substances like Xanax & Provigil almost always do).
Ironically, ebola's virulence and swift death is what saves us from global pandemic. Basically, ebola (and Marburg) are viruses that are too virulent and deadly for their own good. They kill their victims too quickly to ever have time to spread. The viruses that "survive" and "thrive" (in quotes, because viruses aren't actually "alive" in the conventional sense) are the ones that don't kill their victims, and quietly simmer and spread forever. Herpes is the classic example. Lucky people get infected by HSV-1 by their parents or grandparents, and suffer occasional outbreaks of oral cold sores for the rest of their lives. Unlucky people make it through childhood, then get infected from their first blowjob and end up with de-facto genital herpes that's technically HSV-1 instead of HSV-2.
Ebola's main transmission vector is bodily fluids seeping from a corpse. Ebola is self-limiting PRECISELY because it's so deadly and acts so quickly. The moment people realize they're dealing with Ebola, they go hide from everyone else for a few days. Within a week, everyone who was infected is dead, and the survivors can cautiously come out of hiding to clean up the mess. In Africa, when Ebola breaks out in a village, people leave the infected individual (who's not particularly mobile at that point, anyway) to die in his or her hut, then burn the hut to the ground. Callous and harsh, but to a large extent... among primitive people without access to modern medicine that itself can barely deal with it... it works, and it's worked well for thousands of years to keep ebola contained.
See the book I wrote a few levels above. The short answer: the chips are cheap, but making them work in a mobile device with headphones as the antenna is hard, and making them work in a moving vehicle is nearly impossible due to fundamental flaws in the way ATSC's underlying modulation scheme (8-VSB) was designed.
Put another way, for a few bucks more, Samsung could sell you a phone with a mini-75ohm coax connector that you could connect to a 3 story tall Yagi antenna pointing at the transmitter, and it would work perfectly. But it would be almost unusuable with headphones as the antenna, and literally unusable underground or in a moving vehicle because 8-VSB has serious problems dealing with multipath interference, and is almost completely incapable of dealing with doppler shift.
Receiving analog TV with modern chips is cheap, easy, and works well. The problem is, analog TV doesn't exist anymore in the US, and the standard that replaced it is almost impossible to receive using a handheld device with sub-optimal antenna in a moving vehicle.
Lots of phones DO have FM. Try connecting headphones and launching the 'music' app. You might be surprised. I had my Photon for almost 5 months before I stumbled over that feature by accident. I was expecting it to exist (if it did) as a "FM Radio" app, not as part of the "Music" app.
As far as TV goes, it's probably a lost cause. As a practical matter, a high end Android phone already has 80% of the hardware it needs to receive HDTV, and roughly half the remaining 20% consists of "an appropriate antenna" (believe it or not, the ATSC tuner is the least of your problems... it's a single chip that converts 8VSB-modulated radio into a ~19mbit/sec bitstream that the phone's existing hardware can deal with downstream). So, why don't manufacturers bother? Mainly, because American 8VSB-modulated HDTV is hard enough to reliably receive with a PROPER antenna, let alone a pair of headphones plugged into a headphone jack. Don't believe me? Buy a 99-cent UHF loop on eBay, connect it to your HDTV (through an appropriate 300-to-75-ohm balun if necessary), and see how many channels you can actually tune indoors with it. If you're lucky and live in the mid-suburbs approximately 5 miles from the local antenna farm, you might get one or two reliably. If you're downtown, you'll be lucky to get any at all.
It's a fundamental problem with 8VSB modulation. Back in the early 90s, engineers told the FCC & "Grand Alliance" they could optimize for range or robustness, but not both. They were told to optimize for range, and they did. With a proper 2-3 story tall directional high-gain yagi pointed directly at the transmitter, properly grounded, you can receive most American TV stations from 60 miles away with minimal effort, and up to 100 or so miles away if you really work at it. However, the moment multipath distortion (basically, echoes from signals bouncing ricocheting off buildings and mountains) becomes a factor, you can forget about receiving a viable ATSC signal at all. Analog UHF manifested multipath as "ghosting". Digital ATSC manifests multipath as "no signal".
HDTV tuners work in many other countries, because they went with a competing modulation standard called COFDM. COFDM's engineers made the opposite choice of American engineers. Instead of optimizing for range, they optimized for robust reception in conditions where multipath distortion would normally be a problem. The downside is that even a great antenna is unlikely to receive a viable COFDM signal more than 50 miles away. The upside is that you can sit in a moving vehicle driving around the central business district full of skyscrapers in some Asian boomtown and have a perfectly good signal to watch.
As bad as 8VSB is today, it was even WORSE 10 years ago. At least now, it's possible to semi-reliably tune with an indoor antenna if it's a GOOD one. You're still unlikely to get anything consistently watchable from the modern equivalent of a coat hanger (a pair of headphones plugged into a jack). Unfortunately, we've now come about as far as we can with DSPs, and future improvements to 8VSB are going to require extensions that will be backwards-compatible (ie, won't screw up existing tuners), but won't do anything to HELP old tuners. The work has been in progress for the past few years, mostly at the behest of FEMA, due to a very real fear that the next time a hurricane like Andrew roars ashore, people old enough to remember watching newscasters huddling under their desks in Miami during Andrew won't have a viable signal AT ALL, because just the wind-induced antenna motion will be enough to nuke the signal for many viewers (8VSB makes HEAVY use of phase relationships that all pretty much assume an antenna that's stationary, or at least moving in a straight line along a single plane of motion relative to the receiving antenna; flex and wobble the antenna, and that assumption goes out the window). The last time I checked, ATSC-M has been held back by a few things, not the least of which is the knowledge that they're going to get exactly one chance to fi
Java's garbage collection is actually pretty good, and has been for the past 5-7 years (ever since 1.4 or 1.5). Recent versions of Java will let you get away with astonishingly promiscuous levels of short-lived object creation and destruction. If you try that with Android, your application will hang and freeze every 20-30 seconds.
Dalvik, in contrast, does not handle promiscuous creation of short-lived objects well AT ALL. I don't know whether it's because of compromises Google had to make to program around Sun's patents, or just because they never bothered to optimize garbage collection the way Sun did sometime around 2005, but Dalvik's garbage collection just plain sucks, and feels like Java's did way back around 2000. When the Android SDK tells you to re-use objects whenever possible and avoid needless creation and destruction of objects, it *really* means it.
Slashdot Mirror
... and if it does, there's an equally-plausible likelihood that sea levels will (at least temporarily) fall as the ice floats into the sea, and seawater flows onto the submerged coastline formerly occupied by ice. That's not to say it'll have no net effect, and won't eventually melt faster than it would have melted otherwise, but rather to point out that even "fast" means "decades" instead of "centuries".
Not to mention the crazy fantasies some environmentalists have that people would actually just *allow* rising sea levels to destroy any valuable property, or that civil engineers are just going to disappear from the earth.
We're talking about a gradual rise of a couple of feet over the span of hundreds of years, not a fsck'ing tsunami. Major hurricanes bad enough to destroy anything smaller than a skyscraper badly enough to require demolition and rebuilding happen about once per century. As those non-skyscrapers get destroyed, they'll just be rebuilt on taller pilings (or get rebuilt as skyscrapers). Either way, the surrounding terrain can be built up with fill dirt (possibly dredged and pumped from offshore, like the sand used to rebuild Miami's beaches every few years).
In the case of skyscrapers that can't be raised, they'd do what they did in places like Chicago -- turn the second floor into the first floor, turn the first floor into the basement, and spread another 8 feet of dirt around the building's base. In a city like Miami, the roads would get rebuilt a foot higher every few decades (like they have anyway... take a peek at West Road in South Beach sometime, and compare its height to the height of any adjacent building that's more than 10 years old)... gradually turning the surrounding area in poor neighborhoods into a soggy, swampy slum where water flooded front and back yards after most rainstorms. Wealthy areas would get built higher, and in the meantime they'd have more expensive actively-pumped drainage systems added to deal with the annoyance of roads that flood after every summer rainstorm.
Eventually the poor (increasingly swampy) neighborhoods would get bought up during a future real estate boom, bulldozed away, covered by a few feet of new fill dirt to raise them higher than the road again, and covered with expensive new homes. The really, really, hopelessly-poor areas would eventually get bought up and turned into limestone mines (providing cheap fill dirt for buyers in the remainder of the city), and eventually Miami would have a big urban inland lake between I-95 and roughly NW 17 Avenue, bounded by Metrorail and State Road 112 to the south, and ending a mile or two south of the county line. In cities like Washington DC (where the buildings have historical significance and can't be casually rebuilt), they'd just dam & levee the Potomac, and upgrade drainage systems from passive ditches to actively-pumped storm drains.
There are plenty of places that exist RIGHT NOW that would be submerged underwater for all or most of the year if it weren't for active drainage and civil engineering. The only thing rising sea levels would change is the need to do the same thing in areas that historically were capable of being kept dry by less aggressive means.
It's the same reason why, year after year, the NHC issues dire warnings about inland flooding from storm surge due to hurricanes in Florida that ultimately fail to pan out once you get more than a block or two inland -- they're all based on models of a natural coastline that hasn't actually existed in decades, and fail to take into consideration the existence of large-scale urban stormwater management systems.
> Kind of like the nazis? Put people into labor camps and work them to death.
No, this is Slashdot. Remove their brains (effectively killing them), then turn their still-respirating corpses into biomechanical robots and send them to work camps.
> no 3D support
Good god, are you even in middle school yet? Even 10 years ago, realtime-3D was mostly sleight of hand and programming hat tricks (think: Battle Arena Toshinden, probably the best example of a game that did a spectacularly good job of pretending to be 3D).
The 2600's hardware was seriously weak, but the biggest problem with its games were the fact that it had an astronomical learning curve. Take a simple question, like "what was the 2600's resolution?" The truth is, there IS NO simple answer to it. The 2600 has different "kinds" of pixels, and different ways to express pixel hue and luminance, and few of its "rules" were hard limits so much as timing limits you ran into when you just couldn't bitbang things fast enough.
It's hard enough to explain the 2600's theory of operation to someone with an EE degree. It wasn't enough to know "how to program" -- you had to get "down and dirty" with its hardware to a degree that's almost impossible with modern PC hardware. Literally, impossible... in most cases, the OS (Windows OR Linux) won't even *let* you get that close to it. At least, not unless you tried writing your game as a loadable kernel module, or you somehow managed to pwn Windows and get it to execute your program as Ring 0 kernel code. Go ahead... open a 320x240 legacy VGA screen filled with a single color pixel, then try bitbanging raw assembly by busy-waiting and counting clock cycles to change the contents of that one color register in realtime as the imaginary CRT your LCD panel is emulating scans each line. That's basically how many of the 2600's video effects worked.
On a modern PC, it won't work. Literally, won't work. Why not? Because modern multicore x86 architecture isn't realtime-deterministic, and hasn't been for years. Oh, the OUTCOME of a given sequence of assembly language, in the form of a specific value stuffed into a specific register or stored in a specific memory location when the dust settles, is certainly deterministic... but what happens between point "a" and "b" isn't.
On the Atari 2600, you could count the number of cycles each assembly instruction took to execute, and calculate which pixel would be getting drawn on the screen at the moment it happened (I think it was 3 pixels per clock cycle). Contrast that with a modern PC, where multiple cores, pipelines, speculative and out-of-order execution, and a hybrid architecture that decomposes traditional x86 CISC operations into bundles of virtual RISC code "behind the scenes" mean that everything that happens "along the way" is subject to the CPU's "mood".
The games that aged well were the ones that were games first, and graphics demos as an afterthought... Warlords, Circus Atari, Space Invaders, Asteroids, er... well, you know what I mean. What's kind of sad is that the games that IMHO aged the best were the ones I got for Christmas along with the 2600 itself. It seems like almost every game I got between Christmas 1981 and the arrival of my Vic-20 a year later was a disappointment and letdown, partly because Atari's ad agency was too good at hyping them up and making you think they wouldn't be lame and kind of suck. I mean, Defender and Missile Command weren't bad, and Berzerk was OK, but it seems like most of the best-looking games were fun for about 20 minutes. I think I had more fun watching Pitfall's hi-res rope swing back and forth than I ever did actually *playing* it.
A few good games came out after I'd fled for greener Vic-20 pastures a year later (Ms. Pac Man comes to mind), but Atari's quality seriously went down the shithole that summer, especially post-Pacman -- the point when all Atari's management could see were dollar signs and a license to print money, and they had their developers cranking out shit games with undersized cartridges and minimal quality control -- relying entirely upon a rapidly-slipping brand name and marketing -- to keep the cash flowing. By the time they got their mojo back with Ms Pacman, most of us had moved on to greener pastures -- the Vic 20, C64, and the Atari computers, in particular. Or we got a Colecovision. Or both.
It's too bad Coleco's licensing was so short-sighted and such a clusterfuck mess... if any vintage console has real market potential today as a "joystick with embedded videogame and cartridges", it's the Colecovision. Unfortunately, the licensing deals they made in haste and heat guaranteed that Colecovision games will never legally see the light of day in new hardware built this century. I don't think whomever owns Coleco's IP today could even legally still sell Smurfs, let alone Donkey Kong.
^^^ What he said.
It needs to be network-agnostic (so it doesn't just give Google a more total and complete monopoly over Android advertising than they have already), but it needs to be a black box beyond the application's direct realtime control. Otherwise, apps that request "advertising" permission, but not "network" permission, could still use it as a very slow back-channel for leaking information by using things like the rate of ad changes and/or the sequence in which specific ads are requested to encode a bit or two at a time into each ad request that they could then run offline data-analytics on to reconstruct the data hours, days, or weeks later.
But yeah, they really didn't think through the practical combos of permissions when they came up with them. As it stands, it's practically impossible to even FIND an app anymore that doesn't require network, location, phone state, wifi, and personal identity. Even an innocent, well-behaved app needs the network for fetching ads, location for targeting, phone state (so they can go offline and/or pause when you're in the middle of a voice call), wifi (so they can do SSID-based location sniffing since GPS is dysfunctional indoors and tower-based doesn't work well in the US due to differences in the way CDMA vs GSM towers define "location" (CDMA voice and 1xRTT are soft-matrixed among multiple towers, so there isn't really one specific tower to unambiguously call "the tower you're using" like there is with GSM).
What would be nice are some new, refined permissions. For example, a permission that allows apps to power up wifi enough to "sniff the air for SSIDs" without actually establishing a connection. Or a permission that allows a unified location service provider to use the best source of location information available to it, but reduce the precision of the location to something like 1/64th to 1/256th of a degree (with optional, user-defined "blackout zones" (like a 1/2 mile radius around your house or office) where your location is increasingly skewed towards some alternate nearby location up to a mile away as you approach it.
"Black box advertising" would also open up another possibility -- ads targeted to users in a precise geographical area that don't actually disclose the exact location of the user. For example, suppose a business wants to show 3 different ads depending on location.... one to users in a few specific polygon-defined neighborhoods, one to users who are in a larger polygon-defined area that doesn't include one of the more specific ones, and everyone else. With black-box ad permissions that seal it off from the app, the ad client could be served all three ads, then locally choose to show the precise one intended by the advertiser without disclosing which one was actually shown. Or reporting the count to a thirdparty auditor that lets advertisers know how many people saw it, without ever allowing the advertiser to get anywhere near things like IP addresses and unique IDs that could be data-mined to recover the anonymized info.
OK, real-world semi-rhetorical question. What's worse... drivers that are tailored to a specific kernel, but leave end users with a phone that has dysfunctional GPS, camera, 4G, gyro, and whatever else was broken by the new kernel for 5-9 months until the phone's manufacturer grudgingly releases its official update, or drivers that will continue to work with the new version of Android many, many months before the official release ever sees the light of day?
Let's be honest... the Linux ABI breaks because half the kernel maintainers WANT new kernels to break old loadable kernel modules as badly and frequently as possible, and the other half of the kernel's maintainers got tired of fighting with them 10 years ago.
The sad truth is, Qualcomm owns the patents that run America's mobile phone networks, and nVidia makes most of the chips inside the Android phones sold by those same networks. Neither company is going to embrace open drivers anytime soon, and the only thing the current ABI-instability accomplishes is the wholesale DIS-empowerment of end users with Android phones, by keeping us dependent upon our carriers and phone manufacturers for new drivers.
Putting it back into a nVidia context... would you trade 0.2% of your video driver performance if it meant being able to upgrade your kernel at will, instead of having to wait for an official release of a newer one built for your specific kernel?
> This already exists, it's called RMS (Root mean square).
The problem is, a given amount of power doesn't produce the same perceived loudness across the entire audio spectrum. The LU calculation deprives the music industry of its former ability to game the system by focusing the most energy on the narrow band of frequencies that are perceived as being the loudest.
RMS is a nice, simple concept that works well for measuring amplifier power of a 1KHz sine wave at a given max percentage THD, but it's too easy to game when using it to predict loudness. Unless you want popular music to devolve to little more than powerchords striving to emulate the "The Deep Note" (http://www.youtube.com/watch?v=HtIOhYqrr00) and throwing everything they have at the range of human hearing that gives them the most loudness per watt, we need something a little better than RMS.
> And no real gain.
Except pre-recorded music that doesn't sound like shit on quality stereo gear.
This is actually an example of *good* legislation. The whole reason the "loudness war" happened in the first place was pressure from upper management on recording engineers (who, by and large, knew why doing it was bad, and who were mostly forced to go along with it if they wanted to remain employed) to make their next CD a little louder than everybody else's, until we got to the point where a 2004 pop CD was quantized to levels once exclusively the realm of a Telarc *DIGITAL CANON* in a recording of 1812 Overture whose main purpose was to show off your kilowatt-RMS amp and array of subwoofers. What the government did in this case was let the engineers off the hook. When management asks them to "pump up the volume", they can say, "Sure, I can do that. But no radio station in the country will play it, and all the money we're spending to promote the artist will be for naught. Do you still want me to do it, or would you like me to master a recording that sounds good and that radio stations will be able to play?"
I want immersive, clipping-free digital audio back like we had when I was in college. If it literally takes an act of Congress to ensure that 95% of the audio on a 16-bit CD quantizes to an absolute value of 0x3FFF or less, so be it. Now get off my lawn, or I'll have to remind your parents what digital canons sound like when you have a kilowatt (RMS) amp and a pair of 18-inch JL Audio subs in the trunk...
Or do the next best thing... come up with some kind of binary thunking layer to allow binary drivers to do an end-run around Linux's endlessly-changing ABI and allow a binary driver written for an older kernel to limp along under a newer one for the time being. And team up with Google to do it, so every fscking new version of Android won't catastrophically break every .ko driving a Qualcomm chip.
Someone seriously needs to take charge of this and just do it. I mean, for god's sake, if NDISWRAPPER can make *WINDOWS* drivers usable with Linux, how fscking hard can it be to build your own drivers in a way that everything they do interfaces with the kernel at arm's length through your own totally 100% open-source thunking layer, so that whenever a new kernel comes out, end users can recompile the thunking layer and keep using the older loadable kernel module? Hell, at this point, I suspect even Linus would grudgingly cooperate and throw some suggestions at such a project... not exactly *encouraging* it, but peeking at it once it a while just to make sure they don't accidentally do something totally bad.
Once... just fscking ONCE... I'd like to be able to upgrade to a new version of Android without having the camera, GPS, 4G, and half the phone's other features catastrophically break until someone manages to get their hands on leaked drivers from either a phone with compatible hardware and newer version of Android than mine, or leaked drivers that are being beta tested for my own phone's official release.
The succession rules aren't there to ensure that there's someone "who can lead America" -- they're there to ensure that there isn't a melee and free-for-all power grab among those same officials (or the military, or whomever) if this were to happen. They exist to guarantee that if person #4 on the list shows up to claim power away from person #6, person #6 will hopefully do the honorable thing (possibly at the prodding of the police and military) and gracefully hand power over to person #4.
We can live without elected federal leaders for a while, as long as whomever is nominally in charge plays by the rules and fills the role of "placeholder" until elections are held soon thereafter. We had a technically unelected president for almost two years back in the early 1970s (Gerald Ford). Few really liked him, and fewer still loved him, but he knew it, and in retrospect did a decent & honorable job of keeping the lights on in Washington and not rocking the boat until it was time to step aside. Frankly, a placeholder president would have zero mandate to do much of anything besides try to not piss off too many people during his or her short term of office.
If a small nuclear bomb were detonated in front of the Oval Office and took out most of the highest officials, the real chaos wouldn't be due to the lack of a President, but because the lives of everyone left in Washington (most of whom would survive just fine, and who are the ones who personally run America's bureaucracy on a daily basis), would be totally fucked up for weeks.
Anybody who lived in Miami after Andrew, or New Orleans after Katrina, knows what I'm talking about. First, you go through personal survival. Then you become obsessed with saving those you care about, or verifying that they're OK and don't need your help. Then you spend the next 2 months doing nothing besides drive to and from work in the most ungodly traffic jams you've ever seen in your life, shopping endlessly (with lines stretching to the back of the store) and dealing with random wacky shortages of just about everything, and trying to clean up the mess around you. That's part of the reason why the government's "nuclear plans" always involved rescuing the immediate family members of important officials once the officials themselves were safe (or simultaneously). You can't run the country when you're busy trying to rescue your own kids, or standing in line for 3 hours at Wal Mart just to get in the door.
Now, think back to September 12 through 18, 2001 -- the week after 9/11. Remember the people who just freaked out around you? Multiply that by 10, and you have the likely best case scenario to hope for.
A dead president, and deciding who's supposed to temporarily fill his or her shoes for a few weeks or months, would be the *least* of our problems.
> While MVC is a good programming model, I think most frameworks are just there to make the programmers work in a more common fashion
> so that they can be more disposable.
No, MVC is good, and exists, because it's the best way anybody has found so far to allow a programmer who's not much of an artist to collaborate with an artist who's not much of a programmer to produce a substantial web application (or possibly a desktop/mobile application) without stepping on each other's feet every inch of the way, and without involving the bureaucracy of an official project manager and formal development methodologies to try and herd the cats daily and coax the productive work of three people working at full individual productivity out of eight who spend most of their time fixing the mess caused when the other 7 make mistakes or get in the way, or having meetings so they can actively try to have fewer such mistakes.
Why do the Chinese companies NOT provide/implement ADB drivers? Is it just laziness, or do they have some official motive for keeping ADB out of end users' hands? Also, wouldn't refusal to implement ADB mean those chips couldn't be used to build any Google-licensed device, because Google officially REQUIRES ADB support as a condition of licensing? I know 99% of the tablets made with them aren't Google-blessed, but why would a chipset maker COMPLETELY write off the market for official Google-blessed devices just to omit something like ADB that, compared to the rest of Android, isn't terribly hard to implement?
As much fun as it is to bash Microsoft, the sad truth is that the most TiVO-ized and locked down hardware on Earth usually runs some bastardized de-facto fork of Linux. Once Microsoft gets your money, they tend to not care if you want to blow away their OS and replace it with something else. Contrast that with the behavior of... say... Motorola, who's hellbent on shoving locked-down TiVO-ized hardware down its users' throats (though some of us haven't given up hope that Google will eventually make them non-Evil and force them to unlock their bootloaders).
I'm not sure whether IOS, Maemo, or Windows Phone handle it any better, but Android seems to have a real problem dealing specifically with scenarios where the phone has "a network connection", but no actual connectivity that works to "the internet". It's like things check to make sure the phone is "connected", then make blind assumptions based upon it without bothering to consider the possibility that the phone might be connected to:
* a wi-fi access point that's disclaimer-walled. You know, those annoying wi-fi access points that are free, but won't allow you to actually USE them until you swat away their disclaimer page, so that unless you remember to delete the connection to "AT&T Wayport" from some McDonald's, you'll find yourself randomly losing network connectivity while driving if you happen to stop at a red light within 200 feet of a McDonalds.
* Sprint/Clear Wimax that's "active", but has backhaul problems. Clear in particular seems to be kind of bad about taking wimax sites down when they're having backhaul problems, or fixing them on weekends. The tower by my office went into convulsions twice last summer for 3 days at a time, and I had to kill wimax to get my phone to be non-dysfunctional.
* Sprint EVDO that's point-blank dysfunctional during their "Network Vision" upgrade. Right now, and for the past ~2-3 weeks, Sprint's EVDO has been COMPLETELY dysfunctional, point blank, throughout most of South Florida. Most towers are "connectable", but at least half of them seem to have no actual upstream backhaul connection, no actual downstream backhaul connection, or both, at any given time. I've seen Speedtest give me things like 800-2000 down with zero up, and practically written a blues song for Youtube called "Five Bars and 50k(bps)" in honor of Sprint's pre-upgraded EVDO norm of having rock-solid connections to towers that only get 40-80kbps down (but 250-400kbps up) because they only have two T-1 lines servicing an entire cell site.
* The original reason I used to keep wi-fi disabled (before Sprint's 3G became totally dysfunctional and slow after "I-day" last fall), and a variant of the "disclaimer-wall" problem -- the phone will connect to wi-fi, then try too hard to maintain the connection when it has (what used to be) perfectly good 3G connectivity. Oh god, it used to piss me off when I'd get "no network" errors because I walked down the block and my phone was still trying to remain connected to my house's access point instead of using the tower whose blinking red light was visible from the sidewalk about a thousand feet away.
Anyway, you get the picture... there are lots of scenarios where simple probing of the phone's network state will suggest that the phone can get online, but in reality... it can't. And things like internet-updated widgets in particular seem to handle those conditions very badly. On New Year's Eve, my phone became dysfunctional to the point where I could barely even launch the CAMERA app starting ~10 minutes before midnight, and continuing until approximately 12:30am. I finally figured out that it was because there were running apps that were hellbent on fetching data despite the fact that Sprint's network was about to collapse from having 50,000 party-goers in the vicinity of a tower whose EVDO data service was sharing the equivalent of an economy DSL connection.
Google really needs to build some kind of active network monitoring capability into Android, and have it occasionally ping a globally-accessible IP address like 8.8.8.8 to confirm that actual network connectivity exists whenever something asks "is there a network connection" within a few seconds of a failed network data attempt. Yes, I know individual apps could do it themselves... but they don't, and won't. More importantly, this is something that SHOULD be handled globally by the OS for the benefit of the apps running under it, unless Google wants to find themselves getting pinged 40 times per minute by a half-dozen network-using apps running on a single phone, each of which takes it upon themselves to individually confirm network connectivity by pinging 8.8.8.8 or 8.8.4.4.
> The US model is very different.
I've read lots of posts that said they "had" to use dualcore "because of LTE", but why, exactly, did the LTE-equipped US models non-negotiably *HAVE* to be dualcore? Is there some insurmountable engineering reason why they couldn't have just slapped a separate LTE radio module onto them, like Sprint has done with all of their high-end phones for the past 3 years to add wimax to them? I mean, did they make prototype SGS3 phone with Exynos, MDM6600, and Beceem LTE chip, then discover that the combination had a major problem with feedback or harmonics that nuked EVDO or LTE? Or was it just a matter of Samsung trying to save a few bucks by going with a cheaper dualcore SOC that has onboard LTE instead of spending more to build it with an Exynos and a separate LTE radio modem?
You also get to enjoy endless grief. My parents have a real TiVO HD with a pair of CableCards & live in an affluent city where they're far from uncommon. It hasn't worked properly ONE SINGLE TIME since they bought the TiVO and had the Cablecards installed. There's ALWAYS two channels that show up as "unsubscribed" at any given time. They call Comcast, file a trouble ticket, and the problem eventually gets fixed... and two OTHER channels go away and become "unsubscribed".
My dad is CONVINCED they actually have some kind of rack with fixed card capacity and a card or port per channel, their rack is maxed out, they have two more channels than available ports/cards, and that they just keep unplugging and swapping around two channels at a time (disabling their reception by everyone with cablecards) hoping they'll eventually find two that nobody cares about so they can avoid spending a few thousand dollars buying another rack just to accommodate two more cards/ports..
> Unless they hire a bunch of the top guys from XDA, their software will continue to be absolute shyte no one wants on their phone :(
You mean, like the guy behind Cyanogen? He's been a Samsung employee for about a year now. It's not a coincidence that Samsung has suddenly become one of the first-ported platforms for new versions of Cyanogen. Hiring him was a brilliant move for Samsung, because it allowed them to outsource the long-term development of their phone operating system for EOL'ed phones to an army of highly-skilled unpaid volunteers. Since he's an official Samsung employee, they can even let him have access to sourcecode, SDKs, and datasheets that companies like Qualcomm won't allow them to release to the general public. Thus, when a new version of Android gets released, he can personally churn out a new kerneland kernel modules for everything Samsung has soucecode access to within a matter of days He doesn't have time to indiscriminately REWRITE much beyond a few carefully-chosen phone models, but for any task that mainly comes down to dropping in the new kernel source and running make, Samsung phones are literally weeks to months ahead of HTC phones now.
That said, it's a good thing Samsung doesn't lock bootloaders and has Cyanogen's founder working for them, because their own in-house operating system development efforts have historically sucked donkey dick. Sprint's history of Samsung phones is littered with the corpses of unloved phones released with operating systems that were already considered old the PREVIOUS YEAR. The SPH-i300 shipped with PalmOS 3.5... when all the new apps at Palmgear needed 4. The SPH-i500 shipped with glorious 4.1, when all the new apps at Palmgear needed 5. Every phone had the potential to be great, but ended up getting ruined by arriving a year late and a few excessively value-engineered dollars short of tolerability.
An Android "hearing aid" app won't work, because the operating system and bluetooth add too much latency. Hearing aids are one of the most hardcore "realtime" embedded applications you can get, because hearing aids are an application where real users have close to zero tolerance for latency. Latencies in the TENS of milliseconds are distressing to hearing aid users, and latencies that would be annoying for a voice cellular call are *intolerable* for hearing aid purposes.
You *might* be able to root and reflash an Android phone into a dedicated hearing aid device... but an app on a regular phone? Never.
Try this as an experiment: write an Android app that samples the bluetooth mic, applies some trivial audio filter to the waveform, and plays it back through the bluetooth headphone. Now try walking around with it running -- you'll rip the headset off within 10 seconds, because the latency will drive you crazy.
One insurmountable problem: latency. No mainstream operating system optimized for general desktop or phone use -- Windows, Mac, OR Linux -- is suitable for realtime audio processing. Period, end of story. And if you took a rooted Android phone and rebuilt its kernel to give as much priority as possible to the audio processing subsystem, it would nuke the battery in an hour and you'd end up with a device that sucked as both a hearing aid AND an Android phone.
Maybe... MAYBE... if you wanted to help poor people, you could come up with a way to reflash old Android phones to a realtime-optimized kernel that repurposed the hardware exclusively for hearing aid purposes, but you'd still be stuck with wired headphones and microphones because bluetooth has too much latency. And miserably short battery life, even with an extended battery. Remember, you can't use power management with a hearing aid... people don't stop needing to hear just because the screen is turned off.
In any case, forget about trying to run a "hearing aid app" on an Android phone being used AS an Android phone and entertainment device. It won't work.
As a practical matter, some drugs really *are* "too cheap to counterfeit, and are expensive in the US only because we allow "use" patents, while other countries (like India) only recognize "manufacturing process" patents. So, drugs like finasteride (Propecia & Proscar) and atomoxetine (Strattera) are expensive in the US, and practically free in India.
Some drugs, like Tamiflu, *are* genuinely expensive to manufacture, easy to counterfeit, and *likely* to be fake.
Others are genuine, but expired or stored improperly (and possibly repackaged).
For the most part, drugs in the first category are perfectly fine, and most drugs from the third category are too. You just have to use common sense & do some homework to figure out which drugs are likely to fall into category 2 (hint: controlled substances like Xanax & Provigil almost always do).
Ironically, ebola's virulence and swift death is what saves us from global pandemic. Basically, ebola (and Marburg) are viruses that are too virulent and deadly for their own good. They kill their victims too quickly to ever have time to spread. The viruses that "survive" and "thrive" (in quotes, because viruses aren't actually "alive" in the conventional sense) are the ones that don't kill their victims, and quietly simmer and spread forever. Herpes is the classic example. Lucky people get infected by HSV-1 by their parents or grandparents, and suffer occasional outbreaks of oral cold sores for the rest of their lives. Unlucky people make it through childhood, then get infected from their first blowjob and end up with de-facto genital herpes that's technically HSV-1 instead of HSV-2.
Ebola's main transmission vector is bodily fluids seeping from a corpse. Ebola is self-limiting PRECISELY because it's so deadly and acts so quickly. The moment people realize they're dealing with Ebola, they go hide from everyone else for a few days. Within a week, everyone who was infected is dead, and the survivors can cautiously come out of hiding to clean up the mess. In Africa, when Ebola breaks out in a village, people leave the infected individual (who's not particularly mobile at that point, anyway) to die in his or her hut, then burn the hut to the ground. Callous and harsh, but to a large extent... among primitive people without access to modern medicine that itself can barely deal with it... it works, and it's worked well for thousands of years to keep ebola contained.
See the book I wrote a few levels above. The short answer: the chips are cheap, but making them work in a mobile device with headphones as the antenna is hard, and making them work in a moving vehicle is nearly impossible due to fundamental flaws in the way ATSC's underlying modulation scheme (8-VSB) was designed.
Put another way, for a few bucks more, Samsung could sell you a phone with a mini-75ohm coax connector that you could connect to a 3 story tall Yagi antenna pointing at the transmitter, and it would work perfectly. But it would be almost unusuable with headphones as the antenna, and literally unusable underground or in a moving vehicle because 8-VSB has serious problems dealing with multipath interference, and is almost completely incapable of dealing with doppler shift.
Receiving analog TV with modern chips is cheap, easy, and works well. The problem is, analog TV doesn't exist anymore in the US, and the standard that replaced it is almost impossible to receive using a handheld device with sub-optimal antenna in a moving vehicle.
Lots of phones DO have FM. Try connecting headphones and launching the 'music' app. You might be surprised. I had my Photon for almost 5 months before I stumbled over that feature by accident. I was expecting it to exist (if it did) as a "FM Radio" app, not as part of the "Music" app.
As far as TV goes, it's probably a lost cause. As a practical matter, a high end Android phone already has 80% of the hardware it needs to receive HDTV, and roughly half the remaining 20% consists of "an appropriate antenna" (believe it or not, the ATSC tuner is the least of your problems... it's a single chip that converts 8VSB-modulated radio into a ~19mbit/sec bitstream that the phone's existing hardware can deal with downstream). So, why don't manufacturers bother? Mainly, because American 8VSB-modulated HDTV is hard enough to reliably receive with a PROPER antenna, let alone a pair of headphones plugged into a headphone jack. Don't believe me? Buy a 99-cent UHF loop on eBay, connect it to your HDTV (through an appropriate 300-to-75-ohm balun if necessary), and see how many channels you can actually tune indoors with it. If you're lucky and live in the mid-suburbs approximately 5 miles from the local antenna farm, you might get one or two reliably. If you're downtown, you'll be lucky to get any at all.
It's a fundamental problem with 8VSB modulation. Back in the early 90s, engineers told the FCC & "Grand Alliance" they could optimize for range or robustness, but not both. They were told to optimize for range, and they did. With a proper 2-3 story tall directional high-gain yagi pointed directly at the transmitter, properly grounded, you can receive most American TV stations from 60 miles away with minimal effort, and up to 100 or so miles away if you really work at it. However, the moment multipath distortion (basically, echoes from signals bouncing ricocheting off buildings and mountains) becomes a factor, you can forget about receiving a viable ATSC signal at all. Analog UHF manifested multipath as "ghosting". Digital ATSC manifests multipath as "no signal".
HDTV tuners work in many other countries, because they went with a competing modulation standard called COFDM. COFDM's engineers made the opposite choice of American engineers. Instead of optimizing for range, they optimized for robust reception in conditions where multipath distortion would normally be a problem. The downside is that even a great antenna is unlikely to receive a viable COFDM signal more than 50 miles away. The upside is that you can sit in a moving vehicle driving around the central business district full of skyscrapers in some Asian boomtown and have a perfectly good signal to watch.
As bad as 8VSB is today, it was even WORSE 10 years ago. At least now, it's possible to semi-reliably tune with an indoor antenna if it's a GOOD one. You're still unlikely to get anything consistently watchable from the modern equivalent of a coat hanger (a pair of headphones plugged into a jack). Unfortunately, we've now come about as far as we can with DSPs, and future improvements to 8VSB are going to require extensions that will be backwards-compatible (ie, won't screw up existing tuners), but won't do anything to HELP old tuners. The work has been in progress for the past few years, mostly at the behest of FEMA, due to a very real fear that the next time a hurricane like Andrew roars ashore, people old enough to remember watching newscasters huddling under their desks in Miami during Andrew won't have a viable signal AT ALL, because just the wind-induced antenna motion will be enough to nuke the signal for many viewers (8VSB makes HEAVY use of phase relationships that all pretty much assume an antenna that's stationary, or at least moving in a straight line along a single plane of motion relative to the receiving antenna; flex and wobble the antenna, and that assumption goes out the window). The last time I checked, ATSC-M has been held back by a few things, not the least of which is the knowledge that they're going to get exactly one chance to fi
Java's garbage collection is actually pretty good, and has been for the past 5-7 years (ever since 1.4 or 1.5). Recent versions of Java will let you get away with astonishingly promiscuous levels of short-lived object creation and destruction. If you try that with Android, your application will hang and freeze every 20-30 seconds.
Dalvik, in contrast, does not handle promiscuous creation of short-lived objects well AT ALL. I don't know whether it's because of compromises Google had to make to program around Sun's patents, or just because they never bothered to optimize garbage collection the way Sun did sometime around 2005, but Dalvik's garbage collection just plain sucks, and feels like Java's did way back around 2000. When the Android SDK tells you to re-use objects whenever possible and avoid needless creation and destruction of objects, it *really* means it.