Oh, and free hardware smartphones and linux distributions for it actually exist since the early days.
For example: http://linuxdevices.org/openmoko-smartphone-reborn-as-hackable-gta04/
For eg as far as I know you cannot trigger for e.g a wake-up from sleep without sudo (using rtcwake for example) and to take the example of the cron jobs, letting an app edit them would allow it to execute anything. This is out of question to allow apps to have such privileges. So it seems a natural way to use an IPC layer that let you talk with services that allow you to perform similar functionalities but in a controlled/sandboxed way like Flatpak is doing.
But I think a modern clean model (common IPC API, secure, sandboxed, signed, permission system, can’t execute arbitrary apps, etc.) can co-exist with the messy “old” desktop model of the 90s that we are currently using (unsecure, edit cron jobs & .bashrc to execute anything, run sudo stuff, execute unsandboxed program outside flatpak, no common api, mess around in the terminal, etc…) if it is enabled only for “advanced users” (a kind of developer mode).
This is just some random thoughts and just my point of view, but I think it is extremely important for Linux OSes to agree on a common IPC API if they want a future because of :
- security : the current desktop model of the 90s is just craziness in terms of security, any apps can access any resources (mic, camera, etc), can execute anything and can access all your files. This model has to die (but as I mentioned we can keep a “developer mode” for programmers where you can execute anything, open a terminal, etc. but for any regular user we don’t want this total lack of security).
And the open-source argument against that is not sufficient. I want Firefox to be sandboxed because it might have a security breach, I want Atom to be sandboxed because it is vulnerable to code injection and because it executes un-trusted add-on from the web which can access anything on my computer, I want Blender to be sandboxed because .blend files I download might contain python scripts which can also do anything, etc. Moreover many people will always use at least some proprietary apps. - simplicity & maintainability : a single versioned spec where everybody (KDE/GNOME/Purism/etc.) can all come together to design and agree on a IPC API. Apps can target a particular version of the API. No more hacky ways to do the same things in a dozens of different ways.
We can tell all soft dev & companies around the world : “On any Linux distro, if you want to access the microphone, you have make these calls over that IPC. Period. End of the story.”.
Currently it’s like “Well on X you can use ALSA and do that call to that library, on Y you can use OSS, oh, but also you should rather use PulseAudio on those distro, oh but wait, some apps rather directly write to /dev/dsp but for that you need root, but then you could also etc. etc. etc. etc…”. Nobody want to write an app for such a mess. - portability / efficiency / future proof : If there is only one common layer, then any improvement we make under that layer will benefit all apps. A change of underlying technology does not affect the apps. If underneath the distro wants to use ALSA, OSS, cron, anacron, etc. it does whatever it wants, but on the surface there is only one well defined IPC layer accessible to the app. And there is only this layer to port if you want to support those apps on another OS/distro.
We can take an analogy : the Web. It is because we have a single common API that we can run the web everywhere, sandboxed and that it is so successful. We can have a single doc (Official Spec, MDN) where dev can just go, look at “microphone” doc and this is the only one way to use it.
And it applies down to all the stack of the web (Physical vs Link vs IP vs Transport vs Application layer). This is why we didn’t have to re-invent the web when we started to use optical fiber instead of copper wire.
We can also look at Android : same story (security, simplicity for developers, etc…) and in terms of portability I suspect it’s not going to be too hard for them to make make android apps compatible with Fushia. All they have to do is expose an IPC layer that implements Binder’s API.
We don’t know what the future will be, but the more we abstract away from the intricacies of the OS the more any work we do will be re-usable and portable.
3 Likes
that’s true ! I hope the Librem will have a more successful fate
Weren’t the arguments by pulseaudo also about unifying into a common API etc.?
I think device access and sandboxing should be solved nicely separated.
(Unix style, small tools doing specific things well.)
In any case, it’s the recent linux kernels that provide the features to sandbox applications.
One example tool that can manage arbitrary applications is firejail. There could be nice defaults to run everything in it’s own firejail.
“Everything is a file” (also sockets and devices) already is a common unix interface with programmers having libs available in every language. I don’t think it is necessary for the librem 5 to mix in another one and attempting to force unification on another level, because the problem will need a broader linux solution.
Hasn’t the web rather become a mess for application building? Based on a plethora of javascript frameworks with all different page/content/resource APIs.
1 Like
Basicly, what I mean is that it could be better to take the time to think about “smaller” solutions that can actually be more universal, than “large” constructions that can be rather self-specific.
2 Likes
I can’t give you concrete answers to your questions at the moment because I am still finding my way around issues like these, but it’s good that you bring them up. Part of my job is to document applications development on the Librem 5, so the corresponding mechanism to the application lifecycle on Android is something I’m aiming to describe.
Earlier phone environments like Qtopia had ways to effectively suspend applications, though this wasn’t based around a cross-platform standard. Again, things like writing applications that don’t just drain the battery is something that needs to be documented (see this issue) and taking advantage of existing frameworks to do this is desirable.
2 Likes
To add to David’s answer, we discussed power management since the early stages of the project. One of the ideas was to use a suspend daemon that would manage applications that don’t need to be running. A different approach we discussed was an equivalent to “connected standby”, because talking to the network cannot be easily suspended.
In the end, there is precedent with the N900, which didn’t sleep at all and still managed 2+ days of battery life. That’s what we’re going to focus on at first: make sure that programs behave nicely, and downclock or turn off hardware when not in use. That should be a solid base for any future improvements anyway.
6 Likes
Thanks for your posts. Sounds like a good approach to me.
Regarding the suspend daemon, there is of course the need of some hardware interrupt line for the powered modem that needs to be present, to allow…
EDIT: …waking up the low-power core of the CPU and…
…triggering the daemon (and for it to decide to wake up individual apps). Not sure if wifi and bluetooth could support to wake up the CPU from suspend.
The gta04 hardware buttons for example are able to wake up the CPU https://lwn.net/Articles/573409/
2 Likes
That’s a correct observation and we’re not getting away with sleep modes without interrupts from communication devices. Thankfully, interrupts are unavoidable to operate both WiFi and the modem.
3 Likes
This definitely would work great for general use cases, but I would like to have the option for application to provide specialized background services. For example, having a video editing application render my video while my phone is charging.
Maybe Flatpak applications could offer a Systemd service that can be run in a restricted environment. It would have it’s own lifecycle so that the phone can turn off the daemon without losing any data.
1 Like
This is already largely a solved problem in mainline linux: SIGSTOP. The default is to let programs run, but it would be pretty easy to create a daemon that manages background programs and suspends them when they are unfocused and idle. Then again, well written programs generally fall into a select/poll/epoll loop and when unfocused should go to consuming ~0 CPU time anyway.
1 Like
I am not sure if SIGSTOP is the right solution. Sure it does freeze the application, but does it also put the application’s memory into the disk?
Using SIGTERM would probably be a much better idea since the developer is able to intercept this call. Still, having a lifecycle that works on top of SIGTERM would make saving data and states much more eaiser.
So the advantage of SIGSTOP is it doesn’t require modifying the application at all, just a quick review of it to see how it behaves. It doesn’t automatically swap out the program’s pages, but proper cgroup setup would mean as soon as the memory is needed for something else, the stopped program will get swapped out. Using SIGTSTP would let an application decline the stop request too.
Note that writing the memory to the disk if the memory is not needed for anything else is the wrong solution.
1 Like
It’s an okay solution for applications that were not designed to run on a mobile device.
With that being said, I still think it is a bad idea to freeze an application without letting the app know. Apps should be able to save data and disconnect from a server/device before it goes into a frozen state.
If an application is taking too long to quit, kill it. That how iOS handles this situation.
1 Like
That’s the reason for the behaviour review. A real time chat application probably wouldn’t like being SIGSTOPed, as it’s network layer will timeout. Then again, a decently written one will put itself to sleep using either recv or poll, so there’s no need to stop it. Meanwhile, a calculator program can be quite safely stopped and resumed when the user switches back to it. Easy general rule is if the program has open network connections, it probably shouldn’t be stopped.
A more advanced system could easily exist via dbus, along side the more primitive version, but that would require the application in question to support it, which means editing and recompiling. Probably worth it for the most commonly used programs, but not feasible for everything.
Killing misbehaving programs is generally a bad idea, unless the user specifically asks to do so. Sometimes misbehaving really means ‘trying hard not to corrupt data’.
2 Likes
I don’t disagree, but it doesn’t seem to be a problem with iOS applications.
Even if an application is well optimized, It should not stay alive if it doesn’t need to stay alive.
I totally understand desktop applications not really caring about moble-like lifecycles. It is fine if they are not interested in support it; with that being said, mobile applications need this. Mobile applications don’t have the same freedom as desktop application and should not be treated as such.
When an application is no longer in view, it means I am not interested in using it. Mobile applications should be aware of this.
iOS applications are written with that sorta in mind, and are derpy as can be to start with. In general, it’s easy if the assumption is the application can’t have anything important because the user doesn’t control it anyway, so just store everything in the cloud. That doesn’t really hold here.
Define need to stay alive. If you kill the application, you have to restart it when the user wants it again. If it’s asleep, it consumes no power. If there is a need for additional free memory, there is a mechanism to politely ask programs to free some, which can prompt them to exit. There’s also zram, and swap files, which can free memory from almost any sleeping program. Obviously, if the application is not going to be used for an extended period, closing it is fine, but it’s better for the user to have a clear way to indicate that, rather than trying to guess.
It’s certainly a good thing to have the mobile applications as energy efficient as possible, it’s a matter of effort required vs marginal reward. The SIGSTOP method will work for probably 90% of energy intensive applications, I use it for power saving with laptops regularly. It even works for a fair number of networked applications, if they can handle a network connection vanishing out from under them, they’ll be fine. If there is an application that’s likely to be open even an hour a day on most L5s, and it neither puts itself to sleep, nor handles SIGSTOP in a sane fashion, it’s probably worth fixing it. If it’s open for 10 minutes a week, and rarely backgrounded, it’s probably not even if it is a mobile exclusive application.
So you don’t want realtime notification from discord/slack/sms whatever, because the application got stopped/killed when you switched away from it? It should stop calculating its screen contents, and it should put itself to sleep via select or similar until a message comes in, but that isn’t the same as completely parking. Note that, if it sleeps properly, it will literally use 0 CPU cycles until the kernel wakes it up to handle a signal or a network message.
4 Likes
This is simply not true for me. Example: get mail. It takes long over slow network. So meanwhile I’d switch over to other applicaiton, or turn the screen off to save battery. I expect that after an hour, when I remember to check my mail again, it will be synced to the poin in time when sync was initiated, not aborted midway because I pushed the power button to turn off the screen.
In general, it is impossible by the OS to know when application is needed or not. This decision should be left to the user.
On my current outdated phone, even browsing takes enough time to warrant switching screen off. Can’t do that because of the rule “out of focus, out of cpu”. Very annoying.
3 Likes
I can still see SIGSTOP leaving holes.
- The GUI code is still going to be in memory. Not all of it is needed in memory.
- If an application uses a lot of memory, you are going to need to hold on to all of that memory.
- The application state probably won’t be save when you try to reset the device.
I don’t agree with you at all with this. Not all iOS applications use the cloud and they can save data just fine.
I never said I didn’t want background services. But if you want your app to support background services, it should be coded as a separate service, not coded into the GUI application.
If you want to push for SIGSTOP, at least give the app the option know that it is going to be SIGSTOPed. It is not enough to determine when an application should SIGSTOP based on their behavior.
Something like nohup for shell applications would be useful too, as there are things like SSH and file transfers I may also want to keep open in the background.