1. 73
  1. 21

    My Pinebook Pro arrived a couple of weeks ago. It runs the stock Debian pretty well, and once I got i3+Vim+Chromium properly configured it turned into a pretty decent machine for editing text, light browsing, and other “thin client”-ish tasks.

    Sadly I can confirm everything the OP posted about flaky WiFi and weird system setup out of the box. I was reminded more than anything of chasing down the arcane kernel tuning flags, power management tweaks, and system configuration tricks I learned in my early days running Linux on laptops in the early 2000s (when I used Debian and really old Thinkpads because it was all I could afford for a mobile development box).

    So on the one hand, compared to (say) a late-model HP, Dell, or Lenovo running Ubuntu or Fedora, it’s fiddly, poorly-supported, and not particularly fast at anything. On the other hand, it’s a hexacore laptop running an open architecture, open OS, and an impressive array of “portable” apps that costs $200 brand-spanking-new. That is honestly remarkable to me. With the Surface Pro X and other higher-end Windows + Chrome OS ultraportables pushing actual actually-good ARM hardware into the laptop/mobile workstation space as well, I think the next couple of years could be a really fun time to be running open systems on that platform.

    In short, it’s already pretty good and will almost certainly get better as an ecosystem. The hardware is shockingly nice for the price, and Node, Python, Rust, and the usual *nix command-line stalwarts (Git, Postgres, rsync, nginx) all work like you’d expect them to. Recent JVMs, not so much. VS Code is also basically a non-starter for now as well (community binaries don’t really work on the PBP) but I’m guessing MS will get around to it soon enough if they stick to their current push for ARM binaries on Windows.

    In the meantime, I’m back to my (relatively) old Intel-equipped HP Spectre and Surface Pro as daily drivers. The Pinebook is really promising and I look forward to having ARM really, truly well-supported for “desktop” usage under Linux. Soon. For now, it’s a cool conversation starter and a good environment to poke at text-heavy tasks without much temptation to watch random videos or play a quick game (because graphical anything is basically going back to the “bad old days” of proprietary drivers, limited performance, and missing plugins).

    1. 17

      As far as I know, linux filesystem encryption does not allow password changes

      LUKS allows password changes. It has several slots for adding passwords or keys. You can add a new one and remove the old one. Fun fact: LUKS will let you remove every key from every slot without warning you .. found that out the hard way 😅

      1. 9

        I got a Pinebook Pro as well. It’s too early to really add any big learnings from it at this point, but I will say that I really dislike the touchpad. It has some drift issues to it where after I finish moving my finger, the cursor continues in that path as if it has some sort of momentum. It’s very odd and can be irritating.

        I quite like the keyboard. It’s nice to type on. I’ve had trouble getting VS Code to run on it due to the whole arm thing, but I have seen other folks getting VS Code to work on arm. To be honest, I haven’t tried very hard to make it work.

        If anyone has suggestions for things to try out (IDEs, programming languages, compilations, etc), feel free to request here and I’ll see if I can oblige this week. I’m off until I start my new gig on Monday!

        1. 12

          My previous laptop was an Arm-based Chromebook that I nuked the OS of and put my own on. It was cheap (circa 200-250AUD?) and did me well until about 3 years in. Along the journey I learned a lot about non-x86 OS support (bad!), learned to hate locked bootloaders and had to write my own init on a remote mountain villageside because systemd decided my kernel didn’t meet its requirements to boot any more.

          Comments on various sections:


          Being stuck on a special kernel version sucks. It gets abandoned, graphics drivers never go anywhere and bugs stick around.

          The best thing I (would) hope for is some sort of “generic” mainline Linux kernel support. When this happens many more distros will be easy to get working on the device. Not sure how portable device targeting code is between BSD projects, however, and hence whether or not support is infectious.

          The state & development processes of the kernel that you criticise: what really matters is what their approach towards mainline support is going to be. A dirtily-assembled kernel could either be (1) a first step for them in kernel dev or (2) the only step for them in kernel dev; so hope for the former.


          The 16GiB of soldered-on eMMC on my last laptop seemed to be its death. Write speeds were at 1MiB/s at the end of its life and write-heavy operations (like system updates) often made it hardlock. After the third time recovering from various things in /usr/lib being zero bytes long I decided I needed to get a new laptop.

          With 64-128GiB you will (statistically) have a much better time. If you have TRIM support then perhaps even better again.

          The Pinebook Pro can also boot from external mini SD cards

          N.B. “mini” SD cards are actually a thing.

          The locked bootloader on my device (an old u-boot offshoot) decided to refuse to boot off microSD cards towards the end, preventing me from being able to use them instead of the soldered-down MMC. That made me particularly unhappy.

          I do not understand why so many SBC/similar vendors are throwing MMC on their boards. I would have assumed that microSD cards are a better default option – even for shipping devices with ones pre-installed – because of the big market availability and flexibility between vendors. Perhaps MMC is cheaper than I thought.


          Really interested in this section. Along with “fanless” and “has ethernet jack” this makes the only three criteria that actually matter to me. I do admin, education, research & IT work all over the place in bursts so having these things matters to me.

          I am running a refurbished fanless 11.6” Latitude 3160 at the moment, it ticks all 3 of these boxes.

          Electron quibble:

          and the last full charge (which degenerates over time) to 98000uAh.

          98mAh is tiny. For reference: a standard 18650 Li-ion LiCo/LiMn cell is anything from 1500mAh to 3400mAh. Most thin laptops are three or so lipo cells in series, so I expect the mAh of this battery to be somewhere in the same range. 9800mAh makes similarly little sense as they won’t have put all of these cells in parallel.

          Are you reading these values directly from /sys/class/power_supply//charge_full ? On my current laptop these numbers have too many zeroes, there is probably a standard/assumed division factor.


          but not many will miss ethernet on a laptop in 2019. Neither do I (yet).

          Heathen. You shall regret your words sir.

          throws spanners at wifi chipset


          Very curious if suspend-to-RAM is implemented. I am not aware of any ARM SBCs on the market that can do this!

          I have plotted making a computer-in-USB-keyboard before. Mechanics for a flip-out screen is possible but I have always become hung up with suspend (or equivalently low alternative idle methods).

          For it to be useful you need suspend power draw below 1W. For reference: most laptops have batteries in approx the 20-60 watt*hour (Wh) range.

          Filesystem encryption

          I have only started dabbling with this recently, however I do not believe this is correct:

          As far as I know, linux filesystem encryption does not allow password changes and so it does not make sense to ship a laptop with a default password.

          There are a million ways to encrypt disks/partitions/filesystems/folders on Linux. Some methods support key/password changes, others do not.

          As someone who had to fix other people’s computers: I would hate it for encryption to be on by default :D But it is interesting to bring this up. We’re seeing more distro installers provide encryption as an install-time option and it’s becoming more popular with Windows users adopting Bitlocker. Theft of web-browser saved credentials is otherwise really easy and would be a simple way to nab money from things like paypal accounts; let alone the fear that would grapple my heart if someone gained access to my email accounts. They should be offering a setup-time option for this if they can’t offer an install-time one instead.

          Mess of tools and programs

          You think that’s bad? >:D

          Check out the stuff that comes with miZy some time. This openWRT spinoff is brilliant from a practical point of view if you own an Orange Pi Zero (I used it in my 1.2km wifi adventures), but it’s a mess of scripts all over the place.

          I agree, everything special should be put in one folder (such as /opt/pinetools/). This makes it:

          1. Much easier for users to discover what tools they might need to use and how this particular distro spinoff varies from mainline.
          2. Much easier for devs to determine exactly how this distro spinoff varies from mainline & how far it has to go.

          Tips and tricks

          This is starting to sound like my Snow again. I had lots of self-written tools, scripts and tweaks to get things a bit saner.

          Looking forward to seeing some of the [TODOs] replaced with some bits of detail.

          1. 4

            No F***ING Ethernet!!

            1. 2

              Probably wouldn’t be too hard to add in a future version (with an adapter to handle the size difference, like on the thinkpad x1 carbon), given that the RockPro64 board also sold by Pine64, which is the same SoC as the Pinebook Pro, has ethernet.

              A USB-Ethernet adapter will suit me fine though. I’m didn’t buy a Pinebook Pro for its performance. Hopefully it lives up to my expectations when it arrives in December (fingers crossed).

              1. 4

                Cautionary sidetale: I have not had great experiences with USB ethernet adaptors.

                The cheap ones I have tried have silly faults like not sending out link pulses. This means they work in “normal” networking situations, but do not let you connect to certain other cheap devices that also don’t send out link pulses and generally are not as reliable.

                Many of my USB-C wielding friends complain about their adapter devices becoming flaky and stopping working, so I am not sure if the more expensive ones are necessarily better either.

                1. 1

                  Fair. I’ve never had to use them in a situation that relied more on link than transport level protocols, and a usb adapter. The last USB-C only computer I had was a MacBook (2015), but that died about a year ago, and I replaced it with a same-era thinkpad for 300€ and haven’t looked back, so I can’t comment on that either.

              2. 1

                What about accessing a broken router ? USB-to-Ethernet dongle?

                I want a laptop with TWO ethernet (8P8C) plugs. :)

              3. 4

                Neat, the author has opened a pull request upstream regarding one of the battery values. https://github.com/rockchip-linux/kernel/pull/196

                1. 4

                  Pine64 is promoting open hardware. The Pinebook Pro’s primary audience are people who support Pine64’s mission and want to move away from UEFI, Intel Management Machines, closed source drivers and coincidental compatibility with Linux.

                  I thought about buying one two, but what held me off was that it seemingly wasn’t going to have a wifi-chip that doesn’t need a non-free driver. Since there seem to be quite a few pre-installed packages, it might be worth running vrms to check if they didn’t add something without the user noticing.

                  The Pinebook Pro crashes around every 24 hours (5 crashes in the first 5 days). For now, I don’t suspect a hardware defect but a kernel crash in mrfixit’s kernel 4.4.196. Kernel crashes are hard to debug:

                  If it’s using Debian with systemd, it should be rather trivial to access the logs from the last boot (or rather crash) using

                  # journalctl -b -1

                  since journalctl also logs dmesg.