And GPU buffers? And in-flight network requests? And notification handling? And D-Bus presence? And watchdogs? And other held resources like pids and fds?

This gets brought up several times in this discussion. Hardware with drivers, firmware and device trees exist, see e.g. Fairphone. It even works with open source camera apps (e.g. done in /e/OS). The problem is not (only) the hardware, it is that the Linux desktop stack is wholly unoptimized for phones. And the fact that Meego/Maemo/etc. are now almost two decades ago shows that it is not 'would be easy to solve'. Heck, Linux laptops, which have been available since forever still have far worse battery life than Windows or macOS.

You need a stack that is designed from first principles for phones. Luckily we have one that is open source (AOSP).

Some don't work at all, bc they must be GSF-only I guess (installed via Aurora store). Others like Whatsapp or Signal sort of work but sometimes the app seems to not be running (even though I set up the no battery optimization). And I get multiple unread messages at once when manually starting the app.

Same, they work fine and are immediate. The only exception has been Signal. Must be that I'm using sandboxed Google Play Services?

> Without hardware documentation, you're looking at decades of reverse engineering effort just to get somewhere half as far as an engineer with hardware documentation can get in a weekend.

I'm not sure this is true anymore and it is becoming less true with each new LLM release.

> No one cares about spending a decade reverse engineering the hardware on a Google Pixel or Samsung Galaxy.

Actually, this might a cool idea - just get a few super cheap smartphones, connect them all to a PC, give LLM access and tell it "make linux gud like android pls" and just give it a weekend.

Android is still open enough. Worst case, AOSP can be forked and it will still be leagues ahead of non-Android Linux phones. That also applies to the sovereignty point. I see especially GrapheneOS and /e/OS grow because of this in local communities.

LLM-driven optimization is a good point. However, Linux desktop communities tend to be quite aggressively anti-LLM. E.g. GrapheneOS has been heavily attacked by these people for only using an LLM for security auditing. But maybe these projects will fork into LLM-accepted forks who will then rapidly out-innovate.

I know, but that's a set of libraries. Nothing which can't be done, because the foundation is there. In most basic terms, you need to be able to freeze apps and be able to tell when they have nothing to do, so they can be scheduled with minimal time slices to run a single, lightweight function to check whether they need to do anything at all.

Of course it's more complicated than that, but it's not impossible, since the foundation is already there.