You didn't mention that it can send SMS in the permissions you listed, so the app is not able to.

The ability to send texts is a separate permission (separate from reading texts and separate from placing calls or reading phone state). The SMS and Place Calls permissions are listed under a heading, "Things which may cost you money."

If I was installing a chat app, as you suggest, which wants to be able to send texts, I would not install that app. There'd have to be a clear and compelling reason an app can send texts or place calls before I would approve it. The only times I've done so is when the app has been by a large and respected publisher (such as Google themselves), and even then I think about whether this is something I really would find much value out of.

The guys who made those decisions, for the most part, came out much, much wealthier than they started. For themselves they made the right decisions, they figured out a way to sap a huge amount of wealth out of the economy while painting pictures that made it seem a lot safer to the investors they were reselling mortgages to than it actually was.

The major differences between grid and cloud is that cloud has "unlimited" and momentary scalability. If demand explodes for your service, you can have 30x the capacity inside of 5 minutes. When it's a big VMS or a local Xen cluster, there's a very realistic ceiling to how high you can scale based on how much physical hardware you own (or lease). If there's a demand explosion, your response time past that ceiling is weeks or days (or if you pay a very high price for the privilege, hours - if you're lucky, realistically when we had a 4 hour hardware response time, it still always managed to end up closer to 24 hours). If you colocate, you might even have to physically relocate to a new cage, which involves downtime or capacity reduction.

Also with cloud services, if demand subsides, you can scale back down, and you paid for that extra capacity with an hourly granularity. In addition, this scalability is controllable with software, you create OS images that are custom tailored to your software preinstalled and configured, then just spin them up and down as demand requires. There's still a capacity ceiling, but because that ceiling is shared across thousands of other customers, it's much, much higher than you probably have the resources to dedicate in your own datacenter or colo location, and doesn't require a substantial up-front financial obligation.

So cloud stuff isn't really a fad, it's amortizing the costs associated with huge capacity options across a large number of customers. It's not something you couldn't do before, it's just a way to have access to it without a huge initial investment. It introduces new risks and points of failure, but also makes it so you can focus on your software stack rather than having to hire network and operations engineers to manage physical hardware (or having to pay for new capacity with a monthly granularity such as with hosted hypervisors, and also having to spin up a clean image and install your software stack before it can come online, vs spinning up a pre-imaged OS which is ready to roll as quickly as it can boot).

All that said, that doesn't mean there's no cloud bubble. A lot of investors right now want to hear that word in your sales pitch. If they don't hear it, and they don't hear "social" as well, you probably don't meet the profile most of their clients have asked them to invest in. Cloud isn't some magical unicorn which makes problems go away. It solves certain problems and introduces new problems. A large cloud cluster running 24x7 is more expensive and performs worse than the same capacity as a dedicated colo. If your solution to cloud is just to use it as a VPS, you're going to pay out the nose for that, and most people end up doing exactly that. They don't put the time into learning how to create custom images, they don't script server management, the only way they can bring more capacity online is if an engineer sits down and opens the web management console, spins up some instances, patches those instances, installs the right software, configures that software, and manually brings it online. Basically a lot of people treat cloud like grid, and they end up with the downsides of both.

And this I think is the biggest problem. It creates a conflict of interest. In my area in Pennsylvania, local cops have been setting up ENRADD devices, which are only legal in PA. These devices are basically two beams of light that your car breaks as it moves through, and based on the timing and the known distance of the two beams, they can tell how fast you were going.

Except that they can't. If the beams are set up in such a way that the first beam triggers on your wheel, and the second beam triggers on your bumper, it can greatly over-estimate your speed (they are only 3 feet apart, it can easily clock you at 60mph while you're doing 30mph). Also, being just beams of light, even if installed correctly, a car coming the opposite direction can be the trigger of the second beam, so that can also produce unreliable results.

They set these things up on the busiest roads, virtually guaranteeing they have a nonstop stream of revenue. They line up 5 or 6 patrol cars in a row to pick up people, and they have the tickets pre-filled out as much as possible (including date, officer name, location, direction of travel, and even the fine and ticketed speed). The only thing left to fill in is to copy over the drivers license and car info. They only ticket you for going 5 MPH over, then write in "Actual speed X MPH" according to presumably what the ENRADD device told them. This way there's no points on the ticket, and most people realize that paying a ~ $110 fine is a better use of their time than fighting the ticket in court (I for example am an hourly contractor, it would cost me more in lost productivity than simply driving to the court house, nevermind however many hours I might be inside).

