This is a big part of why Android was developed in the first place. The operating system and application architecture that makes sense on desktop just doesn't make sense on mobile. Despite the many problems Google's restrictive APIs which you are forced to use can cause for developers, they are also highly optimized for power usage.

▲

jeroenhd 7 hours ago | parent | next [-]

The architecture can work if enough smart people are put to work on it. That's how Apple managed to turn macOS into a mobile operating system.

I think UBPorts and Sailfish prove that Linux for phones is practical if you're willing to rely on Linux applications that stick to mobile friendly APIs.

You need to configure and compile your Linux kernel for aggressive power saving, of course. Seeing how Linux currently struggles to effectively do power management on laptops without S3 sleep, there's plenty of work to be done if you want to use it with a phone.

It's not just about app developers either, Qualcomm's modifications to the Linux kernel are public thanks to GPL but most phone kernel modifications haven't made it into the upstream kernel so far. Projects like postmarketOS are trying to make things better but it's not easy to port practical code that works into code that's acceptable for the maintainers of the broader Linux project.

	▲	gf000 2 hours ago \| parent \| next [-]
		But I mean, why not take the 100s of thousands of man-hours that went into making Android this very Linux-Kernel based mobile OS and build on top? Will you be happy with xeyes and a terminal? Like, even a technically superior solution is completely useless without an ecosystem to make use of it, and desktop GTK/qt apps won't work nicely on mobile without actual porting. Let alone a technically significantly inferior one that is a misfit in this shape for mobile hardware.
	▲	3036e4 5 hours ago \| parent \| prev [-]
		SailfishOS also came (at least back in the day of the first Jolla Phone and Tablet) with an excellent terminal app and built-in sshd that made it work great with pretty much every Linux command-line and TUI application (only exception was of course those with hardcoded minimum screen size support). Termux for Android is maybe half that good, not as well integrated, but still good enough that I use it every day, much more than I use other apps other than the browser.

▲

gf000 2 hours ago | parent | prev | next [-]

I would argue that the legacy OS and app architecture we have on desktop OSs doesn't make sense there, either.

It's a model that worked fine in multi-user setups where you ran a single executable, so that the security per user was meaningful, but today it just sucks.

Android is quite elegant in reusing the Linux kernel's permission system, but on a granularity that actually makes sense (apps are started as separate users, and they just elevated their concept of user a level higher).

▲

blueflow 7 hours ago | parent | prev [-]

Android is also Linux, so Linux isn't the problem - its the userspace. In terms of wakeups, the systemd/dbus desktop architecture is the worst.

▲

jeroenhd 6 hours ago | parent [-]

UBports (the maintained fork of the dead Ubuntu Touch project) runs fine with systemd/upstart/wayland.

Hell, my watch runs Tizen and that's running a bog standard Wayland + PulseAudio + systemd setup: https://docs.tizen.org/platform/porting/system/#systemd

With the right kernel drivers, configuration, and tweaks, with a well-configured userland on top of that, you can run the "normal" Linux stack in a mobile device.

Getting applications to conform with an API that won't let them drain the battery in the background to make sure notifications don't arrive two seconds too late is much harder. Desktop applications don't really like being suspended/resumed the way mobile applications do.

▲

rolandog 5 hours ago | parent [-]

That's quite interesting. How would one go about making one's app or services suspend/resume friendly?

Are there well-known good practices?... Or, do they need to be rediscovered as they are perhaps proprietary know-how?

	▲	gf000 2 hours ago \| parent [-]
		By making a soft and then a hard suspend the reality they have to abide by, or otherwise they are killed and users will think they are broken apps. Mobile apps just had to "grow up" in this environment, plus they have proper APIs for this two-way communication between OS and the app. Android will just ask the app to save its state and then simply unload it from memory (after a while) - but this also makes perfect sense for the desktop scene, you also want to improve energy efficiency there. A spreadsheet app doesn't have to continuously run when it's in the background. You just have to add proper APIs and permissions so that apps can optionally ask for extra background work.