Pine64 should re-evaluate their community priorities(drewdevault.com)
drewdevault.com
Pine64 should re-evaluate their community priorities
https://drewdevault.com/2022/01/18/Pine64s-weird-priorities.html
135 comments
A question to you as someone from the hardware side: Why is it not a focus for hardware devs to build hardware that works with existing software? Why do I always need a special kernel for every arm64 board out there?
Often it's that there are hardware components chosen without mainline drivers, then there is also the problem of each board having a different layout. With arm64 EFI things get better but it's still a difference compared to x86 where you can boot almost any old OS on your newest laptop, thanks to PCI and other standard interfaces.
Often it's that there are hardware components chosen without mainline drivers, then there is also the problem of each board having a different layout. With arm64 EFI things get better but it's still a difference compared to x86 where you can boot almost any old OS on your newest laptop, thanks to PCI and other standard interfaces.
> A question to you as someone from the hardware side: Why is it not a focus for hardware devs to build hardware that works with existing software? Why do I always need a special kernel for every arm64 board out there?
Because the SoCs used in these sort of boards originally went into things like cheap Android set top boxes and the like. Those customers just need an image that can boot to Android and work well enough, and it is easier for the hardware vendors to hack at their in house kernel branch than to get everything upstream.
Because the SoCs used in these sort of boards originally went into things like cheap Android set top boxes and the like. Those customers just need an image that can boot to Android and work well enough, and it is easier for the hardware vendors to hack at their in house kernel branch than to get everything upstream.
Cost and power efficiency. If you want cheap portable electronics that have batteries that last forever, then you need to build SoCs that have exact features needed for a specific application and no more.
Maintaining software compatibility would mean sacrificing either price or power consumption. So a manufacturer can choose between spending money rewriting the software, or having to pay anywhere between 15¢ to $100 more per unit. If you’re making millions of units, then savings from using more limited SoCs will quickly pay for an army of software engineers.
Maintaining software compatibility would mean sacrificing either price or power consumption. So a manufacturer can choose between spending money rewriting the software, or having to pay anywhere between 15¢ to $100 more per unit. If you’re making millions of units, then savings from using more limited SoCs will quickly pay for an army of software engineers.
NetBSD builds one kernel for all supported ARM64 devices, there is no reason why Linux can't do the same. The devicetree selected by the firmware provides the description of a particular board.
supported really is key in that sentence. Does NetBSD build one kernel to rule them all because they only support a limited number of very similar ARM64 devices, or is their kernel just more flexible in adjusting itself at runtime?
Also, ARM64 is only one ISA. 32-bit has at least v5, v7 and thumb in wide circulation (though I may be off-target on what's exactly referred to as an ISA on arm).
Also, ARM64 is only one ISA. 32-bit has at least v5, v7 and thumb in wide circulation (though I may be off-target on what's exactly referred to as an ISA on arm).
> I bought a PinePhone hoping to be able to start using it and developing on it. But until it can reliably make it through the day, stay connected to the network, and not miss calls and texts, I have to use my android phone and I don't have two sim cards, so I can't really use it and develop on it.
I recently also looked at the PinePhone but felt it was too early for me to get involved, because it's very, very clear that you can't actually use it as a day-to-day phone yet, at least that's from what I gathered, but somehow you ended up with the idea that you could actually use it as a phone. I'm wondering if you never looked at their official resources for PinePhone as they make it kind of clear it's not ready to be used in any normal fashion yet?
I recently also looked at the PinePhone but felt it was too early for me to get involved, because it's very, very clear that you can't actually use it as a day-to-day phone yet, at least that's from what I gathered, but somehow you ended up with the idea that you could actually use it as a phone. I'm wondering if you never looked at their official resources for PinePhone as they make it kind of clear it's not ready to be used in any normal fashion yet?
Not sure what your experience has been, but I've been using mine as my only phone for over a year and it's been fine. Running Manjaro, which it came with (although I've been tinkering with NixOS on an SD card).
It's been a smoother ride than my previous phone, an OpenMoko FreeRunner which I got around 2008. The default OS on that was already abandonware by the time I got it!
It's been a smoother ride than my previous phone, an OpenMoko FreeRunner which I got around 2008. The default OS on that was already abandonware by the time I got it!
What's the NixOS experience like? I haven't tried in a while but my phone would get stuck on the NixOS splash screen. How did you install yours? So you have a public repo I could look at?
I used a pre-build image from Hydra. The mobile-nixos project site links to their Hydra jobs:
https://hydra.nixos.org/jobset/mobile-nixos/unstable
That links to the latest build for pinephone aarch64, e.g. https://hydra.nixos.org/build/164693256
That gives the output path, e.g. /nix/store/6py525nywqdbyjs7jy1rm9vw53hmm5f1-pine64-pinephone_full-disk-image.img
We can look up that hash on cache.nixos.org, e.g. https://cache.nixos.org/6py525nywqdbyjs7jy1rm9vw53hmm5f1.nar...
That gives us the download URL, e.g. https://cache.nixos.org/nar/087ljdm30k8wqgdhdjdhc15bmkk01g69...
We can unxz that, then trim the leading bytes according to the Nar file format (described in Dolstra's PhD thesis, figure 5.2, page 93 https://edolstra.github.io/pubs/phd-thesis.pdf ). Since this .nar only contains one file, we can just ignore the header bytes (they're padded to multiples of 8 bytes; I think in this case we need to skip the first 96 bytes). We can do this while dd-ing the image to our SD card, e.g.
Note that the above images have no usable user accounts. I mounted the resulting SD card and edited the /etc/shadow file to enable root login without a password. I could then log in to a text console, using an external keyboard :)
https://hydra.nixos.org/jobset/mobile-nixos/unstable
That links to the latest build for pinephone aarch64, e.g. https://hydra.nixos.org/build/164693256
That gives the output path, e.g. /nix/store/6py525nywqdbyjs7jy1rm9vw53hmm5f1-pine64-pinephone_full-disk-image.img
We can look up that hash on cache.nixos.org, e.g. https://cache.nixos.org/6py525nywqdbyjs7jy1rm9vw53hmm5f1.nar...
That gives us the download URL, e.g. https://cache.nixos.org/nar/087ljdm30k8wqgdhdjdhc15bmkk01g69...
We can unxz that, then trim the leading bytes according to the Nar file format (described in Dolstra's PhD thesis, figure 5.2, page 93 https://edolstra.github.io/pubs/phd-thesis.pdf ). Since this .nar only contains one file, we can just ignore the header bytes (they're padded to multiples of 8 bytes; I think in this case we need to skip the first 96 bytes). We can do this while dd-ing the image to our SD card, e.g.
sudo dd if=087ljdm30k8wqgdhdjdhc15bmkk01g69zqvr3gv13sra8pkgk387.nar of=/dev/my-sd-card bs=96 skip=1
Note that the above images have no usable user accounts. I mounted the resulting SD card and edited the /etc/shadow file to enable root login without a password. I could then log in to a text console, using an external keyboard :)
Thanks! I'll try it out again soon and see what happens.
Some notes from a Pinephone owner:
Wondering if the thoughts in this thread factor in the Pinephone Pro yet or no? I am looking to get one of those eventually. I think it just started doing pre-orders.
I got a second basic text/call line for my Pinephone but I don't use it as a phone right now. The modem is finicky when it works, seems to need a certain battery charge (like near full). I also have to restart it several times to get the modem to work. I'm using Mobian/Phosh. I'm not 100% a fan of the Phosh look/how it works multi-task wise but it does work out of the box more than a couple other "front ends" I tried. KDE Plasma was pretty but I couldn't just plug in an external monitor and have it work. Overall I like the idea of the phone/want to learn to develop for it. Unfortunately my screen is falling apart/peeling near the top edges. Also the battery even in airplane mode will die within a day or so.
What was neat was running ARM VS Code but it was slow as hell eg. 5 second click lag.
Old screenshot https://i.imgur.com/a7OHjcZ.png
Wondering if the thoughts in this thread factor in the Pinephone Pro yet or no? I am looking to get one of those eventually. I think it just started doing pre-orders.
I got a second basic text/call line for my Pinephone but I don't use it as a phone right now. The modem is finicky when it works, seems to need a certain battery charge (like near full). I also have to restart it several times to get the modem to work. I'm using Mobian/Phosh. I'm not 100% a fan of the Phosh look/how it works multi-task wise but it does work out of the box more than a couple other "front ends" I tried. KDE Plasma was pretty but I couldn't just plug in an external monitor and have it work. Overall I like the idea of the phone/want to learn to develop for it. Unfortunately my screen is falling apart/peeling near the top edges. Also the battery even in airplane mode will die within a day or so.
What was neat was running ARM VS Code but it was slow as hell eg. 5 second click lag.
Old screenshot https://i.imgur.com/a7OHjcZ.png
Here's a mini rant. Samsung Galaxy Buds. Bluetooth Headphones. I had to accept/enable like 10+ permissions just so I could turn off the default equalizer that makes everything sound bassy. That is annoying.
I can't deny that my $300 Android phone I'm using now would run circles around Pinephone Pro but I still look forward to that idea one day.
I can't deny that my $300 Android phone I'm using now would run circles around Pinephone Pro but I still look forward to that idea one day.
I can't quite understand what you're saying here. A PS5 devkit can't make calls but it's still developed for. Why does a phone need to be your daily driver to be able to develop for it?
I call tell I'm obviously missing something here and happy to be called out.
I call tell I'm obviously missing something here and happy to be called out.
A PS5 dev kit functions as a full PS5 though, so you can be reasonably certain a game developed for it will work on a real PS5. You can test it like someone playing a PS5 would by sitting in front of it with a controller.
A phone that has trouble with basic features you're expecting a final product to get right is much more effort. If you're not going to be using it like a normal phone daily, you won't find certain bugs.
What if your map app crashes when the GPS location jitters too much like in the real world? Or gives inaccurate results when you walk next to high current power line that screws with it's internal compass? It's nearly impossible to simulate day to day usage to catch these things.
But sure, you can develop for it now. But when bugs with basic features you rely on happen, you'll have to make a guess whether it's your code or the phone's bug.
Then when bugs are either fixed or deemed not OS issues, you'll have to re-test and re-develop parts of your code to cope with that over and over.
A proper working dev kit that works as a day to day phone is much more worth developing for, unless you're REALLY into the pinephone and don't mind extra work.
A phone that has trouble with basic features you're expecting a final product to get right is much more effort. If you're not going to be using it like a normal phone daily, you won't find certain bugs.
What if your map app crashes when the GPS location jitters too much like in the real world? Or gives inaccurate results when you walk next to high current power line that screws with it's internal compass? It's nearly impossible to simulate day to day usage to catch these things.
But sure, you can develop for it now. But when bugs with basic features you rely on happen, you'll have to make a guess whether it's your code or the phone's bug.
Then when bugs are either fixed or deemed not OS issues, you'll have to re-test and re-develop parts of your code to cope with that over and over.
A proper working dev kit that works as a day to day phone is much more worth developing for, unless you're REALLY into the pinephone and don't mind extra work.
That's a fair and measured answer. I sit corrected. Hadn't considered it from that point of view.
> I don't have two sim cards
Having a twin SIM card is rather cheap here, and would be a decent option for something like that. I've gotten one for tinkering with a Raspberry Pi 4G module.
I totally agree with your point though.
Having a twin SIM card is rather cheap here, and would be a decent option for something like that. I've gotten one for tinkering with a Raspberry Pi 4G module.
I totally agree with your point though.
Are these firmware-level issues that can be fixed by flashing a ROM somewhere? Or something endemic to the chip that has no hope of being fixed?
This is the entire arm community, and its so entrenched that despite SBBR/Systemready just about every single SoC manufacture and board vendor continue to follow this one off embedded mindset where everything is bound into a blob containing the firmware, OS and applications. (ex: see rpi) when just focusing on conforming the existing firmware standards would allow not only one off hacked up linux to work, but windows and various other OS's. There isn't any reason other the stubbornness and ignorance that the arm ecosystem doesn't work just like the desktop PC market at this point when it comes to being able to install any random OS on any random board.
There are some notable exceptions to this (Solidrun?) but the senior engineering has blinders on (and lots of false excuses why it wont work), and the mgmt chain likes the status quo because they see it as some kind of market segmentation strategy.
There are some notable exceptions to this (Solidrun?) but the senior engineering has blinders on (and lots of false excuses why it wont work), and the mgmt chain likes the status quo because they see it as some kind of market segmentation strategy.
I suspect that the manufacturers are frightened that someone will undercut them if they conform to an open standard.
Indeed, seems like the IBM "fiasco" with PCs looms large here. The dominance of clones was awesome for consumers, not so much for IBM.
> The dominance of clones was awesome for consumers, not so much for IBM.
Are you sure? it is really hard to predict what would have happened. Without the clones would the Apple II have taken off (it did have clones, but they would have needed to come up with a 16/32 bit upgrade pretty soon - the IIgs comes to mind though it was too late) , or maybe the mac?
Sure IBM had a name and would have got some sales, but would the platform take off? IBM did make a ton of money on PCs even if they were a bit player overall.
We can never know the above.
Are you sure? it is really hard to predict what would have happened. Without the clones would the Apple II have taken off (it did have clones, but they would have needed to come up with a 16/32 bit upgrade pretty soon - the IIgs comes to mind though it was too late) , or maybe the mac?
Sure IBM had a name and would have got some sales, but would the platform take off? IBM did make a ton of money on PCs even if they were a bit player overall.
We can never know the above.
The IBM (also Apple) clone fiasco looms large over every sector of electronics. Nobody seems interested in investing in manufacturing electronic hardware without some prospect of customer lock-in.
[topic of funding aside]
for the pinephone specifically, it feels like its ignoring what does exist?
https://xnux.eu/devices/pine64-pinephone.html there is a strong kernel which is upstreaming its changes.
Now, as a time-strapped developer, who gets told "if you wait, the fixes will appear, or you can double/triple your effort to manually patch things, and then undo that when those patches go mainline anyhow" like, I would personally be happy leaving my distro broken for 6+ months for that stuff to settle, cause elsewise you are going to be building apps to support APIs that might change completely between patch and mainline, because there isn't an abstraction layer like ios or android.
Its a new approach, drop hardware and specs, and embrace community passion, I thought it was a bad idea at the start, but I'm now sure I'm wrong.
A Kickstarter phone beginning around the same time, custom hardware and OS, even with a budget and price 3x what pine goes with, would have probably far less progress than what exists now with pine devices
for the pinephone specifically, it feels like its ignoring what does exist?
https://xnux.eu/devices/pine64-pinephone.html there is a strong kernel which is upstreaming its changes.
Now, as a time-strapped developer, who gets told "if you wait, the fixes will appear, or you can double/triple your effort to manually patch things, and then undo that when those patches go mainline anyhow" like, I would personally be happy leaving my distro broken for 6+ months for that stuff to settle, cause elsewise you are going to be building apps to support APIs that might change completely between patch and mainline, because there isn't an abstraction layer like ios or android.
Its a new approach, drop hardware and specs, and embrace community passion, I thought it was a bad idea at the start, but I'm now sure I'm wrong.
A Kickstarter phone beginning around the same time, custom hardware and OS, even with a budget and price 3x what pine goes with, would have probably far less progress than what exists now with pine devices
I'd like to point out that megi (the author of that site/kernel) refuses to upstream the improvements to the mainline linux tree, which is why it's still impossible to boot the PinePhone with a kernel.org kernel and have things working. This is not even just an issue for the PinePhone but all other Allwinner A64 based devices hit the same issues and now have to pick patches from that kernel.
The second megi decides the PinePhone or the A64 isn't interesting anymore (since the new one is Rockchip rk3399) that whole tree maintainership will collapse.
The second megi decides the PinePhone or the A64 isn't interesting anymore (since the new one is Rockchip rk3399) that whole tree maintainership will collapse.
that doesn't seem correct, https://patchwork.kernel.org/project/linux-usb/patch/2021110... e.g. megi submitting patches as late as november last year
Could you cite where they refuse to upstream?
Could you cite where they refuse to upstream?
It's mentioned in the pine64 developer chats when discussing this with megi, that +4-1 patch is a joke compared to the amount of patched code in the megi tree.
Why doesn't he want to upstream the patches?
AFAIK some things that are (or were, I may not be up-to-date there) present in the megi's tree aren't even upstreamable at all, like the modem power manager driver. When you maintain your own tree, you can be much more liberal in what goes there compared to what mainline maintainers will accept.
Because it isn't that much work to keep rebasing his tree according to megi.
Could the pmOS folks get involved and start submitting mainline patches themselves? The Mobian folks might also be interested since they probably want to minimize long-term deviations from Debian, which is based on the mainline.
We're working together with the maintainers of various distros now to first of all avoid this mess on the pinephone pro, and then on the longer term fix up pinephone in mainline.
Pinephone give a month warranty, that's it. Its a dealbreaker for any consumer. Pinephone Pro can get you through the day, but it goes for 400 plus duties, and it also only has a month warranty. Kickstarter, Indiegogo can get away scamming or false advertising.
Instead, look at Framework and Fairphone how a company can release a modular device, for a realistic price.
Instead, look at Framework and Fairphone how a company can release a modular device, for a realistic price.
I'm not fussed about the warranty so much as the "updates" period, which, if everything gets upstreamed, might be 10+ years with the pinephone, something that very very few can hold a candle to (afaik fairphone only gets there if you also include 3rd party support)
Framework is, afaik, a bunch of people who have already several long years of wrangling laptop devices and their supply chains, similarly Fairphone is on their 4th iteration, a lot of long years
And more importantly, even with all those years behind their products, I can't buy either of 'em, I however have a pinephone in my hands already
Framework is, afaik, a bunch of people who have already several long years of wrangling laptop devices and their supply chains, similarly Fairphone is on their 4th iteration, a lot of long years
And more importantly, even with all those years behind their products, I can't buy either of 'em, I however have a pinephone in my hands already
In Europe they can’t do that.
In Australia, if they had an Australian presence they couldn’t do that, but given that they don’t, and each individual is importing a device, the Australian consumer protection laws don’t apply.
> I will go on the record as saying that Manjaro Linux is a bad Linux distribution and a bad place to send this money. They have a history of internal corruption, a record of questionable spending, and a plethora of technical issues and problematic behavior in the FOSS ecosystem. What limited budget there is to go around was wasted in their hands.
Can anyone elaborate on this? I did a little search-foo but couldn't easily find some information regarding this claim...
Can anyone elaborate on this? I did a little search-foo but couldn't easily find some information regarding this claim...
My experience attempting to contribute to Manjaro (fixes to packages including some without with which packages simply hung when being built interactively, as they depended on stdin being EOF as it is in their CI environment) was met with not just a cold shoulder but active offense and hostility. They don't accept pull requests (in fact, their gitlab configuration doesn't even let one fork), nor is there a mailing list for patches. There simply is no contribution workflow, and this isn't even clearly documented (it's fine to be a "cathedral", but you should be up-front about it).
From my perspective as a Phosh developer, my experience with Manjaro was that they're often packaging unmerged work-in-progress branches with known issues just to ship new features as first (without even mentioning that they ship experimental code or where it comes from), which then causes their users to fill bunch of invalid bug reports upstream.
I rarely like to speak bad of an individual, but the lead developer is an absolute dunce. Maybe the rest of the team is wise and can make up for it, I don't care enough to check. They make braindead decisions(holding packages for weeks for 'stability'), braindead recommendations (cert expired, just set your system clock back duh), and steal code. It was obvious from the code at the time that the developer didn't even really know how to code.
/rant
/rant
You can’t even access the arch repositories from manjaro. It’s pretty wack.
This is part of their model. Manjaro’s repositories are downstream of Arch.
Except, their model is also to ship an AUR helper out of the box, despite the fact that holding back distro packages compared to upstream actively breaks AUR ones that depend on those in the core Arch repo.
If they bothered to do the same thing with the AUR that they're doing with the upstream Arch packages, it'd be one thing. But as is, basically they're claiming that their design keeps the experience "stable" despite the fact that this same decision directly causes other parts of the experience to become unstable.
If they bothered to do the same thing with the AUR that they're doing with the upstream Arch packages, it'd be one thing. But as is, basically they're claiming that their design keeps the experience "stable" despite the fact that this same decision directly causes other parts of the experience to become unstable.
I believe there was also a problem where some bad coding had every Manjaro box in the world spamming the shit out of the arch repos to the point they were crashing. I'm not sure if the fix was amicable agreement or just an upstream block.
I have mentioned a few times in the Pine64 community that they should really focus more on their compute modules. It means they can mass manufacture a single board that can be well tested, reducing overall risk and offering an upgrade path for their hardware. They can then fit their product lines with an appropriate module, even if this ends up being at the slight cost of size.
Another thing that kind of bugs me is that they currently have some "star devs" they send all of the new hardware too, but they are very over worked and split between many projects. Even they don't really get a heads up regarding what is in the pipeline. I believe if you want devs to be involved, you should somewhat consult them in the process.
> Many of the distros targetting Linux for mobile devices have people working on the important focus areas, but as a matter of necessity: to accomplish their goals when no one else is working on these problems, they had to become experts and divide their limited volunteer time between distro maintenance and software development.
Not sure if it's distro maintainers that become software devs, or the other way around.
Another thing that kind of bugs me is that they currently have some "star devs" they send all of the new hardware too, but they are very over worked and split between many projects. Even they don't really get a heads up regarding what is in the pipeline. I believe if you want devs to be involved, you should somewhat consult them in the process.
> Many of the distros targetting Linux for mobile devices have people working on the important focus areas, but as a matter of necessity: to accomplish their goals when no one else is working on these problems, they had to become experts and divide their limited volunteer time between distro maintenance and software development.
Not sure if it's distro maintainers that become software devs, or the other way around.
They are using the same SoCs across the compute modules and the products in cases, a lot of stuff is shared between them.
I deliberately got a Quartz64 instead of something like a Pinenote as I expected to work on core drivers.
I deliberately got a Quartz64 instead of something like a Pinenote as I expected to work on core drivers.
> They are using the same SoCs across the compute modules and the products in cases, a lot of stuff is shared between them.
I'm aware, each device is essentially a "copy and paste" PCB with hardware repositioned - but because it is repositioned, there is no clear upgrade path. When a board breaks, you need to wait for another manufacturing run. The SBC from a PineTab won't work in a PineBook or a PinePhone or a A64 LTS board, despite them all having very similar capabilities, power requirements, etc.
Each of the boards also has their own set of hardware revisions, as "copy and paste" is never so straight forwards in hardware. They literally already have the answer to this problem though: standardize the hardware platform into modules.
I'm aware, each device is essentially a "copy and paste" PCB with hardware repositioned - but because it is repositioned, there is no clear upgrade path. When a board breaks, you need to wait for another manufacturing run. The SBC from a PineTab won't work in a PineBook or a PinePhone or a A64 LTS board, despite them all having very similar capabilities, power requirements, etc.
Each of the boards also has their own set of hardware revisions, as "copy and paste" is never so straight forwards in hardware. They literally already have the answer to this problem though: standardize the hardware platform into modules.
Couldn’t agree more with this. I recently got a PineNote as well and was disappointed with the lack of community organization. The wiki is bare, and the people hanging on Discord and IRC just seem to be hacking on their own things.
I am motivated to start writing software for this device with a “do one thing well” philosophy, as a device like this should have. But it’s hard to get started on that when the advice for getting started on it is “you should try getting your favourite distro to run on it and go from there.”
Yeah sorry, no. I want to contribute where I can to the project as a whole, not get Doom running on an e-ink tablet.
I am motivated to start writing software for this device with a “do one thing well” philosophy, as a device like this should have. But it’s hard to get started on that when the advice for getting started on it is “you should try getting your favourite distro to run on it and go from there.”
Yeah sorry, no. I want to contribute where I can to the project as a whole, not get Doom running on an e-ink tablet.
I can empathize with the PinePhone folks because it's been out for a while, but if you decided to buy a PineNote that is 100% on you and no one else. This is fresh-off-the-chain new hardware that is only available through invites...
The monthly blog is very clear on the current state of the PineNote with only one user having successfully run a GUI and touch screen as of last week.
> the people hanging on Discord and IRC just seem to be hacking on their own things
Last I check they are unpaid and don't have to work on "your" thing.
The monthly blog is very clear on the current state of the PineNote with only one user having successfully run a GUI and touch screen as of last week.
> the people hanging on Discord and IRC just seem to be hacking on their own things
Last I check they are unpaid and don't have to work on "your" thing.
> I can empathize with the PinePhone folks because it's been out for a while, but if you decided to buy a PineNote that is 100% on you and no one else.
I'm not sure why you and the other commenter are so keen to throw me under the bus. I'm not saying that the purchase was a waste, nor that I regret buying it. And neither of you have said nothing to address any of my points about the lack of direction and community structure. I want to help make it a nice device to use but there's nothing to latch onto. The hardware is nice and worth what I paid.
> The monthly blog is very clear on the current state of the PineNote with only one user having successfully run a GUI and touch screen as of last week.
Yeah, great. Where are the efforts to package this hard work up and build on it?
> Last I check they are unpaid and don't have to work on "your" thing.
Of course they're unpaid. What I'm trying to get at is that few people are working together towards something that's usable because there's no organization. If there is anything, it's certainly not obvious. I'm not asking anyone to work on "my" thing, I don't have a "thing". I'm looking for "things" to help with, but people are just playing around.
I'm not sure why you and the other commenter are so keen to throw me under the bus. I'm not saying that the purchase was a waste, nor that I regret buying it. And neither of you have said nothing to address any of my points about the lack of direction and community structure. I want to help make it a nice device to use but there's nothing to latch onto. The hardware is nice and worth what I paid.
> The monthly blog is very clear on the current state of the PineNote with only one user having successfully run a GUI and touch screen as of last week.
Yeah, great. Where are the efforts to package this hard work up and build on it?
> Last I check they are unpaid and don't have to work on "your" thing.
Of course they're unpaid. What I'm trying to get at is that few people are working together towards something that's usable because there's no organization. If there is anything, it's certainly not obvious. I'm not asking anyone to work on "my" thing, I don't have a "thing". I'm looking for "things" to help with, but people are just playing around.
> I want to help make it a nice device to use but there's nothing to latch onto.
I'm completely confused - what do you want to latch onto? Pine64 has never been in the business of telling you what you should run. Latch onto your community. Are you a KDE guy, then latch onto the plasma community. If you are GNOME guy, then latch onto their community. There are dozens of other communities you can latch onto. Or create your own community.
Pine64 will be happy to document any community that gets their stuff to run on the PineNote, but for now they are waiting on communities to do something. If you are looking to Pine64 for a community then you are in the wrong, they intentionally do not create a community because they want every community to feel equally welcome (this isn't possible, but it seems to be their goal).
I'm explicitly saying I see your complaint as invalid and something I don't want Pine to fix. Sure they can do something about your complaint, but it will make the whole worse for everyone else.
I'm completely confused - what do you want to latch onto? Pine64 has never been in the business of telling you what you should run. Latch onto your community. Are you a KDE guy, then latch onto the plasma community. If you are GNOME guy, then latch onto their community. There are dozens of other communities you can latch onto. Or create your own community.
Pine64 will be happy to document any community that gets their stuff to run on the PineNote, but for now they are waiting on communities to do something. If you are looking to Pine64 for a community then you are in the wrong, they intentionally do not create a community because they want every community to feel equally welcome (this isn't possible, but it seems to be their goal).
I'm explicitly saying I see your complaint as invalid and something I don't want Pine to fix. Sure they can do something about your complaint, but it will make the whole worse for everyone else.
It doesn’t matter if you work on KDE or Gnome when the boot loader doesn’t work, when the display driver doesn’t work, and mainline Linux doesn’t run on the device. Everyone needs these things to work, but no one is working on them
It's quite the paradox that people are off doing weird stuff but they have no bootloader. The pmOS page refers to U-Boot like it exists and people seem to be working on the SoC and eink display at the rate they can.
Most other devices are consumer released so you get an old kernel that gets everyone at the top of the stack going right away, but then blocks mainlining since no one can correctly claim authorship of the implementation for the process of porting and fixing it.
Most other devices are consumer released so you get an old kernel that gets everyone at the top of the stack going right away, but then blocks mainlining since no one can correctly claim authorship of the implementation for the process of porting and fixing it.
> Everyone needs these things to work, but no one is working on them
A few people do seem to be working on these critical things, just not together towards any common goal. The way GP puts it, the Pine64 communities are ideologically opposed to reducing development friction because that would mean people could start thinking about doing useful things to do with these devices. Who would want that? The suggestion that the status quo is working out positively is completely baffling to me.
A few people do seem to be working on these critical things, just not together towards any common goal. The way GP puts it, the Pine64 communities are ideologically opposed to reducing development friction because that would mean people could start thinking about doing useful things to do with these devices. Who would want that? The suggestion that the status quo is working out positively is completely baffling to me.
This has only been out for a few weeks. What makes you think the people who actually know how to do anything are not working together, as opposed to working with each other via email and other private channels that we don't know about?
I suppose the *BSD and linux communities working on this might not work together much, but they are working to very different things so there isn't much they can do together. (even then I expect that they are in contact about "have you figured out X, I can't get it to work" "oh, I got that, the docs say 0x35 which doesn't work but I tried 0x36 and that seems to be everything I need" )
If you are not part of those communities, then it will be tricky to get in. However I trust people who know what they are doing in those communities are working on it. They have been in the past, it just takes them a few months.
I suppose the *BSD and linux communities working on this might not work together much, but they are working to very different things so there isn't much they can do together. (even then I expect that they are in contact about "have you figured out X, I can't get it to work" "oh, I got that, the docs say 0x35 which doesn't work but I tried 0x36 and that seems to be everything I need" )
If you are not part of those communities, then it will be tricky to get in. However I trust people who know what they are doing in those communities are working on it. They have been in the past, it just takes them a few months.
> via email and other private channels that we don't know about
That would be 0/3 on the slogan of "Open. Friendly. Community driven."
All of your replies have been complete non-sequiturs to my comments.
That would be 0/3 on the slogan of "Open. Friendly. Community driven."
All of your replies have been complete non-sequiturs to my comments.
> [...] they want every community to feel equally welcome (this isn't possible, but it seems to be their goal).
> I'm explicitly saying I see your complaint as invalid and something I don't want Pine to fix.
What a joke.
> I'm explicitly saying I see your complaint as invalid and something I don't want Pine to fix.
What a joke.
> his is fresh-off-the-chain new hardware that is only available through invites...
That changed two weeks ago. Anyone can buy it now. (if it is in stock, and Chinese New Year means you won't get it for a couple months...) They try to be clear that it boots and you can see something on the display but that is about it.
That changed two weeks ago. Anyone can buy it now. (if it is in stock, and Chinese New Year means you won't get it for a couple months...) They try to be clear that it boots and you can see something on the display but that is about it.
Yeah I remember reading that somewhere as well, but the page does not allow you to order one it seems? https://www.pine64.org/pinenote/
The "pre orders only open for developers" is a button that will take you to a page allowing you to add it to your cart. I am not ready to buy one so I removed it from my cart instead of paying, but it looks to me like anyone can buy one.
PineNote has been out for only a month or so, there are only a few thousand units in total out there and you are surprised there isn't a community yet? The only people who should be buying it these days are those trying to build a community. It isn't Pine's fault you bought something without knowing what state it was.
This kind of attitude and response is extremely offputting, toxic, and rude and doesn’t make me want to donate my time to “the project”.
I posted my genuine thoughts and experience and this is the response I get? I want to contribute to the software but there isn’t any meaningful structure in place to do so. This isn’t Pine’s first device, far from it, yet it feels like I have to start from square one.
I posted my genuine thoughts and experience and this is the response I get? I want to contribute to the software but there isn’t any meaningful structure in place to do so. This isn’t Pine’s first device, far from it, yet it feels like I have to start from square one.
This is how Pine has always operated and it has worked for them. Other places don't make you start from square one - and it is years before you get anything because of all the tim they spend getting all the parts ready.
Actually most places spend years getting Windows (android or whatever) and you are lucky if they acknowledge hobbies at all.
Actually most places spend years getting Windows (android or whatever) and you are lucky if they acknowledge hobbies at all.
> Implementing and upstreaming kernel drivers, u-Boot support, etc
Which drivers haven't been upstreamed?
Also, you say it'd take a few weeks to create a standard installer by upstreaming "the last 6 patches?" What are these patches, and where's the link? Has someone already done the work and it's just waiting to be submitted, or are you saying these patches would form the basis for two weeks more work on top of getting everything upstreamed?
> Building out a robust telephony stack for Linux
What's the current state of the telephony stack for Linux? Are there competing projects? For the most complete project, what is missing WRT the pinephone? What isn't possible to do on it currently-- say, by fucking around in a terminal window-- that must be developed for pinephone be considered to have an API suitable for a cheap, modern smart phone?
> Building a mobile user interface for Linux
Isn't Phosh this? If not, what would you suggest as an alternative to what Phosh is currently doing?
I'd like to hear the details on this. E.g., if the biggest problem with the telephony stack were that it doesn't yet support animated emojis, I'd go ahead and buy a pinephone. I suspect the problems go deeper than that. But commenters here seem to just say, "Definitely not a daily driver." I have no idea what the scope of the problem is from that.
Edit: clarifications
Which drivers haven't been upstreamed?
Also, you say it'd take a few weeks to create a standard installer by upstreaming "the last 6 patches?" What are these patches, and where's the link? Has someone already done the work and it's just waiting to be submitted, or are you saying these patches would form the basis for two weeks more work on top of getting everything upstreamed?
> Building out a robust telephony stack for Linux
What's the current state of the telephony stack for Linux? Are there competing projects? For the most complete project, what is missing WRT the pinephone? What isn't possible to do on it currently-- say, by fucking around in a terminal window-- that must be developed for pinephone be considered to have an API suitable for a cheap, modern smart phone?
> Building a mobile user interface for Linux
Isn't Phosh this? If not, what would you suggest as an alternative to what Phosh is currently doing?
I'd like to hear the details on this. E.g., if the biggest problem with the telephony stack were that it doesn't yet support animated emojis, I'd go ahead and buy a pinephone. I suspect the problems go deeper than that. But commenters here seem to just say, "Definitely not a daily driver." I have no idea what the scope of the problem is from that.
Edit: clarifications
> What's the current state of the telephony stack for Linux? Are there competing projects? For the most complete project, what is missing WRT the pinephone? What isn't possible to do on it currently-- say, by fucking around in a terminal window-- that must be developed for pinephone be considered to have an API suitable for a cheap, modern smart phone?
I can't answer this from a technical perspective. I can answer this from a user experience perspective. I use a pinephone as a daily driver. I mainly communicate with people via SMS/MMS. The current state of things is this:
Ususally SMS/MMS works, but sometimes it will stop working for a few weeks. Then I have to track down the magic AT commands I need to send to the modem to make it work again. The modem constantly disappears and reappears. This happens about 10 times a day. It will disappear for sometimes hours at a time before coming back. During this time, I cannot receive SMS/MMS or phone calls. Phone calls work, but call waiting and three way calling do not. And I forgot to mention, MMS doesn't work just yet. I have to compile a (fairly stable) MMS application from source because distros are waiting to ship it until it gets a "stable" release.
In general, I would not yet recommend a Pinephone to anyone whoever relies on their phone for anything mission critical.
I can't answer this from a technical perspective. I can answer this from a user experience perspective. I use a pinephone as a daily driver. I mainly communicate with people via SMS/MMS. The current state of things is this:
Ususally SMS/MMS works, but sometimes it will stop working for a few weeks. Then I have to track down the magic AT commands I need to send to the modem to make it work again. The modem constantly disappears and reappears. This happens about 10 times a day. It will disappear for sometimes hours at a time before coming back. During this time, I cannot receive SMS/MMS or phone calls. Phone calls work, but call waiting and three way calling do not. And I forgot to mention, MMS doesn't work just yet. I have to compile a (fairly stable) MMS application from source because distros are waiting to ship it until it gets a "stable" release.
In general, I would not yet recommend a Pinephone to anyone whoever relies on their phone for anything mission critical.
Holy moly! I'm amazed you put up with that. I would hardly call my SMS messages mission critical. But it'd be a nightmare for me to be constantly making excuses to friends about why I was appearing to ignore them.
Does Pinephone use the same stuff that Purism has been building or is there a standalone SMS/MMS app now? It was always my impression that they've been piggybacking (and good!) but the progress rate from Purism leaves a lot to be desired. I was rather surprised they were building SMS/MMS stuff on top of libpurple, like I never considered the idea of using pidgin (technically Chatty for them) for text messaging even if it makes a sort of sense. Last I heard in March, MMS was so broken that if you even just received an MMS message, it would corrupt that contact and you couldn't send or receive anything anymore from them. One 'solution' at the time seemed to include trashing the .purple/chatty/db/ folder and restarting phosh. I know someone who has both phones so I've been hearing some fun stories of brokenness, but I've yet to receive my own librem.
PinePhone does nothing. The different software stacks are a different story. You can several different phone software stacks on the phone, one is Purism's and so of course it does, but I'm not sure about the other choices.
> I was rather surprised they were building SMS/MMS stuff on top of libpurple
Chatty does not use libpurple for SMS for a while now (and never did for MMS).
> MMS was so broken
It wasn't even enabled by default, as it was explicitly marked as experimental until recently.
Chatty does not use libpurple for SMS for a while now (and never did for MMS).
> MMS was so broken
It wasn't even enabled by default, as it was explicitly marked as experimental until recently.
Ah, skimming https://source.puri.sm/Librem5/chatty/-/issues/30 I see that the incomplete work of integrating mms with purple-mm-sms and then eventually with chatty was stopped.
Where I heard from was initially a Purism employee testing MMS, but searching around the issue was probably related to this: https://forums.puri.sm/t/librem-5-can-no-longer-receive-sms-...
Where I heard from was initially a Purism employee testing MMS, but searching around the issue was probably related to this: https://forums.puri.sm/t/librem-5-can-no-longer-receive-sms-...
YES- I recently got a PinePhone and after distro hopping I felt the same way but couldn't put my finger on it. Somethings work in some distros (Mobian vs Manjaro) and it was really frustrating and its not immediately clear why it doesn't work- obviously people are working on it just not together. This is a good priority list that would help herd these cats!
I have similar feelings about my retro handheld device (RGB10, an Odroid Go Advance knockoff). Yes, the fact that it works at all and is so cheap is pretty nifty, and no, I don't really expect any support from the kind of company making this type of device. But at the end of the day, when everything is such a jumble, with a fractured ecosystem of multiple OS options that all have their own little quirks and rough corners, it's hard to get too excited about investing a lot into it.
I'm currently using Lakka on it (using the Odroid Go Super image) without too much fuss, but I'm having trouble to run most N64 games on it (like it crashes back to the launcher). Super Mario 64 works well though.
They are a small company with small revenue
Funding (1) $1.7M
Yearly Revenue (2) <$5M
How much funding can they realistic provide for those priorities? State grants from Horizon Europe projects or similar could be an alternative source for funding, probably with better recurring probabilities but it would require a champion to lead through the burocracy and in the end it's a coin toss (or lower) to get approved.
Sources: (1) https://www.crunchbase.com/organization/pine64 (2) https://www.zoominfo.com/c/pine64-inc/372007622
Funding (1) $1.7M
Yearly Revenue (2) <$5M
How much funding can they realistic provide for those priorities? State grants from Horizon Europe projects or similar could be an alternative source for funding, probably with better recurring probabilities but it would require a champion to lead through the burocracy and in the end it's a coin toss (or lower) to get approved.
Sources: (1) https://www.crunchbase.com/organization/pine64 (2) https://www.zoominfo.com/c/pine64-inc/372007622
(a) I think the article isn't asking them to provide more funding, but to consider re-allocating what they already do.
(b) I think even without actual funding, PinePhone can set the tone of priorities for the community. If they speak about this issue, people will at least listen.
(b) I think even without actual funding, PinePhone can set the tone of priorities for the community. If they speak about this issue, people will at least listen.
And, to that end, there's a lot of routes they could go to get this sort of thing done.
A public bug tracker + bounty, for example, would go a LONG way in messaging what needs to be done. Even a small amount of money ($100, $200) towards whatever issues are important would be a good signal to the community that "hey, we really need someone to do this".
A public bug tracker + bounty, for example, would go a LONG way in messaging what needs to be done. Even a small amount of money ($100, $200) towards whatever issues are important would be a good signal to the community that "hey, we really need someone to do this".
What if I make a $1b fund and put the Krita guy and the Blender team in charge of forming the company apparatus to produce a phone that's not a god damn piece of shit? I would want to stipulate right out the gate that there should be at least 100,000 $1,000 bounties paid in the first three years.
Go ahead, i'd like to see the result.
I would turn that question around. Given the stories here of bad user experience, it sounds like there is a very limited niche for the hardware. If they made something more reliable, they might be able to provide a lot more funding.
It doesn't matter what they do, someone will be unhappy. They fill a niche that I'm glad someone does. They could go for a different niche, but then they leave this one unfilled.
They are like a Syabas subsidiary or something.
I feel this. I've had a PinePhone, PineBook Pro, and was looking at their Clusterboard but I sold the PP and the PBP and didn't buy the Clusterboard all because of small hardware issues that basically persist on all of these devices today. The PBP still doesn't sleep properly without special consideration ("hacks" basically). The Clusterboard also needs tweaks to get PXE boot working (more "hacks") and a plethora of other outstanding issues that make running it for, let's say, experiments in local K8s clusters, aggravating.
With the hardware so unreliable for day to day computing it's really only for the same kinds of people who can be found with a motorbike in their garage that works, without any issues, for one glorious day out of the year.
I agree with Drew: the efforts could really use some focus but people like Drew who can both lead with wisdom and scratch a bigger itch than just theirs are in short supply in the FOSS community.
With the hardware so unreliable for day to day computing it's really only for the same kinds of people who can be found with a motorbike in their garage that works, without any issues, for one glorious day out of the year.
I agree with Drew: the efforts could really use some focus but people like Drew who can both lead with wisdom and scratch a bigger itch than just theirs are in short supply in the FOSS community.
> Implementing and upstreaming kernel drivers, u-Boot support, etc
I agree that this is important and I totally want to contribute but the truth is I don't have the knowledge to do this. Not yet at least. How does one learn how to do this?
I've written a small user space driver for some laptop USB stuff. I reverse engineered the manufacturer's proprietary applications and drivers and made a Linux program that talks to the hardware the same way. Is this the correct approach here?
I agree that this is important and I totally want to contribute but the truth is I don't have the knowledge to do this. Not yet at least. How does one learn how to do this?
I've written a small user space driver for some laptop USB stuff. I reverse engineered the manufacturer's proprietary applications and drivers and made a Linux program that talks to the hardware the same way. Is this the correct approach here?
>How does one learn how to do this?
It's not something you can learn in a fortnight. You first have to learn C and Assembly for the architecture you're using, then you need to study how different OSs on different hardware manage to make themselves boot and then you need to use this knowledge to study the SoC's documentation and implement the stuff there. If documentation were perfect maybe you'd only need to know how to program and simply follow the specification, but in these cases experience with a large number of cases is a must to navigate the environment.
It's not something you can learn in a fortnight. You first have to learn C and Assembly for the architecture you're using, then you need to study how different OSs on different hardware manage to make themselves boot and then you need to use this knowledge to study the SoC's documentation and implement the stuff there. If documentation were perfect maybe you'd only need to know how to program and simply follow the specification, but in these cases experience with a large number of cases is a must to navigate the environment.
Thanks for the pointers.
The postmarketOS wiki has some nice guides on how to work on hardware enablement for a mobile device - including mainline kernel support.
I will read it.
Which telephony stack is generally used on PinePhones (e.g. by Majaro, Mobian, etc.)?
I've found the freesmartphone.org stack to be reasonably pleasant; e.g. a couple of years ago I used it to manually delete SMS messages from a SIM http://chriswarbo.net/blog/2019-11-29-openmoko_sms_deletion....
Unfortunately the freesmartphone.org page seems to be down (archived at https://web.archive.org/web/20210327153615/http://www.freesm... )
I've found the freesmartphone.org stack to be reasonably pleasant; e.g. a couple of years ago I used it to manually delete SMS messages from a SIM http://chriswarbo.net/blog/2019-11-29-openmoko_sms_deletion....
Unfortunately the freesmartphone.org page seems to be down (archived at https://web.archive.org/web/20210327153615/http://www.freesm... )
Sxmo uses ModemManager[0] for calls+texts, and mmsd-tng[1] for MMS support. It generally works quite well (in my limited experience), modulo some dropped messages (might already be fixed?) and the modem occasionally getting filled up with messages which take a while to clear (causing newer messages to not be delivered).
I can't speak for what other distros use.
[0] https://gitlab.freedesktop.org/mobile-broadband/ModemManager [1] https://gitlab.com/kop316/mmsd/
I can't speak for what other distros use.
[0] https://gitlab.freedesktop.org/mobile-broadband/ModemManager [1] https://gitlab.com/kop316/mmsd/
> modulo some dropped messages
mmsd-tng is a lot more stable in dealing with transient network issues with 1.7, which was the cause of dropped messages (dog fooding your work helps!).
I think almost all other distros have moved to the modem manager stack (to my knowledge, UBPorts is the only one who still uses oFono). Phosh uses MM, Plasma Mobile moved to MM, and SXMO uses MM, which are the major players in phone DEs.
mmsd-tng is a lot more stable in dealing with transient network issues with 1.7, which was the cause of dropped messages (dog fooding your work helps!).
I think almost all other distros have moved to the modem manager stack (to my knowledge, UBPorts is the only one who still uses oFono). Phosh uses MM, Plasma Mobile moved to MM, and SXMO uses MM, which are the major players in phone DEs.
For the record, FSO code is archived at https://github.com/freesmartphone/
Most distros use ModemManager these days, although some still use oFono.
Most distros use ModemManager these days, although some still use oFono.
What is PinePhone's business/development model that they hope to avoid the pitfalls that befell OpenMoko?
To me, it just looks like a repeat of that attempt, and its floundering around the basics of the telephony stack.
https://en.wikipedia.org/wiki/Openmoko
To me, it just looks like a repeat of that attempt, and its floundering around the basics of the telephony stack.
https://en.wikipedia.org/wiki/Openmoko
Counterpoint regarding Manjaro. It just works. My install experience of Debian vs. Manjaro on the Framework laptop was that Manjaro was a snap while Debian asked me for driver info.
Also, Valve’s recommendation for Steamdeck developers was Manjaro. (I don’t know if they’ve updated that guidance with other options.)
https://www.gamingonlinux.com/2021/11/valve-adds-documentati...
Also, Valve’s recommendation for Steamdeck developers was Manjaro. (I don’t know if they’ve updated that guidance with other options.)
https://www.gamingonlinux.com/2021/11/valve-adds-documentati...
Did you try the "unofficial non-free" images for Debian? They're generally needed for full functionality on recent hardware.
Thanks for the suggestion! I was actually unaware of the existence of this.
I expect Ubuntu might also work quite well. I haven't tried it yet, but I may.
I expect Ubuntu might also work quite well. I haven't tried it yet, but I may.
Majaro package manager was broken when my pinephone shipped! Took me hours with a crashing UI to update and recover.
I agree, Pine64 is essentially waiting on other entities to carry this work, like Purism for example. They should at least have someone supporting software even if it only increases the rate to a drip.
How long does it take from when Purism has hardware until they sell it? Pine64 it isn't very long.
Different models, I'm glad Pine has this one as it is useful. That doesn't mean others are wrong models, but you can't be both.
Different models, I'm glad Pine has this one as it is useful. That doesn't mean others are wrong models, but you can't be both.
Yeah but if my hardware I buy is effectively useless because the software is garbage then am I likely to buy Pine64 again?
If that is your problem then you are not the target market in the first place. There are a lot of people who are unhappy with the type of devices we can buy. Pine64 is a refreshing improvement to us, but they are not to everyone.
I’m definitely their target market. However if Plasma mobile is their advertised software of choice and is unsupported by them directly I’d rather buy a Linux phone like a Librem 5 before a drop more money on another Pine64 phone. The Librem is actually getting focus and software improvements. The Pinephone is at the whim of time and energy of some good citizens when it comes to software. One of these citizens is the Librem efforts.
They can tote all day long about how focused their hardware efforts are and how that improves their release process. Adding in a developer dedicated to the software side wouldn’t change that balance. They’re not even in the same ballpark anyways.
Spoiler: I own a Librem 5 and a Pinephone.
They can tote all day long about how focused their hardware efforts are and how that improves their release process. Adding in a developer dedicated to the software side wouldn’t change that balance. They’re not even in the same ballpark anyways.
Spoiler: I own a Librem 5 and a Pinephone.
There's some context I'm missing from Drew's take on the Manjaro distribution in the note of the article.
He could be referring to multiple things, but the one I recall was the treasurer resigning, claiming he felt/was removed by the founder for blocking what he saw as misuses of donated funds and breach of the agreed spending guidelines:
https://news.ycombinator.com/item?id=23940824
The original link is dead because the database for the entire Manjaro forums was lost shortly after that, so you'll need to use archive.org if you want to read the original discussion:
https://web.archive.org/web/20200807042341/https://forum.man...
https://news.ycombinator.com/item?id=23940824
The original link is dead because the database for the entire Manjaro forums was lost shortly after that, so you'll need to use archive.org if you want to read the original discussion:
https://web.archive.org/web/20200807042341/https://forum.man...
I think the big issue with these niche products is they need to be much cheaper if the company's want to push out broken software.
Like, let's say, the pine phone was 100$.
Cool, even if it bricks after a month I'm okay. At 400$ , I'm upset.
I don't understand how anyone can feel it's ok to charge so much money for non functional products
Like, let's say, the pine phone was 100$.
Cool, even if it bricks after a month I'm okay. At 400$ , I'm upset.
I don't understand how anyone can feel it's ok to charge so much money for non functional products
the pinephone is $150, the pinephone pro is $400
Additionally, they have a very clear disclaimer about the target audience, you don't have to buy it if you don't like it.
> Beta Limited Edition PinePhones are aimed solely at early adopters. More specifically, only intend for these units to find their way into the hands of users with extensive Linux experience.
Additionally, they have a very clear disclaimer about the target audience, you don't have to buy it if you don't like it.
> Beta Limited Edition PinePhones are aimed solely at early adopters. More specifically, only intend for these units to find their way into the hands of users with extensive Linux experience.
[deleted]
No mention of the Pinecil?
https://pine64.com/product/pinecil-smart-mini-portable-solde...
Does this dilute the brand or grow it?
https://pine64.com/product/pinecil-smart-mini-portable-solde...
Does this dilute the brand or grow it?
Hard to say in a business sense, but that's the next soldering iron I want to own. I think it packs many great features that others can't match.
isn't it just a slightly different ts100?
Unfortunately, to make the whole thing work, all of the categories the author listed need to be at maximum priority. There's no stack-ranking them; fail in any and nobody cares about this platform.
If the goal is to provide an alternative to iPhones and Android devices, the table-stakes is huge. It's an extraordinary amount of work to get a new mobile platform even as far as the "not as painful to use as a Blackberry" phase of polish if building it out from scratch.
If the goal is to provide an alternative to iPhones and Android devices, the table-stakes is huge. It's an extraordinary amount of work to get a new mobile platform even as far as the "not as painful to use as a Blackberry" phase of polish if building it out from scratch.
It doesn't need to be "an alternative to iPhones and Android devices" right now. It just needs to be somewhat usable by developers; since those are the ones improving and fixing things, writing new drivers and applications, etc. Those things will be necessary for a 'consumer oriented product'.
For example, it would be unacceptable on an 'iPhone alternative' to, say, have to tweak shell scripts to set the right driver options, or whatever. However, developers might find that OK (although annoying).
For example, it would be unacceptable on an 'iPhone alternative' to, say, have to tweak shell scripts to set the right driver options, or whatever. However, developers might find that OK (although annoying).
The Windows Phones were amazing. I recently bought a 920 just to have it because I was obsessed with the design in the past (though most APIs no longer work). It is sad what happened to those phones. The hardware/camera was great imo.
> I will go on the record as saying that Manjaro Linux is a bad Linux distribution and a bad place to send this money. They have a history of internal corruption, a record of questionable spending, and a plethora of technical issues and problematic behavior in the FOSS ecosystem. What limited budget there is to go around was wasted in their hands.
Can someone explain this?
Can someone explain this?
If you feel like contributing to Pine64 but still would wait for their less mature devices like PinePhone or PineNote to become more stable, you can help them by purchasing other products like their embedded boards etc. Last year I got the Pinecil solder iron and was impressed by its quality.
They should see if they can sponsor Collabora work on this instead. Collabora has a solid track record of delivering high-quality work that is upstreamed, and former Intel Vulkan Driver lead Jason Ekstrand joining them this is exactly in their ballpark.
Ah, another software guy telling a hardware company how to run their business.
Nothing new under the sun I guess.
It's worth nothing that Pine64 is already succeeding where a lot of other companies have failed and is also designing, producing and delivering way more than many bigger companies even promised.
They probably know better.
Nothing new under the sun I guess.
It's worth nothing that Pine64 is already succeeding where a lot of other companies have failed and is also designing, producing and delivering way more than many bigger companies even promised.
They probably know better.
The librem costs more than a pine phone iirc. Does it offer things the pine phone doesn’t? Eg, I heard purism has better microcode access to their chips so maybe drivers will be easier to write?
What are Pine Phone plans about the swtich from 3G to 5G?
A footnote in the article:
"I will go on the record as saying that Manjaro Linux is a bad Linux distribution and a bad place to send this money. They have a history of internal corruption, a record of questionable spending, and a plethora of technical issues and problematic behavior in the FOSS ecosystem. What limited budget there is to go around was wasted in their hands."
I use manjaro and I love it. Never knew the community was like this though. Does anybody have more information on the above?
"I will go on the record as saying that Manjaro Linux is a bad Linux distribution and a bad place to send this money. They have a history of internal corruption, a record of questionable spending, and a plethora of technical issues and problematic behavior in the FOSS ecosystem. What limited budget there is to go around was wasted in their hands."
I use manjaro and I love it. Never knew the community was like this though. Does anybody have more information on the above?
How do you prevent manjaro from bricking itself every few months? Do you just not update it? That's why I stopped using it. I have no idea what their QA looks like but it can't be very extensive.
I'm now testing out straight-up Arch with a manually-installed KDE Plasma for a few months now (inside a VM that I frequently snapshot). No issues so far.
I'm now testing out straight-up Arch with a manually-installed KDE Plasma for a few months now (inside a VM that I frequently snapshot). No issues so far.
I just update it all the time and it never bricks.
Interesting. I was updating it once a day or so and this still happened.
It never bricked for me, but I had regular issues from updates when I used it a few years ago. I don’t remember the details, though. I switched to Arch and things are much more stable.
The only thing that annoys me on Arch (or any rolling distro) is that you have to update things like postgresql as they come, because holding that package back counts as a “partial upgrade”.
The only thing that annoys me on Arch (or any rolling distro) is that you have to update things like postgresql as they come, because holding that package back counts as a “partial upgrade”.
To me that's one of the benefits for most things, I can understand something like not wanting to take a feature bump when there's still support for a version.
You can just install that version out of aur and that package will track that specific major version.
Next time instead of an upgrade. Backup, remove the pacman package, install the air package and restore and you'll save yourself a lot of headaches.
You can just install that version out of aur and that package will track that specific major version.
Next time instead of an upgrade. Backup, remove the pacman package, install the air package and restore and you'll save yourself a lot of headaches.
Same here. Manjaro is IMHO the best "gateway drug" to Arch.
I'm a electrical hardware design engineer.
I agree, that if Pine64 has enough money to fund a full time engineer, that's a much better use than giving any money to the distros. They should be funding an embedded specialist who should focus on board bring up, because clearly we're not out of that stage yet.
I've built lots of high-volume electronics hardware that is easily as complex as a cell-phone, and the order of development is very important. I'm in the middle of such development right now... Working on software and UI is a dead last on that priority list every time.