I mentioned that they have 5 or 6 patrol cars issuing tickets - these are township level cops, in some townships that might be the entire police force, spending an entire day individually earning the police force a few thousand bucks per hour. The tickets are pre-dated, so you know they are going to issue every ticket in that stack before going home. The roads are the busiest roads, so they have the best chance of creating false positive readings.

It's absolutely unconscionable that the police force gets to keep the proceeds of their activity. It creates a mercenary mindset. These cops are going to be incentivized not to increase traffic safety, but to earn a profit. Ticket proceeds should be given to state social programs rather than benefit those who are tasked with enforcing the tickets. Likewise seized property and other form of proceed from police activity should not benefit the police force.

In fairness, OP's question is remarkably vague. The question boils down to "What are good communications tools for Linux?" Well, that depends on what you mean, and what you need. If you need to pass files back and forth and send fully formed comments, email. If you need to voice conference... a phone. If you need video conference, Skype or Google Hangouts. If you need text-based back-and-forth, any IM client. If you need Microsoft Office editing, Google Docs, Open Office, or Office in Crossover. If you need VPN, OpenVPN or "vpnc" to talk to Cisco VPN gateways.

There's just so many things which could be meant by "communications," and in traditional requirements document format, a question is posed that seems entirely reasonable to the asker, but completely fails to describe any problem that should or could be solved.

SQL injections are impossible if all user input is necessarily relegated to a bound parameter. Unfortunately like pretty much every modern major vulnerability, having a correct way to address the problem doesn't necessarily mean you'll never see it. Saying, "That would never happen to us because we only hire good developers," is not a good affirmative defense.

You can work very, very hard to make sure these sort of common vulnerabilities don't exist in your systems, but you can't guarantee that they never will, even if you control the entire software stack (which many places do not). So in the spirit of defense in depth, it pays to use all the same anti-SQL-injection stuff you're already using, then go ahead and protect yourself in case your other measures have failed.

Unfortunately, however, I dislike the idea that a newly deployed feature might be flagged as suspicious by an intermediary and disabled. This seems like it would create some very hard to diagnose problems - particularly if it rejects some statements from a transaction and not others. Now you may end up in an inconsistent state, and so your security tool might be what actually breaks you.

Not from a legal perspective it doesn't. It's just a claim for damages, with nobody disputing the claim. No consideration at all is given to the law because it is not actually tested.

It will take a year or two, but all metered ISP's will be adopting this concept that receiving some content costs you more than receiving other content, with perfectly "valid" technical reasons such as described (it's within our own network, it costs us less, and we pass that savings on to our customers, look how benevolent we are!).

Using Comcast as a generic metered ISP, and Netflix as a generic high-bandwidth content site: soon Comcast will let services like Netflix host a node within Comcast's network, for a price. That price will be like most hosted services, including flat monthly colocation costs, external bandwidth usage pricing, and so forth. Perfectly reasonable. Something tells me it'll also have a requirement for disclosure of customer demographics, and things like that.

