I enjoy the Pinephone, but it certainly has its issues. I’d kill for better performance; it’s very close to usability. I also have some issues with the hardware (it seems my battery has stopped working entirely, recently.)
On the other hand, there is one confounding software issue that I think makes it the hardest as a full replacement for a modern smartphone: push notifications. An equivalent for APNS or FCM that allows for relatively low power consumption, low latency push notifications would need to be devised, financed and actually adopted. It’s nice to imagine a world where apps on phones are like how apps on desktop are and just keep, for example, active WebSocket connections at all times, but this doesn’t appear to be something practical with current technology.
Maybe federated, E2EE push notifications could come into existence? A sort of ActivityPub of pushes... It’s a pipe dream, but one can hope.
Without mass-market and the scale that comes with it (including returning income from existing users) it's near impossible to provide the same nice UX as an iPhone or a Google-riddled Android phone.
That's the whole problem with most projects and why they neither produce acceptable usability nor a an acceptable price point. It's not that it's not technically possible, it's just infeasible without becoming yet another android vendor.
Even just having an 'alternative OS' on existing hardware is a non-existent market, and those projects try very very hard. Adding the hardware problem in to the mix makes it harder, not easier.
I’m not very concerned with it competing per se; they managed to put out a fairly compelling package and sell through 30k units. Yeah, they won’t be fabbing custom ARM cores any time soon, but it ain’t nothing.
Open source software is a slow burn. It takes time, but projects can grow for a very long time even when things seem dormant, and then suddenly seemingly out of nowhere things are actually pretty good. I certainly was impressed with how well they were able to bring GNOME onto phones so far.
It’ll always work best if people don’t consider them to be on the same level as commercial software; it has a different appeal, but one that should not be discounted. Just as there have been so many “year of the Linux desktops,” so to have there been many incorrect calls about the death of it.
I keep wondering why nobody just supersets Android. Even just having an Android phone which is designed to be repairable and have drivers in the kernel tree so it isn't tied to a specific kernel version, people would pay for that.
And then on top of it you can add all of your Google-alternative libraries and services, which need not be perfect immediately to get people to use it because they can start off running Android apps and buying it for the open hardware. But as you get more users, the software improves too.
> The mass market does not care about repairable hardware or open drivers.
The evidence for this is that people didn't refuse to buy the first generation of unrepairable devices. Because nobody told them they were unrepairable until they broke, and by then they already owned it. And by then the unrepairable devices were all you could get.
How many people would buy a phone if you could honestly market it as lasting for ten years instead of three and having a lower repair cost when you drop it on the concrete?
> Using niche open SoC will make the device slower and/or more expensive. The mass market cares about price and performance.
The mass market doesn't care about performance on mobile devices. They can't even tell the difference. It's all marketing. Even the phones that are actually faster on paper aren't faster in practice when the "slower" one still does everything instantaneously.
Even on the deskstop, linux arguably has a less stable GUI. At least on the desktop you can drop into a CLI and fix things. Even if you don't know what you're doing, you can google your way to a script and copy + paste.
RAM is almost 3 times faster indeed, but it's not the only thing that matters (CPU clock and double the L2 cache, much more powerful GPU, faster eMMC, better thermals). That's not "tighter integration", that hardware is simply more powerful.
Conversations.im does jabber on Android without push notifications. It just leaves an idle TCP socket. I haven't noticed latency issues with that, but I'm not a heavy user
Part of the problem is that Linux desktop apps typically aren't designed to conserve on network usage and/or don't have mechanisms to do so without a push server.
For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Desktop clients, on the other hand, will stay running and receive every message, even if they're not messages that you necessarily care about/that would notify.
The protocol could in theory have an in-band way to tell the server "hey, I really only care about notifications now, could you only send me those?" but currently it doesn't. By contrast, most Android/iOS apps can rely on push notifications and suspend completely when they're not in the foreground - meaning they're not receiving anything but what's important enough to notify about.
> For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification.
Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. If they already added FCM an APNS, they'll have to add something to support a 3rd OS. It could be in-band or out-of-band, but either way sending a message on a TCP connection is really all that is needed.
As a side note, Jabber did add an in-band way as you suggest, but then also had to add OOB signalling because Apple disallows open sockets for background apps.
> Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that.
Yep, it does, so you could do this; the problem for the Linux desktop is just that there isn't a standardized out-of-band push notification system yet. (I saw another commenter mention UnifiedPush, which sounds interesting - in any case it's not widely supported yet.)
> As a side note, Jabber did add an in-band way as you suggest
It's been a while since I looked into this in detail, but IIRC Jabber generally doesn't have a server-side way to determine which messages should notify? As I recall, the protocol was designed with smart clients and dumb servers in mind, though I'm sure some of that has changed over time - but that design decision doesn't lend itself as well to clients on battery-constrained devices.
Although with that said, the fact that you aren't required to be in the same set of MUCs on every device helps in battery-constrained devices; for example I only stay joined to the rooms that my friends are in from my phone, unless I need to join another one temporarily.
Client state indication helps for things like suppressing presence updates, but it doesn't go as far as to e.g. let you only be notified for messages that would highlight you in a large MUC, right? So either you're joined to the MUC and receive all messages in it, or you leave the MUC and don't get notified about any of them.
Although now that I read the spec again, it seems general enough that maybe it could be used to implement behavior like that? I don't think I've seen any servers that do, though.
Prosody has an option for filtering MUC messages with mod_csi_battery_saver (which is the currently recommended community module for CSI), I don't think ejabberd does though.
> groupchat messages must set a subject or have the user’s username or nickname mentioned in the messages (or be encrypted) to count as “important”.
You need to keep the connection alive, which means regular traffic, which means regularly sending data, which needs energy. More connections mean a) more traffic and b) unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself.
The radio is a massive battery draw, so you want it to be off as much as possible. The built-in push notification service will batch low priority packets and send them all alongside the next high priority one it receives.
Mozilla has mobile style push notifications for Firefox and you can just leave eg a mail client running in the background using the IMAP IDLE feature for mail. As long as you restrict that sort of thing to just a couple apps it's fine.
More than push notifications the WiFi firmware needs a feature to whitelist IPs that can wake the phone from sleep so you get instant notifications from services.
On the other hand, there is one confounding software issue that I think makes it the hardest as a full replacement for a modern smartphone: push notifications. An equivalent for APNS or FCM that allows for relatively low power consumption, low latency push notifications would need to be devised, financed and actually adopted. It’s nice to imagine a world where apps on phones are like how apps on desktop are and just keep, for example, active WebSocket connections at all times, but this doesn’t appear to be something practical with current technology.
Maybe federated, E2EE push notifications could come into existence? A sort of ActivityPub of pushes... It’s a pipe dream, but one can hope.