A Month of Pining

2020-11-28, post № 237

hardware review, #opinion, #diary, #freedom

Precisely one month ago, I opened a long awaited parcel shipped directly from Hong Kong: my very own Pinebook Pro had arrived. Eager to further my grasp on both software and hardware freedom, I unwrapped my mail and began to incorporate pine64’s flagship laptop into my workflow. Accompanying this journey, I wrote a diary which I share in this post.

Whilst a Pinebook may not boast with specs of performance, novel input methods or included licenses, it is part of a niche computing sector which values and upholds principal human rights even in the alien realm of microprocessor-based technology. Following my steadily growing discomfort regarding my computing equipment over the past months, I hoped for the Pinebook Pro to introduce me to a world of productive, in part minimalist and most importantly truly free computing experience. After a month of usage, I can confidently proclaim it to have delivered on this front more satisfactory than any other of my multitude of computing devices I have amassed over the years.

Especially in current times, it is calming to interact with an intricately mingled system of physical machinery and abstract commandments in which I can at least to a certain extent trust, lifting an ever-present veil of fear cloaking most boxes of bits. A Pinebook comes with software switches to turn off the built-in camera, microphone and WiFi card as well as Manjaro KDE Plasma running out of the box. Whilst I would prefer not having a camera or microphone built into my device at all and have a real physical switch to turn both off, as well as a more minimalist desktop environment, I am capable to entrust it my presence infront of it; in contrast to e. g. a proprietary phone lying on a tabletop nearby.

I am unaffiliated with pine64^[1] and purchased my Pinebook Pro myself. I wrote the entirety of this blog post including the diary seen below using my Pinebook^[2].

A detailed account of my experience with my Pinebook is given by a diary I wrote over the course of November 2020:

Pinebook Pro — a diary of usage

2020-10-28. I am now a piner. Whilst I bought a Pinebook a good while back, I had to wait for it shipping from Hong Kong, going through customs and shipping locally. On 2020-10-28, 20:00, however, I finally opened my package after a few hours of deliberation.

Having opened the box, a short letter thanked me for my purchase and welcomed me into the world of pine. Further examining the machine, a slick logoless black slate, I was surprised by its weight distribution. With a metallic top housing the screen, its center of mass is located far back, allowing it to tip back a bit. Overall build quality is comfortingly robust, though.
Pressing the power button located in the upper right corner of the keyboard, my Pinebook started up without problems (I mistakenly plugged the power cable into the headphone jack; fortunately nothing caught flames).
I was unsure if the trackpad had a protective layer or if its glossy appearance was part of its design — it was a protective film but I only confidently removed it a few hours later; without a flap as the screen had, peeling it off was finnicky.
An initial sudo pacman -Syu took its sweet time — it could not have been updated for over a month whilst being in transit!
When ordering, the pine folks warn about dead pixels. Whilst I do have a small amount of dead pixels a bit left of the upper-right corner of the screen, the overall screen experience is stunningly sharp as well as thoughtfully matte though the viewing angle very narrow.

Imprecisions regarding the trackpad make KDE Plasma cumbersome to use — especially with the preset small UI size. I see this as a positive: nudgingly making the user aware of the inherent bloatiness of a mouse leads to quick configuration of essential key bindings. As I ran my Manjaro first-install script (I frequently wipe my various installations, making such a script handy to have), it crashed left and right before letting pacman update (I suspect some mirrors had to have changed). After letting pacman update, only two packages could not be installed: ghc and brave; turns out a niche architecture has its drawbacks.
Software-hardware switches appear to work; I accidently disabled WiFi and then tried to find out why I could not connect my network … I question why the camera and microphone are not disabled by default (Pine+F10, Pine+F12, not Pine+F11; see the documentation on Privacy Switches).
Unfortunately, the ISO US keyboard I chose is incompatible with standard German QWERTZ: a missing key left of y (or z on QWERTY, i. e. the key twice left of x) on which LESS-THAN, GREATER-THAN and PIPE are positioned on the German layout (as I am writing this at 2020-10-29 01:00, I still do not know how to type these three characters) and an oddly positioned #-key (being swapped with the upper L-shape of the enter key). The overall typing experience is pleasant; a trackpad is mostly bloat anyways.
The lack of GHC and Brave are unfortunate. Overcoming the lack of my default choice for a browser is easy enough: just use Firefox. To still be able to compile Haskell source, I plan to rent a Debian Intel VPS and ssh into it. For now, I simply have to be content with less niche languages.

