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.
True, but starting from $200 there's still room for improvement. I would purchase in no time a $350 model with double the battery plus high power LoRa RTX module with external antenna connector, and GPS receiver.
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.
They specifically don't want to have too many SKUs to manage. Adding an option for an extended battery would double their SKUs. The management side of Pine64 is pretty barebones.
Both of those positions are valid. Bigger batt for $50 more would be great, vs meeting a price point and fewest possible skus.
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.
According to [0] the limit in the US is 100Wh, so you could fit a battery that is three times bigger (assuming 3.3V). I don't know what the relevant numbers are elsewhere.
Actually it doesn't ban them, it just says that you don't need any special approval if you have less than two 100Wh batteries. Which is odd, because most people have more than two batteries if your counting batteries contained in devices like laptops/cellphones/etc. This regulation seems to apply only to standalone batteries.
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.
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.
Amps is a bad measure because it only measures size and not voltage. What you really want is Watt/Hours, this is a 38Wh Battery, in context, a 13 inch Chromebook Pixel (a pro linux laptop, sort of) was ~70Wh, a Macbook Pro 16 is 99Wh.
Laptop batteries are powering Intel/AMD x86 processors which are much more power hungry than an ARM proc I imagine. Also, Macbooks and other premium laptops have 2k or 4k screens, while this one should be more energy efficient at 1080p.
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.
I don't think there are any binary blobs in the normal atf+uboot+kernel boot path. The display will run without the mali, so. AFAIK it can be run entirely open source. There could be some additional hidden burned in place firmware to handle the early SPI/etc boot flow, but they actually document the cortex M0 mgmt processor as well. So that puts them ahead of basically everyone.
Not all the documentation is "good" the DDR controller registers are in the docs AFAIK, but lack a theory of operation section.
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.
If there are no blobs in the "normal" path, why isn't this device supported by mainline Debian without special patches? Is this code making its way into kernel/bootloader upstream so that distros can pick it up?
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
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.
I've tried the pads on the past few years' Dell XPS laptops, and the one on the MS Surface Book, and I can say they are definitely not as nice (physical touch-wise, ignoring the integration with the software at all) as Apple's.
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).
I have Apple Magic Trackpad 2 and Dell XPS 9380 touchpads next to each other right now, they're very similar, with the Dell one being slightly smoother. I liked the surface on my old Lenovo Yoga 2 Pro a bit more than both of them though, although that one was slightly less responsive for the very light moves because it required a bit of jitter filtering - Yoga 900 improved on that, but the surface was IMO worse there.
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've been an exclusive user of touchpads on some Lenovo and Dell laptops over past 10 years and I also have Apple Magic Trackpad 2 and access to a Macbook, so I have a comparison.
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).
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.
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 have one of these laptops. I would guess that he's talking about the same issue that I would describe as an "annoying touchpad" on my unit. The issue is a tad difficult to describe, but it feels like the trackpad is always a little delayed. I don't notice it when strating to move the cursor, but when ending a movement the cursor will consistently slowly slide a bit further in the direction it was being moved. This happens even for small movements, making fine adjustments a real pain.
My trackpad also won't depress anywhere near its top-right corner, to the point where it only comfortably depresses at the bottom-left.
I want to like this machine, but the issues are bad enough that I've committed to a keyboard-only setup software-wise.
My pbp arrived a few days ago. The stock image seems to introduce a small but noticeable latency when moving the cursor via the trackpad. It also seems overshoot slightly: picking out a small button usually has me circling it once or twice first.
I have the ISO version of this (2nd batch) laptop, which has a different keyboard layout, but the same touchpad.
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.
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.
I would take 4xA72 over 2xA72+4xA53 any time. Heterogeneous systems are annoying. Linux probably has some fancy scheduler settings to prefer fast cores (??) but FreeBSD will happily schedule compile jobs onto the slow-ass A53 cores when the A72s are idle, which is annoying.
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 :)
There is only 1 PCIe lane and it goes to the USB3 controller. Running from a SSD on USB3 isn't that bad, but they still haven't made default booting from USB possible yet.
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.
I use a few plugins to make web development a better experience. Nothing particularly exceptional. Syntax highlighting, nerdtree, ctr-p, linter, prettier, bracket highlighter, etc.
> 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'm sure Debian has reasons for doing it that way but the undeniable consequence is that they made a decision that resulted in more complicated package updates.
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).
I've generally found Arch to be an excellent distribution for development. It's years since I used Debian but by comparison it used to be a world of pain. Arch runs well on ARM devices; why not try that on the Samsung?
You get merge conflicts because you're relying on debian patches. You can just download a clean package from upstream, compile it and create a binary .deb for local use via Debian's packaging tools.
I cloned the Debian Git repository. I'm not relying on Debian patches, which as you've already stated are stored separately (unless they're stored separately and applied to the source code they accompany).
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.
My dad would have loved to have you instead of me. He walked in on me with the family PC taken completely apart and flipped out, lol. I agree with you though.
I also got to play around on a NeXT cube as a kid. I had no idea they were so expensive! Wikipedia says a NeXT cube cost around US$10,000 (equivalent to about $19,600 in 2019.)
For 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.
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.
Yeah, except that that's A) the designer, artisan variant, and B) a whole different class of device. IIRC, it uses a semi-integrated standalone wireless keyboard, which would add a whack ton of thickness to something that's marketed as being fairly small.
Using a reasonable OS (Linux etc), 4GB is absolutely fine for browsing and basic tasks, and indeed is often fine for development and other more-than-basic tasks as well, depending on how exactly you work (Emacs/Vim instead of an IDE, for instance).
Is 4GB considered too little under Windows these days?
It amazes me no end that when I turned 18 I was contracted to work on a Cray J90 with a staggering 128 Mwords of RAM at a financial institution, and that today 4GB is considered tight for running a consumer OS with a browser with more than a few tabs open.
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.
and I think back to the old B6700 ... for which we bought 1.5Mb of core (yes, actual hand threaded core) for $1M in the late 70s ..... it supported 40 terminals
4GB is terrible under Windows 10 (you'll be swapping all the time, which means either visibly thrashing if running a spinning disk, or wearing out a SSD with excess writes). 8GB is considered a mildly tolerable amount, and 16GB is almost the standard for "real" use. Yet under Linux, even as little as 2GB can make for an incredibly snappy and productive experience. Go figure.
Heh, Firefox doesn't have that problem at all. I don't think I have pulled more than 1 GB on it? But then again I usually only have 10-20 tabs open at the most.
For reference, I have a Thinkpad x200 with 8 GB of RAM (it has an Intel Core 2 Duo). I installed Debian with XFCE, and it idles at 300 MB of Ram, and I have yet to use more than 1.5 GB of RAM. I say that to say I think 4 GB of RAM is plenty if you use it for casual computing tasks.
I use a 2011 Dell Vostro w/ 4GB RAM and a 2010 era Core i3 as my media machine, hooked up to my TV. Handles 1080P Youtube/Netflix and Acestream streams very well.
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.
There are many used thinkpads in that price category. They tend to be easy to repair and upgrade. Almost nothing new in that price category will be repairable or upgradable.
Dell 3189 is my current portable computer. Came with Win10, (dog slow) but I fixed that with Debian stretch (awesome). Has run everything I've thrown at it including Android Studio. It's got a pretty nice keyboard for a laptop.
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.
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.