Why I left Pine64
blog.brixit.nl
blog.brixit.nl
After Pine64 went to all the trouble to make a series of branded early developer editions for various distros, and ongoing community goodwill outreaches, I didn't expect something like this to happen.
IMHO, any handheld hardware right now wanting to be open and sustainable Linux should probably start by making sure it's solid with PostmarketOS configured with a mainline kernel, as a good test. (PostmarketOS is a litmus test for purity, and has had a bunch of work to make bringing it up easier than the usual server/desktop purity test of Debian.) Working Phosh and Plasma userlands running atop PostmarketOS are good further tests. Supporting additional distros, userlands, and hacking is also important.
(Even if the hardware is something like the Purism Librem 5, which has invested heavily in lots of good distro work, if PostmarketOS with mainline kernel boots cleanly and runs solidly, that's a good sign.)
While Debian has more strict policies on software licensing etc the musl component of postmarketOS pretty much makes sure that no closed source software will ever run in userspace. The main difference is that postmarketOS does deal with firmware for hardware while Debian doesn't. Hopefully we someday get at a point where even the firmware for these devices isn't problematic anymore.
Some distros, such as alpine Linux, use musl libc as their system wide C library.
glibc is pretty much ubiquitous, so any closed source software will be compiled against glibc and will not work with musl c libraries.
That's not to say a vendor couldn't do a muslc build of a closed source software, just that it's pretty much unheard of.
I believe binary compatibility is a goal of musl, being able to run a glibc binary against a musl libc library, but I think that's a long way off.
So an alternative on a musl libc distro is to use something like flatpak that bundles glibc libraries in a sandbox / container.
The side effect the grandparent comment is referring to, is that you have a good idea all the software on your system is open source, other than what you are running in flatpak, as closed source binaries are unlikely to run on your musl system.
> That's not to say a vendor couldn't do a muslc build of a closed source software, just that it's pretty much unheard of.
The ironic thing is that musl makes it easier to do static binaries, so in a world where glibc wasn't older I would have expected to see more proprietary software compiled against musl (albeit, statically linked so that it didn't really matter).
I fail to understand the reasoning of PINE64 on stuff like this recently. It's like they became a spiritually fundamentally different company. Can't see how this is supposed to make them money either.
> Now I can just focus on making postmarketOS work better. On the PINE64 hardware, and all the many other devices supported by postmarketOS
...Maybe not so terrible after all. For a while there I almost thought pmOS was
luckily postmarketOS existed before the PinePhone and can easily exist after, the pine devices isn't even the majority of devices we support.
I really want them to succeed but I have a hard time making sense of them lately.
Luckily it seems like SHIFT Phones is actually improving the situation, they actually have one of their developers helping out with the kernel development and the device is not terribly hard to get postmarketOS on and I think it'll only get easier to dual boot that device in the future. Sadly the SHIFT 6mq that is supported is also not nearly as cheap as a PinePhone. Hopefully we can get similar levels of support on their cheaper mediatek devices.
Do you think it's realistic to expect the power situation to be(come) better than it is on the PPP today?
A few postmarketOS developers are working on improving the support for the SHIFT hardware and it seems to be going great.
It goes for 655 EUR and has AMOLED, a feature I miss with my FP4. Both are popular smartphones in Germany but Fairphone is more internationally oriented. If you can wait a year you might wanna check the successor Shiftmu [2]
Was more curious about reviews and user experiences.
The whole linux side is just a bit of a mess
See for instance the Allwinner D1 chip.
Running the Pinecil off a Riden bench PSU with a simple DC power plug is rock solid, for comparison.
Here's a similar report by someone else: https://www.reddit.com/r/PINE64official/comments/qq7wv8/pine...
I've seen a few others.
Given the complexities of USB PD, it could also be on the side of the iron and then down to the version of IronOS. The other reporter mentions it works fine with other chargers, but that doesn't speak to correctness/compliance. I did not investigate much since my bench PSU is right below the PinePower on my workbench :)
I will say it generally works nicely with the little USB-C-equipped power delivery breakout boards I use in projects, or MCU boards I've tried. I also park my phone on it a lot. So I am getting use out of it.
https://wiki.pine64.org/wiki/Pinebook_Pro_SPI
Tow-boot releases here:
Expected board: 'pine64-pinebookPro'
Found board: ''
This was my first taste of mobile Linux, and pmOS was easily the best distro I used on it in terms of documentation, install tools, performance, and package selection. pmOS has the advantage of being more mature than other mobile Linux distros, but all the work they've put in over the years has really paid off and helped make the ecosystem more viable, so thank you!
I'm really sad to learn about this with Pine64, I had a hint of this when I saw there has never been a second batch of pinetabs and no communication about it (at least that I saw). I had no idea it was this bad though and this makes zero sense why they would kill the ecosystem they spent so long building. It sounds like the decision was made purely based on reducing user support requests? Even though someone that buys one of these is likely to be a tinkerer/hacker with prior experience with *nix and distros already have their own community support channels and would already be doing most of that work for free?
Improvements and advancements would stagnate due to the 25x duplicated effort, and resources would be lost in keeping those projects happy. Also, any potential user looking to switch would be deluged with options, which is what crippled desktop Linux.
While I do not understand enough about Pine to know why they specifically made the business decision to gut their dev community and go with Manjaro Linux, my guess would be something along the lines of Manjaro's widespread dominance as a top Linux distro backed by a powerful foundation. Pine is pivoting to what they have decided is their future: a full-stack hardware to software open source offering that in their eyes would have a better shot at cracking open the phone market.
They probably were aware of the consequences, but have bet on making it big and creating a new, streamlined ecosystem after extinguishing this one. It remains to be seen if they will succeed.
People keep saying this, like too much effort is a bad thing. But OP makes it clear that there's very little duplication of effort in the Linux-on-phone/mobile/SBC community - most developments are shared community-wide. There are some technical divergences (Alpine/musl vs. glibc- and init-based systems for example) that can impact direct compatibility, but they're very minor.
they "sell" it as "25x duplicated effort" but in reality, there's 25x little tweaks to a build system, that give thousands of people zero effort to port their known platform right away. Now those thousands of people will have REAL effort to adapt their knowledge and existing ways to fit that one holy way enforced by the device true owners.
In reality it is "25x places where i will have to hide my plan for monetize this". Just like most other projects, greed always destroy everything the community help build in good will.
This is not a zero sum game: I believe we can have both an OSS approach to Linux while at the same time having a channel of commercial development that brings more adoption (and fun, hackable devices!). This "one holy way" and the multitude of community-based distros can coexist, in the same way that commercial software companies and OSS communities have already learned to.
These issues crop up on bleeding-edge hardware due to different distros running differently-timed versions of the same underlying components. They fade away over time as software versions start supporting the formerly-bleeding-edge hardware across the board, and the issues invariably shift to the next bleeding-edge hardware release. This is not an immutable fact about the ecosystem, it's a consequence of wanting something to function before it's fully ready for serious use.
* OS 1 finds a bug in Gnome, reports it and perhaps fixes it
* OS 2 benefits from pulling in the new code as well, fixing bugs
* OS 3 writes a driver for the camera and publishes it as part of their kernel
* OS 4 finds a bug in the camera driver they started using, publishes their fix
Yes, there's some overheard to running 25 projects. There's also a huge downfall to excluding 24 projects from contributing as first class members of the project. To boot, it's also a situation where the more contributions make the fixes contributed even more battle tested and beneficial.
tl;dr - OSS development styles don't map onto commercial development styles cleanly
Commercial development allows you to afford to control the hardware, make deals with other companies, and pay people to build compatibility with your system (i.e. Nvidia), which is what Microsoft and Apple did to keep their position. Server distros like Debian, Ubuntu, and Redhat already have deep foundational and corporate backing, and are a joy to use.
There are definitely drawbacks such as vendor lock-in and all the issues that come with corporate vs community control of the software. However, I believe having a single center of development and revenue (to pay for the development), while at the same time having fully open source software and hardware is possible and would have a huge impact.
At the same time we have companies like pine, who seem to support FOSS through relatively open hardware, but which to me seem increasingly more about a way to make a profit of the FOSS trend by using volunteer work without any investment from their end. I question if they are actually interested in their devices actually being functional for regular use. See also this article: https://news.ycombinator.com/item?id=32330043
Finally we have distributions like Manjaro who seem more interested in growing their slice of the pie at the cost of other distributions instead of growing the whole Linux ecosystem. https://www.reddit.com/r/linux/comments/hxpj87/change_in_man...
>> It seems the large corporations like FANGs are largely pushing OSS to use volunteer work to make software a commodity
Why would you expect them to do anything different? Companies are driven by profit, not some sense of morality. OSS licenses allow them, even encourage them, to trade volunteer (aka free) labor in return for source code availability.
>> which to me seem increasingly more about a way to make a profit of the FOSS trend by using volunteer work without any investment from their end.
There's often serious investment from their end, but that's irrelevant. They absolutely want to leverage FOSS to make a profit. And that's explicitly allowed by OSS licenses.
To put it another way, your disillusionment is because of a "bug" on your end, not on theirs. They are behaving exactly as OSS is designed. Your _expectation_ of their behavior is inaccurate, and so does not match reality. Not surpisingly this makes you sad :(
> >> It seems the large corporations like FANGs are largely pushing OSS to use volunteer work to make software a commodity
> Why would you expect them to do anything different? Companies are driven by profit, not some sense of morality. OSS licenses allow them, even encourage them, to trade volunteer (aka free) labor in return for source code availability.
Apart from the fact that companies and corporations can act ethically despite driven by profits, I did not say I'm desillusioned with the corporations, but the FOSS community. Essentially it is us as users&developers who let this happen.
> >> which to me seem increasingly more about a way to make a profit of the FOSS trend by using volunteer work without any investment from their end.
> There's often serious investment from their end, but that's irrelevant. They absolutely want to leverage FOSS to make a profit. And that's explicitly allowed by OSS licenses.
Again I don't say that companies shouldn't make a profit, but when OSS started to become more mainstream many (including myself) believed that it would be a way to break the stranglehold of large monopolistic corporations on the software world and create an ecosystem of relatively small software companies that would customise OSS software for specific needs on a relatively even playing field. Instead what happened is that OSS might have accelerated the concentration of the software world, by making small jobs essentially unviable.
Regarding investment, I expect that FANGs still very much come out on top, just imagine what they had to pay in licencing cost for their datacentres if no oss operating systems existed. Also much of these investments are towards use cases with very little benefit for normal users.
> To put it another way, your disillusionment is because of a "bug" on your end, not on theirs. They are behaving exactly as OSS is designed. Your _expectation_ of their behavior is inaccurate, and so does not match reality. Not surpisingly this makes you sad :(
I think you misunderstand me, my disillusionment is with the idea what FOSS could have achieved (and people imagined) but didn't. I sometimes wonder if FOSS has made the world a better place, like many hoped it would. You might not care about it but I do.
Also, everyone wants to see "their struggle" as being "good for humanity" - but it's demonstrably false when it comes to FOSS software. All it's done has enabled our current tech monopolies to be built on the backs of free labor, enabled negative social effects, and led to our current digital panopticon. It's also skewed the labor market terribly because of network effects - there are comments on here where people left developing medical software to go sling javascript. Basically that's enabled by cheap, ubiquitous computing enabled by FOSS software.
Also, FOSS eases not only our current dystopian digital panopticon (adtech, tracking, biometric feature tracing) and it's meant to look like "fun work I do for free!" but what it really is, is Palantir getting an infinite supply of labor and code for nothing (and all other tech monopolists). Basically the entire FOSS movement plays into it and doesn't seem to recognize it. "Good for humanity"? The opposite.
In the long and the short, FOSS is not only not "good for humanity" - it's objectively bad for humanity, imo.
I'm intrigued enough to ask how you think users and developers could have stopped it? Or, indeed why you would want it to? The success of OSS I would contend is _because_ of large company adoption.
>> I think you misunderstand me,
I did, although I'm not sure my misunderstanding changes my point. Your clarification though is helpful to narrowing the question.
>> Regarding investment, I expect that FANGs still very much come out on top,
Naturally. But you're selecting for companies that are successful. Compared to the millions of failed startups who added precisely zero to OSS.
>> just imagine what they had to pay in licencing cost for their datacentres if no oss operating systems existed.
Who would they have to pay? MS I guess. Maybe Sun? And that's an improvement because...?
I mean, sure, they get their OS for free. But the so do you and me. This lowers the barrier to entry for everyone. I can run the same OS as Netflix, at no cost, so that's one step towards a Netflix killer. On the other hand what Netflix does is OS neutral. Their value isn't the OS, its above it.
>> Also much of these investments are towards use cases with very little benefit for normal users.
They naturally spend their money improving things that matter to them. I'm not sure I agree about the benefit through. Comparing the Linux of today with 15 years ago, I would argue that the standard has increased immeasurably so I would say a net gain for all of us.
Or take mozillla, which is mostly funded by Google. Yes, they fund for a reason, but Firefox is a net gain.
>> but when OSS started to become more mainstream many (including myself) believed that it would be a way to break the stranglehold of large monopolistic corporations on the software world
I think we're getting to the heart of your complaint here. And I feel like my original reply applies here as well.
Firstly I'm not sure that large companies have a stranglehold on software at all. There are more small companies, or individuals, creating software now than there ever were before. When I started out, to sell software, first you had to sell a computer (I kid you not.) Actually, first you had to _buy_ a computer, and they were a Lot more expensive then (in raw $, no inflation adjustment required.)
Actually we also had to buy DOS, (which was peanuts compared to Unix), and developer tools also cost real money. Getting started as a developer was expensive.
Today its completely different. OSS provides a free OS, free developer tools, free documentation, and all on hardware you can buy for <$100.
>> and create an ecosystem of relatively small software companies that would customise OSS software for specific needs on a relatively even playing field.
It's not a zero sum game, far from it. Companies customising OSS exist (but you can't really grow doing that). Lots more companies are building their own software using OSS tools etc. My own software benefits from things like CEF (thanks Google).
Their success is not your problem. Because their secret sauce is not software. The playing field _is_ level. 99% of programmers do not work for a FAANG.
Your hope for relatively small companies exist everywhere, but you've not heard of them all precisely because they are small.
>> what FOSS could have achieved (and people imagined) but didn't. I sometimes wonder if FOSS has made the world a better place, like many hoped it would.
So let me say this. You should not be disillusioned. FOSS has immesurably made the world better. It touches all our lives every day, whether we know it or not.
It is the nature of successful companies to grow. OSS cannot somehow prevent that. Nor should it. Nor should we look to them as saviours and expect them somehow to fund us.
IBM, Sun, DEC, HP, Microsoft, Oracle - all behemoths from the past (not included in FAANG). Today's giants are tomorrow's legacy companies.
OSS _has_ made the world a better place. But then again so has paid software. Software is a net good. Hardware is forever getting cheaper.
So I'll return to my point. I'm not sure that your disappointment is a function of FOSS failure, but rather a misunderstanding of what Foss set out to, and ultimately achieved.
Celebrate it not for what it might have been, but rather for what it is - because what it is, is pretty great.
[I noticed the stump of the pine tree, which apparently was cut down after a fire, in the picture at the head of this article--maybe why the author left Pine64? :)]
Ubuntu would not survive a day without it.
Corporations has been coopting Free Software for two decades by opposing GPL, calling it Open Source and essentially turning it into unpaid labor.
Yet community-driven FOSS is still possible and thriving around things like mastodon.
Remember to use a license that protects your contributions, your community and your users.
I'm left feeling like there is not a good way to align incentives for a world-changing project like Pine. It's really disappointing to read. I just yesterday setup my PinePhone with postmarketOS, and the sd card setup was so easy, and it is frustrating to hear there is absolute uncertainty about whether that be the case with future devices.
As a customer with three Pine devices (tablet, phone and watch), I'll definitely be writing to Pine and asking them to clarify what they as a company say about this post. Thanks for writing it up.
Please let us know what they say.
The Librem 5 eMMC contains a hidden "partition", which is preferred by the CPU to boot from over the "data partition" where the OS boot loader resides. It should be possible to put Tow-boot into this hidden area, and the OS stored in the data area will have no say. No separate flash chip needed to have an independent boot loader.
I wonder why the PinePhone needs a separate chip for this purpose. Is the CPU unaware of hidden areas on the eMMC?
The pinebook pro batch that has shipped now did not end up with Tow-Boot and instead has BSP u-boot on the eMMC which makes it unable to boot anything else than the shipped manjaro by default. Of course it's only the other distributions supporting this platform that have to deal with this
What about their new PineBook Pro, though? Is that situation still in flux?
> The issue with that is it's really easily wiped or changed when installing an OS.
I'm not really seeing this. If the OS supports this special scheme, they need only deal with the soft block device that's created by mapping "the rest" of the partition. And if they don't, then all bets are off anyway.
For the wiping issue, a lot of times I see suggestions to wipe the first few MB of the storage when there's booting and flashing issues to get rid of an old U-Boot, which is exactly what you don't want in the Tow-Boot case.
U-Boot is GPL. How is this possible?
This is sobering and saddening. I have a Pinebook Pro too and Manjaro is pushed heavily. Manjaro is just not a very good distribution and their security awareness is wanting, but even if they were the best of the best, the fact that they get special preference flies in the face of a FOSS phone. I don't know why Pine doesn't see this, what they were doing with community editions was golden!
I think Pine has their eyes on market capitalization at this point with Purism floundering, they probably think they can capture the niche. It's sad to see the shift. Hopefully they can course correct.
Uh, excuse me? It's user-friendly Arch; i.e., the best distribution.
>their security awareness is wanting
Admittedly, I don't know what this refers to or compared to what distro.
EDIT: https://news.ycombinator.com/item?id=32503090 Ah, lol.
Anecdata for my weak defense: I used Manjaro for years, and none of the problems there affected me.
What you see as a thriving community, others might see as a fragmented market. I don't know if this makes sense, but it feels like the multiple distributions and overlapping projects trades off deep development for broad development.
Maybe it's the inevitable result of everybody scratching their own itch and doing what they can do, or maybe it's a sign of a community that can't work together.
When you destroy the nest for these dev groups, there will be no more software for a fancy distro to package.
So uneducated outside views matter more than the communities themselves?
> multiple distributions and overlapping projects trades off deep development for broad development
So volunteers are supposed to - I don't know - know better, stop working on what they want to work on, and coordinate? And it's the fault of these volunteers that there's "fragmentation"?
You think this is a zero-sum game, and that volunteers are the equivalent of workers at a business who're dividing their energy amongst competing projects instead of working together. That's both incredibly naive of you and also incredibly presumptuous.
On the other hand, there is the problem that work in one project can and should be usable in another, but when that doesn't happen, that's just because that's how the Linux communities are sometimes.
> Manjaro Linux has been largely absent from these efforts.
> In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken versions of software and pointing to the developers for support. Which is why https://dont-ship.it/ was started.
Other distributions like Mobian and Ubuntu Touch are miles ahead that broken thing that Pine chose to adopt as their default distro.
When I got my PinePhone, nothing was working, not even the home screen! So I looked for help on the forums and people were like "LOL no one uses that, just install Mobian or Ubuntu Touch". I tried both, and they were actually pretty OK, I could more or less daily drive the PinePhone!
I think the main reason people repeat that the PinePhone is not ready for use as a daily driver, is that the default distro is completely broken. Pine64 are shooting themselves in the foot in a spectacular way.
I really like Manjaro - on my desktop. So initially I was very happy that they went with it, but since manjaro is desktop focused - it is a great mystery WHY the choosed it at all and not indeed went with Mobian and co?
yes, I really don't understand why they chose to ship that half-baked mess. I get it, PinePhone is for "techies" and the average user knows how to change distro, but the default should be functional. System 76 or Purism laptops don't come with broken distros ¯\_(ツ)_/¯
One of the biggest challenges in running an open source hardware project like this is catering to two very different audiences: The majority of your customers (99.9% or more) just want the hardware to get up and running quickly so they can get to their specific need or application. They don’t want to have to read endless IRC or Discord backlogs to figure out the current best distribution to use or read potentially outdated half-finished Wiki articles describing the tradeoffs of various distros. They want it to work and to get started quickly.
The open-source developers have an entirely different set of desires, preferring endless tinkering with the internals and actually enjoying the process of trying different distributions, building and testing bleeding-edge board support software themselves, playing in someone’s experimental fit branch to get one thing working, and other time-consuming activities relayed to the board itself.
If you let a project cater too much to the developer community at the expense of the 99.9% customers, it starts to become a huge problem.
For the best example, consider the huge success of the Raspberry Pi and their Raspberry Pi OS, while even the biggest competitors (such as PINE64) remain relegated to mostly obscurity. The hard truth is that if you want to make a product like this successful and mainstream, you need to narrow the focus and be ruthless about cutting costs, simplifying, and getting your users up and running with one easy, primary way to get started. I have several Pine64 products and they all suffer massively from the fragmentation and compromises they’ve made. Fun if you’re a kernel developer who spends tens of hours every week keeping up with your friends in the small developer community. Not fun at all if you just wanted to use the product for something and you realize you could spend weeks or months sorting through all of the disparate information sources and developer communities before you can have the product working enough to get started on that thing you actually wanted to build with it.
Contrast this with the Raspberry Pi organization, which has seen massive success by having an uncompromising stance on simplicity and focus, even if the ideological purity of the project isn’t up to certain people’s standards. Like it or not, it’s what made them successful while projects like Pine64 continue to be niche products that require a lot of work and research to use.
And even then, it's only one of the complaints, and this isn't the only places I see backlash against pines treatment of the dev community - again for a company that relies on said community for a lot of software work across their products. My impression is that RPi foundation with Raspian relied a lot less on the community.
But is that really what PINE64 should be trying to do? So far their support hasn't come from the "mass market". It's come from a niche market of open source hackers trying to build and support various Linux distros for mobile devices. Why does improving mass market appeal have to mean alienating your existing supporters?
Not as long as they ship Manjaro as the default OS for their hardware. Rolling-release distributions are not fit for mass-market use.
Also: I've seen some hidden costs of supporting custom OS installs being discussed, i.e. procuring extra chips to allow open boot. This may have factored into Pine64's decision.
That's a false dichotomy, nobody is demanding that users be forced through "custom Linux install" (whatever that means). The problem is also not primarily that Pine64 have chosen a "flagship" distro, but how they and said distro behave towards the other options. I'm sure the quality of the flagship distro is massively improved by making life hard for the project that did useless things like making the camera in the phone work...
Those 99.9% can go buy a phone. They don't need PinePhones.
What if the Raspberry Pi suddenly tried to be an everything computer for everyone? Now it needs a case, and a faster CPU, and expandable memory, and SSD, and a bigger power supply, and so on, until it's practically a NUC that costs $400.
Part of the success of the Raspberry Pi is that you can load whatever OS on it you want. Imagine if you could ONLY run Raspberry Pi OS!
That’s not the issue with the Pine64 ecosystem, though.
The direction they’ve chosen is actually similar to what Raspberry Pi has chosen: You can boot alternate OSes, but the primary focus is Raspberry Pi foundations own needs and everything else comes secondary. This is what it takes to keep a project like this alive, and they know it.
If I put a SD card with ex. Alpine Linux into a pi, it'll boot into Alpine Linux. If I put a SD card with Alpine Linux into a Pinebook Pro, it'll boot into... Manjaro.
EDIT: Actually I guess the Pi 4 added an onboard flash chip with an early bootloader, but I can't figure out if it impacts the boot order or changes how hard SD boot is: https://www.raspberrypi.com/documentation/computers/raspberr...
Pine64 is making enthusiast products for hackers, not mass-market devices for non-hackers. Non-hackers have access to plenty of phones which just werk. Part of the promise of Pine's platform and the appeal to the target audience is the commitment to community.
Sounds like either Pine64 has grown past this and decided to pivot, or has been losing revenue due to a lack of customers from this niche market. Personally, as a hacker I love playing with different OSes. However, if I was to use any open source device like a PinePhone or Pine64 board to build something, I'd prefer a stable environment backed by an established foundation. Environment setup is hell, and figuring out which open-source OS works best, if it will be supported in the future, and how to install it would slow me down immensely.
Sad to see Pine64 only listening to them.
The rest of the point aside, is the author is this harsh on Manjaro I must assume they actually aren't that familiar with Garuda. They're a jolly bunch and it looks great but the quality is severely lacking. It can be fun to play around with in a VM for inspiration and snag some snippets to your dotfiles but I wouldn't recommend it for anything mission-critical.
It's a cool experiment to push btrfs as the only root filesystem option but that's also something that's not for everyone.
Meanwhile, AOSP is fully working, open source Linux-based phone software that runs on lots of modern hardware from a variety of manufacturers. Distributions like GrapheneOS have put huge effort into de-googling, privacy and security. Cameras work. SMS works. Phone calls work. There are lots of apps. I hear there are even a few phones that can do wireless charging!
Why waste any more mindshare on the Pinephone?
You cannot remove the stench of Google from Android and we should stop trying. We should use a scorched earth policy of avoiding any code that Google has written and assume it is harmful by default.
Android is a horrible platform to hack on. I'd much rather hack on something closer to base Linux - think Maemo or similar.
> GrapheneOS have put huge effort into de-googling
They are doing great work but they're still depending on google for maintaining Android (Can GrapheneOS do anything against a feature pushed by Google in Android 13/14 and so on? Nope).
> Cameras work
You still lose all the post-processing stuff which account for a good portion of perceived picture quality.
Uhh....no.I know for a Pixel 3a, you cannot even boot AOSP without compiling in the driver binaries:
https://source.android.com/setup/build/downloading#downloadi...
https://developers.google.com/android/drivers
And there is an entire vendor partition (On the Pixel 3a, it was >400 MB). However, even if a user built AOSP with those drivers, VoLTE, SMS on LTE, Wi-Fi Calling, eSIM, and a few other things do not work.
To get those features, one has to extract them from a stock image:
https://wiki.lineageos.org/extracting_blobs_from_zips
I can't imagine this is any better for newer Pixel phones, nor for any non-pixel phones. This will be true for compiling AOSP or any Android ROM.
On top of which, that Pixel 3a is effectively frozen at the kernel it has when it reaches EoL
Meanwhile installing and administering Android is an unreproducible dumpster fire in the vein of of MS Windows - just with tedious swiping instead of tedious clicking. Even my Lineageos/microG phone, with only Free apps, was never really the comfortable experience I expect from a personal computer. Rather it was just something "good enough" that I had to use when mobile. Its camera produced terrible quality photos, as it lacked the proprietary blobs. Even the best-in-class Google-manufactured phones running community distributions with no compunctions about proprietary blobs seem to produce subpar photos. And I'm still not really sure how self-administered Android updates are supposed to work, besides occasionally paving over the whole thing and then going through the pain of manually setting it up again.
That microG phone has since fallen by the wayside due to the 4G deprecation. I've presently regressed to a stock "full take" Android distribution on a no-charge "upgrade" that was sent to me for the 4G deprecation. There are no community distributions for this model, never mind degoogled ones, because of model churn meant to confuse the market. And I don't see the point to throwing $500+ towards a new Pixel (seemingly what all the innovative community distributions want), and rewarding Google for creating this technological pox where 3-5 years of updates is touted as if it's a long time.
A true Linux-first phone is putting a line in the sand of what Freely works today, rather than constantly playing catchup on the shifting sands of what the ewaste-surveillance industry is pushing this quarter. I'm sick of playing catchup, I'm sick of having to choose one failure from (commercial surveillance, no security fixes, upgrade treadmill). The next device I buy to carry around in my pocket will run standard Linux with all its comfortable bells and whistles, whether that is something like Pinephone or Librem, or whether I flip the table on the whole tiny-device-with-touchscreen compromise and just use something like a GPD Micro PC.
My 25+ years of Linux experience has shown me that it's better to compromise on polish rather than compromise on intended functionality and incentives. The Free ecosystem will gradually get better, and my familiarity with it will continually increase. The proprietary offering, which the Android ecosystem most certainly is regardless of the openwashing, will be forever limited by upstream's corrupt primary goal of bootstrapping subjects into Google's (et al's) commercial surveillance nightmare.
Android, including AOSP, is not an operating system, because it doesn't enable the user to operate the device. It is a kiosk, because it enables the licensee to use the device, and limits utility to OEM, carrier and Google market requirements and business cases.
This has some weird amount of assumptions in it.
People may have any number of uses for pinephone HW. It's a nice SBC with display, touchscreen, battery, a lot of connectivity, very efficient suspend to ram implementation (find me a SBC that will suspend and run at 60mW), I2C and UART connectivity and a very nice GUI bootloader available for really pleasant SW development at any level.
Why waste any effort writing apps for Android, when you can only run them on Android? SW I wrote for Pinephone, I also use on my other Linux tablet unrelated to pine64, and on a Pocketbook E-reader, and on my workstation, without any weird hacks or emulation. It's a nice device/phone for developers used to GNU/Linux way of distributing software. If you don't want to, there's no "security" getting in the way of doing pretty much anything with the phone.
To devs who did nothing with Android, it's a massive waste of time learning all the idiosyncracies of Android, just to be able to make some simple app, or deal with restrictions like no audio recording of calls, no playback of audio into calls, background tasks limitations, etc. If I want to run rdbms on my phone to store data, I'll have it running in 1 minute. If I want to do it on Android and connect to it freely from whatever app I want, it will likely take longer if at all it would be possible.
"Why waste any more mindshare on the Pinephone?" just shows a complete lack of imagination
It's a versatile device that can be used for a lot of things. I can pop my Pinephone out of a backcover and pop it into this: https://megous.com/dl/tmp/1551fe95bdfade31.png and have fun making HW projects with it, for example.
But on the other hand, Pine devices have severely lacked for being able to tell users what the best place to start is. I've wanted to back to my PinePhone a few times and had to ask, like, what is in the best state to use, and nobody could tell me.
Updating my PineBook Pro took a ton of investigating because the simple explanation of how to get from what mine shipped with to what new ones shipped with was hard to find, discussion of what mine shipped with was nearly gone already, and the process for upgrading it also had since changed!
As someone who doesn't build distros, your post is actually really nice for me, now I know I should just install Manjaro on my Pine devices! About time they picked something.
I am not qualified to have strong opinions about particular distros, but I think Pine is extremely overdue for a defined reference implementation.
https://drewdevault.com/2022/01/18/Pine64s-weird-priorities....
Ideally Pine64 would be facilitating the development of a software stack which is then shared among the distributions. But, that's not what they're doing -- they're all-in on relying 100% on "the community" to produce the software. So, given this constraint, are they doing it well?
The answer is "no". Choosing Manjaro alone is not going to get the software built. As explained in TFA, the previous solution encouraging diversity did more to get the software built and is largely attributable for the platform's initial success in building out basic software support. Manjaro does not have a monopoly on the software experts, in fact, they have none of the software experts. By throwing Pine64's entire lot in with Manjaro they are burning the people who actually work on solving these problems. That's not a productive way to build and maintain a community.
But they implement it through "We make life hard for all the other people writing code for our system - including those whose code we want to put into our reference", and I don't see how that's helping anything. They seriously risk that instead of "camera works only in distro Y, so we need to port that from there to reference" they end up at "camera works nowhere, because people from Y gave up"
The diversity of the distributions has helped me _a lot_ to make sure that Megapixels does not have some flaws in it that makes it unable to run on other platforms. Things like musl/glibc differences, weird path requirements in nixOS all have made the actual software better.
If "the golden standard" is the manjaro distro then the requirements for good software plummet really hard because there's no quality standard at all there.
Some more information about the shortcomings of Manjaro: https://manjarno.snorlax.sh/
If you want a manufacturer to decide for you what you should run on your phone, maybe just buy a Samsung or apple device. They've already got it figured out also.
It's fine to have a default option. The problem is when you cut support for running anything else.
> As someone who doesn't build distros, your post is actually really nice for me, now I know I should just install Manjaro on my Pine devices! About time they picked something.
That's old news; if you buy a Pinephone/book, they've come with Manjaro pre-installed for a while now.
About 18 months ago i pulled them back out and ran XFCE on one of them. It crashed with the X11 error (i kid you not): "event arrived before it was sent (your hardware is too slow!)" (going from memory - it might have been phrased differently). i ended up giving them away to someone who wanted to use one for a pihole server, and i was glad to be rid of them. Utter garbage, they were.
As I understand it, the phone is based on the A64 board.
On top of all this, on the PinePhone page they link to a video titled something like "This $200 phone can do ANYTHING!".
You misunderstand. i didn't back the phone/laptop. i backed the first pine64 boards, which were marketed as being much more capable than they turned out to be:
https://www.kickstarter.com/projects/pine64/pine-a64-first-1...
Right now it runs some services through Docker and is pretty dang solid.
I've never taken any manufacturer's performance claims too seriously, there's always an angle.
The referenced Kickstart was for the first pine64 boards, not the phones or laptops:
https://www.kickstarter.com/projects/pine64/pine-a64-first-1...
They were marketed as being "high performance" for both Linux and Android. They weren't, plain and simple. They were next to useless for anything.
It was fantastic for that purpose, and I only migrated because openhabian stopped supporting Pine64.
Supercomputer it certainly is not, though. :D If you mean this: https://www.kickstarter.com/projects/pine64/pine-a64-first-1...
Here's libreelec running on Pinephone (same A64 SoC) https://xnux.eu/log/videos/libreelec6.mp4
Why elevate Manjaro if others were doing the work? Why was that decision made? It doesn't make any sense to me.
Thanks for all the work you've done!
(I don't know why, but it was the most popular distro in the pine64 poll)
If you look at the results, you will notice that Manjaro is not the most popular distro for people who use the phone as a daily driver. This indicates that people who keep Manjaro are less likely to actually use the Pine phone as a phone.
So it seems that the reason it is the most popular is that is the default. If you look at what interface people like, the default (Plasma) only scores 21% in that poll and it falls to 18% amongst those who use the phone as a daily driver.
Just an FYI to anyone reading this:
Purism is actively making it difficult for its customers to receive a refund. Many of those customers have been waiting years for their phones.
Here's just one example I found scrolling through a list of complaints on the purism subreddit:
https://www.reddit.com/r/Purism/comments/syoydj/librem_5_ref...
That's a rare case because the user reports receiving a refund (only after a year and filing a complaint with their AG). There are many more complaints of users being told they have to wait until an unspecified shipping date to get a refund.
It is not ethical for a company to attempt to draw out or flat out refuse refunds to users who have been waiting years for a product. And while you are certainly free to hack away on their hardware, until/unless their business practices change you ought to be explicitly discouraging users from (attempting) to purchase a phone (or really, anything) from Purism.
I don't think it's too late for Pine64 to recover from this, though. IMO, they should define a few support tiers and make it very clear what will be supported at each tier. Then they should commit to a support tier for each of the popular distros for some period of time (eg 3 years). I think it's okay if some projects receive more support than others. But the PinePhone will live or die by the health of its development community. Those developers need to know they're working on solid ground.
I understand that Pine64 is trying to position themselves for greater mass market appeal. I'm part of that market. Maybe Manjaro is best suited for appealing to that market. But regardless, Pine64 shouldn't loose site of what make the PinePhone so appealing to begin with. I haven't bought a PinePhone yet but I've been optimistic about its future and I've hoped to eventually get one. It's primary appeal to me is being able to easily setup whatever distro I want. Without that, I will be much less forgiving of its shortcomings next time I'm considering buying one.
I am not sure Pine was ever about mass appeal. It was supposed to be for people, who want control over the hardware they own. That seems a little different from mass appeal.
Maybe I misunderstood their value proposition.
If I as an individual want to do something with a modern SBC that packaged in software doesn't do Pine64 is the only choice for hardware. Same in wearable tech space (pine watch). Good luck trying to get register level documentation for some parts of a raspberry pi's, or any other sbc's.
I've spent last few weeks working on pine64's hardware at a very low level (mostly rewriting sony's imx219 sensor driver to fit my needs and trying to squeeze out the latency out of the image processor). Specifically I use Soquartz and Quartz64-A (they're very similar).
I went from knowing nothing of the hw and the tool chain and finding every prebuilt image on the Internet as not booting to being able to rewrite the camera driver and tweak the rkISP drivers, generate my own os images etc in few weeks of spare time. This was possible only thanks to the rockchip documentation, the open source BSP kernel (that runs Linux 4.16) and someone at pine64 forums who published how to setup the tool chain. Without pine64 all I'm interested in would require significant reverse engineering effort. Also the mainline kernel support is progressing too.
Is the documentation really good? No, the English versions, save few crucial docs, are quite bad. The Chinese versions are better, but still they leave a lot of important stuff out. Is pine64 making only good decisions as a business? No way. Is the community vibrant? If you can call 2 guys doing all replying to questions on the forum than maybe.
Still, if we want truly hackable hardware to exist in future we should support their efforts. Let's explain what they do wrong, but let's not turn our backs on them completely.
I've also asked repeatedly why those kind of projects are not using android forks instead of other things, and I never got an answer that made sense.
Android is open source and has proven that it's a robust system, I don't understand why people want to use something else.
Also, has anyone really done anything more than just tweak AOSP? Honest question, I don't know. If say Google completely abandoned the AOSP and went full Fuschia (I know this isn't likely), is there any individual or group out there that knows enough about AOSP to take it over?
Probably downstream vendors like Samsung have the technical capabilities. I seriously doubt that they'd be interested in continuing an open source project for wider use, but just maintaining their own fork would be totally doable.
A lot of projects claim to be privacy-centric or love open source, but behave quite the opposite. After reading the above manual, I've been wondering if it's pure incompetence or someone deliberate pushing things that way.
There are several good Open Source implementations of IEEE-1275 Open Firmware available now (see https://github.com/openbios for some). Everyone should just use it instead of implementing their own solutions, to keep the boot loader independent of the operating system while still ensuring broad functionality.
Nope. Just no. Let them due so a different company can take the oxygen and run with the community.
SPI + Tow-Boot would have standardized the boot process and made it more robust.
There are two levels to this:
Kernel development / HW specific support. This is mostly being done by people unrelated to any distro, or unrelated to Pine64 at all. (linux-sunxi community, Google, linaro, bootlin, lima project, libreelec, and various individuals) One exception is Martijn, who did initial bringup for Pinephone Pro, and Mobian's maintainer. Nevertheless, vast majority of ongoing improvements, bugfixes, and HW support work comes from outside of mobile distros, and always did, even the work focused directly at the Pinephone SW support. And these efforts were not supported by Pine64 in any comparable way to how distros were supported initially.
Then there's userspace application work, and integrating all the normal user facing SW into a cohesive whole. This is where the distros come in. I don't know much about struggles with that.
So yeah, don't forget that TFA is just a view of one person, and the sky is not falling. (well, aside from the war, and energy crisis, ... but hey)
This is a false dichotomy. Picking a (crappy) distribution does not make it magically better.
It's the opposite in fact. By hurting the ecosystem less people contribute to kernel, applications etc, making all distributions worse.
Besides, as somebody else pointed out, if I have to buy a phone that requires me to use only one (untrusted) software stack I can as well use an android phone.
Essentially everyone I know thinks of it as being Arch in a gimp suit. Some sort of rlysmart teenager's pet project rather than an actually serious tool for a million different reasons that most people can't even be bothered to get into.
Recently topics such as "injecting ads into homescreen" make me fear for my phone.
So now i know whom to blame for the fact that the camera app crashes 90% of the times before I manage to take a photo.
Heh, so every so often, I read an L5 or Pinephone review and they say "I had some weird problem with MMS and it never worked". Naturally, since none of my apps have any tracking with them, I have no idea what happened or what is wrong. Thus, I reach out to the author to file a bug or send me logs. If they respond, they go "sure, I will get around to it", but I have yet to have it happen.
I tell that story because I wonder if you ever reached out to Martjin or any of the developers. It may be the first time they have ever seen the crash. You may have found an interesting corner case that they can fix for you.
Unpaid FOSS developers owe you absolutely nothing. This kind of self-entitled behavior and snarky comments are some of the major reasons why unpaid devs burn out and stop contributing.
Don't be one of the people to blame for developer exodus away from FOSS.
Just a bit of a fun joke, for people who know the context.
Bugs are the community's responsibility. Anyone who works on them (reporting, fixing, testing) should be commended.
I doubt we'd have anywhere near what we have without Martijn and Megi.