So they included all the hardware requested by Martijn. What remains the rub here?
While they did in the end listen and add SPI _after_ manjaro finally agreed. that doesn't mean they listened to the whole community. Ofcourse PINE64 and Manjaro don't have to deal with how the other distributions boot.
Instead of delaying the PPP production by one day to get U-Boot sorted they decided to not ship mainline U-Boot at all. Which was only possible because Manjaro provided them with an image to ship with that.
In the end the only response there is is a blog post that never claims anything is wrong or should happen differently, after acknowledging all that I've done.
I only wrote why I left, that they themselves think they're manjaro focussed because the hardware that can't ship Linux doesn't ship manjaro doesn't change that this whole behind the scenes situation really burned me out, and I left.
Why does Pine64 favor Manjaro so much? What do they gain by doing so?
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 running? Why do people always have to reinvent the wheel despite it being almost impossible to compete with Android and iPhone anyway, leading to burn-out and failures?
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) components are proprietary and shipped with the GApps. Even something as essential as the notification system relies on Google's servers and proprietary bits (this part has an open source re-implementation though, microG). At this point you need to recompile Android apps to avoid that… if you have access to the source code.
It's hard to fight against this direction, release after release, I think it is a lost battle.
I could live with AOSP today but I'd rather have a functional GNU/Linux environment with no bullshit in a few years.
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 notifications intended for user B" or "attacker manages to dump notifications" must never happen).
> I could live with AOSP today but I'd rather have a functional GNU/Linux environment with no bullshit in a few years.
Same, but as long as people continue bikeshedding and insisting on complete 100% purity every such effort is doomed to fail.
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.)
> 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.
Face reality: most of what the utter majority of the people on this planet use is proprietary and ffs purity bikeshedding won't lead to any success.
> Well written apps will just service the socket they get data from just fine.
The utter majority of providers use CGNAT with extremely short keepalive times for cost saving, the worst I've seen was some crap MVNO dumping connections after ten seconds idling. That means your usual phone will have 20-50 apps that all have to send keepalive data all the time meaning the modem never goes asleep and drains your battery, vs one centralized notification broker that even shoddy MVNOs configure to be exempt from frequent connection drops.
> Already the Pinephone works well enough for people who are used to desktop Linux (sans the hardware issues with the modem.)
So... like what, 3% of users given Desktop Linux market share? LOL the only ones used to Linux on desktop are either forced to do so by their employer or are utter masochists willing to overlook catastrophic flaws for the sake of purity.
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".
It may be less battery efficient than Google's builds but skipping all the spyware really saves a ton of battery.
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.
So I'd argue it makes more sense to first either get a decent alternative OS running on a proprietary piece of hardware (which is almost impossibly hard) or get an open piece of hardware running the only thing that comes close to an open-source OS first (so users will actually buy it because they can actually use it as their daily driver).
It doesn't make any sense for any project without billions of dollars backing it to attempt the 100% purist approach from the beginning. Even Mozilla wasn't able to pull it off, so how and why should anyone else succeed?
Mozilla did not try a purist approach. Their Boot2Gecko was built on AOSP downstream kernels and proprietary drivers. (Then again, there was no such thing as a truly 'purist' device back then, even in non-AOSP land. So they just did what could work at the time.) If you want to explore that kind of approach, there's things like UBPorts and Droidian. They might even make sense, if they end up being able to function as AOSP-compatible Generic System Images (GSI's) and run on mostly any Project Treble-capable device. Make no mistake though, that's a lot harder than doing everything properly in upstream and restricting one's attention to hardware that's compatible with that approach. If only because you're not forced to keep up with churn in the AOSP-native interfaces.
I'm glad you are a part of the community, championing for ease of installation across all distros.
Which other manufacturers provide any feedback channel, or engage with the community during manufacturing?
[1] At least as of a couple of months ago. I'm talking basic functionality being broken, like for example trying to add an icon to the home screen and the phone crashes. I encountered multiple bugs in just the first few minutes of usage.
The original "Why I left Pine64" article adds more info about what went on.