Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pine64’s response to “Why I left Pine64”

pine64.org

Post reply on HN
Print view View original

81–90 of 109 posts

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

#81

Post by yjftsjthsd-h »

Aeolun wrote: post #56

I kinda feel like half of the message here is “We listen to our community, we just don’t always act on it.” I realize that’s healthy, but the way they’re going about it makes me feel like they’re trying to weasel out of it or something. I’m left with a mild feeling of disappointment and I’m not sure why.

I think the problem is that as an external observer, it's almost impossible to distinguish "we listen but don't/can't always act on it" and "we don't listen", because they produce the same actions and are only possible to tell apart by closely following the exact communications (which isn't always possible since some happen in private, and is unreliable anyways if some is trying to appear engaged while not actually listening).

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

#82

Post by zozbot234 »

mschuster91 wrote: post #77
swiley-taway wrote: post #54

Earlier quoted context omitted.

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

> 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 s…

If the connection dies, you just re-establish it when the device is scheduled to wake up (as directed by timers which can easily be auto-coalesced on Linux, so battery drain is a total non-issue regardless of how many apps are active). It's not a bigger issue than checking your email or refreshing your Slack/Discord/whatever.

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

#83

Post by yjftsjthsd-h »

noasaservice wrote: post #17
MartijnBraam wrote: post #9

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…

> 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".

I'm actually on board, but do note that that's going to be a chart full of subnotes and caveats - things like "camera produces an slightly red-shifted but passable image on default software shipped from factory, red-shift is fixed with kernel 5.19-patch-foo but that breaks focus, Mobian ships that kernel with a userspace correction filter that fixes it in the latest nightlies[...]". You'll end up with a small table that's 90% little yellow "works with caveats" boxes and then several pages describing the caveats and various working and shades-of-working configurations. Oh, and it'll need to be timestamped and constantly updated (as in "major bugs fixed, and sometimes added, on a weekly basis")

In short, summarizing active development is never going to be simple.

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

#84

Post by noasaservice »

ac29 wrote: post #72
noasaservice wrote: post #17

Earlier quoted context omitted.

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.

That indicates that hackers can do shit to get it to work.

And, they call it a Pine *PHONE* Pro.

It can't even do the "Phone" thing.

And read up about the hardware critical failures that can destroy stuff when you plug in the wrong usb-c connection.

Yes, I expect a minimum functionality. You know, like NOT FRYING SHIT. They couldn't even manage to do that.

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

#85

Post by 3np »

> I may add that the decision was made among ourselves, without the input of any third parties or partners

Maybe this, right here, is actually a major part of the bigger problem and not exonerating like it seems to be intended

> The reasoning behind not including SPI on the PCB wasn’t motivated by any single project or outside source – it was based on the fact that for years SPI was largely unused on PINE64 devices.

So if they only talked amongst themselves, how could they have any idea of if the SPI was already being used or not?

> And yet, despite this, we agreed to include it on the PinePhone Pro because developers from multiple projects – postmarketOS being one of them – were adamant that it was an absolute necessity.

So yeah, sounds like if they had engaged earlier, a lot of unnecessary frustration and grief could have been completely avoided.

Unfortunately this post does not even hint at the more significant point in Martijns post, the one about the relationships between PINE64 and the community distributions.

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

#86

Post by MartijnBraam »

chylat wrote: post #78
chylat wrote: post #69

Earlier quoted context omitted.

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, j…

This is just after I left. And after me saying (in not the public channel) that samuel is maintaining Tow-Boot, other developers are helping (like me) but that didn't matter.

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

#87

Post by effingwewt »

megous wrote: post #68
Aeolun wrote: post #57

Earlier quoted context omitted.

My $5 bargain bin webcam can take pictures and video at 24hz. My $200 pinephone can, on a good day, do 0.5hz. I dunno, but I expected more.

