I purchased my first smartphone just over a month ago. Until then I'd never owned a smartphone; I started with a Nokia 2630, then switched to a Samsung a107, then to an Alcatel 510A.

So I've never owned a smartphone for most of my life, and mostly didn't miss one. I don't care to check my email or use the browser on the go because I'm almost always in front a PC. If anything, the times I'm not in front of a PC, like on the bus or in bed, I'd much rather not be looking at a screen to begin with. Speaking of bus rides, I don't own a car, so I've never needed to look up directions and have my phone speak them out to me. I very rarely travel to new places, so when I do I just look up the bus route beforehand and write it down (or just memorize it).

I don't have any intention of playing phone games. I have a regular old-fashioned analog alarm clock so I don't need a phone alarm.

You could say I'm an all-round smartphone luddite.

With the COVID-19 pandemic, an interesting problem emerged. I started ordering food through a meal delivery service, which has a website that lets you track the delivery person. Since I live in a gated community apartment building, I'd note when the delivery person was a minute or two away and go down to meet them at the gate. But sometimes the delivery person would not find the place, or go farther to find parking, or just be delivering to someone else first, and I wouldn't know about it because I'd have no way to check where they were. So it happened a lot that I'd wait at the gate for 5 minutes, then go back to my apartment to check my PC and find they weren't going to arrive for some time. If they texted me, I'd have to tap out a reply on the numeric keypad that would take ages to form a cohesive sentence; if I tried to call them they'd often tell me they don't speak English so could I please text them, presumably so that they can then run the text through a translator.

I also started ordering more things delivered which get delivered to a locker. The code to open the locker is then sent to me by email, so I'd have to memorize it on my PC and then not forget it on the way to the locker.

And to be honest, even before the pandemic, I must admit having to write down the bus routes to new places, as infrequent as it was, was kind of a hassle.

Now, if you looked up the last two phones I mentioned above, you might've guessed that I was an AT&T prepaid user. The Samsung was a 2G phone, and when AT&T shut down their 2G network they gave me the Alcatel which is a 3G phone. In January 2021 they notified me that they were planning to shut down their 3G network by February 2022. I figured they might send me a new 4G or even a 5G phone, though it'll probably be a smartphone this time.

I don't want a smartphone though.

Or rather, I don't want an iPhone or an Android. While I've not used smartphones myself, I've read enough about them to know that they have closed hardware that can only be replaced by the manufacturer, closed software that is up to the whims of the manufacturer, and stop being supported a few years after release to motivate you to buy a new one. Sure, all of those points except the first one applied to my dumbphones too, but they were dumb and so weak that it didn't matter.

However there are currently two alternatives - the Purism Librem 5 and the Pine64 Pinephone. Both phones are an ARM SoC connected to a cellular modem and a touch screen in a smartphone shell. They run any Linux distro that supports the hardware, of which there are currently a handful with various levels of working functionality. The Librem 5 is much more expensive than the Pinephone, doesn't have that much better specs to justify the price, and is apparently not readily available due to shortages; I've read that some people who preordered years ago still haven't got theirs. Since I didn't need a fancy phone to begin with, I decided to buy the Pinephone.

OpenSUSE

The current batch of the Pinephone ships with Manjaro installed by default, but I didn't want to use Arch or an Arch-derived OS. Since I use OpenSUSE on my PCs, and since OpenSUSE is working on supporting the Pinephone, I installed OpenSUSE on it. However, this was a disappointing experience. The two main UI stacks for the Pinephone are phosh (ModemManager for the modem, primarily GNOME programs) and Plasma Mobile (ofono for the modem, primarily KDE and Qt programs), and both of these had bad issues.

With phosh, switching the phone to landscape would rotate the wrong way, such that the UI was upside down (I verified that iio-sensor-proxy was reporting the phone orientation correctly). Also, it happened quite often that focusing a text field would not show the on-screen keyboard. Also a lot of programs, even the built-in phone-specific ones like the Settings program, would spawn as floating windows with draggable title bars instead of maximized, and I'd have to manually drag the title bar to the top of the display to maximize them. Sometimes this was impossible because the window would spawn with the title bar outside the display, and no amount of rotating would bring it back in.

