View Single Post
Posts: 3,328 | Thanked: 4,476 times | Joined on May 2011 @ Poland
#8
Originally Posted by olf View Post
All in all I wonder, if the original presumption made in the thread title, "Why do we have iphb in the whole Maemo family" really holds true, as @marmistrz obviously meant to include MeeGo, Mer and SailfishOS in that "family" (although the relationships are weak, e.g. between Diablo and SailfishOS), judging by his last sentence, "edit/clarification: I'm only interested in native apps, not Alien Dalvik."
Maybe the whole confusion just arises from fuzzy (i.e. imprecise) wording.

@all: Is IPhb used in Mer / SailfishOS (as I have not stumbled over anything IPhb related in SailfishOS, yet)?
@marmistrz, do you have any reference (beyond "having heard of")?
Yes, https://build.merproject.org/package...r:core/libiphb

I treat MeeGo as a more average-user-friendly continuation of Maemo and SailfishOS a continuation of MeeGo, hence, by transitivity, SailfishOS a continuation of Maemo.

This statement comes from a private message/e-mail.

Originally Posted by r0kk3rz View Post
What would you propose as an alternative strategy? You want to have good battery life don't you?
A well-written application will either do the work it needs to do or wait at a blocking syscall. This means that as long as all of the applications I'm using are well-written, I don't need to suspend the applications.

A diagnostic tool to find out which applications are battery-hogs plus the possibility to force-suspend the misbehaving ones (as an opt-in; Android Doze is an per-app opt-out which is one of the reasons it's so horrible)

Originally Posted by r0kk3rz View Post
To get good battery life you need to sleep as much as possible, and you can only really do that by being a little aggressive and having the system know exactly what's going on.

iphp/nemo-keepalive is a way to synchronise the wakeups on all the running apps on a system, so maybe apps want to check something on a ~30 second interval they can register such with the system and then get a kick to say 'ok do your thing and tell me when you're done' and all apps will get the same wakeup window.
Agreed. Then, if the application will tolerate a ~5 seconds deviation from the sleep time, it should declare it. The system should not break the applications.

Originally Posted by r0kk3rz View Post
You haven't really described what your issue is with the Android approach, other than use superlatives like 'heretical' and 'awful', so I can't really comment as to whether that applies to the iphb/nemo-keepalive approach or not.
Well, the "heretical" was a little pun, coming from the Android solutions are very often disliked in the Maemo community. I do dislike them too but the heresy is just a hyperbola

The whole idea is, that just as I am the only lord, master and the emperor on my Arch laptop, I expect the same on a phone.

1. On my Linux box an app will (almost) never be killed unless the situation is critical. Usually, if I run out of RAM (i.e. all the buffers get cleared) the system goes so unresponsive that I use the magic sysrq to kill the memory hog.
I expect the same on a phone: no app killing, unless I approve.

2. On my Linux box, an app will not be suspended without my consent. If I'm compiling the kernel and turn off the screen, the device will not stop compiling the kernel because the system is too intelligent.
I expect the same on a phone.

3. The real problem comes when you decide to port a desktop app onto a phone. A correct app will suddenly stop working because the operating system is too intelligent, even if it does nothing wrong.

Originally Posted by olf View Post
mcetool -sdisable
And there was `mcetool -searly`. This should only enable the early-suspend. Do you have any references on what that actually does?

I found this, but it's 8 years old: http://www.thinksrc.com/2010/11/20/suspend-en.html
And this post, claiming that early-suspend was removed: https://plus.google.com/111524780435...ts/RCV8EP3hFEm
__________________
If you want to support my work, you can donate by PayPal or Flattr

Projects no longer actively developed: here
 

The Following 2 Users Say Thank You to marmistrz For This Useful Post: