This person doesn't need the core features of a modern smartphone: consistent alarms and reliable connectivity. As such, it is no wonder they love the pinephone: it is essentially a tiny laptop!
That said, I don't find this very compelling: I am in fact called by people and I don't think having to implement a hack around the system's sleep state is acceptable (especially given that it may still not be reliable, what with the dependability profile of the connectivity chipset). It may be more accurate to call this a Pine: Not much of a phone to be found.
> core features of a modern smartphone: consistent alarms
For me personally, this is one thing missing from a modern smartphone. Many old-school GSM phones, when completely turned off (but battery still inside), if there is an alarm programmed, will turn on automatically few seconds before the programmed alarm, just in time to sound on the dot.
Very useful, and exactly what I want, when I go to sleep. You can sort of approximate that with "do not disturb" mode, but that drains a bit of battery (and traffic in cell data plan) uselessly.
On Pinephone, the RTC(has alarm support) is in the SoC and is always powered by PMIC even when the phone is off. PMIC can be configured to power up on interrupt signal, and SoC can be configured to pulldown the interrupt line on RTC alarm.
On Pro RTC is inside PMIC directly.
HW can do it. Alarm app just has to use the HW correctly.
And for non-systemd systems like postmarketOS, there's waked that writes directly to the RTC dev node directly for the same effect. pmos also patches gnome-clocks to use waked.
That's an "interesting" solution, since exactly what waked does is already done by kernel internally if you use timerfd, without the need for any special daemon. Any app that wants to be woken up at certain time can just register a timer for that time with the kernel.
The issue is that it's not possible to create wakeup timers without root or CAP_WAKE_ALARM, hence why you need a more privileged daemon of some sort that your regular alarm clock app binary. Eg with systemd it doesn't let timer units in the user session that can wake the system, which is what is blocking gnome-clocks upstream from using systemd timer units.
But yes, I don't know why waked uses the dev node directly instead of using CLOCK_ALARM, and it's definitely possible it interferes with anything else going through the kernel using CLOCK_ALARM.
No, you're not missing anything. I should've been clearer that I was talking about gnome-clocks specifically, which wants to use systemd both so that only systemd needs the privileges rather than gnome-clocks itself and so that it can autostart gnome-clocks using the timer [1] even if gnome-clocks is down at the time (ie gnome-clocks doesn't itself need to keep the timerfd alive).
I think one reason not to use the timerfd method is that you (waked) could drop the fd if it terminates unexpectedly. There is probably a way to persist the db separately... But the device node is right there.
If waked terminates unexpectedly, it has to be told about all the registered alarms by all apps again after restarting. Apps need to be notified to provide the info again, etc. If waked would keep a database, then you have a syncing problem, between apps and waked, possibility of desynchronization. If app crashes, and doesn't remove alarms from waked, the phone will wakeup, but there will be no app to present the UI. Sounds confusing.
Automatic resource management by kernel when the app crashes or is stopped is actually quite nice. You just restart the app and setup the timers again from the stored settings. You have to store alarms persistently, in any case. You'll get event in the eventloop of the app that registered the timer, etc. Complexity of the solution is minimal. Less opportunity for bugs and failures.
it has to be told about all the registered alarms by all apps again after restarting
Is that true? Or does it just read from the rtc state? (Or leave it alone?) Also for efficiency reasons, don't you want a single wakeup being scheduled rather than potentially spaced out wakeups?
stored settings
Aka a database, right? Albeit a per-user database. What you are talking about sounds more like a service (daemon) than an app, though, from my perspective. A sort of per-user waked. That operates by holding timerfds it negotiated away from a privileged service. You can't revoke FDs anymore/yet, right? Although you can mark them cloexec and go on a killing spree.
I just want the timer to fire and be handled in the process where it's needed, regardless if the system is suspended or not completely transparently. Waked doesn't help with that. I certainly don't want a special daemon that I have to register with over a complicated protocol (d-bus) in addition to having to manage the timers in app when it can be avoided just by passing a single flag to timerfd_create which will work universally and will not depend on systemd.
Spliting alarms into a deamon and UI shell is kinda pointless unless some other app would need access to alarms. But that would be a different service than waked in any case. Waked doesn't handle timers.
Most smartphones do that, it's part of all SoC vendors' base code. However Google Pixels don't do that (which leads to no standard Android API available for that...)
Agreed. In addition my Pine phone needed a heatsink to handle 95+ degree weather. That's in the open air... when sitting in the pocket it radiated a scary amount of heat.
They are a neat gadget. But I don't think they're more or less of a neat gadget than any other Quectel 25(?) based iot device. The phone form factor, for me, was rendered useless.
If you don't use WiFi, try turning the dip switch off. In my case it makes the phone 7-10 deg C cooler (~39 -> ~31). It'll also make your screen brighter; I can lower brightness from 25% to 0% for indoor lighting.
(This is regardless of whether you're connected to a WiFi network or not. ie just disconnecting from a network isn't enough; you have to turn the dip switch off.)
I've not had OP's connectivity issues, so it works pretty well as a phone. Certainly better than my OpenMoko, which kept having audio issues requiring fiddling in /etc/alsa.conf
I agree about alarms; but like OP, I only use them when the phone's plugged in overnight, and hence not suspended. For ad-hoc alarms on the move, I just use my digital watch.
Same here, no problems with connectivity on my PinePhones' (first edition and pro).
Perfectly functional phones with the added advantage of hardly any spyware or other garbage, plus - if I wanna - I can leave it anywhere for an instant reverse tunnel. Handy for many, many things ..
> That said, I don't find this very compelling: I am in fact called by people and I don't think having to implement a hack around the system's sleep state is acceptable
Nobody has to implement hacks. There's a proper solution on Pinephone that can wake/power it on alarm. OP just doesn't know how to do it.
That's an unrealistic expectation of this phone. If you want thinks to just work you shouldn't buy a PinePhone and they make that really clear on their website.
The sale page of the PinePhone says this in red letters[0]:
"Beta Limited Edition PinePhones are aimed solely at early adopters. More specifically, only intend for these units to find their way into the hands of users with extensive Linux experience."
And their wiki has this to say[1]:
"Bear in mind that the software for these smartphones is very early, with most of the software being in alpha or beta state. That's especially also the case for scalability of applications, their availability and practicability, any hardware function implementations and the firmware. The software is provided as is. There is no warranty for the software, not even for merchantability or fitness for a particular purpose."
It just works for me. It may not just work for you if you load your phone with some software that doesn't use the available features fully. But that's not really the problem of the HW itself.
Worse connectivity than the first cell phones from the 90s, worse applications than the first feature phones from the early 2000s, worse performance than the first smartphones from the late 2000s.
As of today there is nothing really redeeming about it. Sure, some tech enthusiast can hack together a GTK application that shows his FOSS conference's schedule, but that's like having a spork in the middle of the amazon forest.
I honestly don’t understand how it can be slower than those feature phones, and yet it is. Sure, bigger screen resolution doesn’t help, but those ran some interpreted Java..
Does pinephones perhaps have some scheduling issues? That’s the only thing I can think of, it either has way too many processes and/or the switching is way too frequent. But linux itself manages it quite well in my experience even on low-end devices so I honestly don’t know.
EDIT: I assume parent does as well, but I definitely meant the non-pro pinephone here. I don’t have the pro one, but that presumably performs better.
It's a SW optimization issue. Pinephone can give smooth experience with optimized software (for example libreELEC/Kodi https://xnux.eu/log/videos/libreelec6.mp4). Typical GNOME desktop is just not optimized for ARM HW from 7 years ago or so. It got better with GTK4, I think.
Those old phones didn't run Java for anything that mattered. The OS itself and all the core apps would be native code. Java - J2ME, usually - was for third-party apps, and it was slow enough that you didn't really see anything "serious" there (e.g. I haven't ever seen a full-fledged J2ME web browser - the most we got was Opera Mini, which did all the layout computations server-side).
Same thing for early PDAs like Symbian and WinCE devices - all software running on those would be native. Well, WinCE got .NET at some point, and it was usable, but that one is fully JIT-compiled.
I have a Pinebook, with the same CPU as the PinePhone, it doesn't seem all that slow when running at the highest frequency, would be interested to know what frequency the PinePhone typically runs at.
I have both (Book & Phone), and AFAIK they both run at 1.15 GHz. I agree that they aren't slow if you adjust workloads and maybe expectations, but seemingly many commenters here (but also on, e.g., YouTube) aren't willing to do that.
I don’t know, my android phone 2 devices before (sony ericcson xperia x10 mini from 2010) was orders of magnitude smoother and faster (with 256MB of RAM!), and it didn’t get scorching hot from simply being turned on.
Honestly, try browsing the web for a few minutes and it gets uncomfortably hot. Actually, I wouldn’t be surprised if some devices (mine included) have buggy hardware more so than the one you got, because I would expect much worse overall opinions otherwise.
And arm is not a new compilation target, so I don’t buy software differences being entirely the culprit, either. Worse battery life? Sure, that would explain it. But having trouble running a terminal and opening settings in 45 seconds is just criminal.
> Honestly, try browsing the web for a few minutes and it gets uncomfortably hot.
I really haven't had that experience in quite a while. I am mostly running DanctNIX or postmarketOS 22.06 with Phosh and browse with Firefox (with uBlock Origin - I also have a second Firefox profile that has NoScript installed for sites that just have too much janky JavaScript) or Epiphany.
It may help that the south of Germany is not super hot (just hot) and that I use Biktorgj's Modem firmware.
Edit, example: I am writing this in Firefox on postmarketOS while having 4 other tabs open and also two more apps (Tootle and Secrets), and the phone isn't even slightly warm.
That's something I really should try to measure. I would guess that it lasts a bit longer than two hours; definitely way longer than my PinePhone Pro. Battery life totally could be better (one coukld also see it as a feature to not mindlessly be on the phone all day), like OP I really hope for a battery case that's not as bulky as the keyboard case.
Yeah, I am reminded of that scene in the Sorkin Steve Jobs movie, where Wozniak is excited to show Jobs his Nixie tube watch until Jobs points out that it looks like a detonator for a bomb
For those not familiar with PinePhone things: This blog post is about an early hardware revision, the Braveheart edition, which has quite a few hardware flaws that have been fixed since (see [1] for details). In particular, I've never seen that Squeekboard issue on my v1.2 and v1.2a revision PinePhones.
Edit:
Also, if you want to follow the topic of GNU-like Linux on mobile hardware, you may like my blog https://linmob.net
If you wonder about apps for postmarketOS, Mobian etc.: I am also maintaining a project that attempts to list them all (and that needs your contribution): https://linuxphoneapps.org
I am happy to see efforts in developing alternative platforms for mobile phones, specially focused on the free philosophy of GNU/Linux but I wish these kind of posts were a bit more down to earth.
I understand that the author is quite happy to have a Linux phone but all of the good parts (even the killer feature emacs) could have been achieved with a LineageOS phone with no Google Apps.
Saying "I am really happy with this purchase!" and then in the same breath mentioning that the battery life is quite bad, connectivity is flaky at best, the phone doesn't wake up from suspend and suspend prevents the alarm from working... it's quite disingenuous.
Different priorities don't make OP disingenuous.
If you want to run a mostly free software stack and Emacs, LineageOS is definitely way worse than PinePhone [1].
Regarding connectivity: This really seems to depend on the hardware revision (OP's braveheart edition was the first available to the general public), the proprietary bits of the modem firmware, your carrier and maybe a bit luck: I am having less connectivity issues on my PinePhone than on my iPhone 13 mini. Seriously.
It's a cool idea and I'd love to be able to use my phone as a full Linux desktop like the Steam Deck.
But ultimately I mainly use my phone for the following:
- Banking and government authentication - e.g. with BankID and Kivra in Sweden. This is necessary to send money, make payments, file taxes, etc. There's no way around it unless you want to deal with going to the few remaining bank branches in person and sending letters. Same for buying and using train + metro tickets.
- WhatsApp - it's massively popular in Europe for communication and even some services. That said it is slowly losing ground to Telegram (and to a lesser extent Signal and Matrix).
- As a camera. Most high-end smartphones have incredible cameras which means you never need to carry a camera with you for most things, this is pretty indisposable too.
And unfortunately none of the GNU/Linux phones come close to solving those use-cases. Desktop convergence is great, but it's not worth giving up all of those. And if I have to carry an Android anyway, then I may as well just use my Steam Deck for the convergence (and gaming).
I wouldn't know about the situation in Sweden, but in other Nordic countries, you can get a little hardware TOTP device for bank and government authentication since they're not comfortable requiring everyone to have a computerized phone. You press a button and it spits out a 6 digit key that you enter.
I realize this may seem backwards to some people, but I think using a hardware key is actually on the forefront of future best security practices. More complicated devices are simply too easy to hack.
I agree about the picture quality, it's just too convenient to have a good-enough camera in my pocket, and I'll suffer with proprietary drivers if that's what it takes right now. I have to ask about banking and government apps, though.
Here most (all?) banks still allow web access with 2FA through SMS or a physical key. Has that been phased out in Sweden? Our e-government services likewise have multiple authentication options, with a phone app, smartcard, USB key or other proprietary dongle serving as the second factor. I'm pretty sure this is implemented according to some EU standards, is this not the case elsewhere?
I actually got a free USB and NFC FIDO 2-certified key as part of a promo, which I use for government services. I know it's not a panacea, but I trust it more than my smartphone.
> ...That said it is slowly losing ground to Telegram (and to a lesser extent Signal and Matrix)...
As an admitted fanboy of matrix, I sure hope it gains more popularity. Not just because i like the protocol and associated technologies, but also because it can represent usage of something not propriatray for citizens. The more big insitutions like banks and gov. services that allow for use of non-propriatary tech stacks means that maybe more people can leverage them for engaging in more digital (and safe) ways. Further, i looke at the wechat model in China, where so much is done over that platform. Now, imagine as much can be done over an open, secure protocol..which if implemented optimally can perhaps in the future allow for phones/mobile devcices to be built still performant but lower cost allowiong for more folks on other side of digital divide to be able to buy and use them...to engage with orgs/insititutions/gov. for their benefit. (Clearly, my wishes here have lots of "ifs" and dependencies...but, hey, i can dream, right?)
I'm actually not opposed to xmpp! I think its actually pretty cool! I do, however, prefer matrix over xmpp, but its very much my own personal preference, and not because one is superior to the other. In fact, i love that matrix.org has a brief, little snippet around this topic: https://matrix.org/faq/#what-is-the-difference-between-matri...
I like the matrix approach of having all features included in the core protocol, instead of xmpp's approach of leveraging extensions...whicuh again is not bad, its simply what i prefer. also i favor matrix's bridging approach, though it has its flaws (for now). Of course, time will tell...and ultimately i favor any technology that empowers users with more privacy and security, and liberty (through choice as well as open sourceness).
Matrix is pretty popular so now it doesn’t make sense not to use that over XMPP. My Q would be why XMPP over Matrix when Matrix is working great in recent times.
Is it that popular? If any provider like WhatsApp decided were to federate (I assume the goal is to get existing providers to federate and not convince every single person of your new protocol) it would essentially make Matrix irrelevant.
And I don't see WhatsApp adopting a custom protocol like Matrix, especially since they already run on fork of ejabberd and XMPP is the established IETF internet standard. The same thing applies to Google, Facebook, Zoom, Jitsi, etc. which all use or have XMPP experience for their chat products.
Some of these have changed their Code so much in relation to XMPP, I’m not sure how much it matter that they use it. FBM never could do XMPP group chats. Not once in its dozen+ year life.
Google and FB purposefully removed federation, so it doesn’t make sense for either of them to add it. So WhatsApp is out.
—
I wasn’t saying WhatsApp or any chat app specifically should implement Matrix natively. I don’t trust big tech. I am saying, Matrix works well enough and isn’t dependent on the whims of big tech.
I got a PinePhone, and I am a major advocate of FOSS. I purchased the phone primarily to monitor linux mobile development as it progresses.
As someone who needs to use maps a lot, this phone is not daily driver ready. It's also a terrible experience for web-browsing and taking photos.
That being said, I love the pinephone, not because of it's usability, but because of potential. SSHing into my phone and having my familiar linux filesystems and programs is a dream come true. It's truly incredible how far they've come with development on the hardware and driver side. The hardest problems are largely solved, and they are shipping devices to the community in hopes of fostering people to work on the remaining software problems and improving performance on the software side. I think Pine64 and the Pinephone's contributions to Linux on mobile are enormous, even if they aren't perfect, and we are better off for having them.
They ship it from Hong Kong with no packaging foam, so it arrived with a broken screen. I contacted them about it and they gave me some trouble shooting things which didn't work and then told me I could pay to ship it to their service center, even though it shipped to me broken. They referred me to their return policy which at the time basically says the buyer assumes risk for the product if they ship it broken (which is a violation of Visa and Mastercard's seller's terms of service)
I then had to fight them for months to get my chargeback, the whole time they were threatening me in childish ways and only after I won (because obviously, I don't know why they thought they had a chance) did they politely offer to pay for a return label.
Horribly run company, if you order from them be sure to use a credit card or something with a chargeback capability
The problem is that this amounts to a fantasy they wish were a thing. You aren't legally allowed to ship products to consumers broken and keep their money.
They have a bright red notice on the product page begging consumers not to order it. Doing it regardless and demanding it to be treated like an ordinary customer interaction makes sure that this approach will be less likely to be repeated in the future.
I do not understand why somebody would do such a thing consciously. We have the situation that somebody wants to distribute the hardware at cost for development. And a big group of people who want exactly this deal. Why is there a need on a personal level to basically sabotage this? Or what am i missing that doesnt make this behavior really dickish?
edit: And again, i am not talking about people who misunderstood what exactly was offered here. That absolutly shouldnt happen. I just dont understand why somebody would do this consciously.
even if what you say is true, it should have been possible to properly wrap the package so that the phone inside doesn't get damaged. that doesn't cost to much. and if they can't cover the risk of damage with money back, they could offer insurance for that instead. i'd gladly pay a bit extra.
Not going to argue on that. I am just very confused by the sentiment of people ordering something as if it was a consumer product despite knowing the only reason they can get one is because they are using the mechanism for developers to get hardware at cost. Which means the obvious solution is stricter screening of who can get one.
Developers can’t use broken hardware. The packaging doesn’t have to be fancy, but it does have to be secure enough that the phone arrives undamaged. Otherwise no development can be done. The OP is not unreasonable for wanting a physically unbroken product, sold at cost or not.
That just brings us back to not properly communicating or understanding the terms of the interaction. If you get it at cost and the shipping company wont cover the damage, somebody will. In this case the recipient will cover shipping to the service center and pine will cover the actual repairs. Thats the deal. Not understanding it is one thing, doing so and demand otherwise later another.
edit: again, not defending their packaging skills here.
The thing is nobody cares whatsoever what they communicate because you just can't legally do that most places. You can write depending on mood box may contain poo, dead rabbits, or live bobcat instead of phone and when you deliver anything but what the user paid for intact and functional their bank is going to take their money back and whomever is taking payments for you may opt to stop doing so if it happens too much.
Ultimately "YOU CAN'T DO THAT" just doesn't mean you CAN do that as long as the letters are big enough bold enough or red enough. It means YOU CAN'T DO THAT.
You cannot offer goods that don't work on a website where you anticipate people paying with their paycal mastercard visa or amex and expect them not to exercise terms that must exist by law because the alternative to someone doing the easy thing and yoinking their money relatively cheaply back over the wire isn't the incompetent OEM keeping the money its waiting for a very expensive lawsuit wherein the customer takes back not only their $99 but the $5000 it cost them to collect their $99. If enough people do that ultimately they ruin you and people come to take all your tinker toys and auction them to pay your debts.
The actual alternative is to have an actual signed contract with prospective "developers" for access to equipment. There isn't a blurb you can put on a website that will serve.
I think the idea is to create a minimum standard of service, so people have the same base expecations. If businesses started selling a lower-priced with zero-guarantees model (which is essentially gambling), it will become a race to the bottom with an abundance of scammers. It would be hard for users to tell if a certain price point means 20% chance of dead-on-arrival, or 80%.
But these issues only occur at scale. As long as PinePhone is able to keep their zero-guarantees model under the radar, maybe it's fine
I absolutely understand the argument when it comes to ordinary commercial interactions. This isnt supposed to be one though. Its the solution to the problem how you can get hardware to developers as cheap as possible. I do not understand why anyone would insert themselves into this interaction.
That’s not an excuse. In fact, smaller hacker shops more often than not provide a better experience than most ‘consumer’ shops; and certainly better than the average massive corporation.
It’s the kind of place you can maybe talk to an actual human.
It’s not the kind of place where you break your Credit Card Merchant’s rules and refuse refunds on items poorly packaged and broken on arrival.
After reading OP’s comment, I will never be ordering from this company, and I was highly considering it.
You can't. That's why I made the distinction between the ethical and aesthetic aspect, and concluded that the GP was most definitely entitled to a refund. Since the legal and financial framework supports this logic as I do, they were able to turn that refund into a reality.
A decent comparison would be wild, ad-hoc music festivals or raves. Nobody deserves to have painful experiences, and such experiences certainly do not have to be a fundamental part of these events. Nor should people be shamed for complaining after the fact. That said, it's also true that you have to approach these things with a certain mindset that's conducive to making the most of it. The comments I'm seeing here don't reflect that, even if I don't disagree with their arguments regarding commercial responsibility.
Shipping companies have pretty explicit limits on liablility unless you declare a higher value (and pay a fee). Of course they won't accept high value fragile items for shipment if they're not packaged adequately, which seems to be the case here.
Why did you order it if you didnt agree with that policy? They warn you on the product page with giant red lettering. Did you not understand it? Or that it is not a consumer product?
Thanks. I am asking because you can (and absolutely should) work on people accidentally ending up in an interaction they werent supposed to be in. Thats a problem you can work on, especially with your feedback about disclaimer fatigue. And having a look now the current order page is indeed quite the clusterfuck. When i ordered it was just one big red line right above order button,
Either way, its something that can be worked on cooperatively. Its in both parties interest that this doesnt happen.
What is a lot harder, and needs additional information about the motivation, is why somebody would consciously engage into this interaction and then demand it to be a different format. Because then it becomes a task of filtering out motivated people.
I understand the frustration if you got into this not understanding what was going on. In which case even more effort needs to be made to make sure such misunderstandings dont occur again. Thats why i am asking where exactly the problem stemmed from.
If i personally send you a prototype at cost and you demand it to be treated like a normal customer interaction the result will be that i wont be sending out prototypes at cost to just anyone any longer. Thats quite the bummer for people who wanted one.
So the question is how can we connect group A (manufacturer) and B(eager testers) without group C(Consumers) getting caught in the whole thing?
edit: Not saying what Pine is doing is good or bad, but the core problem isnt specific to Pine and many tinkerers might end up in this situation one day. And charging above cost is extremely counterproductive in some situations because it locks out some developers.
Again, you're missing the point: there is no amount of clever verbiage that makes it ok to charge someone money to ship them a phone with a broken screen and make that person eat the cost. It doesn't matter if you call it a "prototype" and say "you're not a consumer". It is not ok no matter what language you use.
If you genuinely want people to be prototype/beta testers, give them the phone for free and then ask for it back at the end of the beta period. But the transaction occurring here is, fundamentally, a consumer transaction no matter what Pine wants to call it, and that comes with certain responsibilities which cannot be disclaimed, period.
I am not arguing that you dont have the rights as a consumer. You obviously have.
I confused why somebody would claim them despite knowing that the only reason they can get a device in the first place is because they are ordering something that is not meant to be ordered by consumers. They arent priced in. You used a mechanism and involved yourself into an interaction you werent supposed to be in. Because the fix for the problem at hand is no longer allowing just anyone to get a devkit. Because the whole point is to get the device to developers as cheap as possible.
edit: Or differently put, the problem here isnt that OP got damaged hardware but that he ended up in an interaction he wasnt supposed to be in. And keeping people from accidentally ending up in there is one problem you can work on, but what motivates people to do this consciously?
I think the people arguing the opposite view might have misunderstood the complaint as being about software. I'm sure Pine64 does get complaints about the software not being usable and that's why they have the big red disclaimers. There's no excuse for shipping a broken screen and not fixing it, or issuing a refund, prototype or not.
In a similar position as OP and recognize most of what they're saying.
> Modem: Frequent disconnects, not receiving calls
Something I believe to be observing is that the phone can stay consistently connected for days if stationary but as soon as I take it out for a drive or longer walk I immediately start getting the disconnects, which I so far have only been able to resolve by a full reboot[0). This seems to indicate that switching towers and/or disconnecting triggers it.
> Bluetooth Audio
At this point I'm realizing OP may have a masochistic leaning. But props for pushing and no kink shaming :)
Aside from the modem dying, my biggest pain-point is absent in the post, despite running a fundamentally similar software stack. Ranfomly, audio will not work in calls. Sometimes it's flawless. Sometetimes I can not hear the other side. Sometimes the other side can not hear me. It happens often enough that it's barely worth the hassle to make phone calls if I can avoid it.
Regarding TOTP apps: https://github.com/grumlimited/authenticator-rs is very close to being a nice experience. It's already functional and stable, needs what seems to be mostly a couple of simple UI tweaks.
[0]: There are some pointers that I was not aware of tho, especially the state of baseband firmware; thanks!)
I've had quite a similar experience; having a Pinephone for about 18 months. As the article mentions, many things are nice and familiar when we have a normal Linux stack, like cron jobs, bash scripting, SSH, etc.
I can't actually relate to e.g. the Android comparisons, since prior to my PinePhone I was running Debian on an OpenMoko Freerunner (since 2008, before Android was released!).
The article mentions the "convergence" dongle and keyboard case, both of which I have:
The convergence dongle is a great idea, but I can't quite get it to work. In particular, I can't get power at the same time as peripherals; so any time I'm using a keyboard+mouse+monitor the phone's battery is quickly draining. The USBC connection is also annoyingly loose, compared to another dongle I've got (although that doesn't have power passthrough at all).
The keyboard case is certainly bulky, but I don't mind; and the extra battery life would consistently last all day unplugged. Unfortunately, it stopped charging a while ago, and I'm not sure why; maybe a software update, maybe I blew the charging circuitry by connecting the wrong port (the manual warns not to do this!)
The keyboard is pretty pleasant to use, either hand-held with two thumbs, or "properly" on a flat surface. I've completely disabled the on-screen keyboard, so using the phone feels less claustrophobic. I can't imagine using Emacs with an on-screen keyboard, but with the keyboard case it's great.
The keyboard provides an extra USBC port for charging, which could solve my issue with the convergence dongle: have power plugged into the keyboard, and the dongle+peripherals into the phone. Unfortunately, they don't both work at the same time. Hopefully this could be hacked around in software, but kernel/firmware hacking is still a bit beyond me :(
As for OS: I've been using the supplied Manjaro. I've managed to boot NixOS Mobile on an SD card, but only as far as the TTY login prompt ;)
I hope some day we'll be able to get rid of Apple-Google smartphone duopoly. Free and open-source, privacy-respecting, hacker-oriented software on PCs has been around basically forever, whereas the situation with (mainstream) smartphones is getting worse and worse each year.
Remember being excited with new AOSP features[1], not the "AI-powered", proprietary nonsense Google has been cranking out recently[2]? Remember rooting?
The article mentions using chatty for SMSes which also happens to be an XMPP client, then a few workarounds to get discord and signal on their phone. It's shameless plug time for me, as I'm developing XMPP gateways for both these chat networks as part of my slidge[1] project. The only other user besides me was precisely interested in getting signal support on their pinephone.
I went into this with an open mind, like maybe breaking yourself off your typical smartphone goto's of Apple/Samsung/Google is a more doable experience these days. But I'm a few paragraphs into this and it's already highlighting how everything just seems like hell.
- Lost his SD card with the photos he took the day he got the phone. I haven't lost a photo since I started auto-backing them up with Google Photos in 2014
- Photo of the leaflet which I assume was taken with the PinePhone looks like it's from a 2008 smartphone
- Seemingly case options are so limited he went straight to 3D printing one? Perhaps that was just for fun
- Had to use a glass screen protector made for an iPhone that works good enough but doesn't fit exactly
- The phone shuts down on impact(!!!)
I can't imagine putting up with this for a day before giving up and buying a normal smartphone. I guess if you're really into tinkering and you view these issues as fun problems to be solved it's fine, but I want to think about my phone as little as possible. Someone texts me, I read it, reply, and shut it back down. I don't want to potentially wait through a reboot because I bumped it wrong, or concern myself about photo backups.
The downside to your solution of saving photos is that Google has all of your photos. I'm guessing a lot of people buying a PinePhone don't want that. Here's hoping you never run afoul of a random Google account cancellation.
The PinePhone isn't popular enough for an after-market case and screen protector industry to pop up yet.
But, yes, if all you want is a rock-solid experience with a smart phone, the PinePhone is not (yet?) for you.
> - Lost his SD card with the photos he took the day he got the phone. I haven't lost a photo since I started auto-backing them up with Google Photos in 2014
There are plenty of ways to back up your photos? Syncthing, Nextcloud, rclone, GNOME Online Accounts (Supports Google and Nextcloud). I personally use rclone and it works very well.
> - Photo of the leaflet which I assume was taken with the PinePhone looks like it's from a 2008 smartphone
ok and?
> - Seemingly case options are so limited he went straight to 3D printing one? Perhaps that was just for fun
I seem to recall I got a glass protector with my PP, but I can't recall for sure.
> - The phone shuts down on impact(!!!)
I had a Pixel 3a that hard broke and would no longer turn on after I dropped it. I know someone else that even with gently handling, the Pixel 3a's display just broke. I on the other hand have dropped my PP a few times with only scratches on the surface.
Different things for different people. You could want a FOSS phone. Or better privacy. Or a Linux experience with an ssh shell. Or all three.
Sailfish gives a Linux experience. It is mostly, but not completely, FOSS. It is more privacy oriented than both main platforms from Google and Apple. For me it is a good compromise for now. For you, that might be different.
As i thought this is a question of having a linux on phone, not a political question. My answer is not adequate for political agenda (even if sailfish os is mostly FOSS), but it more than satisfies the technical (having linux on phone).
Actually from all my experience, as a long time rom cooker, who was running angstrom on blueangel, before the android existed, sailfish is our best bet to dethrone google and apple. A small one, but there is at least a chance.
Everything else is lagging too far behind on the verge of useless, as PinePhone has demonstrated.
Just an example, my xperia 10 II phone is running sailfish without any hardware deficiencies, f.i.: bluetooth and fingerprint reader are running fine, working as expected. Battery life is excellent. There are maybe a few android ROM projects that can brag about that and quite frankly they are not very far from the AOSP.
The biggest surprise for me from this article is that the author didn't like Newpipe, which is surprising for me. I know that it breaks every couple of weeks when Youtube changes something to mess with youtube-dl/newpipe/other systems, but usually within a few hours someone has a dev-build out with the fix, and the main branch gets the fix within a day or two, if that even. I actually think their choice of FDroid is what made the experience painful as it does lag behind I've noticed and I guess it conditions you to wait for the update instead of check the issues and pull a temporary apk. (I like newpipe so much that as a reluctant android user, I have second thoughts on going back to iOS since I'm not aware of any newpipe equivalent (happy to be shown otherwise!))
Overall based on the author's commentary I get why they might like something like the PinePhone as it's less about what it is and more what it represents. Hopefully these phones get to a more stable space in some years.
I ordered one a couple of months ago along with the keyboard case.
The phone arrived in a week or two but the keyboard case was the big selling factor for me so I've barely used it while I await the keyboard.
It shipped in June and still hasn't arrived. I contacted support and they said it seems to be wedged in US customs. The tracking number I have only shows China Post info and so I can't really confirm or deny that info. Rather unfortunate...
Then you would want to be able to run Android apps surely? IOS apps are hyper-focused on a limited set of specific hardware produced by a single vendor. Not to mention that Apple sucks to develop for without actually having Apple hardware and Apple operating systems available.
Whatever adware Google is shovelling isn't part of the app your bank provides, so it wouldn't be an issue in the wine-like layer you want. But as other commenters point out, lots of banking apps don't like running in an emulated device.
If you want to use a banking app without Google or Apple dominating your device, look at something which defangs Android like GrapheneOS or LineageOS.
Android apps work quite well already using waydroid. Unfortunate thing about some banking apps is how they go out of their way not to run without play services and safetynet.
I bought a PinePhone hoping to have some sort of freedom from iOS and at the time the threat of scanning all iCloud uploads.
I played with the PinePhone for a few days, but it really is still a development phone. It has promise but it'll be sitting in a box until the ecosystem matures. I'm really hoping more serious work gets done in making it a daily driver for someone like me, who is very technical but doesn't have the time to figure out why the screen stays dim or how to load in a game that works.
Most people who daily drive their Pinephones use Mobian Phosh, whereas the device comes with Manjaro KDE. You may want to try installing Mobian (and it's really simple).
Not sure if there’s any objective measurement for what most people daily driving the PinePhone use - in my personal count postmarketOS (I do hope they stick to stable ;-)) with Sxmo was quite vocal and not rare, followed by Mobian with Phosh and postmarketOS with Phosh.
I'm setting up a static site, looking for inspirations, and was just looking at this blog yesterday to get a feel for it's Haunt theme! It's unique and gorgeous. Interesting comment system too. OTOH, the text is small on mobile and FF Reader Mode doesn't select the main context accurately, missing a portion of the article.
I bought a PineTime, but a month after the warranty expired, it's accelerometer stopped working. It's a shame since I really enjoy having a custom watchface I wrote in c++.
I bought a PinePhone to use just as an SMS gateway‡. My requirements is about as minimal as they come: it needs to stay connected to the cell network, wakeup when a new SMS comes in, and run my little gateway server that is listening for dbus messages. It often fails to do this simple task.
It seems to not do a great job of staying connected to the cell network. And it also often doesn't wakeup for new SMS messages.
I thought buying dedicated hardware that is designed to send and receive SMS would be better than buying a raspberry pi and an lte dongle, but I now regret that decision.
I've not tried to use the PhinePhone as an actual phone, but from the little time I've been forced to interact with it, the UI is basically unusable. Its incredibly slow and unresponsive. Often times it will just lock up for no apparent reason. SSH'ing into the phone has been the only reliable way of interacting with it.
‡ For the handful of services that refuse to work with Google Voice.
I replaced the Pine Phone for similar functions with an IoT router from GL.iNet (unfortunately also using a Quectel). OpenWRT as the OS. TMobile subsidiary as carrier.
It has been marginally more stable though. It has 9 days of uptime so far.
They claim to be getting T-Mob compliance certified. Although I'd check that if it's relevant.
Which OS are you using? Did you try biktorgj's Modem Firmware (and additionally, the various proprietary releases, to see which one works best with your carrier)?
Doesn't matter how good the hardware is if the software can't make it useful for users, which is largely the problem here.
Most of those 'high MP' cameras are also not really useful anymore without an ISP and those aren't available open-source (except perhaps with camera emulation and a fake CSI interface to the application processor cores).
The RK3399 does have a rather limited ISP, not something you'd want to pump 88M in. If you were to use only 1 camera and combine the two ISP nodes it has you'd have a maximum of 26M. This is also why they used a IMX258 as anything better would require to use the second interface for that single camera too.
But to clarify: it's not really as much about "any ISP" as it is about a good ISP that can do multi-camera composition. The ISP in the RockChip SoC can't even do one, it mostly just does basic cropping/rotation/resizing and controls the PHY. While technically an ISP, it's more like an interface driver at this stage. The driver is open source, but the hardware isn't. That's not always a bad thing, as in this case the hardware doesn't run on any RT blob, it's mostly just a bunch of registers for (image) stream processing.
I think in the android rom hacking world, most ISPs are used with their binary blobs (both firmware and kernel modules) but without the configuration and user land blobs, resulting in working cameras (at high pixel counts) but really bad image quality.
RK3399 ISP does much more than cropping/resizing. (It can't do rotation, btw - if it can, I wanna know where you're getting your details from, because that would be very useful :))
IIRC the other operations are only supported on the other linux media framework (of which I can't remember the name - but it's the newer one than v4l2), and most examples I saw (a while back with a RK3399 dev board) were using libcamera at the time.
It does indeed not need firmware, but higher end IPS blocks often do, especially when you get much higher bandwidth sensors per CSI channel.
What I am wondering now about those calibration tools is if however they are built or reverse-engineered, they could read the pre-existing calibration payload.
Whole of ISP uses v4l2. You communicate with ISP by sending specially formatted buffers (C structs docs I posted) via v4l2 buffers (the same interface you'd get image data, too).
Preexisting calibration data are just XML files with params to load to the ISP and params to use to determine which set of params to load based on statistics collected from ISP (like after detecting what kind of light the scene has, you have to load params calibrated for that light type).
(I do rotation via RGA, so maybe you mean that? That's a separate HW block, not part of ISP.)
> Sure sounds like iphone will get there first, pine could beat them to it.
Pine64 doesn't make any of those components. High end components are also generally from manufacturers that don't share documentation, so entirely useless for Pine64's goals.
PinePhone couldn't even create a phone that can make voice calls properly like a Nokia 3310, yet you're envisioning them beating Apple (!) with rolling out some futuristic technologies.
>PinePhone couldn't even create a phone that can make voice calls properly like a Nokia 3310, yet you're envisioning them beating Apple (!) with rolling out some futuristic technologies.
I believe I understand why you feel I am unhinged.
I said, "Sure sounds like iphone will get there first, pine could beat them to it."
Obviously I said iphone will win, I optimistically or enthusiastically said pine could put in the work and get there first.
>having unrealistic expectations may be considered unhinged by some.
I feel like I wasn't being unrealistic at all.
solid state batteries exist today and can be bought. Obviously early in the commercialization but they do exist. Still unclear how safe they are.
88mp camera is less than what I can go buy from costco right now.
3d scanners totally fit in your pocket. I don't mean photogrammetry neither. The newer iphones have lidar that can scan. Newer androids have depth sensors or TOF sensors.
That said, I don't find this very compelling: I am in fact called by people and I don't think having to implement a hack around the system's sleep state is acceptable (especially given that it may still not be reliable, what with the dependability profile of the connectivity chipset). It may be more accurate to call this a Pine: Not much of a phone to be found.