Hi folks First of all:
> I also really thing something should be done about this, even if you > create a user override, allowing applications to multitask in the > background. Like you give permissions for applications to use the GPS. > Then the battery life would be the users choice, personally i was looking > for a Linux machine in my pocket that is what got me excited about Ubuntu > Touch, but instead i got smoke an mirrors, i use Linux a lot in my life, > computers make our lives easier when they are working for us 24/7 not only > when we are looking at the screen. Choosing Open Source over closed source > is about freedom, so any choice should be based on user choice not some top > down idea, force onto everyone. > > Lets get this fixed. > I agree with that guy for 100%. Said like God. Now about business - why don't you want to make *an system-wide option* of services availability? User will be able to control it himself! 2015-10-01 15:39 GMT+03:00 Krzysztof Tataradziński <ktatar...@gmail.com>: > Hello, > I want submit only one small note > > 2015-10-01 14:04 GMT+02:00 Thomas Voß <thomas.v...@canonical.com>: > >> Hey Simon, >> >> Thanks for your thoughts and ideas. Please find my suggestions and >> replies inline: >> >> On Thu, Oct 1, 2015 at 1:16 PM, Sturm Flut <sturmf...@lieberbiber.de> >> wrote: >> > Good morning dear list, >> > >> > this has been brewing for quite some time now and the discussion >> > Krzysztof Tataradziński started a week ago didn't lead anywhere again, >> > so I'm starting it yet another time: >> > >> > In my opinion the "no background processing for apps on the phone" >> > design decision is wrong, is already hurting us too much and has to be >> > revoked as soon as possible. >> > >> >> To state this very clearly: We are looking at a continuum of potential >> solutions here. >> It is unfortunately not as simple as just revoking one solution and >> picking another one, but >> all the different objectives have to be balanced. To this end, let me >> clarify some of the guiding >> principles and objectives that have to be accounted for in the context >> of lifecycle policies: >> >> (1.) Battery life: One of the scarcest resources on a mobile device >> and something that we aim >> to protect as much as possible. Allowing arbitrary background >> processing hurts a lot here, with Android's >> lifecycle approach being one of the examples where battery life >> deteriorates and becomes unpredictable >> depending on the apps that have been installed on the device. Now this >> wouldn't be a problem for the >> quite technical audience subscribed to this mailing list. But it is >> certainly an issue for the average user who >> should not be forced to maintain a list of running apps and processes >> just to achieve sensible battery life. >> >> (2.) Security & privacy: One of the worst case examples are apps >> running in the background, feeding on a device's >> sensor data and sending it off to the cloud. There have been numerous >> examples exploiting the issue on Android. >> Again, the technical audience subscribed here would be fine, the >> average user likely is not. >> >> (3.) Predictable performance: A phone is expected to perform whenever >> it is needed to, and the application being front & center >> to the user should provide a smooth and crisp experience. To this end, >> the system has to be able to assign as much performance-relevant >> resources as possible to the currently focused app. If arbitrary >> background processing is allowed, the respective scheduling problem >> becomes >> very very hard to solve (if possible at all). >> >> Please note that there are way more aspects to this problem space than >> just the three points I elaborated on before. >> The key point is: For a technical or tech-savvy audience, the >> lifecycle approach we are taking for the phone might seem overly >> restricted. >> However, for the average user, such a harsh policy comes with a lot of >> benefits. >> > But average users don't want to use phone that is limited in that way. > For now that system is for some technical guys; if we want to target > Ubuntu Touch for larger audience we need provide ability to work apps in > background - why people use smartphones a lot of time? Because they can > track their sports, use their favorite chatting app (and get notifications > from it, even when it's 'closed'), get synced data from cloud, get notify > about attack on their castle in favorite online game, etc. > If we don't allow to do that things in easier way, Ubuntu will don't get > too much big market apps, consequently Ubuntu will don't get too much > non-technical users and that harsh policy wouldn't be useful for any one - > there will be no people to appreciate that harsh policy. > >> >> > Why? Let me make a list of examples. >> > >> > - Open Telegram for Ubuntu, send a picture to a friend, switch to >> > another app or scope. On any other platform the message would continue >> > to be sent in the background, but not on Ubuntu. Now you might say >> > "Telegram is going to become a Telepathy plugin, and that one can run in >> > the background", but there is no sign of a Telepathy system service and >> > even if it were already present, you're now forcing everybody to build >> > Telepathy plugins for their services. That's just not going to happen. >> > Let's be honest, WhatsApp and Viber and friends will not go this way for >> > a number of very good (economic) reasons. >> > >> > - Notifications for the myriads of services out there. On any other >> > platform the app would just register a small background service that >> > wakes up every minute or so and then goes to sleep again. Now you might >> > say "We have the Ubuntu Push Notifications service for that", but that >> > requires the service provider to change his whole server side, which >> > noone except Telegram does. That's why we already have to run >> account-polld. >> > >> >> That's actually not true in the general case. Most often, the services >> use the platform's push notification >> infrastructure to deliver updates. Please note that we require >> account-polld to work around the limitation that >> facebook, twitter and google have not integrated with our infrastructure >> (yet). >> >> > - An app that processes location updates in the background, e.g. a >> > fitness tracker or a navigation app. Now this is IMO the best example >> > for how the "no background processing" decision complicates everything >> > to infinity: The simple solution would be to have a small background >> > service that just does whatever it has to do. But since we can't do >> > that, we have to come up with a very convoluted system that most likely >> > involves registering for some list of events with location-service, >> > which then calls a small handler binary provided by the app (like the >> > push notifications design). But how do you prevent that handler from >> > running amok, or from just keep running in the background? Ah, yeah, >> > kill it after five seconds, like the push notification handlers. But >> > five seconds on a slow CPU aren't much when I e.g. also have to do some >> > I/O and use D-Bus, while five seconds on a fast CPU are a lot of time if >> > I don't have to do much. So what's the right maximum runtime for a >> > handler that covers all use cases? There is none. Will location-service >> > support all the event/filter/callback options I need for my specific >> > app? Most likely not. >> > >> >> It will grant a certain amount of processing time to your app or >> better its location update helper. A fitness tracker could easily just >> store >> the respective update for later processing. A navigation app would >> require more sophisticated schemes, but we are happy to evolve the >> service as required (as pointed out earlier). >> >> > - Cloud and P2P services like Owncloud, Dropbox, Syncthing, Tox etc. >> > Apps that control devices via Bluetooth, like my FitBit or a Smartwatch. >> > What's the design for those? More system services? We can't afford to >> > write a system service for each and every use case. That doesn't scale. >> > It already isn't scaling right now. And even if we could, is the >> > proposed solution really to have 100 system services running for all >> > users, instead of five to ten third party background processes that the >> > user really needs and knowingly installed herself? >> > >> >> We would not write a system service for each of them, but instead >> provide a framework to handle the specific problem area. >> It is a lot of work to get those frameworks right, and your help is >> obviously greatly appreciated in doing so. Other than that, it is >> really really easy >> to integrate cloud services with the content-hub infrastructure and >> thus exposing the content in the system. >> >> > I can come up with many more examples for how this is simply >> > complicating our lives, and for what reason? A (tiny) gain in battery >> > life. >> >> Please see the initial list of objectives and guiding principles. On a >> very personal note, I don't think the aim should be to make "our" life >> easier but >> to make the life of users as pleasant as possible. If that means to >> come up with novel and probably harsh solutions and policies to >> address certain >> problems ... that's what it is. >> >> We have many apps that cannot be built/ported right now because we >> > are waiting for APIs and system services that haven't been coming for a >> > year now and only have to be created because we can't just run in the >> > background. Do we even know if the effect on battery life is really >> > worth it? I challenge you to run e.g. Dekko as a lifecycle exception and >> > check if the background polling is noticeable. Because it's not like >> > those system services don't consume any resources at all, the work has >> > to be done by somebody. A "bad" Telepathy plugin will consume just as >> > much resources as a "bad" background process, the "better" design of >> > using Telepathy alone is not going to prevent this. >> > >> >> They do consume resources, for sure. The point is: A fixed set of >> system services controlled and maintained by us results in predictable >> battery life (modulo bugs). >> The real question is not if battery life would deteriorate for >> allowing a specific app to poll in the background. Instead, the >> question has to target the general behavior of >> the system with arbitrary apps being installed in the system. >> >> > What also really confuses me about this issue is that the "no background >> > processing" approach apparently only applies to mobile devices and >> > confined apps. Isn't that somehow against the whole idea of an Ubuntu >> > that is the same on all devices? >> > >> >> It certainly is not. A lifecycle policy is always specific to a >> device, its resources and even the specific usage scenario. >> With that, allowing multiple apps to run even if not focused in >> desktop-like use-cases is perfectly fine. Even altering the behavior >> in case of a phone being plugged in to a power supply would be perfectly >> fine. >> >> > I would really like to hear all your thoughts on this and how we're >> > going to solve the situation, because we quite frankly have actual >> > problems (broken GPS, no SD card support for apps, no Bluetooth, no SIM >> > Toolkit, etc.) which should have a much higher priority than building >> > convoluted and complex designs just to potentially save three hours of >> > battery life over the course of a week. >> > >> >> As pointed out in my introductory comment: battery life is one of >> multiple concerns we have to address. >> >> Cheers, >> >> Thomas >> >> > cheers, >> > Simon >> > >> > -- >> > Mailing list: https://launchpad.net/~ubuntu-phone >> > Post to : ubuntu-phone@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~ubuntu-phone >> > More help : https://help.launchpad.net/ListHelp >> >> -- >> Mailing list: https://launchpad.net/~ubuntu-phone >> Post to : ubuntu-phone@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp >> > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp > >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
