[HN Gopher] Why I left Pine64
___________________________________________________________________
Why I left Pine64
Author : todsacerdoti
Score : 429 points
Date : 2022-08-17 11:05 UTC (11 hours ago)
(HTM) web link (blog.brixit.nl)
(TXT) w3m dump (blog.brixit.nl)
| twiclo wrote:
| 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?
| CameronNemo wrote:
| He mentioned the SHiFT 6mq elsewhere in the thread. And the
| SDM845 SoC as well.
| CivBase wrote:
| 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.
| iuugh0098fghdf wrote:
| 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.
|
| Maybe I misunderstood their value proposition.
| [deleted]
| readingnews wrote:
| 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.
| MartijnBraam wrote:
| 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.
| jancsika wrote:
| > There's the PinePhone and Librem 5
|
| Just an FYI to anyone reading this:
|
| Purism is actively making it difficult for its customers to
| receive a refund. Many of those customers have been waiting
| years for their phones.
|
| Here's just one example I found scrolling through a list of
| complaints on the purism subreddit:
|
| https://www.reddit.com/r/Purism/comments/syoydj/librem_5_ref.
| ..
|
| That's a rare case because the user reports _receiving_ a
| refund (only after a year and filing a complaint with their
| AG). There are many more complaints of users being told they
| have to wait until an unspecified shipping date to get a
| refund.
|
| It is not ethical for a company to attempt to draw out or
| flat out refuse refunds to users who have been waiting years
| for a product. And while you are certainly free to hack away
| on their hardware, until/unless their business practices
| change you ought to be explicitly discouraging users from
| (attempting) to purchase a phone (or really, anything) from
| Purism.
| megous wrote:
| You can always boot/install whatever you want on the Pro, too.
| It's just one extra step. It's as open as it ever was.
| throwaway22032 wrote:
| 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.
| jokoon wrote:
| I really want such project to succeed but I guess there is no
| market or enough money to make it happen.
|
| I've also asked repeatedly why those kind of projects are not
| using android forks instead of other things, and I never got an
| answer that made sense.
|
| Android is open source and has proven that it's a robust system,
| I don't understand why people want to use something else.
| colordrops wrote:
| 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?
| nexthash wrote:
| 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.
| igneo676 wrote:
| 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
| nexthash wrote:
| 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.
| zozbot234 wrote:
| 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).
| zozbot234 wrote:
| > 25x duplicated effort
|
| 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.
| panny wrote:
| 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.
| asdfasdf23r23r wrote:
| 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.
| nexthash wrote:
| 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.
| zozbot234 wrote:
| > 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.
| 4oo4 wrote:
| 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?
| monopoliessuck wrote:
| 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.
| Linda703 wrote:
| skymer wrote:
| 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!
|
| Why waste any more mindshare on the Pinephone?
| kop316 wrote:
| > AOSP is fully working, open source Linux-based phone software
|
| Uhh....no.I know for a Pixel 3a, you cannot even boot AOSP
| without compiling in the driver binaries:
|
| https://source.android.com/setup/build/downloading#downloadi...
|
| https://developers.google.com/android/drivers
|
| And there is an entire vendor partition (On the Pixel 3a, it
| was >400 MB). However, even if a user built AOSP with those
| drivers, VoLTE, SMS on LTE, Wi-Fi Calling, eSIM, and a few
| other things do not work.
|
| To get those features, one has to extract them from a stock
| image:
|
| https://wiki.lineageos.org/extracting_blobs_from_zips
|
| I can't imagine this is any better for newer Pixel phones, nor
| for any non-pixel phones. This will be true for compiling AOSP
| or any Android ROM.
|
| On top of which, that Pixel 3a is effectively frozen at the
| kernel it has when it reaches EoL
| mindslight wrote:
| 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.
| p1mrx wrote:
| What is "4G deprecation"? You seem to be the only person
| talking about it:
|
| https://www.google.com/search?q=%224g+deprecation%22
| mindslight wrote:
| 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.
| megous wrote:
| > Why waste any more mindshare on the Pinephone?
|
| This has some weird amount of assumptions in it.
|
| People may have any number of uses for pinephone HW. It's a
| nice SBC with display, touchscreen, battery, a lot of
| connectivity, very efficient suspend to ram implementation
| (find me a SBC that will suspend and run at 60mW), I2C and UART
| connectivity and a very nice GUI bootloader available for
| really pleasant SW development at any level.
|
| Why waste any effort writing apps for Android, when you can
| only run them on Android? SW I wrote for Pinephone, I also use
| on my other Linux tablet unrelated to pine64, and on a
| Pocketbook E-reader, and on my workstation, without any weird
| hacks or emulation. It's a nice device/phone for developers
| used to GNU/Linux way of distributing software. If you don't
| want to, there's no "security" getting in the way of doing
| pretty much anything with the phone.
|
| To devs who did nothing with Android, it's a massive waste of
| time learning all the idiosyncracies of Android, just to be
| able to make some simple app, or deal with restrictions like no
| audio recording of calls, no playback of audio into calls,
| background tasks limitations, etc. If I want to run rdbms on my
| phone to store data, I'll have it running in 1 minute. If I
| want to do it on Android and connect to it freely from whatever
| app I want, it will likely take longer if at all it would be
| possible.
|
| "Why waste any more mindshare on the Pinephone?" just shows a
| complete lack of imagination
|
| It's a versatile device that can be used for a lot of things. I
| can pop my Pinephone out of a backcover and pop it into this:
| https://megous.com/dl/tmp/1551fe95bdfade31.png and have fun
| making HW projects with it, for example.
| ocdtrekkie wrote:
| 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.
| zozbot234 wrote:
| 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.
| betwixthewires wrote:
| 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.
| selfhoster11 wrote:
| > Why waste any more mindshare on the Pinephone?
|
| Android is a horrible platform to hack on. I'd much rather hack
| on something closer to base Linux - think Maemo or similar.
| dbeley wrote:
| 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.
| zozbot234 wrote:
| 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.
| dbeley wrote:
| 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.
| MartijnBraam wrote:
| 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.
| noasaservice wrote:
| Agreed. Pine the company is a bloody tirefire. I've tried to
| support them, and have gotten burnt again and again.
|
| Nope. Just no. Let them due so a different company can take the
| oxygen and run with the community.
| preisschild wrote:
| Some more information about Manjaro: https://manjarno.snorlax.sh/
|
| Sad to see Pine64 only listening to them.
| 3np wrote:
| > 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.
| cat_plus_plus wrote:
| 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?
| lizardactivist wrote:
| 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.
| mastazi wrote:
| > 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.
| hutzlibu wrote:
| "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?
| ocdtrekkie wrote:
| 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.
| betwixthewires wrote:
| 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.
| MartijnBraam wrote:
| PINE64 hardware is not open hardware and it has never been
| marketed as such.
| yjftsjthsd-h wrote:
| Open in the sense of letting the user run whatever they
| want, not open-sourcing the hardware itself.
| Klasiaster wrote:
| 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).
| yjftsjthsd-h wrote:
| > 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.
| spijdar wrote:
| 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.
| MartijnBraam wrote:
| 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
| ddevault wrote:
| 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.
| preisschild wrote:
| Glad to see you here Drew. I really enjoy reading your blog
| now and then.
|
| Some more information about the shortcomings of Manjaro:
| https://manjarno.snorlax.sh/
| ocdtrekkie wrote:
| 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.
| ddevault wrote:
| I don't entirely disagree. In fact I wrote a blog post
| making similar arguments:
|
| https://drewdevault.com/2022/01/18/Pine64s-weird-
| priorities....
|
| Ideally Pine64 would be facilitating the development of a
| software stack which is then shared among the
| distributions. But, that's not what they're doing --
| they're all-in on relying 100% on "the community" to
| produce the software. So, given this constraint, are they
| doing it well?
|
| The answer is "no". Choosing Manjaro alone is not going to
| get the software built. As explained in TFA, the previous
| solution encouraging diversity did _more_ to get the
| software built and is largely attributable for the platform
| 's initial success in building out basic software support.
| Manjaro does not have a monopoly on the software experts,
| in fact, they have none of the software experts. By
| throwing Pine64's entire lot in with Manjaro they are
| burning the people who actually work on solving these
| problems. That's not a productive way to build and maintain
| a community.
| detaro wrote:
| 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"
| MartijnBraam wrote:
| 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.
| LtWorf wrote:
| > And in my role for the postmarketOS distribution, I developed
| the camera stack.
|
| 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.
| noname120 wrote:
| 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.
| kop316 wrote:
| > 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.
| bioemerl wrote:
| 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.
| megous wrote:
| It's not locked to anything. You're interpreting the original
| article wrong.
| dtx1 wrote:
| 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
| oefrha wrote:
| 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".
| goodpoint wrote:
| > 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.
| detaro wrote:
| How does making alternatives harder to boot and pissing of
| maintainers of software components they rely on improve their
| quality long-term?
| jovial_cavalier wrote:
| 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.
| mkesper wrote:
| Well, with SPI it was the same bootloader too.
| e2le wrote:
| > 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.
| matheusmoreira wrote:
| It's really unfortunate. I remember being excited about the
| pinephone. I had no idea this was happening behind the scenes.
|
| Why elevate Manjaro if others were doing the work? Why was that
| decision made? It doesn't make any sense to me.
|
| Thanks for all the work you've done!
| criddell wrote:
| > 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.
| ddevault wrote:
| 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.
| criddell wrote:
| That makes sense. I was thinking it was KDE vs Gnome all over
| again with a lot of duplicated effort.
| v-yadli wrote:
| 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.
| johnklos wrote:
| > others might see as a fragmented market
|
| 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.
| freedomben wrote:
| I agree with your positions, but the level of snark was
| exceeding uncalled for.
| PragmaticPulp wrote:
| 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.
| cycomanic wrote:
| 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.
| johnklos wrote:
| 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!
| PragmaticPulp wrote:
| > 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.
| yjftsjthsd-h wrote:
| > 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.
| zozbot234 wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
|
| EDIT: Actually I guess the Pi 4 added an onboard flash
| chip with an early bootloader, but I can't figure out if
| it impacts the boot order or changes how hard SD boot is:
| https://www.raspberrypi.com/documentation/computers/raspb
| err...
| ddevault wrote:
| 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.
| nexthash wrote:
| > 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.
| detaro wrote:
| 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_.
| PragmaticPulp wrote:
| 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.
| CivBase wrote:
| > 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?
| nexthash wrote:
| 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).
|
| [1] https://www.cgpgrey.com/blog/rules-for-rulers
| CivBase wrote:
| 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?
| zozbot234 wrote:
| > Can you really consider the "mass market" to be a key
| to power for Pine64
|
| Not as long as they ship Manjaro as the default OS for
| their hardware. Rolling-release distributions are not fit
| for mass-market use.
| nexthash wrote:
| 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.
| detaro wrote:
| 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.
| ajot wrote:
| 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.
| ge96 wrote:
| Hope Pine64 still continues.
|
| Recently topics such as "injecting ads into homescreen" make me
| fear for my phone.
| 3np wrote:
| 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
| GrumpyNl wrote:
| I hope they dont, the PINE64 works great for me and i have 12
| of them in production as QR-code entrance scanners.
| preisschild wrote:
| 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.
| MartijnBraam wrote:
| 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.
|
| The whole linux side is just a bit of a mess
| freedomben wrote:
| 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?
| CameronNemo wrote:
| There are standards for ARM bootloaders to have UEFI
| compat. Pine64 just needs to care.
| mfincham wrote:
| 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 :(
|
| See for instance the Allwinner D1 chip.
| MartijnBraam wrote:
| RISC-V works exactly the same as ARM from the perspective
| of pine64 and distribution and it will not solve anything
| 3np wrote:
| Oh yeah. I never thought I'd have the warm fuzzies for a USB
| PSU until the PinePower.
| freedomben wrote:
| wow... I hadn't seen that before but the PinePower looks
| absolutely incredible
| sho_hn wrote:
| 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.
| commoner wrote:
| 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.
| sho_hn wrote:
| 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.
|
| Here's a similar report by someone else: https://www.redd
| it.com/r/PINE64official/comments/qq7wv8/pine...
|
| I've seen a few others.
|
| Given the complexities of USB PD, it could also be on the
| side of the iron and then down to the version of IronOS.
| The other reporter mentions it works fine with other
| chargers, but that doesn't speak to
| correctness/compliance. I did not investigate much since
| my bench PSU is right below the PinePower on my workbench
| :)
|
| I will say it generally works nicely with the little USB-
| C-equipped power delivery breakout boards I use in
| projects, or MCU boards I've tried. I also park my phone
| on it a lot. So I am getting use out of it.
| MartijnBraam wrote:
| I hope PINE64 doesn't fail, they did great before and I think
| they could continue being great.
|
| luckily postmarketOS existed before the PinePhone and can
| easily exist after, the pine devices isn't even the majority of
| devices we support.
| bluGill wrote:
| 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)
| zozbot234 wrote:
| 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.
| MartijnBraam wrote:
| 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.
| 3np wrote:
| 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?
| Fnoord wrote:
| 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]
|
| [1] https://shop.shiftphones.com/shift6mq.html
|
| [2] https://shop.shiftphones.com/shiftmu.html
| MartijnBraam wrote:
| I think it already is better than the PPP. Also the
| SDM845 is very very fast and a lot more power efficient
| compared to the current pine64 offerings.
|
| A few postmarketOS developers are working on improving
| the support for the SHIFT hardware and it seems to be
| going great.
| [deleted]
| 3np wrote:
| 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.
| pbronez wrote:
| 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.
| t-3 wrote:
| I wa in the same boat, but flashing Tow-Boot to SPI flash
| made booting much nicer. Mine's currently booting from an SSD
| and works great.
| xrd wrote:
| Thank you for all your efforts, Martin.
|
| 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.
| ddevault wrote:
| > I'll definitely be writing to Pine and asking them to clarify
| what they as a company say about this post.
|
| Please let us know what they say.
| desertraven wrote:
| 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!
| Fnoord wrote:
| 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).
| dcz_self wrote:
| 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?
| sigmaris wrote:
| 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).
| zozbot234 wrote:
| 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.
| MartijnBraam wrote:
| 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.
| zozbot234 wrote:
| > 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.
| MartijnBraam wrote:
| 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.
| zozbot234 wrote:
| So the SPI chip is effectively useless? Is this something
| that could be fixed in a newer hardware revision?
| CameronNemo wrote:
| 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.
| MartijnBraam wrote:
| 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
| sgbeal wrote:
| 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.
| megous wrote:
| 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.
|
| Supercomputer it certainly is not, though. :D If you mean this:
| https://www.kickstarter.com/projects/pine64/pine-a64-first-1...
|
| Here's libreelec running on Pinephone (same A64 SoC)
| https://xnux.eu/log/videos/libreelec6.mp4
| solarkraft wrote:
| It seems like your expectations were wrong - and if they're
| really promosed those things you can't even be blamed.
| HidyBush wrote:
| 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?
| criddell wrote:
| These are things lots of people, even developers, do on their
| phones - play games and watch videos.
| ddevault wrote:
| 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.
| sgbeal wrote:
| > 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:
|
| https://www.kickstarter.com/projects/pine64/pine-a64-firs
| t-1...
| jprd wrote:
| I have one of the original Kickstarter A64+, it has
| happily run low disk I/O tasks for years (on account of
| the uSDcard).
|
| Right now it runs some services through Docker and is
| pretty dang solid.
|
| I've never taken any manufacturer's performance claims
| too seriously, there's always an angle.
| HidyBush wrote:
| 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"?
| criddell wrote:
| 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!".
| HidyBush wrote:
| 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.
| TylerE wrote:
| Are your feet sore from moving the goalposts that far?
| criddell wrote:
| Maybe they shouldn't include Netflix in their screenshot
| then.
| sgbeal wrote:
| > 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:
|
| https://www.kickstarter.com/projects/pine64/pine-a64-first-1.
| ..
|
| They were marketed as being "high performance" for both Linux
| and Android. They weren't, plain and simple. They were next
| to useless for anything.
| fullstop wrote:
| I ran openHAB on mine for three or four years until I replaced
| it with a Pi4.
|
| It was fantastic for that purpose, and I only migrated because
| openhabian stopped supporting Pine64.
| humanwhosits wrote:
| 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
| neilv wrote:
| 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.)
| MartijnBraam wrote:
| 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.
| bobsmith432 wrote:
| 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.
| jcul wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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).
| MartijnBraam wrote:
| 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.
| cycomanic wrote:
| 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
|
| Finally we have distributions like Manjaro who seem more
| interested in growing their slice of the pie at the cost of other
| distributions instead of growing the whole Linux ecosystem.
| https://www.reddit.com/r/linux/comments/hxpj87/change_in_man...
| bruce511 wrote:
| 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 :(
| cycomanic wrote:
| > 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.
| analognoise wrote:
| I mean I think FOSS is objectively bad for humanity. But
| I'm an outlier.
| matkoniecz wrote:
| why?
| jacooper wrote:
| What ? Why?
| 3np wrote:
| Your last link is 404ing
| cycomanic wrote:
| Weird it's working for me.
| [deleted]
| 3np wrote:
| Yeah it's back now. Was briefly missing on the altfronts as
| well so not just here.
| stjohnswarts wrote:
| Something wrong with your browser or internet connection, it
| works for me.
| stjohnswarts wrote:
| 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.
| goodpoint wrote:
| More than 95% of Ubuntu packages come straight from Debian.
|
| Ubuntu would not survive a day without it.
| stew-j wrote:
| 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? :)]
| goodpoint wrote:
| > corporations like FANGs are largely pushing OSS to use
| volunteer work to make software a commodity
|
| Corporations has been coopting Free Software for two decades by
| opposing GPL, calling it Open Source and essentially turning it
| into unpaid labor.
|
| Yet community-driven FOSS is still possible and thriving around
| things like mastodon.
|
| Remember to use a license that protects your contributions,
| your community and your users.
___________________________________________________________________
(page generated 2022-08-17 23:01 UTC)