It's good to see Martijn Braam fought the good fight on things like the PinePhone Pro bootloader in eMMC, and I'm sorry to hear the situation became untenable.
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.)
We've spend a lot of time optimizing the developer experience in postmarketOS by making easier tooling and writing more documentation, I'm glad it helps.
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.
Why prevent closed source software from running in userspace? Even in Fedora Linux I find myself having to use closed source software a lot for daily tasks.
It's not intentional, just a side effect of using musl libc instead of glibc (GNU C library).
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.
> 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.
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).
That just happens to be a side-effect of using Alpine as base distribution. If you really need something closed source it's still very easy to just use a flatpak for that.
Unless PINE64 changes course hard, I think this will be the moment they died, so to say. They may keep making SBCs etc alongside other vendors but the phones/tablets/laptops/watches/etc would continue being novelties and realistically majority e-waste. Really quite sad. If I'd name one single person in the FLOSS community who's done the most good for mobile open source, it'd be OP. Thank you so much for your service, work, and patience up until now.
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
As someone who's more familiar with PINE64 than the rest of us, are you as confused as I am? I've noticed minor red flags slowly building up over time and at least from here there are some major inconsistencies with their stated vision and where they seem to actively be going. I think I started seeing it somewhere around the PPP announcement.
I really want them to succeed but I have a hard time making sense of them lately.
AFAIK the pine devices are the only ones you support that are not a big pain to install. I have a few old android phones that you "support", but when I looked at what I had to do to install I decided it was too much effort. Pine devices claimed to be easier because you just throw in a SD card and go (of course the fact that the new ones are not this is why you left)
I would like the process for android phones with postmarketOS to be easier. In the end for a lot of these devices you have to work around vendor weirdness.
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.
Damn, somehow SHiFT phones have been flying completely under my radar. The SHiFT 6mq looks amazing if it'd be feasible to get pmOS running on it. A quick search yield a lot of results, all in German.
Do you think it's realistic to expect the power situation to be(come) better than it is on the PPP today?
See [1]. You can use Firefox Translations to translate the website locally.
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]
Flashing pmOS is not very different from flashing any other Android-native ROM. Of course it's more involved than simply booting from external storage (though some Android devices can use "fastboot boot" to achieve something similar), but it's pretty standard all things considered.
The soldering iron pine64 made is also great. They released a upgraded version a few weeks ago. They also announced a RISC-V SBC, and its great to see them at least continuing to improve the SBC situation.
The devices they make that don't ship with Linux on them are pretty good, those are also easier to get fully functional software since the scope is so much smaller.
Do you think RISC-V will make any difference for the Pine64 situation (especially the SPI flash)? I remember seeing something about a UEFI standard. Would that help?
The currently shipping affordable RISC-V SBCs tend to be RISC-V cores embedded with a bunch of frustrating undocumented peripherals, more or less the same as with affordable ARM SBCs. It's disappointing :(
Having one, I don't feel as good about the PinePower. I bought it together with their Pinecil soldering iron (which is great!) as it seemed like the ideal way to provide power to it, but unfortunately it's a very unreliable combo, with the iron rebooting frequently. Discussion around many similar issue reports online suggests the possibility of bad implementations of USB PD. Perhaps this is more a criticism of the complexities inherent in USB power supply in general, though.
Running the Pinecil off a Riden bench PSU with a simple DC power plug is rock solid, for comparison.
Which PinePower model are you using? In my experience, the Pinecil works flawlessly with the 65W PinePower and the recommended heat-resistant red silicone USB-C cable.
It's the "PinePower – 120W Desktop Power Supply – EU version" and I'm using that same recommended red cable on the PD65W port on the right side of the front plate.
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.
I bought a PineBook Pro and was pretty excited about it. Unfortunately I just couldn't get it to boot reliably. I was ready to do a lot of fiddling with it, accept the slow overall speed, but just fighting with the boot system all the time was not fun. Haven't touched it in months.
I just wanted to say thanks to Martijn Braam for all the work he's put into PostmarketOS along with the other pmOS devs. I was lucky enough to snag a pinetab when the first batch was released, and I was blown away by the quality of pmOS.
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?
I think this is the inevitable outcome of any movement of Linux to the mainstream (Purism has done something similar). As Martijn said in the article, PinePhone devices were operable with 25 different projects. That's 25 different variations of Linux fighting over market share. As Pine enters a growth phase for their business, the consequences of this are going to manifest as paralysis.
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.
Correct. This is non-sense speak by non-developers. Greedy non-developers.
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.
I would like to disagree with your characterization. I use Linux distros regularly at work (Amazon Linux), in school (Rocky Linux, currently studying), and at home (Ubuntu) when hacking together various projects. I've seen firsthand the issues that come with trying to get a distro to interop with Bluetooth, sound, and software not quite designed for it.
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.
> I've seen firsthand the issues that come with trying to get a distro to interop with Bluetooth, sound, and software not quite designed for it.
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.
Right, this boils down to "Oh no! 25x many people are interested in our project. What can we do to reduce that to 1x people interested in our project?" If I can't easily boot my preferred distro, I don't buy your boards. That simple.
I think that's a huge overstatement of how much duplicated effort is involved. The process is much more akin to:
* 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
I guess it comes down to that: will Pine64 take an OSS development approach or a commercial development approach? I've been swimming on the question of why Linux isn't more accessible to more people for a while, and have come to believe that a commercial approach is the only way Linux can achieve the work-out-of-the-box dream.
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.
Historically, "works out of the box" has largely been a matter of low-level hardware bringup. That's one part of FLOSS development where there is already a natural "center of development and revenue", namely ODM's and OEM's. They just need to stop pushing hacked-together, barely-working downstream BSP's tied to a single software configuration, and start cooperating with projects at relevant levels of the stack. Pine64 is actually a lot better at doing this than your average hardware vendor, the OP is mostly complaining about relatively minor quibbles (though important quibbles nonetheless, because they directly impact OP's work).
Pine has been very much in the "we make hardware, community figures out software" camp, otherwise we wouldn't even have the discussions of "different things worked in different distros" etc.
As someone who works for Purism on the Librem 5, I have to say that I never had the impression of stagnation due to duplicated effort. Quite the opposite - we benefited a lot from work done on projects like postmarketOS, Mobian or Plasma Mobile, and I'm pretty sure others are benefiting from Purism's work just as well. A lot of stuff is interconnected and the push to mainline as much stuff as possible was certainly worth it long-term, as we can clearly see its fruits in our everyday work now.
I am a big FOSS proponent (I almost exclusively use FOSS), but I find it difficult to not become disillusioned recently. It seems the large corporations like FANGs are largely pushing OSS to use volunteer work to make software a commodity, while trying to accumulate more and more data, which they consider their main value.
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
I feel like you're inferring qualities in OSS that don't (explicitly) exist. This is not uncommon. Specifically;
>> 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 :(
> I feel like you're inferring qualities in OSS that don't (explicitly) exist. This is not uncommon. Specifically;
> >> 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.
>> Essentially it is us as users&developers who let this happen.
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.
Well we've reduced the price of computing and made it ubiquitous. This coupled with worldwide networked communications systems has led to today, where we have impossible polarization and a large fraction of humanity that can no longer tell reality from fiction - we got the "worldwide communications and ubiquitous computing" part of the tech tree done before we got the "society able to handle worldwide communications and ubiquitous computing" trait.
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.
It seems to me (having sworn to not ever publish another line of free software after many years of doing so) that a kind of serfdom has been established in free software similar to the one working directly for FAANG. The difference is free software doesn't pay enough to live on ramen, if they even notice your project at all.
[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? :)]
The funny thing about manjaro is it would be abandoned in months if arch devs (for whatever reason) just disappeared. I suspect that Canonical could survive such a thing with debian, but manjaro could not.
Well, Manjaro is in a path to make some money; they incorporated a few years back and made deals with developers of privative software like Vivaldi and Softmaker to make their software the default option. I can't blame them, everybody needs to bring food to the table, but after reading TFA I believe they're hurting the FLOSS ecosystem around them.
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.
With my Librem 5 developer hat on, I'm surprised that a SPI chip matters at all.
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?
That does work on the original pinephone, the A64 SoC can boot from the mmcblk0boot0 partition. The rk3399 in the pinephone pro is way more problematic which it is why it's important to have the SPI and also have the SPI flashed from the factory.
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
The boot ROM in the RK3399 in the PinePhone Pro has a hardcoded boot order, and doesn't use the special boot partition of the eMMC - it only looks for a bootloader on the data partition at a fixed sector (64).
Would it be possible to flash Tow-Boot to that sector and only use the rest of the partition as actual data storage? It seems like it would effectively work the same as having a separate SPI hardware chip on-device, while also restoring distribution independence. The downside is that implementing this might require some special-case support though it could likely be implemented most conveniently by using, e.g. dm-linear, so only configuration changes would be needed, not new kernel code.
The issue with that is it's really easily wiped or changed when installing an OS. In the end the SPI hardware did get added and it just works, it's by far the simplest and most reliable solution.
> In the end the SPI hardware did get added and it just works
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.
It seems like in the end the pinebook pro did get the SPI chip on it, but then they flashed a closed source U-Boot to the eMMC instead which does not allow booting from SD. So it's again a complete pain for the other distributions to help these users.
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.
Not useless, but users will need to manually flash tow-boot when that should just be the default. If Pine64 had made better moves, their customers would have never had to worry about firmware or bootloaders, only which (standard) distro install media to use.
I was burned pretty hard by Purism and no longer trust the company. Pine64 though I loved. I have an original PinePhone, the postmarketOs community edition unironically. I have been cheering Pine64 for a long time since, from the outside, they have been doing everything right.
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.
> The original PinePhone was brought up on the existing Linux Mobile projects like Ubuntu Touch, postmarketOS, and Maemo Leste, and also spawned new Linux distributions like Mobian and Danctnix ARM. This grew until there were 25 different projects working on the PinePhone — an apparently thriving community.
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.
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.
It's not a market and it does not act like one. These are not a bunch of startups hoarding intellectual property, they're a group of open projects working together under different flags to build a single product. The work of each is incorporated into the rest.
Well I think at this stage we can hardly call it a market -- it's not 10 different android distros that stem off from a solid codebase, but different groups of developers that interact with each other to bring up the base.
When you destroy the nest for these dev groups, there will be no more software for a fancy distro to package.
> Much of the original hardware bring-up was done by Ubuntu Touch. Mobian developers built the telephony stack via their eg25-manager project. And in my role for the postmarketOS distribution, I developed the camera stack.
> 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.
"Other distributions like Mobian and Ubuntu Touch are miles ahead that broken thing that Pine chose to adopt as their default distro."
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?
oh yes, the problem is not Manjaro itself, it's the particular version of Manjaro that is used on PinePhone. I heard good things about Manjaro itself and I have no doubts that it's a good distro!
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 ¯\_(ツ)_/¯
While I’m sad to see the author leave such a project and grateful for his contributions, I have to say I think Pine64 is actually in the right here.
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.
This is one of the biggest strawmen I've seen on HN, a platform famous for building them. There's a lot wrong with this but the simplest is this: Pine's stated strategy is to deliver hardware and let the community deliver software. And the community did deliver working software under the earlier community model Pine was pushing, and it's thanks to these efforts that "getting the hardware up and running quickly" is even possible. Now they're adopting a different model which completely undermines what worked about the last one.
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.
> 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.
How does making booting alternatives harder and pissing of people developing software components they themselves want to use in their "get started quickly" distro help Pine64? Prioritizing their own efforts towards one distro doesn't have to mean harming the rest of the ecosystem they benefit from.
When you’re trying to make a mass-market hardware product at bare-bones pricing, you have to be ruthless about simplifying the hardware and cutting costs. A single SPI chip isn’t a huge investment in absolute terms, but it adds one more sourcing complication (in the middle of a chip shortage) and creates significantly more RMA complexity (for the reasons that the Pine64 organization accurately explained from their past experience) to cater to a relatively small number of users.
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.
I kind of doubt that adding an extra chip was the only way to preserve the ability to boot from microSD, given earlier hardware revisions did do it too - i.e. its something they decided to take away. (RPi btw nowadays can boot from multiple sources too ;))
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.
> When you’re trying to make a mass-market hardware product at bare-bones pricing, you have to be ruthless about simplifying the hardware and cutting costs.
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?
You come up on your niche, and then when you have access to the broader market, you pivot to the group that will help you grow market power [1]. Similar dynamics exist in a lot of different ecosystems, and Pine seems to be responding to the challenges that have come with becoming big. It's sad that they won't be supporting OS hackers anymore, but they have to pivot if they want to bring onboard more customers (which seems to be the goal behind this decision).
Can you really consider the "mass market" to be a key to power for Pine64 with their current lineup of products, though? The OS hackers seem to be Pine64's only key to power right now. And does supporting them really consume extra resources that could otherwise be better allocated?
My guess is that OS hackers could be considered as one niche, while hackers and builders who prefer not going through a custom Linux install/config for their project (i.e., a weather station or a mobile smart home dashboard) could be a larger one. Definitely not "mass market" or replacing Android levels, but at the same time a significantly larger portion of revenue for Pine64. The switch to Manjaro would provide them with a key backer that allows them to unlock this market. People have been discussing the software quality of Manjaro, so maybe it has a good foundation or connections?
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.
> while hackers and builders who prefer not going through a custom Linux install/config for their project
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...
Tow-Boot is pre-flashed on SPI on Pinephone Pro. How is that making alternatives harder? (aside of course for people wanting to use an alternative bootloader, like levinboot)
You're oversimplifying tremendously and disingenuously.
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!
> 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.
> 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.
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.
I don't think the Raspberry Pi does UEFI boot by default? You'd have to put in a SD card with Raspberry Pi-specific boot support, including proprietary blobs.
Yes, that's true; my point is that the pi will happily boot whatever, unlike the Pinebook Pro which has a default bootloader on internal storage that ignores the SD card. So a distro/OS has to add the pi-specific bootloader to their SD image, and that's a pain, but they can't do anything to make the PBP work, because the machine won't even pay attention to their SD image.
I haven't seen U-Boot in a while (I use levinboot on PBP), but if it has LCD and USB support already on PBP, then the user should be able to just self-erase the bootloader from eMMC using a command or two and then be free to boot from SD card or USB. Or just erase it from the booted default Manjaro.
While I can agree that if you want to make a device with mass appeal you probably should focus your efforts, this doesn't seem to be happening. As far as I can tell Pine does not put any significant effort into the software, but instead hopes that the community will do it. Now if you rely on the community, focusing only on a minority (manjaro users) of a minority (Linux mobile developers) of a minority (phone users wanting a Linux phone) might be a bit too much focus I'd argue.
> Garuda, which aims to have a Manjaro-like experience without holding back packages and the problems Manjaro has.
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.
Given their niche business model, Pine64 is probably barely staying alive, especially in the age of COVID-19 and recession. I do hope they are able to offer open source range of devices, even with limitations. Stepping back from emotions, MicroSD booting is usually quite useless, tried that quite a bit on Chromebooks and everything keeps hanging waiting for I/O. Given limited resources, maybe they are hard pressed to just make what they ship with device not suck badly?
MicroSD booting is brilliant as it allows the OS to install itself onto eMMC. Also when you have an OS installed on eMMC but need to fix something or want to try something out, all you need is to pop in a micro SD and it will boot from it.
At best, the Pinephone is buggy software on low priced but mediocre hardware. It has always been like this, and it is not going to change. There is nobody willing to spend the millions of dollars it would take to make it otherwise.
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!
AOSP is still a google-controlled project that requires a ton of blobs, whereas the Pinephone (and other linux compatible smartphones like the Librem 5) has an entire ecosystem of healthy linux distros (from Mobian to Archlinux) running as close as possible to mainline linux.
> 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.
The blobs are required by hardware OEMs, not by google themselves. You'd have the exact same issue when trying to run pmOS on the same hardware; it actually crops up throughout the embedded ecosystem. Pinephone and Librem 5 are quite exceptional wrt. minimizing the amounts of hardware-specific blobs that they require.
Yeah indeed I should have specified that the whole "mainline linux compatible" is mostly because the Pinephone and the Librem don't use Qualcomm (or worse Mediatek) SoCs.
With a bit of work a lot of this can be improved, Android likes to have userspace drivers while a bunch of that stuff is also already in the kernel, so postmarketOS uses kernel 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:
Try changing the default DNS in AOSP from 8.8.8.8 without doing ill advised, hacky weird nonsense. Have you tried to prevent your AOSP phone from reporting tethering to your carrier in the last ~6 years? The software is licensed GPL, which means you own it outright as a user, to it's core, right? So these types of things should be possible with ease with a little technical proficiency, right?
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.
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.
On the contrary, AOSP is a largely nonexistent OS thrown over the wall by an evil adtech company so they can claim the proprietary malware-laden version they ship to 99.9% of consumers is open source.
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.
AOSP has way too much churn for a sensible system. A Linux phone should just work, and share as much of its code as possible with Linux systems running on other device classes; distributions like pmOS and Mobian (and quite possibly Debian Mobile in the future) are working towards this goal.
On my laptops/desktops/servers, I can rebuild all of my many systems from source, with config kept in git, with a few commands using Nix, and it basically Just Works. Before using Nix, I could reproducibly reinstall my personal Debian environment in 15 minutes with similar uniformly-managed config. When I upgrade software, there's no wondering if I'm going to be forced to upgrade hardware. I'll routinely keep machines running for 10-15 years with no downsides apart from higher power consumption. And when I do upgrade hardware, I'm never forced to change my software environment because of incompatibility.
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.
The carriers are calling it the "3G shutdown" to downplay the fact they're obsoleting relatively new 4G LTE phones that simply don't do VoLTE. Hell, I even continued using mine without carrier voice service, but they eventually blacklisted the whole thing from the network.
On one hand, I understand your frustration here, for sure.
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 don't think the author meant that the problem was Pine "standardizing" on a single distro, but standardizing on a distro which has done (comparatively, AFAIK) little in terms of active software and driver development. By diverting people to a distro which mostly siphons up the work done by others, they risk poisoning the well and driving away the developers actually writing device drivers and infrastructure.
This is exactly right. And also a distro that is just refusing to disagree with pine64 when decisions are made that impact all distributions negatively
Even supposing your premise is correct (and it's not: diversity is good), the question becomes if Manjaro is the right choice, and it is definitely not. Manjaro is a very poorly run Linux distribution with misaligned incentives, poor practices regarding stability and security, and a history of problems playing well with others -- and they don't even work on the software that still needs to be written to make Pine devices useful. This is not the right horse to back.
Diversity is good, but diversity is good once there's a baseline of support accomplished. From a user standpoint, PinePhone has felt like it's spinning it's wheels while each developer builds support for their favorite feature into their favorite distro, so you have one distro where the camera works and one distro where texting works.
I am not qualified to have strong opinions about particular distros, but I think Pine is extremely overdue for a defined reference implementation.
There's not one distro where camera works. There's one distro (manjaro) that was willing to ship broken hacks first while the rest of the community made the actual working camera app. While that app was developed on postmarketOS first it was almost instantly available on the other distributions that didn't first have to undo their previous mess.
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.
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.
How do the steps taken lead them to a better reference implementation? "we officially focus on distro X" - sure, that helps maybe, and I don't think many people object to if its just that, although its annoying if before you loudly promoted diversity. But it also means they need to be the ones doing the work.
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"
Why should they pick something? I thought the whole point of this was to build open hardware and let me pick something?
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.
They're just picking the default SW. You can still run whatever, including any other bootloader or OS. It's not like it's locked like a typical Android phone.
Many Android phones are also open like this as shown by pmOS: someone somewhere has to work on mainline Linux support and normally mainline doesn't really work and there are still some downstream patches left, meaning you can't run what you want unless you have a patched kernel (the same it true for the PinePhone and PinePhone Pro).
> 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.
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.
Martin, if you're still around, could you tell us what phone you would recommend to someone if they were wanting to switch to daily driving PostmarketOS? Do you still see that as the pinephone or do you consider another device as having a more promising future/better hardware/better support?
If I want a phone locked to a single Linux distro controlled by the vendor I will buy an Android phone and it will beat the pine phone in about every single way.
Anecdote: i backed pine64's first-ever Kickstarter and got two of their A+ boards (i think they were called). They claimed high performance and full HD video. In the end i couldn't get a single Android game, no matter how primitive, to run at more than a couple of frames per second and Netflix was too jittery to watch. They've been on my poo-list ever since.
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.
So you backed a developer-oriented project all about open source software and your test to see if it was garbage or not is to consume proprietary video content and play video games through virtualization?
> So you backed a developer-oriented project all about open source software and your test to see if it was garbage or not is to consume proprietary video content and play video games through virtualization?
The referenced Kickstart was for the first pine64 boards, not the phones or laptops:
Don't you think there's a difference between "it's annoying I can't watch full blown movies on this experimental phone" and "it's garbage because no Netflix"?
It depends on what you were expecting. On their A64 Kickstarter they said the graphics capabilities are higher than the original XBox's level of performance. That might lead a person to expect it to play games well. The screenshot included a Netflix icon. The Kickstarter FAQ says it can play UHD 4K video. That might lead you to believe you could watch Netflix on it.
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!".
It can play 4k videos and it can play games, but expecting it to play 4k videos through an unoptimized browser with DRM and play virtualized games is extremely disingenuous.
Are you seriously telling me you expect an ARM board running mainline Linux to play virtualized Android games? This is beyond beyond disingenuous, is somebody paying you to write this or what?
Yes, but they probably should not be buying experimental products for this purpose. Set your expectations according to your purchases. The Pine store makes it abundantly clear that this is not a device which you can expect to plug-and-play for whatever use-case you have.
> Yes, but they probably should not be buying experimental products for this purpose.
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:
Well, thechnically A64 supports FullHD video decoding acceleration, and can run Kodi (librelec) smoothly. It's just SW is there only since 1-2 years ago.
Manjaro with Plasma Mobile had been the default for more than a year when that poll was conducted.
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.
IIRC it was something about personal and/or business relationships and commitment of resources. Actually, going with Manjaro was only half of what made me question the decision: At the time, when PINE64 introduced the "Beta Edition" Plasma Mobile was still quite bad (it improved a lot since).
Hrm, where is there another "open source/hardware" phone that is not more than a new iPhone (e.g. not a libre phone)? I was really thinking about getting the Pine phone pro, but now I am a bit shaken.
I think that the situation is not that bad that you should skip the PinePhone Pro, these are definetly things that can be fixed. There's also a lot more platforms with varying degrees of linux-ness. There's the PinePhone and Librem 5 which are the most well known but on postmarketOS there's now also mainline linux on a bunch of qualcomm devices and I think the mainlining community for those qualcomm platforms is at the moment way healthier than the pinephone one.
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.
As an outsider, it sounds to me like Pine64 has failed to explicitly state how much support they are willing to offer each of the popular distro projects. The Community Edition releases implied a pretty high level of support for each of those projects at the time, but now that support has been dropped and the project developers feel lead on.
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 own one ( community edition ), am currently using one, and still am somewhat optimistic. I should disclose those that I am running PostmarketOS though ( and it makes me glad author will still contribute to that project ).
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.
It is up to Pine64 to decide if, and who, they choose to support with cash for OS development. Is what they did a good choice? Probably not. Are they still the only modern hardware vendor that published (almost) all the driver's source code and register level documentation for the MCU. Yes!
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 understand the author's disappointment, but despite the defeatist tone of the writing I am convinced that this will thankfully not be the end of PINE64.
I use an Android fork, but I can understand why they'd want to use Linux. If they succeeded you'd start seeing more cross pollination of apps from the desktop, and perhaps more mobile focus from Linux devs.
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?
> 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.
I’ve read that in espionage, open source companies are disrupted from the inside. Is an open source, non trackable device with future potential to replace the current situation worth that level of action? Pure speculation!
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.
The ARM ecosystem is really hobbled by the lack of a standard boot loader and device tree mechanism, and the RISC-V ecosystem is heading down the same path.
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.
Sure; I would have preferred a world where OF won, but that's not where the ecosystem went. And UEFI is... fine, and in this case I think the network effects are worth it.
I just want pine to provide hardware that can run a linux kernel without any binary blobs and leave the distros to whoever feels like working on that stack
I totally understand the Frustration the author has here. But I'd rather have any working software version than 10 that don't work well at all and that has always been my pine64 experience. Great hardware, barely any documentation, important hardware and software features don't work at all or are locked behind a very old kernel version
According to TFA (which I don't know enough to verify), the >10 distributions that "don't work well" are the ones pushing the platform forward and solving problems one by one. The blessed monoculture distribution is about packaging other people's work and doesn't really contribute to the development, in fact they only add annoyance due to shitty packaging policy, so with the other distributions pissed off, they won't have stuff to pick up. That's not a promising path to "one working version".
The question is to what extent it's an accurate characterization.
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)
Mobian and pmOS do a huge amount of work wrt. bringing up overall support for OEM devices. The other efforts you mention mostly work at lower levels of the stack, focusing on supporting individual SoC's or IP blocks. Both are very much necessary, but if you care about polishing support for a specific OEM device the mobile distros are doing much of that work.
The point still applies. Do you really expect Linaro or Bootlin to be working on completing mainline support for the PinePhone, Pinephone Pro and other Pine64 devices? That seems like it would be a job for the distros.
I don't expect anything. I'm just telling you how it is, as a maintainer of the pinephone kernel that most of the distros use, and the rest heavily borrow patches from.
It's an entity that's in a position to make a design decision - "We will have one bootloader flashed onto the eMMC - the same for every device we produce." It creates a standard which users and developers alike can fix themselves to. It is definitely a good thing, if you are worried about productizing -- but perhaps not so great if you want a diverse community of hackers.
> The solution to this is Tow-Boot: a distribution of U-Boot that can be put in that flash chip. With this the U-Boot firmware can just be treated like system firmware and be updated through fwupd independent of what distributions ship. This would work not only for the PinePhone Pro, but would also enable things like installing your preferred Linux distribution on a PineBook Pro by popping in a flash drive with a UEFI installer, much like you can on any other laptop.
SPI + Tow-Boot would have standardized the boot process and made it more robust.
Late reply, but... The fact that there is a superior solution is kind of irrelevant. Everyone has their opinion on what is the best solution - I'm sure some people would disagree with your assessment of SPI+Tow-Boot. If there is no one who is actually in a position to make that call, you will just have chaos. That's my only point.
"Making alternatives harder to boot" is really no worse than what you get when trying to install Linux on any off-the-shelf PC with preinstalled Windows.
> I'd rather have any working software version than 10 that don't work well
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.
The idea that Pine64 would go with Manjaro of all possible projects is utterly hilarious.
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.
Lack of warranty is the reason why I don't like this project. I still got some of their devices (PinePower is neat for its price, but again: without warranty).
> 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.
You know whom to thank for the camera stack actually existing.
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.
I wrote the camera driver for the selfie camera, and parts of a sensor interface driver, and the driver gives you a green tint by default. So I'm blameable if the parent commenter dislikes the green tint. ;)
Just a bit of a fun joke, for people who know the context.
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.)