Eventually I discovered that OpenSUSE was carrying an old version of phosh, v0.10.2, whereas upstream had released v0.12.0. The maintainer of the phosh package had a package of v0.12.0 in their personal OBS repository but hadn't upstreamed it to the distribution repository for many weeks. A month later, they finally did, and so I tested that too. The floating windows bug and the on-screen keyboard bug had been fixed, but the landscape orientation was still upside-down.

With plamo, notifications would show up as large floating windows that were large enough to cover up almost everything on the screen (despite having very little content to justify it) but were also goofily offset from the top-left corner by a bit, revealing that they were floating windows. Plamo didn't have phosh's bug with the upside-down landscape, but did have a bug where every boot had a chance that the screen wouldn't rotate at all for that boot. (Again, I verified that iio-sensor-proxy was reporting the phone orientation correctly. Something with the QtSensors library that plamo uses was broken, I guess. I installed a qtsensors sample that dumped all the sensors, but it was broken due to QML errors.)

Plamo's on-screen keyboard is buggy in its own way. First of all, it doesn't have modifier keys like Ctrl. Its terminal program, qmlkonsole, adds its own keyboard layer to the bottom of its window that has these modifier keys. However even that is broken - Ctrl-C sends a C to the terminal rather than a Ctrl-C and thus doesn't kill the active program.

The plamo UI also reminded me why I stopped using KDE on my PC - various visual things that are hard-coded in the QML UI files. For example, there is an option to display the current time in 24-hours format, but this format shows 0:23 and 1:23 instead of 00:23 and 01:23, and cannot be changed because the format string is hard-coded in the QML file. (For the same reason it cannot be changed to show seconds.) The top bar showing the network, battery, etc icons was too small, but I couldn't increase its size because that too was hard-coded in the lockscreen's QML file. The aforementioned on-screen keyboard also has the layouts hard-coded in its QML file, unlike phosh's on-screen keyboard which lets you configure the layouts via a config file.

It always cracks me up when I think that KDE has managed to be less customizable than GNOME.

When I tried the new phosh a month later, I also tried the latest plamo. However all the bugs were still there. Phosh is generally a more polished UI than plamo.

Lastly, OpenSUSE still does not support full-disk encryption in the installer. FDE is critical for a phone that leaves the home, so I wasn't willing to compromise on this.

Distros I didn't consider

As I mentioned above, the phone ships with Manjaro pre-installed, but I didn't want to use it or Arch. This is mostly because I don't like the concept of the AUR, just as I don't like the concept of custom PPAs in Ubuntu. The whole point of using a Linux distro is to get your software from maintainers you can trust, and getting it from random people is the antithesis of that, especially since the packages from random people contain install scripts that run on your computer as root. Of course OpenSUSE has the equivalent of PPAs too (personal OBS repositories), but unlike Arch there is a stronger push to upstream those packges to the distribution repository where the packaging gets some semblance of a code review, so I've never had to add a random OBS repository for software that I would've had to use the AUR for.

Mobian is another popular distro, but because it's based on Debian it has outdated libraries. As a specific example, the singular camera program for the phone, Megapixels, started requiring GTK 4, but Debian and thus Mobian don't package GTK4 yet. So the Megapixels package in the Mobian repository is stuck at an older version until the next Debian release. This isn't a diss on Debian - a stable distro like Debian is great when the stability means your "working" thing remains "working" for years. But unlike a server, the Pinephone has a new and rapidly-changing software ecosystem, and the current software is not "working" in the first place and needs frequent updates, so long-term stability is not what I want from the OS right now.

I've seen SailfishOS mentioned every now and then, but it's closed source, so I have no intention of using it.

