Promising, but how close is it to being ready for consumer use? If all it can do is make/receive phone calls, SMS, and act as a WiFi hotspot, and cost less than USD$300 that would satisfy my list of desires.
https://wiki.mobian-project.org/doku.php?id=pinephone
How to set up a wifi HotSpot is here: https://wiki.mobian-project.org/doku.php?id=tweaks
Although note, as of now, neither the Pinephone nor the Librem 5 can do MMS (they both share ModemManager and it doesn't have MMS functionality)
are there any recent discussions about debugging MMS on Pinephone I could peruse?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager...
There's a start
The basic debugging workflow is to run ofono, run MMSd, and try the scripts under the `test` directory in MMSd's source tree. Error messages logged from the script, MMSd, or ofono might be relevant.
MMSd (mms parsing, mostly) and ofono (dual-stack IPv4/IPv6 networking) need patching to make MMS work on T-Mobile; other providers might also need debugging or custom patches.
I am very excited to purchase, use and tinker with the Pinephone
I remember the original iPhone not supporting MMS either but that was 13 years ago and I haven't received or sent an MMS since.
An aside: if apple would stop making the new iOS updates so draining on older phones it would help - the last iOS update took my battery from 2.5 days without a charge to 1.7 days “overnight” - imagine what this did to people who didn’t buy the silly oversized model with the lower screeen resolution? It’s basically a malware attack on their users to force them to update
Curious what your solution is for non-cloud backed up 2FA tokens. Phones break, get lost, and get stolen, so backups have to be done somehow.
The cloud is a dumb place to store secrets, as anyone on the planet can attack your secret storage. Almost any offline medium (including a Post-It stuck to your monitor on your desk!) is inherently safer.
There’s really two problems.
1. Speed. The CPUs are just underwhelming. It is not unusable by any means, but it definitely feels like many steps backwards. I think at least the PinePhone needs to be running lighter software; Wayland is certainly not an issue, but a lot of heavy GTK software is probably not a good idea. Web browsing is tricky and makes me wish there existed lightweight browser engines that implemented less of the web standard, but it is actually passable believe it or not.
2. Linux desktop software is just not designed for phones. I think Phosh is clever, and feels very nice to use... until you remember its a phone, and then realize the inherent differences. Normal phones have some kind of central push notification management, but not here. I assume when the device sleeps, you simply stop getting any notifications. I haven’t actually seen a notification pop up on the lockscreen yet, so I’m not sure. There’s an SMS and messaging app, and Telegram/tdesktop works really well, so there is that.
I think that both problems could be solved somehow, but it’s feeling like it could be a tough one. One of the things that both iOS and Android did right off the bat was dramatically change the model of execution that apps had, to orient them around the concept of constantly being swapped in and out. There’s really no obvious way you can support standard Linux desktop apps without some compromise here. I would actually be pretty happy if these devices were capable of just staying awake on a low frequency most of the time, because I think that would dramatically simplify things, but you would have to worry a lot about power draw from apps running and etc in ways that you don’t have to in most modern phones.
Some may view the lack of a good push notification story as a benefit, but for me there are definitely things where I want it to be reliable and timely... so I am left feeling a bit lost.
I did my first "Hello, world" app for it on Mobian on Pinephone, linked below, with that library and that seems to work pretty well.
[1] https://github.com/quietlychris/mobian_hello
Edit: After some prelim testing, it does look like the notification from the example I linked doesn't get pushed to the phone while it's sleeping. Unless there's been a fix pushed in the week or so since I've updated it, looks like that's still a to-do.
Libnotify is for sending notifications to the OS for display. However “push notifications” usually refers to the system that handles the push portion. For example, APNS (Apple Push Notification Service) and FCM (Firebase Cloud Messaging.) Lacking a centralized service both on the OS side and in the cloud, it’s difficult to see how a battery-optimized push notification system could be devised. From my understanding, on today’s phones generally the CPU has to wake up periodically to poll, and if you have many individual push services that would be inefficient. (Maybe iPhone has a more clever system than just waking up the main CPU to poll, I do not know.)
Even the userspace running on the modem can hardly be called completely proprietary. It's some busybox system + bunch of other tools that are also under GPL or other OSS licenses. I didn't measure it exactly, but it wouldn't surprise me if the amount of proprietary code in userspace of the modem is < 20%.
You can't modify the modem firmware and then still legally operate it in public networks under most legal jurisdictions around the world.
Anyway, the original issue was about notifications, and ability to implement them without consuming too much power. And one of ways to do it is to extend the modem this way.
Even if you had many push services, waking up periodically and polling them all at the same time ought to be rather efficient.
GTK by itself is quite light, even GTK3. It's certainly lighter than the Java UX of Android.
The Vivante GPU is also pretty capable: https://social.librem.one/@dos/104218666011152589
Notifications on the lockscreen are planned, just give it some time :)
> I assume when the device sleeps, you simply stop getting any notifications.
That's true, and that's one of the reasons why Librem 5 doesn't utilize suspend yet - the idle times as seen in the article are just that: idle, not sleeping. We could have made integrating suspend in ATF our top priority, but there's still a lot of groundwork needed before it will actually make enough sense. There's plenty of other power management work to focus on first.