Meanwhile home bandwidth allowances will be reduced while typical data usage patterns increase (see the established pattern in this regard with SMS and mobile telcos). So services like Netflix will have no choice but to locate a node on Comcast's network, or else Netflix's customers won't be able to afford to give up the bandwidth required to use the service. Prices will go up on those node hosting costs until $0.30 on the dollar paid to Netflix is going to Comcast for the privilege of not burning up the consumer's metered connection. Every other major ISP will be the same way. Customers of unmetered ISPs (only small guys at this point) won't pay a lower price to Netflix, by this point Comcast's terms of hosting will require that Netflix charge the same price to both Comcast and non-Comcast customers (so that their competitors can't advertise that you get a discount on Netflix for buying their service instead, also Netflix probably will pocket that extra anyway).

In the end, instead of Netflix having to pay to have their service unthrottled for Comcast customers (violation of neutrality laws), they'll have to pay to have their service be usable at all (not a violation of neutrality laws, just the only practical response to artificial limits created to produce this outcome). Neutrality laws need to state that no service may receive preferential treatment in terms of either quality of service, impact on the customer's bill, bandwidth allowances, or any other manner which would allow one service to be distinguished from another service in a positive manner. Anything at all short of that just creates a more convoluted path to a non-neutral network.

It's like how credit card companies prevent you from charging a surcharge for using credit cards. But you can have a cash discount. Same thing, different name.

And there is a much greater possibility that they can't fix you, and you survive in utter anguish and misery while the cancer continues to advance in your body unabated. While you could instead have spent that time quietly and comfortably with loved ones and family, having traded that for a vanishingly small chance at survival, and being on the losing end of that bet. It's not like they're sitting on known cures, but busy filling out paperwork instead of saving patients. Until all the animal trials are complete, we don't even know if there's a reasonable chance a new drug will be able to help humans.

Almost all drug candidates are rejected before they get to human trials, because they are discovered to in effect be a bad or ineffective drug. Those that aren't discovered to be bad or ineffective are given to humans in clinical trials before being made available to the general population. Essentially there is already a control in place to get very sick humans access to pre-release drugs that research suggests is likely to be effective and safe in humans.

Such a prognosis would be rare. People have looked hopeless and ended up turning around and recovering. Doctors are extremely reluctant to pronounce you terminal, instead they read you the odds. Just last week, or the week before, I heard an interview on NPR with a woman who's had stage IV breast cancer that metastasized into her skeletal system for the past 25 years. She's tried a wide variety of cancer treatments, none of them have seemed to make much impact on her condition. Typical chances of survival for her cancer at that stage are pretty low (that's about the worst case scenario for breast cancer), but as she demonstrates, the only people whose actual survival time is known with any certainty are the people who are at the "days left to live" stage (and probably already on hospice care), not the "months/years" left stages.

The more certain they are about the survival chances, the more damage has already been done to the body. Even if you could cure the cancer side-effect free overnight, such patients would likely still die from complications.

Dying is not the worst case. Living fully aware, hooked up to a large pile of life support machines in substantial and unending pain is the worst case, and not out of the range of possibilities.

Drugs for terminal conditions do sometimes get approved for earlier human trials. But a study has to be running (there are several reasons they can't just take one-off patients as they become available, it creates too many uncontrollable factors, and makes double-blind methodology all but impossible). For all clinical trials, patients have to be free from complications which may distort results in the study (if you accept patients with existing heart conditions, that patient cannot be used to indicate heart conditions). The healthier the patient, the more meaningful the study results.

So it can be difficult to amass a statistically significant population of very late stage otherwise-healthy patients (don't forget you also need a control group to receive placebo). Meaningful conclusions cannot be derived from "Let's stick this in Joe's arm and see what happens," without a lot of observation and confirmation bias tainting the results. That means that even if you set aside all ethical and legal considerations, you are still going to have a hard time amassing a sufficient study population for practical reasons. Also as noted, the more certain we are about fatality, the less time that patient has to live, and very-terminal patients have this frustrating tendency to die.

That's the nature of drug testing. You test it out in several animals of varying levels of similarity to humans before you start testing in humans. Mice are a common starting point because they're inexpensive and small, and you can run trials with thousands of mice. Also, mice sort of self-destruct if things start going badly in them, they are fairly fragile. So they make good canaries because when things are going badly, the signs are not often subtle.

Plenty of compounds show promising results in mice that prove to have reduced results in later trials with more complex animals or in humans, or show side effects only later in the drug study regime. Conversely it's almost certain that there are compounds out there which would provide amazing results in humans, but which failed early stage drug studies in animals. It's just not a great idea to be testing drugs for the first time in humans without some idea as to what the outcome would be; the fatality rate in animals is pretty high, and you can purposely infect them to treat for a specific disease. There are drugs that even with this prep work still fail in clinical (human) trials, either because of efficacy problems or because of unexpected or more-severe side effects, or some combination (if it's effective but with bad side effects in animals, then not very effective and with horrible side effects in humans, it will be rejected).

The study in this article is the very earliest stage. Usually they do tiny studies like this as the very first trial. Many, many drugs produce interesting results at this stage, and fail the very next set of studies (statistically large populations, which 10 mice is not, even with extremely promising results such as this). The chances of such a drug making it to clinical trials is vanishingly small, almost all compounds fail, only a few ever make it.

Isn't MSN the default homepage for IE? So some possibly significant portion of those active users are just people who don't know or care how to change their homepage. I know when I still worked at a place with Windows servers, the older class of servers would open MSN as soon as you fired up IE to download some software patch, so I myself am probably responsible for hundreds of those "users" without ever even attempting to use MSN.

Weight and mass are two different things. The gram is a measure of mass, not weight. Pounds and ounces are measures of weight. The article conflates the two.

It's incorrect to say something "weighs X grams," just like it's incorrect to say something is X liters long, or weighs X inches.

So the garden gnome is not 1.96 grams lighter at the equator unless something damaged the garden gnome (possibly very likely). The fact that this is put out by a scale company tells me their products aren't trustworthy. Regardless of reduced gravity at the equator, the scale should measure the same grams regardless of where they are. With an error rate of 0.6% depending on your longitude, they are only getting 2 significant figures of accuracy out of their scale. So the correct measure for them to report is that the gnome weighs 3 0 8 grams (line under the 0, 2 sigfigs with one extra digit) since that's all the more confident they can be. That's not a very good scale.

Ok, I'll agree if it's targeted at elementary school kids. Not that I think no elementary school kids are able to handle that book, but that should be up to their parents to meter according to their child's emotional maturity, which is a lot harder if marketing is making it look safe to 6-year-olds.

Orson Scott Card has drawn a hard line with how the Ender series is portrayed. It's very important to him that Andrew Wiggin is portrayed as a 6 year old. That's a big part of the books for him. It's also the reason no Enders Game movies have been made, he refuses to budge on the age of the actors. According to Card, studios keep trying to trick him into agreeing to older actors, even with weasely language such as "Actor portraying Ender Wiggin to be 6 years of age," then later "Due to casting concerns, actual age of actors may vary by as much as 6 years," or some such. It's something he's refused to budge on, and he's been involved in movie discussions a few times; he immediately rejects any offer that offers to do anything but cast kids the age he says they ought to be.

So that maybe offers some insight as to why he would allow it to be marketed at young kids (even though I know you don't agree with it, it's useful to understand the thinking). I think he might actually have written Ender's Game for small kids. He's got a certain fixation with youth and smallness in general, it shows up in a lot of his works. I think his belief is that we don't give enough credit to small kids.

Yeah, I agree pretty strongly on that. GTA and other games like it. I do think at certain maturity levels kids derive what's socially acceptable from their experiences in the world around them, and although it's unlikely that most kids would believe it's socially acceptable to beat a hooker to death, engaging in that simulated activity or seeing it glorified will still have some negative influence on their perspective outside the simulation.

It's not a popular view around these parts, and I've certainly been modded down for voicing it, but I believe it's a good idea to give parents tools to control their children's access to certain kinds of material, including violent video games. These aren't a one-size-fits-all "no kid may play a violent video game under the age of X" kind of rule, just a "an adult should be involved in this decision" kind of rule.

I also believe my kids don't have a right to Internet privacy in my house; I need to know if they're getting involved in certain things. Perhaps they'll earn privacy through trust, but it's not guaranteed. That view has gotten me modded down as well. My kids are only 22 months and 10 months old, so it'll be a little while before this becomes a real issue for me, but I can't see myself changing that view.

As they did for Ender in the book. They took him to a house with a lake on Earth and let him heal, despite the fact that they were rapidly running out of time before the fleet arrived at the Bugger homeworld, and they still had more training they needed him to go through.

Scott's other works are weird and sometimes disturbing. Ender's Game - and on a different level the other books in the series - actually opens a host of ethical discussions (interestingly, Ender's Game was just a prelude for The Hivequeen and the Hegemon, just written to establish the back story for the work Card was trying to create). I agree that there's an age group that this book is inappropriate for, but I don't think that extends to 14-year-olds as in this case. Those kids have certainly read other more disturbing classic literature by this point in English class; much of it with far less ethical / conversational merit.