Ubuntu Touch also gets mentioned every now and then, but it support for the Pinephone is self-reportedly "not suitable for daily use", because "we do not have a PinePhone in the hands of developers interested in the installer" among other things. I also dislike Canonical in general for their past actions, so I have no intention of using a distro associated with them.

PostMarketOS

That left PostmarketOS. Not only is PostmarketOS highly functional on the phone, a bunch of the developers use Pinephones themselves and are vested in keeping it working. A lot of the other distros are in fact downstream from pmos with respect to bugfixes, firmware, etc. pmos is also the distro that created the pmos-tweaks program that is used by other distros - this program lets you tweak some of phosh's (and GNOME's) settings that aren't hooked up to its Settings program as well as some other settings like the suspend timings.

I've been using phosh with pmos and it works very well. When I installed it it had phosh v0.12.0, but it did not have the upside-down landscape bug that OpenSUSE's phosh v0.12.0 had.

As an aside, there's one more popular UI called sxmo. Unlike phosh and plamo, sxmo is based around a tiling window manager with workspaces, popup list menus, and the use of the hardware buttons and multi-finger gestures to navigate the UI. I tried it briefly but it was too hardcore even for me - I use a tiling window manager on my PCs with popup list menus that I navigate with a keyboard, but doing it on the phone with just three buttons was too slow for me to be worth it. sxmo has a variant of dmenu that responds to touch and is also usable under phosh, so I use it in some scripts that need to show lists of actions.

pmos also ships with a default Firefox (ESR) config that reskins the UI a little to make it mobile-friendly. It removes some buttons like the Forward button that aren't needed, and enables pinch-zooming. Pinch-zooming in particular is very useful to fit websites on the phone. For example, Discord's website by default would just show the left sidebar with the names of rooms and the right sidebar with the names of the room's users; the middle section with the actual text chat would be completely invisible. To make it usable, I had to zoom out in Firefox to 30% (the smallest possible zoom), then use pinch-zoom to expand just the text chat portion of the page to fill the screen.

One problem with pmos's Firefox config is that it defaults the user agent header to Firefox-on-Android's user-agent. I imagine they did this so that webservers serve mobile-sized pages to the browser, but it has the result that websites love to tell me to use their Android "app" instead with various levels of passive-aggressiveness. For example, the meal delivery website renders the live map showing the delivery person's position, then straight-up overlays it with an opaque ad for their Android "app" that cannot be dismissed. So I overrode the user-agent config in my custom user.js to be the Firefox-on-desktop-Linux user agent.

I did find one bug that made programs that ask for root permissions via polkit (such as pmos-tweaks) not work. I've documented the bug as well as the fix here. Discovering this issue required me to attach gdb to the phosh process (from a script running a tight loop to catch it as soon as it started), look up the ARM ABI to figure out a function's parameters and result from the asm because I had no debug symbols, and further gdb commands to follow the error pointer and destructure it to get its message. Finding something fundamentably broken in the first few minutes of using a thing, but also having access to the tools to debug and fix it, is of course the quintessential Linux experience :)

The only downside of pmos is that it uses OpenRC as its init system instead of systemd. It's not that I have a problem with OpenRC or an infatuation with systemd, but OpenRC does not have the equivalent of systemd user services, ie services managed by a user-scoped init that run inside a user session. (See below for why I would've liked one.)

Daily-driving the Pinephone

Of course the primary reason for the phone is to make and receive calls and SMS. In this regard, the Pinephone can be a hit or miss for you depending on where you live and what carrier options you have. For me in the USA, the Pinephone works great with T-Mobile or any MVNO that uses T-Mobile as their backbone. Specifically, the phone is able to use VoLTE for calls and 4G for mobile data, so there's no danger of it stopping working any time soon because of networks shutting down 3G.

The phone is able to go to suspend to save battery life - it appears to use about 1% battery per hour which is more than enough for what I need. More importantly, it's able to wake up from suspend instantly for incoming calls, for alarms set via the gnome-clocks program, and from pressing the power button.

