@geniusmusing I've only tried #Manjaro once and cannot remember why I quickly dumped it, but I do recall it being based on #Arch. Arch, of course, is known for being a rolling-release distro that sometimes requires manual intervention as part of its update process.
Still, reading that they just package existing software and don't create the drivers and other software necessary to make the hardware function, I think #Pine64 made the worst possible choice.
I had Pine64 as a stretch goal for a future phone, but I guess I will work toward a phoneless future.
>We rarely, if ever, make responses to blog posts or articles. In fact, there is only one instance that I can think of when we did so. So then, somewhat uncharacteristically, this is a response post to Martijn Braam’s blog in which he explains why he left the PINE64 community. Let’s get one thing out of the way first: Martijn has done a lot for mobile Linux and PINE64 – he is a valued contributor and a colleague with a good insight into how PINE64 and the Pine Store Ltd operate. I should add that his opinions are welcome just as they have always been. Finally, there is no denying that his leaving is a significant loss to the project and, on a private level, a sad state of affairs for us in the community. If it wasn’t clear, we really like Martijn. But this isn’t what this blog post is about. Instead, this is a response to the points and concerns Martijn raises. > >A short summary first: Martijn’s blog entry alleges that following PinePhone community editions, and after settling on Manjaro with KDE’s plasma mobile as the default OS, PINE64 and the Pine Store Ltd have sidelined developers from other mobile Linux projects. The argument is made that this has hurt development. 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. He concludes by saying that we no longer listen to the development community. >...
Q: Question from a non technical person interested in the project. In a hypothetical world where this SPI thingy was dropped, how would this affect/change the process of changing or replacing the OS?
A: In case of PinePhone Pro and Pinebook Pro (so all devices which are using RK3399 SoC), as was stated in Martijn’s blog, all OS developers will need to agree on specific structure on the eMMC, so when user will be changing the OS, the bootloader (u-boot or tow-boot), will not be replaced, or corrupted. So for example, if any OS will try to install their own bootloader (replacing the old one), and something bad will happen during installation, it might result on non-bootable device, and it will require to re-flash bootloader via SD Card (with hardware eMMC boot bypass).