Live data from Hacker News

Pine64’s response to “Why I left Pine64”

pine64.org

71–80 of 109 posts

Re: Pine64’s response to “Why I left Pine64”

#71
post #2

This is a disappointing response. I don't have a horse in this race (besides wanting to have access to good hardware for FOSS platforms), but I do have my ear on the ground in this community, so here are my thoughts on this. > [removing SPI] was based on the fact that for years SPI was largely unused on PINE64 devices. People have been arguing that a u-boot firmware needs to be installed on that flash chip for years,…

> Would you rather find, download, and flash a special-purpose, pinebook-specific image onto a microSD card, pop it in, and boot that up to install a distribution, or would you rather it supports a standard UEFI booting interface over USB, netboot, whatever else, like every other laptop can?

It's possible to write Tow-Boot to the eMMC to do exactly this. SPI isn't needed, it's just more convenient. I happen to prefer SPI and Pine64 was willing to go with SPI too.

I think this issue is blown out of proportion.

Pine64 listened to feedback. The problem here was that timeline's didn't match, not bad intention.

Re: Pine64’s response to “Why I left Pine64”

#72

Earlier quoted context omitted.

The cameras are far from "the simple stuff", it's one of the more complicated systems in mobile devices with multiple high speed components from different vendors that have to work together and not very much documentation for the hardware existing.

Admittedly, that's doubly concerning. Pine chooses the BoM; we don't. And if they're choosing unsupported/unsupportable chips without doing the barest of legwork to get them functional (or hell, get docs public), then that's a huge problem. Pine should be showing on their pages a hardware matrix showing what works and what doesn't. The Pinephone Pro doesn't qualify for the definition "phone". If they were serious, th…

In the store right above the add to cart button it says:

"The PinePhone Pro Explorer Edition is aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux"

To me thats pretty a pretty clear implication that many things may work poorly or not at all.

Re: Pine64’s response to “Why I left Pine64”

#73

Earlier quoted context omitted.

> even if the bootloader is loaded from eMMC, in what way is the user impeded? The "bootloader" isn't just a bootloader, it's effectively a critical firmware component. If the "bootloader" is missing or garbled, the board is bricked and can only be recovered by removing the eMMC, which would be very difficult for most users. Such a thing should not be stored on a data partition and managed like any other distribution…

> only be recovered by removing the eMMC, which would be very difficult for most users. No, it would require an SD-card to recover.

Not even that, USB cable is enough.

Re: Pine64’s response to “Why I left Pine64”

#74
post #2

This is a disappointing response. I don't have a horse in this race (besides wanting to have access to good hardware for FOSS platforms), but I do have my ear on the ground in this community, so here are my thoughts on this. > [removing SPI] was based on the fact that for years SPI was largely unused on PINE64 devices. People have been arguing that a u-boot firmware needs to be installed on that flash chip for years,…

> "people who want [an SPI chip] can just solder one on."

That's how many of the SBCs I own (from differen vendor) are distributed. There's a space to solder the chip. (and you can pick the size you want)

Re: Pine64’s response to “Why I left Pine64”

#76

Earlier quoted context omitted.

Personally, I don't get why the focus was on yet another mobile OS variant instead of creating a reasonably open hardware with an AOSP userland first. Users won't buy devices where they can't even be sure that basic functionality works. And for what it's worth, I know Android isn't without its issues - but why not build something on top of at least its Linux kernel and HAL and save so much effort in getting a system…

If Pine had targeted Android AOSP, I would have had zero interest in their product. I suspect I'm not the only one. Instead, I bought their pinephone because it could run Debian. I went from Maemo (Debian based) to AOSP Android when my n900 no longer worked. I've never experienced such a user-hostile platform as Android-- you even have to expend effort just to gain and retain root on a device you nominally own. And,…

The thing is, that bikeshedding is the approach that everyone has taken so far - and failed catastrophically. Literally every single project either has failed or is in the process of failing - and I count "shipping a product that is barely able to accept calls to a bunch of developers" just that.

So I'd argue it makes more sense to first either get a decent alternative OS running on a proprietary piece of hardware (which is almost impossibly hard) or get an open piece of hardware running the only thing that comes close to an open-source OS first (so users will actually buy it because they can actually use it as their daily driver).

It doesn't make any sense for any project without billions of dollars backing it to attempt the 100% purist approach from the beginning. Even Mozilla wasn't able to pull it off, so how and why should anyone else succeed?

Re: Pine64’s response to “Why I left Pine64”

#77

Earlier quoted context omitted.

