My pbp arrived a few days ago. The stock image it ships with seemed a little laggy, probably due to aggressive cpu throttling for power. Since I'm interested in encrypted disks I knew I would be installing a new OS from the get-go.
Desiring LUKS basically rules out image-based distribution, so to find a compatible installer this [0] page was useful. I opted for straight Debian (bullseye). This amounts to a script wrapping debootstrap that adds in the local firmware and kernel patches. I was required to use a sufficiently fast and large microSD card (16 GB+). As reported on [1] and in the dedicated thread [2] there are a few small issues:
* firefox does indeed crash in the way described, though I expect this will resolve itself after an upstream update
* The brightness up/down keys do not work, though they do in the base image
* I've encountered issues with the wifi getting wedged after resuming from sleep.
Still, on the whole it seems snappier than the base image, and the track pad latencies issues I noticed there don't seem to manifest here.
Regarding the trackpad latency, have you seen that there is an update for it ? https://forum.pine64.org/announcements.php?aid=23 while it is more about the mouse moving while you are typing, it may help in your case.
Seeing all that empty internal space makes me wonder if they couldn't increase the device's appeal by fitting it with a bigger battery. 8-10 hours of charge time is good, but a $200 laptop that could go for (say) 20 or 30 hours on a charge would really turn heads.
I suppose it's possible that would require some kind of custom battery, and this is just the most appropriate battery for this enclosure they could get off-the-shelf, though.
From the technical specs it looks like it is powered via a 5V port: "Barrel Power (5V 3A) Port"
That would mean that you could plug in a battery powered portable USB charger (power bank) to increase its capacity perhaps. If 10000mAh at 5V gets you 8 hours then you you could easily extend the capacity with a couple power banks.
I don't think there is as much empty space as you think. If you look at https://youtu.be/TsNR2lECd2s?t=121 it has a Macbook air design where its wedge shaped with no vertical space in the front.
Yes, yes, and yes. I would pay a lot of money for a _small_ laptop with 30 hours of battery life. Something like a MacBook Air 11 inch would be ideal. Hopefully someone tries and cram a huge battery in this unit someday.
It's an 10,000 mAh battery, though. That's huge, isn't it? I don't know any other laptop that has a battery that big. Looking online, Macbooks seem to have around 6,000 mAh.
Increasing a single cell battery system over 10Ah is not trivial.
First, the RK3399 and it's companion PMIC is designed with single cell applications primarily.
Second, I don't know the exact reason why, but commonly available lithium cells top out at 10Ah. Even many fuel gauge ICs don't support cells larger than that.
Adding another cell requires substantial development (design/source the pack, balancing and charging circuit) and extra BOM cost, whereas single cell involves copying reference design (which I know because I'm designing hardware product around RK3399 and ~70Wh battery pack)
TL;DR; Can be done, but developers probably wanted to reduce the risk and stay on commonly walked path.
The really nice thing is that the RK3399, while an old and not particularly fast ARM, has almost entirely open documentation. A bit of googling should land both parts of the TRM, which covers every bit of the SOC's registers and devices minus the Mali.
The follow-on RK3588 announced last year with 4x A76's (and 4x A55s) in 8nm should completely crush the RK3399 performance wise. If it comes with open documentation too, it could be a killer hacker chip this year.
(just to add to that)
The RK3399 has 2x A72's with a peak frequency of 2Ghz and 4 A53's. The RPi's 4x A72s easily run at 2Ghz as well, given a heatsink. For most workloads the much faster A72s are a big advantage over the A53s.
An "annoying touchpad" is likely a dealbreaker for me. It's the holy grail for Linux to me and I feel like it's never been solved by anybody but Apple (w/o Linux).
That being said, I could exist in the command line most of the time...
Google's modern Pixelbooks have it pretty close, coming from someone who uses a Magic Trackpad all day at work. Not perfect, but really close. As I understand, Apple's magic trick was basically feeding the trackpad inputs through the iPhone's touch logic.
Apple's touchpads are nothing special, at least these days where you can easily get a high quality touchpad on pretty much anything but the cheapest laptops available. It's actually how macOS handles touchpads that makes them feel special.
However, apparently Pinebook's one is actually pretty problematic and needs some firmware updates to work better.
Is it really that much of a dealbreaker at $200? I use a MBP as my main device which I'm told has the best trackpad. I still prefer to use an external wireless mouse.
I wonder if we should return to the trackball. I have an old KVM keyboard that has one built-in, and it's not so bad. Seems like it wouldn't get in the way like a touchpad does. Why is it that we stopped using those?
The track pad in my Matebook Pro is pretty damn close to my Macbook. Feels like the older mac track pads with the physical click instead of the faked haptic click.
This is a tad tangential but has anyone done extensive software development using an ARM device?
I was able to get pretty far with a rooted Samsung tablet running Debian in a container (C++ development works great, you can install stuff like VSCode and Clang without too much trouble) but when it came to anything mobile, ironically it all fell apart because the Android toolchain isn't built for ARM64 (save the one in the Debian repositories, which is too old). I even tried to update the package myself but apparently Debian copies all the code into its own repositories and doesn't make clear how to update it.
The Pinebook Pro, having the same CPU architecture, should have the same problems, at least for now. I'm very interested in seeing them solved though.
I've done some web development work on my raspberry pi 4. It's almost there, but even using vim, some things are still too slow (I do primarily front-end development). 4gb of RAM means I can't have a ton of things going on, but it's easily enough for back-end, webpack, editor, and a handful of tabs without much issue.
Now, there are some CPU differences here. 3399 has 2 A72 cores at 2GHz and 4 A53 cores at 1.5GHz. The pi 4 can be overclocked to 1.8-2GHz pretty easily which makes it about as fast. I believe the Pi 4 GPU is slower, but it's mostly not relevant for dev work. When Ubuntu finishes working out the bugs with their 64-bit OS, it should offer another big speedup. That is probably enough to boost JS performance (and general system performance) high enough to not feel especially painful.
> but apparently Debian copies all the code into its own repositories and doesn't make clear how to update it.
Debian always keeps the maintainer's patches separate from the "clean" upstream code. I'm not saying that it can't sometimes be hard to do major updates but please don't blame the Debian folks for that, it's not cool.
I use a MACCHIATObin (Marvell Armada8k - 4xCA72@2GHz) as a second desktop. I don't do mobile, but for what I do — C (FreeBSD kernel), Rust, Elixir, D, GTK, web frontend with Firefox — everything is fine.
Also I usually develop my website's backend (Elixir) directly on the EC2 a1 instance it runs on :)
I think for now the best solution is to use this as a mobile terminal for a machine that is running an x86/64 chip then just remote in either via SSH or x2go.
Thank you for bringing this to my attention and causing me to go back and look closer at the pic.
I was JUST thinking:
* This makes all the stuff I did to set up octoprint for my 3d printer obsolete in one shot. I have spent more money than $200 and many hours trying to find unusual usb and hdmi ribbon cables and right-angle plugs, and designing and 3d printing a frame and stand for a touch screen and pi4, bt keyboard... for an end result that is frankly not very elegant. And here is all the same stuff in a much tidier package all in one effortless shot. (this is all true of pretty much any laptop of course, not just this one)
* BUT... Oh right, I keep forgetting. Laptops have batteries, which go bad in just a couple years, and many laptops do not run without the battery connected. The pi4 setup has no lithium battery to go bad in a couple years, and it's passively cooled. It can sit there plugged in and powered-on 24/7 for years, and most laptops can not.
I've been tempted by these as semi-destructible machines for my young kids to cut their teeth on. The oldest has a Chromebook but reinstalled with GalliumOS which has been perfectly adequate so far. I'd be intrigued to see a direct comparison between these as two ultra-cheap Linux options.
Why are children these days ‘allowed’ to ’destructive’? I was using my mother’s NeXT Cube back in the early nineties when I was about eleven or twelve and it’s still in mint condition. It was made very clear to me that allowing me to use it was an enormous privilege and that if I had in any way damaged it there would have been hell to pay and I have absolutely no doubt that my arse would’ve been kicked into tomorrow if I had broken my side of the deal. Teaching kids to take care of stuff is a key point in the escape from disposable consumerism.
A second-hand Thinkpad 11e might be a better option. They are designed from the get go for the education market (looks like some schools buy them in bulk), and are very sturdy. But can be had for pretty cheap on eBay in used condition, and it's just a regular Intel laptop with hardware that's all Linux-compatible.
I have an old RK3399-based Chromebook. I now end up using its Intel "Core m"-based counterpart (originally bought for my partner) more, but the ARM machine was/is 100% fine as a fancy terminal for my backend Web dev work. I had no trouble messing with Go on an even earlier ARM (Tegra K1) Chromebook.
The Surface Pro X did not take off, but I suspect that's a combination of ARM not being competitive at the high end and needing a friendlier ecosystem. ARM might do a bit better once larger core designs and denser process nodes (RK3399 is 28nm!) filter down to lower-priced devices and there's great software to run, like a refined Windows/ARM or Chrome OS w/Android or something else.
(I've been hoping for ARM to make inroads into Serious Computers for some time, so who knows, but it does seem successful in lower-end Chromebooks, and Amazon and MS are publicly experimenting with it, so...)
> You can’t fault the Pine64; everything has to be built for ARM and that’s still a work in progress. I eagerly await the day Visual Studio Code is available for ARM.
Thankfully this is changing rapidly, thanks in part to raspberry pi desktops.
Most, if not all, popular server apps are already available in ARM. Desktop apps will take time.
I've gotten my PineBook Pro and I'm seriously impressed with the build quality and feel for a $200 machine. My touchpad has a minor defect in how it was installed, but it's probably an easy fix.
[+] [-] phs|6 years ago|reply
Desiring LUKS basically rules out image-based distribution, so to find a compatible installer this [0] page was useful. I opted for straight Debian (bullseye). This amounts to a script wrapping debootstrap that adds in the local firmware and kernel patches. I was required to use a sufficiently fast and large microSD card (16 GB+). As reported on [1] and in the dedicated thread [2] there are a few small issues:
* firefox does indeed crash in the way described, though I expect this will resolve itself after an upstream update
* The brightness up/down keys do not work, though they do in the base image
* I've encountered issues with the wifi getting wedged after resuming from sleep.
Still, on the whole it seems snappier than the base image, and the track pad latencies issues I noticed there don't seem to manifest here.
[0]: https://wiki.pine64.org/index.php/Pinebook_Pro_Software_Rele... [1]: https://wiki.pine64.org/index.php/Pinebook_Pro_Debian_Instal... [2]: https://forum.pine64.org/showthread.php?tid=8487
edit: formatting.
[+] [-] herogreen|6 years ago|reply
[+] [-] smacktoward|6 years ago|reply
I suppose it's possible that would require some kind of custom battery, and this is just the most appropriate battery for this enclosure they could get off-the-shelf, though.
[+] [-] aphistic|6 years ago|reply
[+] [-] p1itopre|6 years ago|reply
[+] [-] qubex|6 years ago|reply
EDIT: As the commenter below pointed out, the limit is 100,000 mWh and not 10,000 mWh. I stand corrected.
[+] [-] davidhyde|6 years ago|reply
That would mean that you could plug in a battery powered portable USB charger (power bank) to increase its capacity perhaps. If 10000mAh at 5V gets you 8 hours then you you could easily extend the capacity with a couple power banks.
[+] [-] matt_heimer|6 years ago|reply
[+] [-] eclectocrat|6 years ago|reply
[+] [-] jolmg|6 years ago|reply
[+] [-] charwalker|6 years ago|reply
[+] [-] fest|6 years ago|reply
Second, I don't know the exact reason why, but commonly available lithium cells top out at 10Ah. Even many fuel gauge ICs don't support cells larger than that.
Adding another cell requires substantial development (design/source the pack, balancing and charging circuit) and extra BOM cost, whereas single cell involves copying reference design (which I know because I'm designing hardware product around RK3399 and ~70Wh battery pack)
TL;DR; Can be done, but developers probably wanted to reduce the risk and stay on commonly walked path.
[+] [-] StillBored|6 years ago|reply
The follow-on RK3588 announced last year with 4x A76's (and 4x A55s) in 8nm should completely crush the RK3399 performance wise. If it comes with open documentation too, it could be a killer hacker chip this year.
(just to add to that) The RK3399 has 2x A72's with a peak frequency of 2Ghz and 4 A53's. The RPi's 4x A72s easily run at 2Ghz as well, given a heatsink. For most workloads the much faster A72s are a big advantage over the A53s.
[+] [-] sneak|6 years ago|reply
[+] [-] tbyehl|6 years ago|reply
There are community builds for ARM.
https://code.headmelted.com/
https://github.com/VSCodium/vscodium
[+] [-] lanewinfield|6 years ago|reply
That being said, I could exist in the command line most of the time...
[+] [-] AgloeDreams|6 years ago|reply
[+] [-] seba_dos1|6 years ago|reply
However, apparently Pinebook's one is actually pretty problematic and needs some firmware updates to work better.
[+] [-] l3db3tt3r|6 years ago|reply
[+] [-] Balanceinfinity|6 years ago|reply
[+] [-] rchaud|6 years ago|reply
[+] [-] jolmg|6 years ago|reply
[+] [-] ColanR|6 years ago|reply
[+] [-] monocasa|6 years ago|reply
[+] [-] jammygit|6 years ago|reply
[+] [-] Youden|6 years ago|reply
I was able to get pretty far with a rooted Samsung tablet running Debian in a container (C++ development works great, you can install stuff like VSCode and Clang without too much trouble) but when it came to anything mobile, ironically it all fell apart because the Android toolchain isn't built for ARM64 (save the one in the Debian repositories, which is too old). I even tried to update the package myself but apparently Debian copies all the code into its own repositories and doesn't make clear how to update it.
The Pinebook Pro, having the same CPU architecture, should have the same problems, at least for now. I'm very interested in seeing them solved though.
[+] [-] hajile|6 years ago|reply
Now, there are some CPU differences here. 3399 has 2 A72 cores at 2GHz and 4 A53 cores at 1.5GHz. The pi 4 can be overclocked to 1.8-2GHz pretty easily which makes it about as fast. I believe the Pi 4 GPU is slower, but it's mostly not relevant for dev work. When Ubuntu finishes working out the bugs with their 64-bit OS, it should offer another big speedup. That is probably enough to boost JS performance (and general system performance) high enough to not feel especially painful.
[+] [-] zozbot234|6 years ago|reply
Debian always keeps the maintainer's patches separate from the "clean" upstream code. I'm not saying that it can't sometimes be hard to do major updates but please don't blame the Debian folks for that, it's not cool.
[+] [-] floatboth|6 years ago|reply
Also I usually develop my website's backend (Elixir) directly on the EC2 a1 instance it runs on :)
[+] [-] btreecat|6 years ago|reply
[+] [-] dmix|6 years ago|reply
Something built with hackers in mind.
[+] [-] Brian_K_White|6 years ago|reply
I was JUST thinking:
* This makes all the stuff I did to set up octoprint for my 3d printer obsolete in one shot. I have spent more money than $200 and many hours trying to find unusual usb and hdmi ribbon cables and right-angle plugs, and designing and 3d printing a frame and stand for a touch screen and pi4, bt keyboard... for an end result that is frankly not very elegant. And here is all the same stuff in a much tidier package all in one effortless shot. (this is all true of pretty much any laptop of course, not just this one)
* BUT... Oh right, I keep forgetting. Laptops have batteries, which go bad in just a couple years, and many laptops do not run without the battery connected. The pi4 setup has no lithium battery to go bad in a couple years, and it's passively cooled. It can sit there plugged in and powered-on 24/7 for years, and most laptops can not.
So you just removed that issue. Thanks!
[+] [-] hajile|6 years ago|reply
The big question for me is drivers. Last I checked, rk3399 SBCs had terrible issues with non-android linux GPU drivers. Has that been fixed yet?
EDIT: looks like the biggest 64-bit issues have now been fixed. I'll have to try again. Now to get it booting from an external SSD...
https://ubuntu.com/blog/updated-images-of-ubuntu-for-the-ras...
[+] [-] jessaustin|6 years ago|reply
[+] [-] JeremyMorgan|6 years ago|reply
[+] [-] throw0x2away|6 years ago|reply
[+] [-] thom|6 years ago|reply
[+] [-] qubex|6 years ago|reply
[+] [-] int_19h|6 years ago|reply
[+] [-] s17n|6 years ago|reply
[+] [-] rahuldottech|6 years ago|reply
I really want to get this just so I can hack the hell out of it. With all that empty space in the case, there are so many possibilities...
[+] [-] twotwotwo|6 years ago|reply
The Surface Pro X did not take off, but I suspect that's a combination of ARM not being competitive at the high end and needing a friendlier ecosystem. ARM might do a bit better once larger core designs and denser process nodes (RK3399 is 28nm!) filter down to lower-priced devices and there's great software to run, like a refined Windows/ARM or Chrome OS w/Android or something else.
(I've been hoping for ARM to make inroads into Serious Computers for some time, so who knows, but it does seem successful in lower-end Chromebooks, and Amazon and MS are publicly experimenting with it, so...)
[+] [-] 3fe9a03ccd14ca5|6 years ago|reply
Thankfully this is changing rapidly, thanks in part to raspberry pi desktops.
Most, if not all, popular server apps are already available in ARM. Desktop apps will take time.
[+] [-] seabrookmx|6 years ago|reply
[+] [-] Evidlo|6 years ago|reply
[+] [-] nwrk|6 years ago|reply
4GB RAM sounds terrible even for browsing and basic tasks.
I'm looking to switching to one of those devices in future, so far on trusted Thinkpad x230 (no FHD, $150 USD) for travel purposes.
Can anyone comment on "no NPM yet that I know of though" ?
Does node development work normally ?
[+] [-] ocdtrekkie|6 years ago|reply
[+] [-] smnscu|6 years ago|reply
[+] [-] Scarbutt|6 years ago|reply