Trying out the Pinebook Pro – a $200 ARM Laptop
jeremymorgan.com
jeremymorgan.com
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.
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.
I would yoink one with the biggest battery possible too.
But I would aslo do the same for several other upgrades that I particularly value. I would take as much ram as they want to offer. I would take as much ssd space as they want to offer. I would take as much ssd speed, cpu, pixels, as they can deliver. I would pay whatever it takes to make it weigh less and be smaller while still doing all that. And don't forget to put at least 2 full speed usbc/thunderbolt/hdmi ports so I can have external portable monitor without drivers.... Then again I don't want touch, or any form of face or fingerprint, or any more than the minimum gpu to run a traditional non-compositor desktop and display video at 30fps.
But now I have completely obliterated the entire concept of meeting a target intersection of functionality and price. I've thrown price right out the window.
And, that's just my personal individual set of priorities. You don't care about half the stuff I would pay anything for, and you probably do care at least a little about stuff I actively don't want. (gaming gpu, touch, face id, hell webcam at all)
So, back to the beginning, they came up with a reasonable set of functionality to target, and a reasonable price to target, and really, even though I too would like a big battery, it makes no sense to talk about $250 version that has a bigger battery.
I've used a few different small ARM SBCs which were a lot less powerful than this laptop, and the software availability is astounding: Codeblocks, Boa Constructor, Anjuta, Lazarus, Geany, Notepadqq, most languages and libraries, and many other non development related software. As an example, Libreoffice on Debian Stable is available ready to install (no build required) on i386, amd64, armel, armhf, arm64, mips, mipsel, mips64el, ppc64el, s390x. Same for example for lua (the language) while the sid (unstable) version adds another bunch of unofficial ports (alpha, hppa, m68k, powerpcspe, ppc64, ppc64el, riscv64, sh4, sparc64, x32). In many contexts one could move from x86 to ARM and never feel there is something missing because really there is almost nothing missing, save maybe for the horsepower.
38Wh is fairly small for a laptop battery.
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.
EDIT: As the commenter below pointed out, the limit is 100,000 mWh and not 10,000 mWh. I stand corrected.
[0] https://www.tsa.gov/travel/security-screening/whatcanibring/...
For context 100Wh is only about 2x most normal laptops. A few systems with secondary batteries (Thinkpads for example) come within 10-15Wh of the limit when configured into their max battery configurations (although in my case that is two batteries).
I'm betting that is something you could actually walk through security with. I can't imagine the guys running the scanner are making estimates of battery capacity. For sure I've carried more than 200Wh worth of batteries before, considering for a while I was regularly traveling with two fairly high capacity laptops, a tablet, charging battery and cellphone. I'm also not the only odd ball with more than one laptop. Now that i've slimmed it back down to one, I regularly notice other people dragging out more than one.
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 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.
Not all the documentation is "good" the DDR controller registers are in the docs AFAIK, but lack a theory of operation section.
OTOH, there is example code in TFA for that, https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/...
So, really as far as I know this is literally the most open A72 platform out there when it comes to docs you can get via google. The MALI being the problem, which means that one could consider one of the reverse engineered QC chips or the rpi better understood (because of the Adreno or vp9 efforts) but even then the documentation quality is worse.
The rest i don't know exactly. But all in all this seems like a viable replacement for the obsolete 12/13' ThinkPads coveted in some crowds. Could have more RAM, better Displays, but hey, all Open Source, so this really could be new 'ecosystem' for that.
Edit: I know this is for Allwinner, but this applies to other SOCs which embed MALI also. I'm watching this space, and it slowly 'trickles down' there. [2] https://bootlin.com/?s=Mali
There are community builds for ARM.
That being said, I could exist in the command line most of the time...
Reminds me of the days of cleaning mouse balls. Man, those things get covered with the grossest stuff.
Thought briefly about cleaning it, but then went back to my blissful ignorance.
The annoying touchpad doesn't work. It isn't accurate and difficult to click anything with any sort of accuracy. It also activates easily when you are typing.
It's honestly the biggest issue with the laptop and the primary reason why I stopped using it after a few days. I might give it another go with a different keyboard layout and disabling the touchpad. The screen and case are great. The keyboard I have is meh, but not too different from a mid-grade Chromebook.
However, apparently Pinebook's one is actually pretty problematic and needs some firmware updates to work better.
The only difference in the actual hardware that I noticed (aside of the surface texture, which is up to personal taste, and of course size, which you can easily check before even buying) is that the ones from the first half of the decade required some jitter-filtering in software, while newer ones did not. Also, Apple touchpad does an unusually big share of input filtering on the device itself, while most other ones leave it to the software (which is fine, unless your software does it poorly of course).
Generally Windows drivers for touchpads used to be shit for a very long time; this only started to change a few years ago. On GNU/Linux it depends on the configuration, but there's a ridiculous amount of ways to screw it up, so some people don't even realize that it can be better (although it seems to be getting better with recent driver stacks).
Whatever process Apple uses to finish the glass touchpad surface must be hard to replicate, because I haven't found anything comparable.
Some are bearable, but not as much of a joy to use (compared to other input devices).
Those differences are very minor though compared to how touchpads used to work and feel like on Windows 10 years ago.
When it comes to how well they work, they're all essentially equivalent. The only reason to get the Apple one is if you care about its quiet haptic feedback (the Dell XPS one clicks very loudly) - and on Linux you can actually make it even more quiet than what macOS allows you to configure ;]
I don't even notice the apple trackpad when I'm using it. Others, I do notice.
While I'll admit Apple's trackpads have been the best laptop trackpads for the past several years, I personally hate trackpads. I always make sure I have a mouse in my laptop bag.
This is going to date me, but my very first laptop was a Powerbook 170, and damn, I loved its trackball.
For my desktop, I recently switched from a mouse to a Kensington trackball because I had some wrist issues using a mouse, and it's fantastic. I was concerned that my four monitor setup would be an issue moving the pointer from end to end, but it hasn't been an issue at all.
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.
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.
If it feels alright when you don't have any plugin, then try to see which is / are causing the slow downs.
Vim shouldn't be slow without any plugin.
UPD: NetBSD prefers fast cores now: https://twitter.com/mrgtwentythree/status/121661988693740339...
4xA72@2GHz is not bad for web development (I have that on my MACCHIATObin), the thing with the RPi4 is that it has worse RAM and I/O. SD cards are garbage and you really only have USB3 to share between everything else. Having native SATA makes everything better :)
I don't think RAM is an issue though. Performance seems to scale pretty much linearly with clockspeed improvements which indicates either the RAM timing is tied to the clockspeeds (seems unlikely) so bandwidth is increasing or it already has more than it can use. That said, rk3399 designs tend to get about 20% better performance (or around 1gb/s) on synthetics.
I'm surprised better IO doesn't exist on the chip if Broadcomm planned on selling it to other customers. I don't think a single SATA port would greatly increase costs, but would have a huge impact on performance.
As a final thought, they really need to consider mounting the RAM and CPU on the other side of the PCB. That would allow good cooling solutions that don't compromise the other board functionality.
Also I usually develop my website's backend (Elixir) directly on the EC2 a1 instance it runs on :)
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'm used to Arch Linux where, for the most part, you can just download a PKGBUILD, increment the version number and you're done. Have a look at Arch [0] vs. Debian [1]. Arch's package specification just tells the build tools where to get the code and how to build it. Debian's includes all the code so the repository has to be updated first (which I tried, resulting in merge conflicts).
Perhaps this approach has advantages (like not relying on the third party code hosting) but it also comes with disadvantages.
I have no ill feelings towards the Debian project or its contributors but they are responsible for the choice that led to the issue I have, so I feel it's entirely reasonable to "blame" them (I don't feel that's the right word, they just made a tradeoff that is inconvenient to me but might make sense to them).
[0]: https://git.archlinux.org/svntogit/community.git/tree/trunk/...
[1]: https://salsa.debian.org/android-tools-team/android-platform...
Something built with hackers in mind.
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!
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...
$ uname -m -p -i
aarch64 aarch64 aarch64
$ npm --version
6.13.6For that price I am amazed we had one in our house at all. I think my dad was trailing it or something, we did not have it very long.
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...
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...)
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.
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 ?
Is 4GB considered too little under Windows these days?
I really cannot fathom what could possibly require so much memory. It’s just taking some hypertext markup, some scripts, and rendering a web-page.
I genuinely do not understand. I’m totally baffled.
Yes, it does.
I lack nothing.
https://www.bobble.tech/free-stuff/used-thinkpad-buyers-guid...
On the supply side, the very high cost of Intel CPUs has been adversely constraining the pricing flexibility of Mac computers. Apple sells orders of magnitude more iOS devices, all ARM-based; if they could sharply increase the sale of Mac computers, it would also be profitable for them -- and it might unify+simplify their software development efforts.