I’m a little jealous of the engineers who get to work on this project. It would be so exciting to build something like this from the ground up, improving it constantly. The challenge, scope, and meaning are compelling, no?
I've worked on smartphone electronics and it's not as exciting as you think. I'm pretty sure they chose the i.MX8 because they couldn't source Snapdragons so they got a little luckier with NXP, but the vast majority of the engineering done on a smartphone is in firmware and software with absolutely shitty support from the manufacturer. Bug fixes that only get distributed to customers after they've ran into the bug and struggled with it for weeks (instead of just putting the bug fix into the BSP), no version control or historical view of vendor drivers or modified kernels, firmware that has "hello world" levels of polish, documentation that is only available under three levels of NDAs, and few open source projects to learn from for what are usually almost-but-not-quite bespoke PCBs. Worst of all, consumer hardware products can sell at such scale that it's worth it to keep an engineer working on a single bug for months at a time only to find out that it was a bug in vendor silicon all along - it is soul crushing. Silicon manufacturers have very little respect for software and it really makes the entire process a lot more painful than it should be.
Iterations in electronics are really expensive (my last project cost $30k for 10 assembled prototypes not including of our labor) so most people just copy as much of the manufacturers' reference design as they need. They pour over PCB layout notes and look at how the manufacturer or other customers did and mostly just copy them. Most of my engineering decisions are based on about a dozen black box helper apps that take in my fab's capabilities and signal specs and spit out DRC rules. It gets a little trickier with antenna design but that's often outsourced because you need very specialized facilities for FCC certification anyway.
All in all, it's just like working on a complex distributed system. There are so many things to juggle like R&D budget, per unit COGS and space budget, suppliers and part availability, and supply chain orchestration that it ends up being lots of boring work just to coordinate between all the different experts involved with small bursts of productivity when everyone is properly aligned.
> I'm pretty sure they chose the i.MX8 because they couldn't source Snapdragons
I'm pretty sure that it was expressly chosen because it's reasonably documented unlike most SoC chips. Not that this solves the expense and effort with iterating hardware, of course.
Back when it was Freescale, I don't remember their documentation being that much better than Qualcomm's. The software support sure was better at first but given the RaspberryPi community size, I think it'd be a wash - although I don't know when LibRem started development. The biggest difference I experienced was that you could download iMX documentation along with all the reference designs without breaking into a Freescale employee's house or proving to one of their account managers that you could sell millions of units.
That is, by far, the thing I loved the most about the i.MX6 design I worked on: it was a high cost low volume board, but we could still get parts from Digikey and just download the reference material off the website. A company like Qualcomm wouldn’t have given us the time of day.
The raspberry pi is based around a graphics chip with a proprietary threadx based operating system. Librem's "software support" standards are high enough (no proprietary software) that this qualifies as worse support than a random Allwinner SoC.
This project feels like how the Pandora project was. It was expensive for it's time, promised to do cool things and then was in suspended animation for years while the world changed. Snapdragons got mainlined. Phones got cheaper. Other Linux phones that worked completely came out.
They should have delayed it and just put in a mainlined snapdragon processor.
Easier said than done. As of few years ago, Qualcomm wouldn'y really talk to you unless you can guarantee at least 100k unit purchase- which gets quite expensive fast at ~30-40$/pc for a mid range SoC.
At the point where we got access to documentation and very basic support, around $1M USD was paid (part of which was covering the initial shipments of chips though).
It's funny you mentioned Pandora actually. I backed the open Pandora and when I first got it, I was severely disappointed. I think I threw it into a desk drawer for a couple of years and I stumbled upon it. When I opened it I was surprised to see it was still an active community and the device was not only usable but actually a joy to use! I used it has a laptop for a long time until a lost it (oops).
That's just reminded me that I also backed the Pandora, waited ages (years?) and then when I got it I had moved on in need, and I was really disappointed in it. I sold mine within days, and the only upside was it was really profitable to do so as they were still in heavy demand at the time.
I thought I'd check on the project while writing this (every now and then I come across something that reminds me of it), and I see that the Preorder FAQ for the Pyra looks exactly like the one that was up for the Pandora for (what seemed like) years!
Ahh sorry! The openpandora was my laptop, it was incrdibly small and worked really well for that. I also had a small USB keyboard i I needed to sit down and type longer.
Yes, only because the reference point is the average of all manufacturers :-)
Last time I checked, they hadn't corrected the documentation of their previous line of SoCs (almost 10 years old), despite acknowledging the errors I reported many ears ago. You can either consider that personal support was good, or that, by not correcting stuff they know is false, they don't give a damn about wasting every other user's time (and wasting the support staff time again and again each time a user will ask the same question).
I also remember using a simple piece of software from them (a GUI for pins assignment, which basically consisted of a list of checkboxes, or some kind of simple spreadsheet if you want): that super basic thing leaked several gigabytes of memory per hour, just idling. Well, I couldn't let it on 1 hour, I had to take the habit to stop and restart it after 15-20 minutes...
I've been around the block in major, Top 10 silicone companies.
The app you talk about was probably developed by some summer intern on a tight schedule and never documented, then someone else took over.
They literally don't give a flying fuck about software. One manager I had once was so clueless, he couldn't understand that the GUI of the C# app I made had no code behind it, and kept asking why clicking the buttons isn't doing anything no matter how many times I tried to explain that a GUI can exist without functionality and it's a separate effort to implement that.
Certain apps we were using internally were based on same Java version from 12 years ago since the person who developed it is now a senior line manager and also the sole maintainer.
Then they brought in some Agile/Scrum consultant to increase efficiency and he implemented 45 minute daily stand-ups with 10 people and half of them remote via phone from another country and then he spent most of the day chasing us around the building asking how soon story X will be done. Then they outsourced the whole thing to Poland.
Working in that industry as a SW developer has been a colossal pain and a huge setback for my career I try to slowly erase from my resume.
I can't believe I forgot to mention the errata! A mentor got so pissed off at Qualcomm one time that he delayed the start of his next contract by a month so he could farm a list of professional electrical engineers working for companies that use Qualcomm chips and developed a relationship with many of them just to create a secret errata sharing network of EEs that were covered under Qualcomm's NDAs. Even a few lawyers at one of the biggest companies who got wind of the idea decided it was worth the risk.
Sadly he passed away before he had the time to really get it off the ground.
I don't know much about that side of the industry so this is only what I've gleamed from mentors and account managers at suppliers: silicon fabrication is extremely conservative and naturally monopolistic because of the sums of money involved and these two factors interact in weird ways. The gross margins on chips are 90%+ but because of the large amounts of upfront capital, they have to strike a balance between derisking the R&D and maximizing profit. Since it is so expensive, demand for specialized chips can only support so many customers per design which limits competition and redesigns are so expensive that clients are locked into their suppliers. The vendors know this and they know that hardware designs are locked in whereas customers have a lot more control over their software so when it comes to derisk the project, investment into software quality is always the first to get cut to the bone. Afterwards, due to that derisking, most of their software engineers spend time chasing bugs in the barebones software and supporting customers so they never get to invest in the software after release before they have to move onto the next product.
This isn't the kind of environment you'd find many passionate software engineers because most of them leave for greener pastures unless they really care about the product they're working on, but they're rarely qualified to run developer experience departments.
Sounds like the silicon fabrication industry is ripe for disruption ala Stripe / Monzo. May be, since you know so much, you should build one. :)
You spoke of the Basebands...that reminded me that Fabrice Bellard works on the other side of the equation [0]. May be, if we are lucky, he turns his attention to fixing mobile phones [1].
I wish! I've actually looked into it and there's lots of interesting work in academia and garages on small scale, low cost silicon fab [1] as well as the electron microscopy necessary to do quality control [2]. Last I checked the state of the art was using regular microscopes with Texas Instruments digital micromirror devices from projectors with basic photoresist and etchant. The DMD reflects light from your light source onto the wafer with the resist and you can control the micromirrors like pixels to only reflect light at the pixels you want to expose the resist. The doping is doable with basic vapor deposition but alignment between steps is brutally hard and the doping requires a lot of tuning and environmental stability to get right so the feature limit is 1 micrometer at best.
I even found a TI 1080p UV DMD and bought a roll of lithographic film to try to get that feature size limit down. My plan was to expose the litho film instead of the wafer directly and build very precise jigs for the film off of a precision machine base I could get for a few grand, with custom built linear motors to move between steps but I got stuck on the physics and math. It looked like I had a solution using neural networks and a DIY laser interferometer as the feedback loop as a shortcut to learning control theory but then got distracted by more urgent matters... c'est la vie
Some very interesting work there, reminds me of Ben Krasnow's lair. You guys should hang out!
I thought the voiceover video for the SEM lithography experiment worked really well ( https://youtu.be/SB94rQtKlKI ). How does the spot size from the SEM compare to the ~1-um resolution you get from the DMD? I assume you're not actually getting 5 nm out of it...?
I've been on silicon side. Because chips are rushed out the door and always behind schedule, and they expect large customers to make 2-3 product lines with it during the chip's lifetime.
It's been a while since I moved up the stack to frontend development so I don't remember most of them but the primary one was the Saturn PCB toolkit [1]. There was one that we used in place of Saturn PCB toolkit that was far easier to automate but I can't find it now. I wrote lots of custom scripts to turn Excel formulas into Altium rules and there were quite a few crappy WinForm apps from fabs.
Edit: Nowadays I only do electronics for personal projects and since I stick to three fabs (a local one one I've got a relationship with and two Chinese specials), I've just got a few manually created DRC templates per fab, # of layers, and max signal speed with a few templates just for RF that I got from a mentor.
That's screen on, though, if you look at the title of the chart. That's probably no worse than my Pixel 3 (which is by no means an endurance athlete, but is probably fairly representative of the Android mass market).
The lack of screen off times in the article is definitely worrying, though. That's just as important a metric.
Edited to add: actually, the first graph is screen off, I think. Looks like it's a tick under 10 hours. Which is poor, so I hope there's more scope for software improvement, but I also think is a fairly significant improvement over where they were 6-12 months ago.
The pinephone recently got a 40% increase in idle battery life to ~100 hours with the modem off and ~24 with it on https://www.pine64.org/2020/07/15/july-updatepmos-ce-pre-ord... (control-f search for "crust"). I would hazard a guess that this might be portable to the Librem 5 (but maybe they already implemented it, IDK).
Edit: but my two sibling comments now seem to have more useful information than this one.
Crust is, simplifying a bit, just something that enables suspend to RAM on Allwinner platforms. From what I know you don't need anything like that on i.MX8MQ, since the SoC and PMIC will already take care of what's needed there by themselves.
Keep in mind that that "idle time" is actually "suspended time" - to handle things like incoming notifications over the Internet you still have to periodically wake up. Without suspend, PinePhone currently has a pretty similar idle power usage to Librem 5's. Once Librem 5 starts utilizing suspend to RAM, it should see a very similar improvement like the one you're linking to.
Crust runs in a RISC cpu inside the Allwinner chip, and it only works in that. I don't know if the NXP chip has a 'dedicated' core to manage the actual ARM cores, but all the work done in Crust won't be portable to the Librem, if it can be done, it'll have to be done from scratch
The key is probably this sentence: "In the future, we are also planning to support suspend to RAM." That is, the CPU is never being fully powered off, only clocked down.
AFAIK, Android uses suspend-to-RAM heavily (this is what a "wakelock" is all about: it prevents Android from suspending when held), and that has a large impact on battery life.
> The key is probably this sentence: "In the future, we are also planning to support suspend to RAM."
A distant future. A Purism employee (who will probably show up here since he takes part in each HN thread related to Purism) said nobody is working on it. So don't hold your breath in the near future.
It's not exactly that "nobody is working on it". There was some initial work on suspend done already, you can flash a different ATF branch and get it to suspend and resume just fine - it's not used by default as currently you have to choose between suspend or DRAM frequency scaling. It's just not the top priority right now, because we're focusing on runtime power management and other promised features like DisplayPort first and there are still some things to do before it actually makes more sense to go back to suspend.
If we worked on suspend instead of runtime PM for the past half a year, we would probably now have 100h+ suspend time that would go down to 2-3h as soon as you kept ssh connection open or did anything else that would prevent it from suspending. Or even actually used the phone.
Also, just being able to suspend is one thing; but there's a ton of work still needed to properly utilize suspend from userspace, so you can still keep things like IM or e-mail notifications working transparently. The less power the phone uses when not suspended, the better - at this moment, suspend would be just a band-aid.
I'm looking forward to your product succeeding, so please don't take this comment antagonistically.
Have you considered how much good press the suspend time got the Pinephone? And how it is one of the key features people talk about - as in, how long the phone will last? And how in these threads people keep asking you about it? And how you could have that good press?
From your comments I worry you are only looking to release such a feature when you've fully implemented every system involving it. I realise this is very easy for me to say from a backseat position, but maybe bump it up the release schedule, and then those that do have librem 5s could at least have a 103 hour tablets that sat in their pockets, not a 5 hour paperweight that sat on their shelves until they wanted to charge it and play with it again. If nothing else, it will completely change the y scale on your bar charts.
I've been very much enjoying the updates around the librem 5 and hope everything goes well for your product.
We have a limited workforce and we have to prioritize. I'll take a reasonably working phone that easily works for a full work day on battery (like the one we have right now) over a phone that sleeps for many hours but burns through the battery fast as soon as you want it to actually do anything.
Focusing on suspend time first may be worth it marketing-wise, but in my personal opinion that would be kinda deceptive.
It needs a full-stack integration to work properly, it's an immense amount of work. The Linux kernel is great at lots of things, but being good at scaling back power usage is not one of them. You'd want to be able to have timers that will wake the machine up form suspension that application developers can use and throttling of radios. The device has to be suspended, but you should still be able to receive calls. MacOS does this impressively well (try pinging your Macbook as it's slowly nodding off, and see the response time increase). Better still, you can ping a macbook over WiFi that's completely suspended - SSH and other services won't work, but the kernel will still be there and do some I/O - this requires some kind of a power-level aware system in the kernel that can coordinate with device drivers and have userspace interfaces for registering applications that might want to receive data when the machine should be suspended. The designwork required to achieve this with Linux and it's ecosystem is far more than the capable but small team at Librem can reasonably achieve, not because the team is small, but because this would require a lot of coordination between different upstreams.
It's definitely a huge amount of work... there are many wrinkles to it, eg, if integrated to the radio firmware, it can do things like wake on specific network traffic and then go back to sleep if it understands the nature of the wake reason only extended to handle that network traffic on the cpu. But then if eg, the ssh session has keepalive enabled, there has to be infrastructure to schedule doing that coupled with another limited-scope wake and go back down afterwards.
Last time I worked on this kind of thing there was great kernelside suspend support that works, but in terms of userland there was no generic linux arrangements for this kind of finegrained management of it.
I also understand the point that for users, atm they just see no ability to defer when they will use the phone while it's still needed to receive calls, which is fatal. It seems properly solving this needs a new, separate userland project somewhere.
> Should I expect the Librem 5 developers to be able to achieve the same thing before they ship Evergreen?
It's unlikely it'll get as good as Samsung or Apple by that time but it should definitely improve. Unless they made some critical mistake in the hardware, they can make continuous improvements in the software.
It's no surprise that this is one of the last things they're focusing on. Idle power management on modern operating systems is hard and is very kernel and hardware specific because kernel interrupt and process scheduling comes into play. Hence why Apple is so good at battery life - they have such unilateral control over the hardware and software stack that they can make optimizations that Linux/Windows/Android really struggle with.
These are the kind of breakdowns I'd like on every phone out there. If they were to publicly release a standardized battery testing procedure with a list of all hardware used for testing, the would make it much easier to compare battery life across phones on the market.
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.
What have you tried? Things should "just work" if you install ofono and MMSd. There are more details (urls, which forks are involved) at https://sr.ht/~anteater/mms-stack/
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.
Not mine. I need anki, authy, a calculator, a good podcast app, an audiobook app, a VPN, security/privacy, and then just a really long battery life.
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
PinePhone has most of those, but if you're insisted on a specific app/brand, you are limiting yourself. For instance, Mobian comes with a 2FA app. Authy is a bad security choice anyways because you shouldn't send your 2FA tokens to a cloud.
Those QR codes are much safer on paper, secured well, than any digital medium that can be hacked.
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.
You are always free not to install the latest update and have the android experience of using an old version OS on a 2 year old phone. On a serious note, I don't think they reduce your battery on purpose, the class action lawsuits Apple lost handled that. It might be just optimising runtime and letting your phone handle new apps? So CPU runs faster and squeezes out more performance?
Yeah, I'm pretty far from being able to switch to a Linux phone without the ability to read TOTP tokens from YubiKeys. For apps that don't support hardware tokens, I store the TOTP seeds on a YubiKey, which prevents malware on the phone from being able to steal my seeds.
I just recently received my PinePhone Braveheart unit, which is by no means a similar device. However, I did try running Mobian, which runs a similar stack (including Librem’s innovative Phosh.) It actually is pretty impressive, and even though it is not aimed at consumer use it is pretty close to being usable as a basic phone with Linux.
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.
[disclaimer: I work for Purism] Having both Librem 5 and PinePhone right in front of me, I'd say that it's RAM speed, not CPU that's underwhelming. Librem 5 feels much snappier to use, even for such tasks as apt-getting over ssh. They have pretty similar CPUs, but Librem 5's RAM is more than twice as fast as PinePhone's and it shows.
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.
Ahh, that does look very impressive. Well, then I certainly look forward to that. The current price point for the Librem 5 (showing up as $750 USD for me now) is a bit more than I’m willing to drop for it though, so I guess I’ll have to really think about this.
I'm not sure I've had that issue with Mobian--I definitely am able to receive phone calls while it's sleeping in the other room, so it's not like there's an inherent inability to push notifications during sleep. I think that using `libnotify-bin` is the recommended library for doing notifications at the moment, although I haven't tested it to see if it pops up during sleep.
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.
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.
Phone calls and text messages are way different than push notifications. The modem is a separate chip on the device that can almost definitely wake up the CPU, and there is, to my knowledge, no such chip for fetching push notifications over the internet. Even if there was, you can verify by hand that apps like tdesktop don’t support any kind of central push notification service from the operating system, so it would be impossible for the device to do anything special; it simply has to be awake for traditional apps to process push notifications.
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.)
You can possibly use the modem itself for monitoring for notifications, even if the main SoC sleeps. And wake the main SoC up from the modem. It would only work over mobile data though.
Modem firmware is, but the Linux running on the modem isn't. It's under GPL. Some people would even like to run mainline Linux there, eventually.
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%.
Sure I can. Modem's firmware is split into two parts. Linux OS running on ARM CPU and modem's modem FW running on hexagon cores. It's possible to modify ARM CPU code without affecting modem's operation much at all. ARM CPU just takes care of some audio/USB and such interfacing tasks. It's laregely free to run your own tasks. The manufacturer even allows customers to build their own userspace code for the ARM CPU inside the modem and extend it this way as part of quectel open linux SDK.
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 this is true, you still need to coordinate all of them to happen at once, so it doesn't obviate the need for an OS-level service to coordinate this at least.
I don't know what your definition of light is, but it just doesn't match mine, and I also actually contest the idea that it is necessarily "less light" than Android UI. They're pretty different beasts, and there's multiple dimensions to "lightweightness." What I do know is that GTK pulls in quite a lot including a CSS engine. You can certainly do UI libraries that use a lot less cycles and RAM.
If I recall correctly, the last thread I saw on this, the biggest hurdle was the sheer size of the device. It looked like it was discovered in a time capsule from the 1990s
It's not a matter of contesting the race to thinness. Here, the stuff is as thick as two not-especially-thin phones; it is reaching the realm of PDAs, except it hasn't got the clamshell and the keyboard.
It is pretty thick, but both my previous phones - Nokia N900 and Openmoko Neo Freerunner - were thicker. Personally the thickness doesn't bother me at all, it feels right in the hand; if I could magically change it without influencing anything else I would rather make the screen smaller.
This phone is an embarrassment. Petty mismanagement https://www.phoronix.com/scan.php?page=news_item&px=Zlatan-T... , subpar products, and breakdowns like this are nice, but you know what's better? Getting a working phone then getting the behind the scenes look rather than 2 unfinished products. It has none of the charm of the n900, at least pinephone is much cheaper, although I don't see a point to a Linux phone when they're mainlining a bunch of snapdragons like the one in the s9, with full network support.
Once postmarketOS succeeds there's little reason to get these Linux phone as devices, and the main reason was good support before postmarketOS ported Linux but the hardware is pretty bad. Poor hardware and poor software for a hefty price, a phone that when sold wasn't even functional and is still rough around the edges.
You’re not wrong that the project has had issues and unforced errors. I’ve felt similar disappointment at the slow progress, misleading statements, and product limitations.
But they’re one of precious few companies with a fighting chance of bringing open software to mobile. For that reason alone, they’re still on the side of the angels in my opinion.
So root for the Pinephone and PostmarketOS, and continue to hold Purism accountable. But if Purism and the Librem have an outside shot at positively contributing to the mobile landscape if given the chance, then entirely-valid criticisms of the company and product should be tempered with that chance in mind.
I would like to think that pine and purism had some effect on the mainlining, but project treble for Google had been thought of separately.
I won't buy their hardware at this rate, but I hope they'll have a good mark on the Linux phone.
You can have it converged with Android and KDE connect already. These problems are absent from pine, so it's not the fact it's a Linux device it's incompetence that causes these issues.
None of the behind the scenes crap, no constant delays and no drama, with way better hardware for a cheaper price. If you want a server in your pocket the pine works for that but so does a cheap Android phone too.
