4 ms·

Android (and I think iOS?) both reserve the right to purge paused apps from memory if memory is needed (a paused app being an app that the user is not currently

Android (and I think iOS?) both reserve the right to purge paused apps from memory if memory is needed (a paused app being an app that the user is not currently looking at). This seems well suited to phones, but leads to a totally different programming model whereby apps must be ready to persist their state and be deflated/reinflated/stopped without warning. Will Ubuntu for Phones struggle to make good use of the phone memory if it doesn't use this technique? (I assume it just uses the desktop-PC model of 'a thing is running until its stopped, page to disk if necessary?') edit: also, as people have pointed out, there are battery life implications

BenoitEssiambre 14y ago
Interesting question. That would be a fundamental architectural difference with lots of ramifications. I too would like to know the answer to this.
subway 14y ago
With speedy enough flash, this could be essentially accomplished in the kernel with swap space.
Jach 14y ago
Perhaps Shuttleworth is counting on phones having more than a few gigs of RAM in the near future, making app suspension rather pointless if your concern is memory. (Rather, it is more useful to me in prolonging battery life.)
- jeremyjh 14y ago
  They are trying to target the low end though.
CJefferson 14y ago
While this is important for memory, it is also really important for battery usage. My experience with Android is that waking every second is enough to kill a phone's battery noticeably faster. I suspect most existing linux apps and frameworks are not good at saving CPU and battery enough to be on a phone. I would be happy to be proved wrong.
- Stratoscope 14y ago
  > While this is important for memory, it is also really important for memory usage. I think you meant battery usage. (I'll delete this comment to reduce clutter after you edit...)
  - Stratoscope 14y ago
    Forgive the added clutter, but I came back to delete my comment as promised and HN wouldn't let me. Ah well... :-)
hobbyist 14y ago
Could you explain what do you mean by a "totally different programming model"? Do you mean the network state with the external server?
- codeulike 14y ago
  I mean that Android/iOS apps have to listen for 'pause' events and the like, and then pause themselves pronto and save all their state somewhere, and then (if needed) re-inflate themselves and pop back infront of the user as if nothing has happened. The smartphone App lifecycle and way state is managed is pretty different to a general PC application.
ajross 14y ago
This technique already exists in Unix, and has for decades. SIGTERM is easy to deliver, can be caught trivially if needed, and its default action is generally exactly what you want (i.e. it kills the process -- on smartphones software generally needs to be tolerant of an unexpected shutdown anyway due to battery death, etc...). This same argument was had in the MeeGo days. Putting a bunch of junk into the framework APIs to support this is just needless "feel good" complexity around a problem that's already solved. All that's needed is a component to make the decision to kill processes.
- codeulike 14y ago
  Thats somewhat similar. But iOS and Android apps are built to pause/sleep, which is somewhat different to a kill. A paused Android/iOS app might get killed, but it might also get un-paused, and then it has to carry on (in the users eyes) as if it was never interfered with at all.
  - fusiongyro 14y ago
    As it happens, there's also SIGSTOP and SIGCONT. The responsibility to write the app correctly is always going to fall on the app developer. It's just that for phone apps, it's a lot more obvious that you need to. But it doesn't have to be that way, and frameworks to facilitate writing apps like this would be a totally userland proposition, just using traditional Unix signals that are rarely used today.
    - codeulike 14y ago
      Thats interesting. But then my question would be: will the phone be restricted to running apps that behave graciously by handling those signals?
      - fusiongyro 14y ago
        There's no way to know a priori without introducing some pretty onerous restrictions.
primitur 14y ago
I think its important for the non-Embedded people to understand something: there is nothing in the iOS Systems Criticality design which wasn't already figured out, 20 years previously, in the history of computing. Nada. iOS was, essentially, the consumer-computer-OS marketing people finally getting some proper engineering under their skin enough so that they could pretty it up and package it and sell it, $99 a pop, to all the teenager coders. The effort to get OSX and iOS suitable for such demanding environments as the teenage pocket just suddenly became an Embedded discipline, rather than the monolithic desktop phase. Of course iOS is now an Embedded OS; but OSX pretty much always should have been in the first place, albeit for the hardware gluttony of the 90's and so on. Nobody ever really used every single megabyte, productively, much space out there being maintained by the Desktop OS's is pure fat and cream, all things considered, from an Embedded OS perspective. Oh, you've got a pagefile that a daemon resizes for you if you need it .. luxury! :) But in the embedded world, such a problem as purging unused apps, dealing with power models and load concerns and failover policies, and so on: solved, done deal, decades ago. In the POSIX model, you have all the signals. A well-written program will receive them, know what they mean, and handle them. It takes very little work to set up signal handlers to recieve power events, or RAM-overrun/underuse events, from the kernel. The difference in the Embedded world is, most C-/or Assembly- coders were expected to know it, per the specs of the Embedded Application. Onboard computers for Rail-Transportation, for example, have had an operational - and safety-critical certified - power management model very similar to the way Apple treat the Phone Services, for decades. Most pre-DOS computers had means of managing such things too. My old Magnum Pizzabox would tell me when the LPT lines went high/low, in case the lineprinter drawing current from it was suddenly, actually, on fire. (I kid, but then again, not really..) And now what is happening is Ubuntu is getting an Embedded tattoo, too. An easy thing for Linux; Linux has been Embedded friendly, for a long time. (If you travel anywhere by Rail in Europe, the UAE, Canada, and many other countries, Linux is keeping your train on the track.. and has, for the last 10 years, been running big machines elsewhere, 24/hrs. day, 365, year after year, power on and frequently .. off ..)

BenoitEssiambre 14y ago

Interesting question. That would be a fundamental architectural difference with lots of ramifications. I too would like to know the answer to this.

subway 14y ago

With speedy enough flash, this could be essentially accomplished in the kernel with swap space.

Jach 14y ago

Perhaps Shuttleworth is counting on phones having more than a few gigs of RAM in the near future, making app suspension rather pointless if your concern is memory. (Rather, it is more useful to me in prolonging battery life.)

jeremyjh 14y ago
They are trying to target the low end though.

CJefferson 14y ago

While this is important for memory, it is also really important for battery usage. My experience with Android is that waking every second is enough to kill a phone's battery noticeably faster. I suspect most existing linux apps and frameworks are not good at saving CPU and battery enough to be on a phone. I would be happy to be proved wrong.

Stratoscope 14y ago
> While this is important for memory, it is also really important for memory usage. I think you meant battery usage. (I'll delete this comment to reduce clutter after you edit...)
- Stratoscope 14y ago
  Forgive the added clutter, but I came back to delete my comment as promised and HN wouldn't let me. Ah well... :-)

hobbyist 14y ago

Could you explain what do you mean by a "totally different programming model"? Do you mean the network state with the external server?

codeulike 14y ago
I mean that Android/iOS apps have to listen for 'pause' events and the like, and then pause themselves pronto and save all their state somewhere, and then (if needed) re-inflate themselves and pop back infront of the user as if nothing has happened. The smartphone App lifecycle and way state is managed is pretty different to a general PC application.

ajross 14y ago

This technique already exists in Unix, and has for decades. SIGTERM is easy to deliver, can be caught trivially if needed, and its default action is generally exactly what you want (i.e. it kills the process -- on smartphones software generally needs to be tolerant of an unexpected shutdown anyway due to battery death, etc...). This same argument was had in the MeeGo days. Putting a bunch of junk into the framework APIs to support this is just needless "feel good" complexity around a problem that's already solved. All that's needed is a component to make the decision to kill processes.

codeulike 14y ago
Thats somewhat similar. But iOS and Android apps are built to pause/sleep, which is somewhat different to a kill. A paused Android/iOS app might get killed, but it might also get un-paused, and then it has to carry on (in the users eyes) as if it was never interfered with at all.
- fusiongyro 14y ago
  As it happens, there's also SIGSTOP and SIGCONT. The responsibility to write the app correctly is always going to fall on the app developer. It's just that for phone apps, it's a lot more obvious that you need to. But it doesn't have to be that way, and frameworks to facilitate writing apps like this would be a totally userland proposition, just using traditional Unix signals that are rarely used today.
  - codeulike 14y ago
    Thats interesting. But then my question would be: will the phone be restricted to running apps that behave graciously by handling those signals?
    - fusiongyro 14y ago
      There's no way to know a priori without introducing some pretty onerous restrictions.

primitur 14y ago

I think its important for the non-Embedded people to understand something: there is nothing in the iOS Systems Criticality design which wasn't already figured out, 20 years previously, in the history of computing. Nada. iOS was, essentially, the consumer-computer-OS marketing people finally getting some proper engineering under their skin enough so that they could pretty it up and package it and sell it, $99 a pop, to all the teenager coders. The effort to get OSX and iOS suitable for such demanding environments as the teenage pocket just suddenly became an Embedded discipline, rather than the monolithic desktop phase. Of course iOS is now an Embedded OS; but OSX pretty much always should have been in the first place, albeit for the hardware gluttony of the 90's and so on. Nobody ever really used every single megabyte, productively, much space out there being maintained by the Desktop OS's is pure fat and cream, all things considered, from an Embedded OS perspective. Oh, you've got a pagefile that a daemon resizes for you if you need it .. luxury! :) But in the embedded world, such a problem as purging unused apps, dealing with power models and load concerns and failover policies, and so on: solved, done deal, decades ago. In the POSIX model, you have all the signals. A well-written program will receive them, know what they mean, and handle them. It takes very little work to set up signal handlers to recieve power events, or RAM-overrun/underuse events, from the kernel. The difference in the Embedded world is, most C-/or Assembly- coders were expected to know it, per the specs of the Embedded Application. Onboard computers for Rail-Transportation, for example, have had an operational - and safety-critical certified - power management model very similar to the way Apple treat the Phone Services, for decades. Most pre-DOS computers had means of managing such things too. My old Magnum Pizzabox would tell me when the LPT lines went high/low, in case the lineprinter drawing current from it was suddenly, actually, on fire. (I kid, but then again, not really..) And now what is happening is Ubuntu is getting an Embedded tattoo, too. An easy thing for Linux; Linux has been Embedded friendly, for a long time. (If you travel anywhere by Rail in Europe, the UAE, Canada, and many other countries, Linux is keeping your train on the track.. and has, for the last 10 years, been running big machines elsewhere, 24/hrs. day, 365, year after year, power on and frequently .. off ..)