2020-10-30. Since I do want to use my Pinebook productively, yet not switch to the US keyboard layout, I needed to find a way around the missing key twice left of x. After some searching, I came across Karol Stasiak’s blog post which promisingly showed how to create a custom layout. After a few hours of tinkering and without success, I decided to hard-overwrite the standard German keyboard layout, i. e. edited /usr/share/X11/xkb/symbols/de’s 24th line:

    ...
    // 2020-10-30, Jonathan Frech's Pinebook Pro physical keyboard adjustment
    key <AC06>  { [ h, H, less, U00AB ] };
    key <AC07>  { [ j, J, U007C, U2193 ] };
    key <AC08>  { [ k, K, U005E, U2191 ] };
    key <AC09>  { [ l, L, greater, U00BB ] };
    //key <AC07>  { [         j,          J,        dead_belowdot, dead_abovedot   ] };
    ...

I decided to overload the right part of the home row: hjkl. Since < and > have a meaningful directional interpretation, less so | yet definitely ^, I think it is a reasonable layout. Adding the ability to type «↓↑» will hopefully turn out to be useful (I had to associate a symbol with Alt+Shift+{hjkl}, so I experimentally chose those four).
Something odd I noticed is that the Pinebook’s keyboard labels both keys left and right of the spacebar as “Alt” — they still have different meanings, though. Accessing @, for example, is only possible with the right “Alt” key, on other keyboards labeled “AltGr”.

I generated the entire imagery of jblog post 236 on my Pinebook. While running ImageMagick takes a few seconds, developing is perfectly possible and comfortingly free. Switching keyboards frequently causes mistypes, both my above described custom layout as well as the non-L-shaped enter key are minor hinderances.

2020-11-02. One use case I envision for my new Pinebook is to be able to effectively read PDFs. Whilst I enjoy zathura, I might for now use Firefox to view online PDFs (one may think about writing a web-zathura adaptor script). Either way, reading PDFs on a Pinebook is a pleasant experience.
Only when looking up something on the web, one notices a slight slow-down compared to more powerful machines. It gives one time to think.

2020-11-04. I now acquired a VPS (virtual private server) — hopefully I will manage to significantly stream-line my computing processes.
Especially when writing an ‘@’ symbol, e. g. to log in ssh root@213.160.73.165, I mistype Ctrl+q instead of AltGr+q. Because of this reason, I disabled the window-closing shortcut.

Useful commands to configure a (Debian-based) VPS:

% ssh root@213.160.73.165
# apt update && apt upgrade
# apt install vim curl git make ghc golang zsh htop gcc clang
# reboot
...

Note that ssh-copy-id apparently has some issues on Arch; it did not work for me. So instead of

% ssh-copy-id root@213.160.73.165
... password ...

I used

% scp ~/.ssh/id_rsa.pub root@213.160.73.165:
... password ...
% ssh root@213.160.73.165
... password ...
# cat id_rsa.pub >> .ssh/authorized_keys

which I hope to be the correct way to add an SSH key. Then I enabled SSH login server-side:

% ssh root@213.160.73.165
... password ...
# vim /etc/ssh/sshd_config
... set `PubkeyAuthentication yes` ...
# systemctl restart sshd
# logout

I want to not have be root all the time, so

# apt install sudo
# useradd -m j
# passwd j
... set password for new user 'j' ...
# EDITOR=vim visudo
... add `j ALL=(ALL:ALL) ALL` below root to give this new user all privileges ...

