Comment Re:Once in a Hundred-Year storm... (Score 1) 148
I think you misunderstand what the 10, 50, and 100 year storms refer to.
I think you misunderstand what the 10, 50, and 100 year storms refer to.
1. I don't believe that there are any "biomarkers" for "violence" that are not common to every person alive today.
2. Remember "The Bell Curve"? http://en.wikipedia.org/wiki/The_Bell_Curve Once you start attempting to match biology to behaviour you run into all kinds of problems with biases and statistics.
I really want to build a laser mosquito zapper (like this one: http://spectrum.ieee.org/consumer-electronics/gadgets/backyard-star-wars). However, this looks pretty pricey (multiple cameras and galvanometers).
If the expense/time is a bit daunting, mosquitoes are attracted to heat, so some incandescent bulbs in front of a fan, with a mesh bag behind it, will scoop them out of the air (along with lots of other insects.) I had a friend with one of these and she collected something like a pound of insects per night.
With that said, I don't think either one is going to make a dent in your local mosquito population unless you had two dozen of them running nonstop. Getting rid of stagnant water in your neighborhood will do far more than any amount of adult mosquito hunting.
I've seen them for sale. >_>
You didn't follow the link, did you? It's a situation that's called "a tragedy of the commons", which doesn't mean it's a tragedy.
And anyhow, it's not about battery life, but applications using more than their fair share of memory, IO or other resources contribute to starvation for other apps that run at the same time, possibly causing crashes in other apps when they cannot allocate memory (because they're well behaved and allocate when needed and free when done), cannot update alarms in time, can't take a phone call(!), can't AV scan an incoming e-mail, or a million other things that can go wrong if too many apps on a system are hogs.
added to the fact that not all code needs to be optimized, only the little portions that perform the most critical tasks.
That this is false is my point - it's only true if your app is the only app on a system. On a shared embedded system, the portions that don't do critical tasks are just as important to optimize for the rest of the system.
Because there's no penalty to your own app, it becomes a tragedy of the commons.
To follow up on my own post, what we see in environments like the Android world is a tragedy of the commons. If everybody played nice, everybody would benefit. But there's no penalty to yourself for being greedy, so you are. And so are all others.
Android really needs something like strictly enforced cgroups.
Even though it's unrelated with my original post, you are saying that not going native is worse because it uses more CPU cycles/battery?
Explain to me why, for decades, the industry used J2ME, Java (Android) and now ObjC (Apple). I guess the entire mobile industry is selfish and greedy?
Of course they are. But that's beside the point. Development is a trade-off - you have to work with the market you have, within deadlines that means you'll sell, and developers you can find and afford. So yes, you make do with what makes the task feasible.
But you don't have to make it any worse than necessary by allowing bloat and doing things inefficiently. Adapting a mindset that you do work in a shared embedded environment, and do things frugally doesn't incur a great cost.
You probably didn't understand GP, though, the message is that you don't need to optimize something that doesn't consume enough cycles be a performance problem.
It's not just about cycles. It's also about resource use in a shared environment. The key word being shared. Whether something doesn't impact your own application isn't the problem - unless you have thought about how it could impact other applications and the overall system, you haven't done your job.
It's impossible to personally attack an Anonymous Coward.
But I'm glad you recognize what you are doing.
As for "What wasting", I asked you(?) to re-read the guy's second paragraph, but this was apparently too hard. So let me quote it:
Any attempt to raising a point about how you don't need to optimize everything but only few critical zones of your code (what matters), or that a cache wasting algorithm can end up being faster anyway just because it's more efficient, immediately results in myself being dismissed or treated as ignorant because, something inefficient is obviously inefficient and I must be stupid for not realizing that.
That wasting. Right there.
Re-read his second paragraph, AC.
Or did you just intend to troll and see how many moderators you could trick?
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.
