Things like better roads, cell service, and power can take a back seat until people with broken limbs are off the street and getting medical care.
But that's part of the problem. Without passable roads, many can not get to the medical infrastructure. And without phone service, large groups of people in rural locations are completely unable to obtain any type of aid at all. In fact, one of the first infrastructures restored to Hatti was airports and air traffic control. Yet such things obviously ranks low on your list of priorities; despite that fact its critical.
In the US, our highway and rail systems are actually part of our national defense - as is the case for all industrialized nations. Take a look at the back of many signs on major highways, many have DOD stamps and/or numbers used for DOD and national emergencies. Without these resources, nothing can effectively move. That's the way it is in Hatti right now. Supplies are piling up at airports because its difficult to move anything out. This is forcing helicopters to become one of the primary movers and helicopters are extremely poor substitutes for trucks and trains.
Remember, one truck can provide supplies for an entire village. It can take days for a helicopter to deliver the same quantity. And without simple things like phones, helicopters don't necessarily know the priorities of where supplies are most needed.
In many cases, we're not talking about building street lights and paving roads - we're talking about running water, a line to call for help, means to deliver people medical help, food, water, electricity, sanitation, means to dispose of bodies and trash, to protect against disease, so on and so on...
Remember, its widely believed one of the most significant technological advances for humans is plumbing and its associated water in and sanitation out. The need for basic infrastructure can not be stressed enough. It is extremely important.
That's a series of viruses and with a well known impact on humans. H1N1, is new and the WHO stated up front they don't know what the wider impact on humanity will be. Based on early studies of infection, it looked like it could be more lethal than anything else going around. And they stated they don't know exactly what the death rate will be but that they did expect it to be more so than the common flu. All of which has been proved to be correct.
It sounds like you're confusing media coverage, which has been despicable fear mongering, with the official statements made by the WHO, the CDC, and the well established medical facts.
The truth is, H1N1 is a pandemic and it has killed far more than the typical flu; including some otherwise healthy people. Had people not been active in obtaining vaccines, its likely the death toll would be yet higher, especially among the elderly or those who have compromised breathing and/or immune systems.
At the end of the day, the "mass-hysteria" you're referring to lays strictly on the shoulders of media. Everyone else has been extremely responsible and diligent in their handling of the situation and of releasing the known facts. This is yet another reason why ratings of news should be outlawed. News should not be about entertainment and it should absolutely not be about hysterical fear mongering to obtain yet higher ratings.
In recent times, you can literally place the death of hundreds, if not thousands, directly on the shoulders of "reporters." No ifs, ands, or buts. There are literally laws to punish people for doing what "reporters" do on a daily basis. And yet they get away with it because people falsely believe reporters should be allowed to say anything at any time, so long as its not slanderous or liable, without any regard for the implications or repercussions.
It used to be that reporters would actually delay reporting news so as to ensure it didn't inflame situations or directly cause the death of people. These days, they believe its their absolute right to directly cause the death as many as possible because they can then turn around and report on it, and at the same time attempt to be indigent about how they're not responsible for anything they do.
At the end of the day, if you want someone to blame, please blame the right people. The people to blame are absolutely the "e-porters" (entertainment reporters); as they largely stopped being true, responsible reporters perhaps as long as several decades ago.
The proper question is: How do I find someone qualified to do this for me?
You mean because he's humble enough to realize he doesn't know every thing, you believe he's unqualified anything. I suggest you look hard in the mirror and read what you just wrote to yourself.
That's right. Remounting ex2/3 as ext4 does not provide all the performance benefits. To truly gain the performance boost, you must format at ext4.
Also, when mount ext2/3 as ext4, depending on the mount options, you many not be able to roll back to ext2/3 if you don't like how things go via the ext4 mount experiment.
Could of sworn I remember reading the number is actually closer to 3% and likely under represented, with Apple holding something like 10%. And these numbers are fairly old.
Meaning, assuming my memory is correct, Linux's numbers today are likely to be 5% and still drastically under represented.
Most surgery is probably done on married women to hide aging
That used to be true. Now surgery is as commonly used to either become more competitive in their social hunting grounds or to allow them to hunt in circles which were previously unattainable.
Remember, parents are now having to tell their thirteen year old daughters that they can't get new faces and tits. Likewise, its becoming more common to provide new noses and even tits to girls for their sixteenth to eighteenth birthday. Implants are not just for hookers, strippers, and old women any more.
I think the logic is, we have been breeding out the less attractive traits of our species. Thusly, surgery maintains the status quo, or nearly so.
Look at some old pictures and art. To a large degree, many of the most beautiful women of the time are frequently range from ugly to moderately beautiful by today's standards. There are reasons (small sample sizes, less diversity, etc) in part explain this, but it does support that as a whole we have been breeding out less attractive traits. One possible rebut to this trend is surgery.
Plastic surgery has drastically reduced selective pressures on women. In fact, I remember hearing one geneticist say once such methods become globally accepted, the rate of human evolution is likely to drastically slow, if not come to a stop.
Really the big question is, is 3G available when the user wants to use 3G. Otherwise, who cares if its in 2G when the phone isn't being used as that likely provides a huge battery life boost.
Okay, I missed the JVM jit speed there...but that still only shows median performance of existing dalvik applications, not worst case. The worst case is significantly slower. Remember, the worst case means those Dalvik applications don't exist because its not usable.
I sure hope us Europeeeens have a similar ability to jam GPS, and the stones to use it, if the US _ever_ jams Galileo!
You can jam GPS for roughly $20.00. Ask US pilots who have flow over Iraq during the early part of the war. The Iraqies would jam GPS and light tire fires in hopes of preventing laser locks because of the huge/dense black clouds of smoke. That's the reason some bombs missed their target, causing collateral damage. I guess they forget that most countries can lock via visual tracking, radar, IR, RF, and that jammers can be targeted too.
Jamming localized GPS is well known, cheap, and technically easy.
I will add, if data loss is to happen, its far more likely to happen with the use of applications like Advanced Task Killer as it just kills applications without informing them; which violates normal life cycle of applications and services. Which means, white technically it would be an application bug, its likely to trigger the least tested save/recovery code in the worst way, on a regular basis.
But then again, I already argue using applications like ATK is for users who don't know any better anyways. I would never advocate its use.
How in the world did you deduce that 1.7x performance improvement while comparing it only to itself translates into Dalvik being significantly faster than other non-JIT JVMs? That makes absolutely no sense whatsoever. Strongly smells of disconnect from reality and an over abundance of blind Android fanboy-ism.
One example of something I remember reading is one dev talking about how his code was typically fast enough on other non-JIT mobile JVMs and that his code on Dalvik is at least an order of magnitude slower (hmmm...sounds familiar does it...), making the application unusable. His only recourse was to rewrite code via the NDK or wait and see what the upcoming JIT solution will provide for his code. Given that this is representative of typical feedback and Google absolutely doesn't disagree, how in the hell can you possibly believe that Dalvik is at all comparable to other non-JIT JVMs based strictly on relative comparison to it self? You can't unless you're blind to the facts and don't want to know the truth.
Manipulating linear memory, one byte at a time, is an especially poor performance case for Dalvik. This is why basic image manipulation almost always has to be done in native code (user library) and/or OpenGL (which calls back to native code) on Android.
With a cache hit or a failed scheduler prediction the worst you face is a performance hit.
We have a winner. That's entirely the point!
Terminating an app due to memory constraints risks data loss.
Not in the android framework. In android, you can only *request* and/or *inform* that you're done service/activity is done. That's it. Android notifies you when the user has finished with your activity, thusly a menu item is completely useless because its *impossible* for it to do anything that you can't already do with the existing notification system.
Accordingly, part of the life cycle is to inform you that the system is terminating your application/service. There is a caveat that services can be terminated without notification but that only happens under extreme memory pressures and even then, Android provides facilities to allow you to maintain state and resume when Android automatically reloads persistent services.
Data loss is not a noteworthy concern.
but the fatal flaw is it depends on app authors to play nicely.
The fatal flaw is that it assumes developers are not morons. The fact that anyone can freely develop and the cost to enter the market is $25.00, means morons are openly invited. The fact that users don't know/understand the difference between a poorly written application and a properly written application only compounds the problem.
but I do not accept that it is the best method.
I never argued it was the best method. I do agree it has some shortcomings which assumes developers are not idiots and actually know how to use the framework.
How on earth can two legitimate services performing functions I asked of them in any way be construed as abusive?
Android supports two types of services. The distinction is made based on how the service is started. Non-persistent services live as long as the application does and as such, has a foreground application-like life cycle. This life cycle is very memory friendly. Persistent services continue to run beyond that of the application. Far too often developers are starting their service to run persistently, often at boot time, which provides no benefit in the fact that its there. Thusly, its wasting both memory and CPU. The CPU cost is spent managing its life cycle and constantly loading/unloading it from memory.
As I previously stated, developers are creating persistent services when whey should not be doing so. As a result, the service sits in memory, doing nothing or nearly nothing. Developers who create persistent services but do not actually require a persistent service or do not provide a means to disable their persistent service or do not provide a means to prevent the service from loading at boot, are abusing Android's service facilities and drastically increasing memory pressures; especially one low memory devices. Large increases in memory pressures causes thrashing and high latency user interactions, which provides for a very poor user experience.
Here's an example. Application requires a login. User logs in and checks out the application. User logs out. At this point, there is literally nothing the service can do since the user is logged out. The service should terminate. Almost without fail, developers fail here. The same goes for many news and weather applications. Many don't provide for the user to simply poll at application start, thereby alleviating the need to have a background service running. The result is a service stays running 24/7 to obtain weather information once or twice in a day. The abuse and poor design of many Android applications are nearly endless.
If developers would simply fix their bugs (e.g. SQLite cursor leaks, service abuse), the memory pressures on your typical Android device would be drastically lowered and provide for a drastically superior user experience. As such, this is the real problem. Missing menu items are simply not a factor.
I would go out on a limb and say perhaps as many as 80%-90% of Android applications which use a SQLite database have memory leaks. Worse, many of these applications insist on creating persistent services. Even more insulting, the system even tells you there are leaks and you can see them spewed all over the place in the developer logs. Not hard to draw a conclusion on the negative effects this will have on a device over the course of a day or week; depending on the leak rate.
Actually the burden of proof is on you because I couldn't care less if you believe me.
Option one, I spend lots of time trying to find various articles I've read over the span of a year plus trying to convince some douche of a fact that doesn't significantly matter. Even more so, your ignorance doesn't negatively affect me.
Option two, you spend the same amount of time doing option one for yourself. This means you're smart and can research and are interesting in learning.
Net result, option one would make me an idiot. Option two would educate you whereby you'd likely learn a lot more about android which you didn't already know. Since I'm not an idiot, you're only option is option two.
Tell me, when you have a conversation with someone and they tell you something you didn't already know, do you call them a lair and then wrestle them to the floor to force them to do YOUR research? If you don't, you're a hypocrite. If you do, you're likely writing this from jail or prison. Contrary to the popular trend on the Internet, your ignorance is not someone else's responsibility. If you don't want to be ignorant, do you're own research. I don't owe you anything and neither does anyone else on the Internet. Grow up.
Keep searching. And I'm sure you'll be searching and reading for while. The JIT stuff is somewhat new. The rest is fairly old; spanning over the last year or so.
And I have no idea why you believe the post above is contrary to my assertion. Think about it. That compares JIT to JIT. I stated non-JIT to non-JIT. Neither is contrary.
Allow me to provide a single theoretical scenario that demonstrates the absolute truth of this statement:
I have a ssh session open in one app, and a rdp session open in another. Both apps are currently in the background. I start a 3rd app that puts a memory squeeze on the system forcing android to terminate one or the other.
The simple fact of the matter is android cannot infer which would be less disruptive to me. The only way to do this is to ask. Some operating systems would "ask" by simply refusing to start the 3rd app. Android will simply kill one and let the chips fall where they may.
All I ask is the chance to mitigate this behavior to the best of my ability by providing some control over what remains running. As I said earlier, the necessary code to provide an extra menu entry would likely fit in in the tail end of an already used memory page. Impact on memory usage would be 0.
That's nice and all, but let's get back to reality. Android doesn't work that way - which is what I've repeated said. Period. End of discussion. Adding a useless menu item is not going to change anything. Period.
No re-read my posts above about abusive services - to which the cure, in no way, shape, or form, has absolutely anything to do with menu items. Period. End of discussion.
Slashdot Mirror
Things like better roads, cell service, and power can take a back seat until people with broken limbs are off the street and getting medical care.
But that's part of the problem. Without passable roads, many can not get to the medical infrastructure. And without phone service, large groups of people in rural locations are completely unable to obtain any type of aid at all. In fact, one of the first infrastructures restored to Hatti was airports and air traffic control. Yet such things obviously ranks low on your list of priorities; despite that fact its critical.
In the US, our highway and rail systems are actually part of our national defense - as is the case for all industrialized nations. Take a look at the back of many signs on major highways, many have DOD stamps and/or numbers used for DOD and national emergencies. Without these resources, nothing can effectively move. That's the way it is in Hatti right now. Supplies are piling up at airports because its difficult to move anything out. This is forcing helicopters to become one of the primary movers and helicopters are extremely poor substitutes for trucks and trains.
Remember, one truck can provide supplies for an entire village. It can take days for a helicopter to deliver the same quantity. And without simple things like phones, helicopters don't necessarily know the priorities of where supplies are most needed.
In many cases, we're not talking about building street lights and paving roads - we're talking about running water, a line to call for help, means to deliver people medical help, food, water, electricity, sanitation, means to dispose of bodies and trash, to protect against disease, so on and so on...
Remember, its widely believed one of the most significant technological advances for humans is plumbing and its associated water in and sanitation out. The need for basic infrastructure can not be stressed enough. It is extremely important.
Common cold is also a pandemic.
That's a series of viruses and with a well known impact on humans. H1N1, is new and the WHO stated up front they don't know what the wider impact on humanity will be. Based on early studies of infection, it looked like it could be more lethal than anything else going around. And they stated they don't know exactly what the death rate will be but that they did expect it to be more so than the common flu. All of which has been proved to be correct.
It sounds like you're confusing media coverage, which has been despicable fear mongering, with the official statements made by the WHO, the CDC, and the well established medical facts.
The truth is, H1N1 is a pandemic and it has killed far more than the typical flu; including some otherwise healthy people. Had people not been active in obtaining vaccines, its likely the death toll would be yet higher, especially among the elderly or those who have compromised breathing and/or immune systems.
At the end of the day, the "mass-hysteria" you're referring to lays strictly on the shoulders of media. Everyone else has been extremely responsible and diligent in their handling of the situation and of releasing the known facts. This is yet another reason why ratings of news should be outlawed. News should not be about entertainment and it should absolutely not be about hysterical fear mongering to obtain yet higher ratings.
In recent times, you can literally place the death of hundreds, if not thousands, directly on the shoulders of "reporters." No ifs, ands, or buts. There are literally laws to punish people for doing what "reporters" do on a daily basis. And yet they get away with it because people falsely believe reporters should be allowed to say anything at any time, so long as its not slanderous or liable, without any regard for the implications or repercussions.
It used to be that reporters would actually delay reporting news so as to ensure it didn't inflame situations or directly cause the death of people. These days, they believe its their absolute right to directly cause the death as many as possible because they can then turn around and report on it, and at the same time attempt to be indigent about how they're not responsible for anything they do.
At the end of the day, if you want someone to blame, please blame the right people. The people to blame are absolutely the "e-porters" (entertainment reporters); as they largely stopped being true, responsible reporters perhaps as long as several decades ago.
The proper question is: How do I find someone qualified to do this for me?
You mean because he's humble enough to realize he doesn't know every thing, you believe he's unqualified anything. I suggest you look hard in the mirror and read what you just wrote to yourself.
That's right. Remounting ex2/3 as ext4 does not provide all the performance benefits. To truly gain the performance boost, you must format at ext4.
Also, when mount ext2/3 as ext4, depending on the mount options, you many not be able to roll back to ext2/3 if you don't like how things go via the ext4 mount experiment.
Because looking at what you're taking a picture of is completely non-obvious.
Presumably everyone with at least one working eye will be sued next.
Linux desktop market share is maybe 1% at most.
Could of sworn I remember reading the number is actually closer to 3% and likely under represented, with Apple holding something like 10%. And these numbers are fairly old.
Meaning, assuming my memory is correct, Linux's numbers today are likely to be 5% and still drastically under represented.
that Santa Claus and the Easter Bunny are myths
WHAT?!?!
Oh my God...NOOOOOOOOOO!!! You son of a bitch! NOOOOOOOOOO!!!
BTW, mod up the parent. +1 Insightful
Most surgery is probably done on married women to hide aging
That used to be true. Now surgery is as commonly used to either become more competitive in their social hunting grounds or to allow them to hunt in circles which were previously unattainable.
Remember, parents are now having to tell their thirteen year old daughters that they can't get new faces and tits. Likewise, its becoming more common to provide new noses and even tits to girls for their sixteenth to eighteenth birthday. Implants are not just for hookers, strippers, and old women any more.
I think the logic is, we have been breeding out the less attractive traits of our species. Thusly, surgery maintains the status quo, or nearly so.
Look at some old pictures and art. To a large degree, many of the most beautiful women of the time are frequently range from ugly to moderately beautiful by today's standards. There are reasons (small sample sizes, less diversity, etc) in part explain this, but it does support that as a whole we have been breeding out less attractive traits. One possible rebut to this trend is surgery.
Does the Kindle have any USB ports which would allow for adoption of a braille pin reader? If so, it seems only a driver would be required.
and the penis develops.
The penis develops from what is the clitoris. Some women actually have a falic-like clitoris.
Well the only group that we can really make fun at now are the White Male Catholics.
I was going to add, "and the drunken Irish", but that would be doubly redundant.
Plastic surgery has drastically reduced selective pressures on women. In fact, I remember hearing one geneticist say once such methods become globally accepted, the rate of human evolution is likely to drastically slow, if not come to a stop.
Why is this marked troll?!?
Really the big question is, is 3G available when the user wants to use 3G. Otherwise, who cares if its in 2G when the phone isn't being used as that likely provides a huge battery life boost.
Okay, I missed the JVM jit speed there...but that still only shows median performance of existing dalvik applications, not worst case. The worst case is significantly slower. Remember, the worst case means those Dalvik applications don't exist because its not usable.
Which brings us full circle, I'm still right.
Add to it your refusal to give links,
Absolute proof you're a fucking idiot. And a lazy fucking idiot at that. Nuff said.
I sure hope us Europeeeens have a similar ability to jam GPS, and the stones to use it, if the US _ever_ jams Galileo!
You can jam GPS for roughly $20.00. Ask US pilots who have flow over Iraq during the early part of the war. The Iraqies would jam GPS and light tire fires in hopes of preventing laser locks because of the huge/dense black clouds of smoke. That's the reason some bombs missed their target, causing collateral damage. I guess they forget that most countries can lock via visual tracking, radar, IR, RF, and that jammers can be targeted too.
Jamming localized GPS is well known, cheap, and technically easy.
Ya, replying to myself.
I will add, if data loss is to happen, its far more likely to happen with the use of applications like Advanced Task Killer as it just kills applications without informing them; which violates normal life cycle of applications and services. Which means, white technically it would be an application bug, its likely to trigger the least tested save/recovery code in the worst way, on a regular basis.
But then again, I already argue using applications like ATK is for users who don't know any better anyways. I would never advocate its use.
How in the world did you deduce that 1.7x performance improvement while comparing it only to itself translates into Dalvik being significantly faster than other non-JIT JVMs? That makes absolutely no sense whatsoever. Strongly smells of disconnect from reality and an over abundance of blind Android fanboy-ism.
One example of something I remember reading is one dev talking about how his code was typically fast enough on other non-JIT mobile JVMs and that his code on Dalvik is at least an order of magnitude slower (hmmm...sounds familiar does it...), making the application unusable. His only recourse was to rewrite code via the NDK or wait and see what the upcoming JIT solution will provide for his code. Given that this is representative of typical feedback and Google absolutely doesn't disagree, how in the hell can you possibly believe that Dalvik is at all comparable to other non-JIT JVMs based strictly on relative comparison to it self? You can't unless you're blind to the facts and don't want to know the truth.
Manipulating linear memory, one byte at a time, is an especially poor performance case for Dalvik. This is why basic image manipulation almost always has to be done in native code (user library) and/or OpenGL (which calls back to native code) on Android.
With a cache hit or a failed scheduler prediction the worst you face is a performance hit.
We have a winner. That's entirely the point!
Terminating an app due to memory constraints risks data loss.
Not in the android framework. In android, you can only *request* and/or *inform* that you're done service/activity is done. That's it. Android notifies you when the user has finished with your activity, thusly a menu item is completely useless because its *impossible* for it to do anything that you can't already do with the existing notification system.
Accordingly, part of the life cycle is to inform you that the system is terminating your application/service. There is a caveat that services can be terminated without notification but that only happens under extreme memory pressures and even then, Android provides facilities to allow you to maintain state and resume when Android automatically reloads persistent services.
Data loss is not a noteworthy concern.
but the fatal flaw is it depends on app authors to play nicely.
The fatal flaw is that it assumes developers are not morons. The fact that anyone can freely develop and the cost to enter the market is $25.00, means morons are openly invited. The fact that users don't know/understand the difference between a poorly written application and a properly written application only compounds the problem.
but I do not accept that it is the best method.
I never argued it was the best method. I do agree it has some shortcomings which assumes developers are not idiots and actually know how to use the framework.
How on earth can two legitimate services performing functions I asked of them in any way be construed as abusive?
Android supports two types of services. The distinction is made based on how the service is started. Non-persistent services live as long as the application does and as such, has a foreground application-like life cycle. This life cycle is very memory friendly. Persistent services continue to run beyond that of the application. Far too often developers are starting their service to run persistently, often at boot time, which provides no benefit in the fact that its there. Thusly, its wasting both memory and CPU. The CPU cost is spent managing its life cycle and constantly loading/unloading it from memory.
As I previously stated, developers are creating persistent services when whey should not be doing so. As a result, the service sits in memory, doing nothing or nearly nothing. Developers who create persistent services but do not actually require a persistent service or do not provide a means to disable their persistent service or do not provide a means to prevent the service from loading at boot, are abusing Android's service facilities and drastically increasing memory pressures; especially one low memory devices. Large increases in memory pressures causes thrashing and high latency user interactions, which provides for a very poor user experience.
Here's an example. Application requires a login. User logs in and checks out the application. User logs out. At this point, there is literally nothing the service can do since the user is logged out. The service should terminate. Almost without fail, developers fail here. The same goes for many news and weather applications. Many don't provide for the user to simply poll at application start, thereby alleviating the need to have a background service running. The result is a service stays running 24/7 to obtain weather information once or twice in a day. The abuse and poor design of many Android applications are nearly endless.
If developers would simply fix their bugs (e.g. SQLite cursor leaks, service abuse), the memory pressures on your typical Android device would be drastically lowered and provide for a drastically superior user experience. As such, this is the real problem. Missing menu items are simply not a factor.
I would go out on a limb and say perhaps as many as 80%-90% of Android applications which use a SQLite database have memory leaks. Worse, many of these applications insist on creating persistent services. Even more insulting, the system even tells you there are leaks and you can see them spewed all over the place in the developer logs. Not hard to draw a conclusion on the negative effects this will have on a device over the course of a day or week; depending on the leak rate.
So, unless you're an ancient greek philosopher, you can choose to not introduce hemlock in your body
Actually he had a choice. He chose to be true to they self and as such, chose to consume the hemlock. ...just being overly pedantic...
Actually the burden of proof is on you because I couldn't care less if you believe me.
Option one, I spend lots of time trying to find various articles I've read over the span of a year plus trying to convince some douche of a fact that doesn't significantly matter. Even more so, your ignorance doesn't negatively affect me.
Option two, you spend the same amount of time doing option one for yourself. This means you're smart and can research and are interesting in learning.
Net result, option one would make me an idiot. Option two would educate you whereby you'd likely learn a lot more about android which you didn't already know. Since I'm not an idiot, you're only option is option two.
Tell me, when you have a conversation with someone and they tell you something you didn't already know, do you call them a lair and then wrestle them to the floor to force them to do YOUR research? If you don't, you're a hypocrite. If you do, you're likely writing this from jail or prison. Contrary to the popular trend on the Internet, your ignorance is not someone else's responsibility. If you don't want to be ignorant, do you're own research. I don't owe you anything and neither does anyone else on the Internet. Grow up.
Keep searching. And I'm sure you'll be searching and reading for while. The JIT stuff is somewhat new. The rest is fairly old; spanning over the last year or so.
And I have no idea why you believe the post above is contrary to my assertion. Think about it. That compares JIT to JIT. I stated non-JIT to non-JIT. Neither is contrary.
Allow me to provide a single theoretical scenario that demonstrates the absolute truth of this statement:
I have a ssh session open in one app, and a rdp session open in another. Both apps are currently in the background. I start a 3rd app that puts a memory squeeze on the system forcing android to terminate one or the other.
The simple fact of the matter is android cannot infer which would be less disruptive to me. The only way to do this is to ask. Some operating systems would "ask" by simply refusing to start the 3rd app. Android will simply kill one and let the chips fall where they may.
All I ask is the chance to mitigate this behavior to the best of my ability by providing some control over what remains running. As I said earlier, the necessary code to provide an extra menu entry would likely fit in in the tail end of an already used memory page. Impact on memory usage would be 0.
That's nice and all, but let's get back to reality. Android doesn't work that way - which is what I've repeated said. Period. End of discussion. Adding a useless menu item is not going to change anything. Period.
No re-read my posts above about abusive services - to which the cure, in no way, shape, or form, has absolutely anything to do with menu items. Period. End of discussion.