Since it can be quite confusing to know if one is logged in or local, I intend to mod my zsh prompt to reflect my current ‘position’. (Which led to the implementation of jt zsh-prompt --cloud.)

2020-11-05. Removing my Pinebook’s local repositories; intending to primarily use my Pinebook as a terminal to my server. Unfortunately, pacman -Syu did not yet change the ssh-copy-id shell script bug (apparently caused by a mistyped parenthesis).
One must be careful about quickly moving their Pinebook vertically; the heavy metallic screen enclosure might else rip from its hinges.
On full screen brightness, the battery holds charge only for a few hours; leaving my Pinebook asleep overnight (approx. eight hours) drains around half of a fully charged battery.
All in all I am getting more familiar with the keyboard and achieve to setup and taylor my server-Pinebook interaction more to my liking.

2020-11-06. I began to write a .tex document through SSH. Installing texlive-full is fast on the download (intra-cloud data flow) yet slow on the install (my virtual machine only runs at 1 GHz). Whilst tunneling zathura through SSH via X11 sounds viable on paper, in my experience it was laggy and pixelated. As such, I opted to use sshfs and mount my entire server-side home directory on my Pinebook, opening server-compiled PDFs in zathura client-side. One feature of zathura which is also documented in their man page: R reloads a document (zathura did not reload automatically for me when viewing changing documents on an sshfs mount).

Overall happy with my current server setup, yet intrinsically paranoid, I set PermitRootLogin prohibit-password in /etc/ssh/sshd_config (followed by systemctl restart sshd), try to monitor authentication log files via sudo grep -i 'accepted' /var/log/auth.log and hope for my user password to be adequately strong to fend off any unwanted visitors. It is scary to see the traffic to my server without a domain (sudo grep -i 'failed' /var/log/auth.log). I mainly interface with my server through my Pinebook, turning it into a portable terminal.
To avoid permanent (external) tampering with my git repositories, I intend to regularly make hard local copies of all my work.

2020-11-14. Still a happy piner. Whilst my VPS plan works in principle and after changing my sources to Debian unstable, I was able to use dvisvgm version 2.10 instead of 2.6 which has a severe bug rendering it useless to me, ssh does bring with it some sluggishness, especially when using a fullscreen terminal emulator. Furthermore, when staying connected over ssh and letting my Pinebook sleep, the connection gets broken yet I have to wait a few seconds for it to truly give up. Jerky wireless performance can irritate when working on a document or even the prompt.

Yesterday, I used my Pinebook as a torch since it was the only illuminating object at hand.

2020-11-21. Oddly enough, Manjaro hang on startup. After forcing a restart, my Pinebook hang even earlier. Doubts about power availability crept up and as the screen turned black, I knew the problem: Having let the Pinbook turned off for a few days, its battery must have fully drained. Even after writing these words, my battery is reported to be on 0% charge.

2020-11-22. I have started development on a new esoteric language — ifi^[3] — on my Pinbook, written entirely in C++.

Wanting to write a miniKanren logic gate builder^[4], I noticed not to easily be able to install Racket on my ARM architecture. Thus, I will develop miniKanren on my cloud server for the moment.

2020-11-26. Once again I came back to a dead Pinbook. Its battery does not appear to be suited for long periods of standby operation.

2020-11-27. Friday afternoon, I decided to properly format and proofread my diary telling my story of the first month as a piner and create a standalone blog post out of it. Naturally, this process is performed exclusively using my Pinebook.
Whilst the short power cord and inherent network sluggishness do to some part impede the experience, overall I am glad to have found pine64 and their Pinebook Pro, making me see a faint shimmer of light in the midst of an all-encompassing, overwhelmingly depressing computing infrastructure. I wholeheartedly wish for free hardware to establish itself as a permanent, strong and essential pillar of modern computing.

May freedom be a guiding principle.