> Even something as essential as the notification system relies on Google's servers and proprietary bits. Agreed, but a notification broker that's usable for more than just "on-device" generation of notifications or wants to avoid every app polling constantly will always need some sort of centralized server infrastructure that costs a lot of money to develop, keep running and secure (something like "user A gets notif…

I told myself I'd stay off this site because there's so much distracting crap on here but I need to correct this one. You don't need a notification broker unless you want to run non-free garbage. Well written apps will just service the socket they get data from just fine. This is already the way things work on Linux, the only thing missing for real time notifications is to have the network interfaces wake the device…

> You don't need a notification broker unless you want to run non-free garbage.

Face reality: most of what the utter majority of the people on this planet use is proprietary and ffs purity bikeshedding won't lead to any success.

> Well written apps will just service the socket they get data from just fine.

The utter majority of providers use CGNAT with extremely short keepalive times for cost saving, the worst I've seen was some crap MVNO dumping connections after ten seconds idling. That means your usual phone will have 20-50 apps that all have to send keepalive data all the time meaning the modem never goes asleep and drains your battery, vs one centralized notification broker that even shoddy MVNOs configure to be exempt from frequent connection drops.

> Already the Pinephone works well enough for people who are used to desktop Linux (sans the hardware issues with the modem.)

So... like what, 3% of users given Desktop Linux market share? LOL the only ones used to Linux on desktop are either forced to do so by their employer or are utter masochists willing to overlook catastrophic flaws for the sake of purity.

Re: Pine64’s response to “Why I left Pine64”

#78
post #69

I am a big fan, but I also find this situation and the response to be a bit disappointing. I highly respect Martijn and the effort he has poured into pmOS and Pine64 and surrounding projects. Without wanting to make other important people feel left out, I consider him an absolute legend and the fact that he has felt compelled to write this blog post (and, unfortunately, to leave) is massively concerning. I think it's…

Disclaimer: I was in the Pine64 IRC channels at the time, so have some limited visibility, but not all visibility. Pine64 was looking for somebody to commit to maintain PineBook Pro support in Tow-Boot (a relatively new project) I don't know if the point-of-contact was made aware that PineBook Pro was not going to be shipped with Tow-Boot.

I found logs. For context, tl_lim is the founder of Pine64.

2022-06-01, the Pine64 dev IRC chat:

> [T] I pause on move forward due to no one commit to maintain. If MayueIC interest to maintain, lets move forward and include Tow-Boot into the PBP factory build. @MayeulIC, you can send an email to info@pine64.org, we will ship a free Pinebook Pro to you so that you can maintain the Tow-Boot.

> [T] On the integration, just follow the recent PinePhone Pro way that flash OS build to eMMC then flash Tow-Boot to SPI Flash.

> [T] Frankly speaking, I am happy on developer commit maintaining Tow-Boot on Pinebook Pro. Thanks and a big shout out to @MayeulIC.

2022-06-02, in the Tow-Boot chat, which was discussing tl_lim's above comment:

> spikerguy: Tllim asked on. 25th April about pbp tow boot support i replied it just work fine as it should. But just because i am the one to work on factory images plus i am the manjaro arm pkg maintainer maybe he didn't wanted to hear from me instead the community that was assuring him about tow boot and none replied

> The current batch factory image is already submitted. So hopefully we can keep things ready for the next batch

I don't see all comms, but overall I see Tow-Boot on SPI at factory-time as nice-to-have but not essential (users can easily do this, distros don't need to require it, and the next batch can improve it if needded), Pine64 has showed willingness to use Tow-Boot. Tow-Boot has 1 developer, and I'm not sure if they were willing to commit to support this. I understand if they weren't.

This issue is blown out of proportion.

Maybe a good step would be for Pine64 to fund Tow-Boot's support of Pinebook Pro.

Re: Pine64’s response to “Why I left Pine64”

#79

Earlier quoted context omitted.

If Pine had targeted Android AOSP, I would have had zero interest in their product. I suspect I'm not the only one. Instead, I bought their pinephone because it could run Debian. I went from Maemo (Debian based) to AOSP Android when my n900 no longer worked. I've never experienced such a user-hostile platform as Android-- you even have to expend effort just to gain and retain root on a device you nominally own. And,…

The thing is, that bikeshedding is the approach that everyone has taken so far - and failed catastrophically. Literally every single project either has failed or is in the process of failing - and I count "shipping a product that is barely able to accept calls to a bunch of developers" just that. So I'd argue it makes more sense to first either get a decent alternative OS running on a proprietary piece of hardware (w…

> ...Even Mozilla wasn't able to pull it off

Mozilla did not try a purist approach. Their Boot2Gecko was built on AOSP downstream kernels and proprietary drivers. (Then again, there was no such thing as a truly 'purist' device back then, even in non-AOSP land. So they just did what could work at the time.) If you want to explore that kind of approach, there's things like UBPorts and Droidian. They might even make sense, if they end up being able to function as AOSP-compatible Generic System Images (GSI's) and run on mostly any Project Treble-capable device. Make no mistake though, that's a lot harder than doing everything properly in upstream and restricting one's attention to hardware that's compatible with that approach. If only because you're not forced to keep up with churn in the AOSP-native interfaces.

Re: Pine64’s response to “Why I left Pine64”

#80
This seems easy enough, right? If the SPI chip is in shipped units, and tow-boot is available for it now, then it should be simple enough to ship out of the box starting with the next batch of hardware, and it should be simple enough to post official instructions for installing it from Manjaro. While that wouldn't change the past, it would fix things going forward and let Pine back their words with actions.
Post reply on HN