So let me get this straight.. In the beginning we had a very simple very open design. Any host can talk to any other host on any port. Then, over the years bouts of paranoia, fear, and idiocy have created default drop firewalls and nat devices that fundamentally break the open nature of the internet, protocols that rely on that nature break when presented with that stupidity, and somehow it's the fault of the protocol designer?
How would you suggest we operate? Instead of using my internet connection to accept connections from my peers should I proxy through a 3rd party? Should I use a ridiculous hack like upnp to beg the nat device for a forward? What happens when we're all behind default drop inbound firewalls w/ a nat'd address generously provided by our ISP? Suddenly and even though you have an internet connection and I have an internet connection we can no longer communicate directly with each other? Do you not see this as a problem? Is this still a protocol issue?
As opposed to the arrogance of assuming our current understanding of the physical world is absolute in its correctness? He was saying he's wise enough to realize we probably do not understand everything, and it is impossible to know what we've yet to learn.
I agree 100% with one caveat.. that simple equation to describe the large complex behavior should be a highly reduced equation of the so called fundamental rules in order for it to be described as emergent.
Correct me if I'm wrong, but isn't the very idea of emergent phenomenon the result of a complex system emerging from less complex interactions? I was always under the impression the idea of a "theory of everything" is to isolate those simple interactions that all emergent behavior stems with the idea being that perhaps, in time, the emergent behavior can be predicted or even constructed.
Perhaps emergence can go both ways.. somehow? There is no base set of rules, and no matter how far in either direction you look you find more? I don't know, but it does seem that was we increase scale the trend is one way. The larger scale systems that we can explain are explained by smaller scale systems (at least from our point of view) and not vice versa.
In the end and for all we know we may be so far from the truth that if and when we do discover it it will look nothing like what we currently understand. We have no scale or basis for comparison. I find it amazing anyone would even attempt make claims as to what "the end" of knowledge looks like.
Expensive compared to what? I spent more on a Dell R610 and an ESX license this morning than the average annual salary of a commercial airline pilot. Burger king pays more for its night shift supervisors...
These are mostly toys meant to make the cpu run _hot_. Neither of them is designed specifically to perform a comprehensive path test of the CPU. See nabsitd's reply to my original comment for a non comprehensive example of things that need to be tested thoroughly.
Even hitting every instructions is not enough to test every path. There are things such as cache coherency and reliability, branch predictor testing. You have out of order execution and pipelining that needs to be examined, etc.
If a part of the processor that determines safeness for out of order execution has a single piece wrong that could be enough to start corrupting a filesystem. Granted, I imagine such a quirk would be highly unlikely, but these tests are most definitely not going to be able to tell you one way or the other of something is lurking broken that's going to ruin your day.
prime95 doesn't cover all of cpus functionality. Granted, it does directly or indirectly stress the fpu, cache, maybe task switching and interrupt handling. However, there are many more things that can go wrong.
To be fair, I don't know of a better way to test, and I'd love to see a discussion of better utilities. If I tried this I'd probably do mprime and keep an eye out for MCE's in the system logs, but don't delude yourself into thinking that core is error free because you ran prime95.
Another way of describing a widely known fact is "urban myth". People not demanding confirmation before simply accepting something as the truth is the cause of much misinformation.
What the hell is wrong with you two? The only situation I can find this even remotely acceptable is in response to verified abuse complaints, and even then the appropriate resolution is attempt to contact the customer then disable the entire connection if the customer is unable to resolve the issue. Depending on the severity you don't necessarily need to do it in that order.
I'm leasing an internet connection. You route IP packets destined for my address directly to me, and you route any and every IP packet I send to the appropriate next hop. The end. No if's, and's or but's. No blocked, ports, no traffic shaping, no injected tcp resets... nothing. Just route the damn traffic.
I believe we mostly understand each other now, and I want to thank you for keeping the thread going and discussing this with me.
I do have one final question maybe you could answer, however. Can an application indicate to android that it cannot save its own state because it does not control it (e.g. text editor in ssh)? The idea being perhaps failing to start the app that needs the memory might be a better action than terminating the existing app that cannot be terminated without loss of state
It seems based on this discussion that the front running app is king of the hill, and android would do anything possible to start it than present an error condition.
How on earth can two legitimate services performing functions I asked of them in any way be construed as abusive? The choice is potential data loss in one, or failure to start another. Android chose the former.
My new app will come up, and I'll be oblivious to the failure of the one that was terminated. Maybe I had an unsaved file in vi in a terminal. Whoops.. the front running web browser needed memory, so the connected was broken to kill the app. Bye bye data. At least I didn't have to be inconvenienced by a web browser that refused to start.
The point is I have to always be keeping this problem in mind while using the device.
With a cache hit or a failed scheduler prediction the worst you face is a performance hit. Terminating an app due to memory constraints risks data loss. This is not a caching algorithm we're discussing. This is a "try really hard to do multitasking in a memory constrained environment without ever showing the user unpleasant error dialogs" issue. Apparently the android choice is silent termination without regard to consequences.
Also, I'm not sure where you got it in your head that I'm claiming this is not how android is suppose to work. I'm fully aware of that. The discussion is about the drawbacks and consequences. I admire the methods from an aesthetic standpoint, but the fatal flaw is it depends on app authors to play nicely. This is analogous to the problems faced by cooperative multitasking with regards to UI responsiveness.
I accept this is how it is with android, but I do not accept that it is the best method.
but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.
This statement is contrary to almost every facet of modern computing. And almost without fail, those who take your position are wrong.
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.
This statement is contrary to almost every facet of modern computing.
How so? Do you have examples? While the idea is by no means novel, it is certainly not popular. Nearly every popular general purpose OS leaves application management to the user. In the mobile space some solve it by simply not allowing multitasking to take place avoiding the problem altogether. Resource management via leaving everything on and relying an applications themselves to intelligently save state and handle random termination gracefully is hardly "almost every facet of modern computing."
There are only two or three ways to immediately terminate an Android application and none are recommended. Some provide negative feedback to the user, further annoying them.
Yet some of the more reasonably behaved ones managed it. As a previous poster mentioned pandora is one such app, the *oid series of emulators all have a perfectly functioning quite option.
When Android decides it needs more memory it will terminate applications as it sees fit. That's the end of it, no matter how much you want to complain.
Indeed, and being forced into this should carry the same stigma as the linux oom process killer. If it goes that far something has gone wrong.
This is nonsense and verging on asinine. I don't mean that as a personal insult as you did mention this is in google's guidelines, but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.
Not only are there issues of badly behaving apps draining battery when not terminated, but there are issues of apps with persistent roles such as internet radio, remote terminals, download managers, badly behaving websites with non-interruptible multi page operations, etc.
When I'm involved in a complex work flow I know what needs to remain up and what can be terminated to free up resources. Some magic voodoo app manager does not.
Asking for an extra menu entry to quit an application is not too much to ask. The few lines of code it'd require would fit in the tail end of an unfilled memory page. Don't give me any nonsense about compounding memory pressure. If I hit back or home fine, stay up. If I hit menu > quit then by all means terminate.
There's a reason task managers are among the most popular android applications. In a perfect world with perfect 3rd party apps the magic voodoo app manager might work, and I do appreciate its idealistic goal. The fact of the matter is it doesn't work that well.
I based my assumption on no wifi on the market description. Perhaps the one available on the market is different or the author has failed to update its description. So I apologize for spreading that misinformation.
I'm not at all against rooting the phone, and I was pleasantly surprised when I found apps that require you to do so are even available on the market. It's a testament to how open the entire process is.
My only issue is when people assume that a solution that only works on a rooted phone is a global solution on the misguided assumption that every should and does root their phone. This is especially annoying when such people don't bother to provide a disclaimer mentioning that their solution does require root. Rooting a phone is not the norm, and treating it like it is only confuses people when things don't work for them.
All in all I don't disagree with any of your points. I just wish people would point out their solutions are for a small group of atypical users only.
It's a problem with developers, and it annoys the piss out of me. There are a precious few apps that actually completely close when you hit menu -> quit. Most don't, and many even lack a quit command altogether.
I don't know if it's because android is attracting developers that aren't use to multitasking on phones (e.g. iphone) so they don't even think of the need for a proper quit or if it's something else, but I hope they learn soon. I get tired of having to run a task manager to manually kill each app after I'm done using it.
Everything you just described has been available in a myriad of forms on several distributions for years. The.app bundle might as well be a rpm, details like where the installed files go are just details with good package management.
Also, any decent distribution will setup mime types so that a click on a package on a website will bring up the installer. Some have taken it further than that, e.g. OpenSUSE with their 1 click installs from their build service. Search. Click. Done.
Slashdot Mirror
we do not have a space police in place yet.
I do believe that's the point...
So let me get this straight.. In the beginning we had a very simple very open design. Any host can talk to any other host on any port. Then, over the years bouts of paranoia, fear, and idiocy have created default drop firewalls and nat devices that fundamentally break the open nature of the internet, protocols that rely on that nature break when presented with that stupidity, and somehow it's the fault of the protocol designer?
How would you suggest we operate? Instead of using my internet connection to accept connections from my peers should I proxy through a 3rd party? Should I use a ridiculous hack like upnp to beg the nat device for a forward? What happens when we're all behind default drop inbound firewalls w/ a nat'd address generously provided by our ISP? Suddenly and even though you have an internet connection and I have an internet connection we can no longer communicate directly with each other? Do you not see this as a problem? Is this still a protocol issue?
As opposed to the arrogance of assuming our current understanding of the physical world is absolute in its correctness? He was saying he's wise enough to realize we probably do not understand everything, and it is impossible to know what we've yet to learn.
Thank you for the book reference. That looks absolutely fascinating. It would have already been bought if it was availabe on the Kindle :)
I agree 100% with one caveat.. that simple equation to describe the large complex behavior should be a highly reduced equation of the so called fundamental rules in order for it to be described as emergent.
Correct me if I'm wrong, but isn't the very idea of emergent phenomenon the result of a complex system emerging from less complex interactions? I was always under the impression the idea of a "theory of everything" is to isolate those simple interactions that all emergent behavior stems with the idea being that perhaps, in time, the emergent behavior can be predicted or even constructed.
Perhaps emergence can go both ways.. somehow? There is no base set of rules, and no matter how far in either direction you look you find more? I don't know, but it does seem that was we increase scale the trend is one way. The larger scale systems that we can explain are explained by smaller scale systems (at least from our point of view) and not vice versa.
In the end and for all we know we may be so far from the truth that if and when we do discover it it will look nothing like what we currently understand. We have no scale or basis for comparison. I find it amazing anyone would even attempt make claims as to what "the end" of knowledge looks like.
Expensive compared to what? I spent more on a Dell R610 and an ESX license this morning than the average annual salary of a commercial airline pilot. Burger king pays more for its night shift supervisors...
Most people don't need to defend their rights because they willingly give them away.
Fixed that for you.
These are mostly toys meant to make the cpu run _hot_. Neither of them is designed specifically to perform a comprehensive path test of the CPU. See nabsitd's reply to my original comment for a non comprehensive example of things that need to be tested thoroughly.
Even hitting every instructions is not enough to test every path. There are things such as cache coherency and reliability, branch predictor testing. You have out of order execution and pipelining that needs to be examined, etc.
If a part of the processor that determines safeness for out of order execution has a single piece wrong that could be enough to start corrupting a filesystem. Granted, I imagine such a quirk would be highly unlikely, but these tests are most definitely not going to be able to tell you one way or the other of something is lurking broken that's going to ruin your day.
mprime performs FFT's when doing stress testing. The documentation explicitly states it's a FPU stress test...
[citation needed]
prime95 doesn't cover all of cpus functionality. Granted, it does directly or indirectly stress the fpu, cache, maybe task switching and interrupt handling. However, there are many more things that can go wrong.
To be fair, I don't know of a better way to test, and I'd love to see a discussion of better utilities. If I tried this I'd probably do mprime and keep an eye out for MCE's in the system logs, but don't delude yourself into thinking that core is error free because you ran prime95.
announce lists are intentionally very low traffic. I'm subscribed to over 50, and I rarely receive more than 4 or 5 mails a week at most.
Another way of describing a widely known fact is "urban myth". People not demanding confirmation before simply accepting something as the truth is the cause of much misinformation.
What the hell is wrong with you two? The only situation I can find this even remotely acceptable is in response to verified abuse complaints, and even then the appropriate resolution is attempt to contact the customer then disable the entire connection if the customer is unable to resolve the issue. Depending on the severity you don't necessarily need to do it in that order.
I'm leasing an internet connection. You route IP packets destined for my address directly to me, and you route any and every IP packet I send to the appropriate next hop. The end. No if's, and's or but's. No blocked, ports, no traffic shaping, no injected tcp resets... nothing. Just route the damn traffic.
That's not exactly an insurmountable problem
I believe we mostly understand each other now, and I want to thank you for keeping the thread going and discussing this with me.
I do have one final question maybe you could answer, however. Can an application indicate to android that it cannot save its own state because it does not control it (e.g. text editor in ssh)? The idea being perhaps failing to start the app that needs the memory might be a better action than terminating the existing app that cannot be terminated without loss of state
It seems based on this discussion that the front running app is king of the hill, and android would do anything possible to start it than present an error condition.
How on earth can two legitimate services performing functions I asked of them in any way be construed as abusive? The choice is potential data loss in one, or failure to start another. Android chose the former.
My new app will come up, and I'll be oblivious to the failure of the one that was terminated. Maybe I had an unsaved file in vi in a terminal. Whoops.. the front running web browser needed memory, so the connected was broken to kill the app. Bye bye data. At least I didn't have to be inconvenienced by a web browser that refused to start.
The point is I have to always be keeping this problem in mind while using the device.
With a cache hit or a failed scheduler prediction the worst you face is a performance hit. Terminating an app due to memory constraints risks data loss. This is not a caching algorithm we're discussing. This is a "try really hard to do multitasking in a memory constrained environment without ever showing the user unpleasant error dialogs" issue. Apparently the android choice is silent termination without regard to consequences.
Also, I'm not sure where you got it in your head that I'm claiming this is not how android is suppose to work. I'm fully aware of that. The discussion is about the drawbacks and consequences. I admire the methods from an aesthetic standpoint, but the fatal flaw is it depends on app authors to play nicely. This is analogous to the problems faced by cooperative multitasking with regards to UI responsiveness.
I accept this is how it is with android, but I do not accept that it is the best method.
but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.
This statement is contrary to almost every facet of modern computing. And almost without fail, those who take your position are wrong.
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.
This statement is contrary to almost every facet of modern computing.
How so? Do you have examples? While the idea is by no means novel, it is certainly not popular. Nearly every popular general purpose OS leaves application management to the user. In the mobile space some solve it by simply not allowing multitasking to take place avoiding the problem altogether. Resource management via leaving everything on and relying an applications themselves to intelligently save state and handle random termination gracefully is hardly "almost every facet of modern computing."
There are only two or three ways to immediately terminate an Android application and none are recommended. Some provide negative feedback to the user, further annoying them.
Yet some of the more reasonably behaved ones managed it. As a previous poster mentioned pandora is one such app, the *oid series of emulators all have a perfectly functioning quite option.
When Android decides it needs more memory it will terminate applications as it sees fit. That's the end of it, no matter how much you want to complain.
Indeed, and being forced into this should carry the same stigma as the linux oom process killer. If it goes that far something has gone wrong.
This is nonsense and verging on asinine. I don't mean that as a personal insult as you did mention this is in google's guidelines, but no automatic app manager no matter how advanced knows enough about how I use my phone and how the apps I use function to successfully perform its role.
Not only are there issues of badly behaving apps draining battery when not terminated, but there are issues of apps with persistent roles such as internet radio, remote terminals, download managers, badly behaving websites with non-interruptible multi page operations, etc.
When I'm involved in a complex work flow I know what needs to remain up and what can be terminated to free up resources. Some magic voodoo app manager does not.
Asking for an extra menu entry to quit an application is not too much to ask. The few lines of code it'd require would fit in the tail end of an unfilled memory page. Don't give me any nonsense about compounding memory pressure. If I hit back or home fine, stay up. If I hit menu > quit then by all means terminate.
There's a reason task managers are among the most popular android applications. In a perfect world with perfect 3rd party apps the magic voodoo app manager might work, and I do appreciate its idealistic goal. The fact of the matter is it doesn't work that well.
I based my assumption on no wifi on the market description. Perhaps the one available on the market is different or the author has failed to update its description. So I apologize for spreading that misinformation.
I'm not at all against rooting the phone, and I was pleasantly surprised when I found apps that require you to do so are even available on the market. It's a testament to how open the entire process is.
My only issue is when people assume that a solution that only works on a rooted phone is a global solution on the misguided assumption that every should and does root their phone. This is especially annoying when such people don't bother to provide a disclaimer mentioning that their solution does require root. Rooting a phone is not the norm, and treating it like it is only confuses people when things don't work for them.
All in all I don't disagree with any of your points. I just wish people would point out their solutions are for a small group of atypical users only.
It's a problem with developers, and it annoys the piss out of me. There are a precious few apps that actually completely close when you hit menu -> quit. Most don't, and many even lack a quit command altogether.
I don't know if it's because android is attracting developers that aren't use to multitasking on phones (e.g. iphone) so they don't even think of the need for a proper quit or if it's something else, but I hope they learn soon. I get tired of having to run a task manager to manually kill each app after I'm done using it.
Everything you just described has been available in a myriad of forms on several distributions for years. The .app bundle might as well be a rpm, details like where the installed files go are just details with good package management.
Also, any decent distribution will setup mime types so that a click on a package on a website will bring up the installer. Some have taken it further than that, e.g. OpenSUSE with their 1 click installs from their build service. Search. Click. Done.
Updates show the same list of required permissions as a fresh install does. It wasn't clear to me if you knew this or not..