Earlier quoted context omitted.
I never understood why the PinePhone does not ship with Mobian or PostmarketOS instead of Manjaro. Manjaro quickly felt buggy and fragile on the first minutes I tried it, while the two others felt more robust. I'd rather see the PinePhone ship with one of these distributions. Why does Pine64 favor Manjaro so much? What do they gain by doing so?
Personally, I don't get why the focus was on yet another mobile OS variant instead of creating a reasonably open hardware with an AOSP userland first. Users won't buy devices where they can't even be sure that basic functionality works. And for what it's worth, I know Android isn't without its issues - but why not build something on top of at least its Linux kernel and HAL and save so much effort in getting a system…
Pine64’s response to “Why I left Pine64”
51–60 of 109 posts
Re: Pine64’s response to “Why I left Pine64”
#52This is a disappointing response. I don't have a horse in this race (besides wanting to have access to good hardware for FOSS platforms), but I do have my ear on the ground in this community, so here are my thoughts on this. > [removing SPI] was based on the fact that for years SPI was largely unused on PINE64 devices. People have been arguing that a u-boot firmware needs to be installed on that flash chip for years,…
So as is practically stereotypical for the Linux community, we're going to let a squabble over distros send us to buying proprietary hardware and more than likely... straight up giving Google more money, as seems to be the top hardware choice of vendors of so-called "secure Android forks".
Re: Pine64’s response to “Why I left Pine64”
#53Earlier quoted context omitted.
I never understood why the PinePhone does not ship with Mobian or PostmarketOS instead of Manjaro. Manjaro quickly felt buggy and fragile on the first minutes I tried it, while the two others felt more robust. I'd rather see the PinePhone ship with one of these distributions. Why does Pine64 favor Manjaro so much? What do they gain by doing so?
Personally, I don't get why the focus was on yet another mobile OS variant instead of creating a reasonably open hardware with an AOSP userland first. Users won't buy devices where they can't even be sure that basic functionality works. And for what it's worth, I know Android isn't without its issues - but why not build something on top of at least its Linux kernel and HAL and save so much effort in getting a system…
It's terrible in that it's huge piles of inefficient software that can barely run on hardware that's actually pretty powerful.
It's doomed in that as time passes, different FLOSS bits of it get "deprecated" and replaced with something proprietary. Or a new API appears, but Google phones actually ship a slightly better proprietary one.
There's a big conflict of interest when an ad company wanting to spy on people and lock them in is the steward of an open source OS.
EDIT: Also, don't forget that most devices out there use a custom kernel. There's no single "AOSP".
Re: Pine64’s response to “Why I left Pine64”
#54Earlier quoted context omitted.
Because AOSP is controlled by Google and the incentives to develop an actually open platform are not there. Even the SDK to develop for it is guarded by a silly license. That could have been a first step though, but at the risk of endangering the motivation to develop for mobile GNU/Linux and still be dependent of AOSP with nowhere to go when it really goes towards the wrong direction. More and more (essential) compo…
> Even something as essential as the notification system relies on Google's servers and proprietary bits. Agreed, but a notification broker that's usable for more than just "on-device" generation of notifications or wants to avoid every app polling constantly will always need some sort of centralized server infrastructure that costs a lot of money to develop, keep running and secure (something like "user A gets notif…
You don't need a notification broker unless you want to run non-free garbage. Well written apps will just service the socket they get data from just fine. This is already the way things work on Linux, the only thing missing for real time notifications is to have the network interfaces wake the device up instead of relying on eg rtc-wake.
>centralized server infrastructure that costs a lot of money to develop
Maybe but Mozilla seems to get away with doing it for free and they have way less money.
And the higher level comments are right. AOSP is absolute fucking garbage. Before Android 5 it wasn't clear if this was something intentional from Google but it's clear now. They hate people having control over their devices and are in many ways even worse than Apple here despite publishing some code.
>100% purity
Purity will be the only thing that results in success. Already the Pinephone works well enough for people who are used to desktop Linux (sans the hardware issues with the modem.)
Re: Pine64’s response to “Why I left Pine64”
#55Earlier quoted context omitted.
I never understood why the PinePhone does not ship with Mobian or PostmarketOS instead of Manjaro. Manjaro quickly felt buggy and fragile on the first minutes I tried it, while the two others felt more robust. I'd rather see the PinePhone ship with one of these distributions. Why does Pine64 favor Manjaro so much? What do they gain by doing so?
Personally, I don't get why the focus was on yet another mobile OS variant instead of creating a reasonably open hardware with an AOSP userland first. Users won't buy devices where they can't even be sure that basic functionality works. And for what it's worth, I know Android isn't without its issues - but why not build something on top of at least its Linux kernel and HAL and save so much effort in getting a system…
I went from Maemo (Debian based) to AOSP Android when my n900 no longer worked. I've never experienced such a user-hostile platform as Android-- you even have to expend effort just to gain and retain root on a device you nominally own. And, I don't trust anything in the Android ecosystem to not be spying and tracking.
Re: Pine64’s response to “Why I left Pine64”
#56I realize that’s healthy, but the way they’re going about it makes me feel like they’re trying to weasel out of it or something.
I’m left with a mild feeling of disappointment and I’m not sure why.
Re: Pine64’s response to “Why I left Pine64”
#57Earlier quoted context omitted.
About the pinephone pro - DONT. Much of the device still doesn't even work. And we're talking simple stuff like the cameras. Calling is also super sketchy. You can text but voice calls effectively is a fail. The IMU does appear to work correctly, for things like rotation. It is pretty fast. You can also fry your device (hardware damage!) if you get the pinephone keyboard and plug in USBC into the phone port instead o…
The cameras are far from "the simple stuff", it's one of the more complicated systems in mobile devices with multiple high speed components from different vendors that have to work together and not very much documentation for the hardware existing.
My $200 pinephone can, on a good day, do 0.5hz. I dunno, but I expected more.
Re: Pine64’s response to “Why I left Pine64”
#58Earlier quoted context omitted.
> Even something as essential as the notification system relies on Google's servers and proprietary bits. Agreed, but a notification broker that's usable for more than just "on-device" generation of notifications or wants to avoid every app polling constantly will always need some sort of centralized server infrastructure that costs a lot of money to develop, keep running and secure (something like "user A gets notif…
I told myself I'd stay off this site because there's so much distracting crap on here but I need to correct this one. You don't need a notification broker unless you want to run non-free garbage. Well written apps will just service the socket they get data from just fine. This is already the way things work on Linux, the only thing missing for real time notifications is to have the network interfaces wake the device…
> the only thing missing for real time notifications is to have the network interfaces wake the device up instead of relying on eg rtc-wake
Waking the device up for each incoming packet would probably drain the battery. But yeah, I had descent battery life on Android without GApps with mails and two chat apps (Signal and Element) so this can't be impossible to achieve. The modem has to stay up for incoming calls, listening a few additional TCP connections is probably fine. Maybe it's less power efficient than a centralized solution but still very usable. We could also imagine a solution where the used service is configurable.
> Purity will be the only thing that results in success
If you don't enforce 100% open source, you are less incentivized to fix broken stuff and develop open source alternatives.
The "open source but not quite" niche is already fulfilled and it's LineageOS and its friends. That's already done. So nobody loses here.
Re: Pine64’s response to “Why I left Pine64”
#59Earlier quoted context omitted.
> Even something as essential as the notification system relies on Google's servers and proprietary bits. Agreed, but a notification broker that's usable for more than just "on-device" generation of notifications or wants to avoid every app polling constantly will always need some sort of centralized server infrastructure that costs a lot of money to develop, keep running and secure (something like "user A gets notif…
I told myself I'd stay off this site because there's so much distracting crap on here but I need to correct this one. You don't need a notification broker unless you want to run non-free garbage. Well written apps will just service the socket they get data from just fine. This is already the way things work on Linux, the only thing missing for real time notifications is to have the network interfaces wake the device…
Re: Pine64’s response to “Why I left Pine64”
#60Earlier quoted context omitted.
I told myself I'd stay off this site because there's so much distracting crap on here but I need to correct this one. You don't need a notification broker unless you want to run non-free garbage. Well written apps will just service the socket they get data from just fine. This is already the way things work on Linux, the only thing missing for real time notifications is to have the network interfaces wake the device…
Unless I am missing something you need a notification broker due to the very widespread usage of CGNAT on most mobile networks. There has to be a reachable outside server.