Hacker News Reader

Comment by codeulike | Hacker News Reader

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

View on HN

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.

> 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...)

Forgive the added clutter, but I came back to delete my comment as promised and HN wouldn't let me. Ah well... :-)

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.

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.

If you want presistent state in your GUI app then yes, you have to have that in the app framework. Ubuntu for Phones is using a new (and so-far closed source!) Qt5-based framework, so I can't speak to their choice there. I suspect they've picked something sane, though.

This is, however, a tangent. The ability for an app to persist state and "start" in the last state the user saw has nothing to do with the OS's ability to kill an app to conserve memory. And note again that the requirement for an app to survive an unexpected failure (i.e. you can't expect to have been "paused" -- this is true on Android and iOS too!) is still there, there's nothing that extra layers of API will do to fix that.

> The ability for an app to persist state and "start" in the last state the user saw has nothing to do with the OS's ability to kill an app to conserve memory.

I'd say it does. Pausing apps (as opposed to killing them) is another way of conserving memory, and battery, while preserving usability.

But as you say perhaps Qt5 will handle this. Is the Ubuntu Phone restricted to only running Qt5 apps? I'm not clear on that.

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.

Thats interesting. But then my question would be: will the phone be restricted to running apps that behave graciously by handling those signals?

There's no way to know a priori without introducing some pretty onerous restrictions.

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 ..)

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

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

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.)

They are trying to target the low end though.

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

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.

Reply on news.ycombinator.com