Nobody wrote the driver for H.264 HW encoder support, yet. When that happens, Pinephone will be capable of that, too. That's not a $200 proposition, though. :) And I guess there's no huge motivation, given the expected quality of the resulting image. Maybe someone will write it for some other similar AW SoC that uses the same HW block. Such is the power of FOSS.

If it's beta software and prototype hardware then they should be in the 'give it to some people willing to help with bugs and documentation' phase, not 'charge people for a phone that can't make phone calls' phase.

I used to be all for early adoption, but too many people ran off with my money via Kickstarter and Steam Early Access.

edit- add phase x2 =p

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

#88

Post by hertzrat »

yjftsjthsd-h wrote: post #83
noasaservice wrote: post #17

Earlier quoted context omitted.

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…

> 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". I'm actually on board, but do note that that's going to be a chart full of subnotes and caveats - things like "camera produces an slightly red-shifted but passable image on default software shipped from factory, red-shift is fixed with kernel 5.19-patch-foo but t…

If it’s no, but has a dozen asterisks, to the end user, that’s still a “no, this component does not work properly.” The footnotes can be 5 pages long but the chart is still straightforward

One day I’ll probably end up with a Linux phone, but I mean, not if I’m worried I’ll get surprised when it arrives

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

#89

Post by yellowapple »

> The example given in the blog post supposes that the community team and Pine Store employees were firmly intent on removing SPI on the PinePhone Pro and coerced not to ship Tow-Boot.

I don't see where in Martijn's blog post that "coercion" was "supposed" at all. What he actually wrote:

> Negotiating this solution was hell. Manjaro is incentivized not to agree to this, since it cedes their sole control over the bootloader, and PINE64 listens to Manjaro before anyone else. Furthermore, PINE64 does not actually want to add SPI flash chips to their hardware. Apparently, there has been some issues with people using SPI flash as RW storage on the A64-LTS boards, which would be a support issue.

> After months of discussions between the community, Manjaro, and PINE64 leadership, we finally were able to convince them to ship the PinePhone Pro with an SPI flash chip with Tow-Boot installed on it.

He doesn't even claim that Manjaro objected at all to the idea of adding an SPI chip and preloading Tow-Boot on it; only that they have a possible vested interest in resisting it, and that PINE64 therefore also does for as long as it considers Manjaro the preferred OS for PinePhones.

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

#90

Post by megous »

effingwewt wrote: post #87
megous wrote: post #68

Earlier quoted context omitted.

Nobody wrote the driver for H.264 HW encoder support, yet. When that happens, Pinephone will be capable of that, too. That's not a $200 proposition, though. :) And I guess there's no huge motivation, given the expected quality of the resulting image. Maybe someone will write it for some other similar AW SoC that uses the same HW block. Such is the power of FOSS.

If it's beta software and prototype hardware then they should be in the 'give it to some people willing to help with bugs and documentation' phase, not 'charge people for a phone that can't make phone calls' phase. I used to be all for early adoption, but too many people ran off with my money via Kickstarter and Steam Early Access. edit- add phase x2 =p

> If it's beta software and prototype hardware then they should be in the 'give it to some people willing to help with bugs and documentation' phase, not 'charge people for a phone that can't make phone calls' phase.

It can make phone calls.

It took a separate $31,000 kickstarter and 4 years of a multi-vendor cooperation to create and upstream then non-existent accelerated stateless video decoding API for Linux. Pine64 would have never released anything if they waited on Linux API standardization process (have multiple users of the API in kernel, etc.). And even after 2 years of availability, the only major user of the API is gstreamer, and it's still bubbling through the stack so that you can just open Firefox and play an accelerated video.

Pushing through this process even nicher accelerated encoding feature, usable pretty much only for the cameras (which are quite crappy on the OG pinephone, so motivation is already low, there), is just not going to happen for giving someone a 7 year old outdated phone worth $150 only to some enthusiasts and $0 to pretty much everyone else, lol. That's just ridiculous.

Post reply on HN