Phosh's calls program, gnome-calls, does not support call blocking. I wrote a small Python script plus an OpenRC service file that uses ModemManager's D-Bus interface to listen for incoming calls, then instantly hang up based on some rules. I've posted a basic version of the script here if you find it useful.

As I said above, OpenRC doesn't have the equivalent of systemd user services, and this is one of those cases where a user session-scoped service would've been useful. Since the call-blocking script runs as a system service, it doesn't have access to the GNOME Evolution Data Server D-Bus API that contains the contacts I stored using the gnome-contacts program. So my script cannot do anything fancy like block all numbers except the ones I've listed in my contacts, or block the numbers I've listed as "Spam". Instead the script has to maintain its own copy of which numbers to allow / block.

Well, actually it doesn't. I discovered that Evolution Data Server stores the contacts in a sqlite database at a well-known location, so I've changed my script to open this DB and query it for every incoming call. This isn't a great solution because it's relying on an undocumented implementation detail that EDS uses sqlite, not to mention the rare possibility that the read will race with EDS doing a write, but it's good enough for me.

Besides, I've since added my number to the FTC's Do Not Call registry, so I don't get that much spam any more.

Another problem with the gnome-calls program is that it doesn't let you silence a call but leave it ringing. I used to do this on my dumbphones with numbers I don't recognize so that they eventually time out and go to voicemail or get disconnected, rather than letting the caller notice that a human has voluntarily hung up the call and is thus available to be bothered by another call. So I either have to rush to slowly silence the phone by lowering the volume with multiple presses of the volume button (holding it down doesn't repeat), or hang up immediately.

The gnome-clocks program has the problem that when it fires an alarm, you have to unlock the screen to silence it. This means I have to listen to it play for a few seconds before I can silence it, compared to the instant it takes me to press the top of my analog alarm clock to silence it.

I said above that the phone is able to wake from suspend for gnome-clocks alarms, but there is a caveat. gnome-clocks must be manually started at least once after the phone has rebooted, so that it can register its alarms with waked (so that the phone is woken from sleep at alarm time) and so that it's running in order to fire the alarm when it's time. This is because pmos patches gnome-clocks to register its alarms with waked, but waked only handles waking the device from suspend, not of spawning / notifying the application that registered the alarm. Upstream gnome-clocks is planning to integrate with systemd by generating new timer units instead, but that won't work for OpenRC-using pmos even when it does get implemented anyway.

Phosh has a problem that running a program from the application grid a second time focuses the existing window instead of opening a new instance of the program. While it's convenient for single-instance programs like the Calls program, it's annoying for programs like the terminal that you'd actually want multiple instances of. The kgx terminal program, that phosh distros usually default to, does have an application menu with an option to open a new window, so that can be used as a workaround. I use foot, for which I've created a custom desktop entry file that has Exec=foot --app-id 'Foot'. This changes the default app ID of foot windows from foot to Foot, which is sufficient to defeat the code in phosh that tries to look up an existing window to focus based on the desktop entry filename.

I use keepassxc on my PCs to manage my passwords and TOTPs. keepassxc is available on the Pinephone but its UI is too big for the display and it does not support touch scrolling. (Amusingly, it has an option called "Compact mode" that does nothing but remove a couple of pixels of empty padding around some toolbar icons.) The devs have stated that they don't want to make a mobile-usable UI. gnome-passwordsafe is an alternative program that supports keepassxc's database format and does have a mobile-usable UI. Unfortunately it doesn't support TOTP; support for it was merged recently but it's only planned for a future 6.0 release, not in the current 5.0 or upcoming 5.1 release. There's another program called otpclient that just does TOTPs, so that is what I use in tandem with gnome-passwordsafe, but otpclient cannot use keepassxc's database so I had to import all my TOTPs into it individually.

By the way, otpclient shows a notification when you tap an entry telling you it's copied the code to the clipboard. If you wanted to see the actual code because you want to type it in manually instead of pasting it, you probably can't because the notification will be covering it. If you try to tap the notification to make it go away, it'll spawn another copy of otpclient that then presents a modal asking you for the database decryption password, that you then have to close. Hopefully you did this all in time for the TOTP code to still be valid. I fixed this by disabling notifications in otpclient's settings.

For maps, I tried gnome-maps, but its OpenStreetMap backend doesn't have my home address, and I couldn't find any way to add a custom pin for my home address inside the program itself rather than to OSM (which I don't care to do). It also doesn't support planning public transit routes, which is the primary thing I need maps for. I also tried pure-maps but it was buggy and incomprehensible. At first it wouldn't show any map tiles because its default tileserver returned HTTP 418 (which I only discovered by running the program from a terminal and looking at its stderr, because there was no UI indication of this error); this joke status code didn't exactly make the best impression on me. I tried installing the associated osmscout-server that downloads maps locally, and then pure-maps did show map tiles. While it was still missing my home address, it did let me add a custom bookmark for it. But then I could find no way in its unlabeled, incomprehensible UI to rename it from the default name, and it didn't support transit routes either, so I gave up on it. I just use Google Maps in a browser.

I purchased the edition of the phone that comes with a USB docking bar, but apparently my docking bar is bad because the LAN connection drops if it's idle for too long and requires a power cycle of the docking bar to realize it's still connected. It isn't a problem for me because I have an ssh connection running htop and some other things open permanently while the phone is plugged in to my LAN, so the traffic keeps the interface alive.

The docking bar also allows connecting a monitor using HDMI. I've seen many mentions in the IRC channel that this is broken, so it might not work. I don't have an HDMI cable anyway, so I haven't tried it. Instead I just installed wayvnc, a VNC server that works with any wlroots-based compositors as phosh's phoc is, and connect to it from my PC with vncviewer tunneled over ssh. Of course this means I only get the 720x1440 screen rather than my PC monitor's resolution, but it's still better for doing complicated stuff that requires a mouse and keyboard instead of having to unplug them from my PC and into the docking bar. It would've been nice to have wayvnc running as a user service just like I do on my PCs, but again OpenRC doesn't have such a thing. So I made a couple of .desktop files to start and pkill -9 wayvnc respectively, so I can do quickly that from the programs list instead of a terminal.

For example, one of the problems that requires a mouse and keyboard is dealing with Firefox. It has a bunch of issues like popup menus that don't go away if you tap in an empty space, only if you tap the original button that created the menu or use a mouse to click in an empty space instead. (If it was a context menu from a long-press, there's no way to dismiss it other than with a mouse.) Also, if you rotate the screen while firefox is open, all the popup menus become unnaturally zoomed in visually but still respond to mouse clicks and finger tapping as if they were the original size. There's no way to fix this other than close Firefox and reopen it.

All that might've sounded like a rant, but I'm actually quite happy with the phone. It's not like "thing is broken and requires working around" is a Linux-specific problem - just ask Windows users how to create a new file named .gitignore in the Explorer UI, or all the users of closed-source software that have to stick with older versions of the software because they can't afford the new ones and thus have to deal with the old version's quirks, or all the users of closed-source software that have been auto-updated to newer versions with different UI and are thus forced to learn the new UI's quirks.

In fact, I went to a restaurant recently with some coworkers, and learned that apparently it's now a thing for restaurants to not offer paper menus but instead a QR code to a web page. I happened to have my Pinephone with me, and the camera program detected and scanned the QR code just fine.

The Pinephone's CPU and GPU are very weak compared to current iPhones and Androids, but that's not a problem for me since I still don't have any intention of doing anything intensive with it like games or videos. Calls, SMS, and basic browsing for e-mail and maps is all I need. I still have my dumbphone for emergencies, and I might end up needing it if the Pinephone has a problem and needs replacement parts because Pine64 ships from Hong Kong.

And of course, I can now monitor the meal delivery person while I'm waiting at the gate, know whether they're actually nearby or still a few minutes away, and respond to their texts much more quickly and easily.