|
|
|
|
@ -1,254 +1,254 @@ |
|
|
|
|
{% if type == "rss" %} |
|
|
|
|
{% extends "rss-item.xml" %} |
|
|
|
|
{% extends "rss-item.xml" %} |
|
|
|
|
{% else %} |
|
|
|
|
{% extends "blog-post.html" %} |
|
|
|
|
{% extends "blog-post.html" %} |
|
|
|
|
{% endif %} |
|
|
|
|
|
|
|
|
|
{% block title %}A Couple Weeks with the PinePhone{% endblock title %} |
|
|
|
|
{% block date %}2021-04-29{% endblock date %} |
|
|
|
|
{% block summary %} |
|
|
|
|
I got my Mobian Community Edition PinePhone around mid-May and have been living |
|
|
|
|
with it as my only smartphone ever since. In this post, I'd like to discuss a |
|
|
|
|
bit of that experience, the positives and negatives, and some of my hopes for |
|
|
|
|
the future of PinePhones broadly and Mobian specifically. |
|
|
|
|
I got my Mobian Community Edition PinePhone around mid-May and have been living |
|
|
|
|
with it as my only smartphone ever since. In this post, I'd like to discuss a |
|
|
|
|
bit of that experience, the positives and negatives, and some of my hopes for |
|
|
|
|
the future of PinePhones broadly and Mobian specifically. |
|
|
|
|
{% endblock summary %} |
|
|
|
|
{% block content %} |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Firstly, let's just be honest about what the |
|
|
|
|
<a href="https://pine64.com/product/pinephone-beta-edition-linux-smartphone/">PinePhone</a> |
|
|
|
|
is at the moment. Right |
|
|
|
|
now, the PinePhone is a fully-functional smartphone, meaning it can make |
|
|
|
|
phone calls, receive and send text messages (though not, as of now, MMS), |
|
|
|
|
access maps using GPS (although not directed GPS navigation - yet), and access |
|
|
|
|
the internet via browsers and apps. However, what the PinePhone lacks is a well-developed |
|
|
|
|
app ecosystem such as those of Android or iOS. For example, I have yet to find |
|
|
|
|
a way to access Facebook Messenger from my phone, a communication app that was |
|
|
|
|
previously one of the central pillars of my digital communications. Additionally, |
|
|
|
|
I can't use Snapchat or Instagram or Venmo or CashApp or any of the other apps |
|
|
|
|
that are staples on almost any young person's (and most any older person's) phone |
|
|
|
|
these days. In fact, I would argue that it's better to think of a PinePhone as a tiny Linux |
|
|
|
|
computer that can make phone calls and send text messages and use mobile data. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Now, for those familiar with Linux, this might not sound so bad. There's at |
|
|
|
|
least one program for almost anything a computer can do, often many more; that's |
|
|
|
|
a pretty big app ecosystem! Alas, Linux developers are stretched incredibly thin |
|
|
|
|
and there is as-of-yet little support for the kind of adaptive/reactive scaling |
|
|
|
|
needed to make apps usable on a tiny screen like that of the PinePhone. While |
|
|
|
|
Mobian's default shell, phosh, provides `scale-to-fit`, and other shells |
|
|
|
|
provide similar functionality, this just makes the actual elements of the app |
|
|
|
|
GUI smaller. So, for example, if you `scale-to-fit` GNOME Calendars, it will |
|
|
|
|
all fit on the screen, but each day of the month will be miniscule, the |
|
|
|
|
headerbar will be virtually unusable due to size, and so on. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Fortunately, this is changing. The recent libadwaita from the GNOME project - |
|
|
|
|
which is functionally GTK 4, a graphical user interface (GUI) toolkit library - includes elements from |
|
|
|
|
libhandy, a GTK 3-friendly GUI library that helps develop reactive apps. Personally, |
|
|
|
|
I've tried to develop with libhandy in the past, and while it's fairly simple |
|
|
|
|
to do using the old-fashioned method of handwriting code to layout one's GUI, |
|
|
|
|
it's much less friendly to the now-preferred GNOME development method of using |
|
|
|
|
XML files to layout an app interface (somewhat like writing a website in HTML |
|
|
|
|
then scripting it with JavaScript). Unfortunately, the GNOME XML format is far |
|
|
|
|
less friendly to handwriting than HTML, and libhandy has to be specially compiled |
|
|
|
|
to work with Glade, the GNOME tool for laying out interfaces, which in turn may |
|
|
|
|
not support libhandy as a first-class citizen depending on version, and so on |
|
|
|
|
and so on. In other words, libhandy was difficult to use due to tooling issues. |
|
|
|
|
As libadwaita displaces GTK 3 and, presumably, libhandy, this should change, |
|
|
|
|
and as it does, apps should be rewritten to be more friendly to mobile usage |
|
|
|
|
by default. Very exciting stuff if you ask me! |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
That's about all the knowledge I have of developing for the PinePhone, so let's |
|
|
|
|
turn to my preferred OS and its shell, that being |
|
|
|
|
<a href="https://mobian-project.org">Mobian</a> and phosh. Mobian itself |
|
|
|
|
is just <a href="https://debian.org">Debian</a> with necessary |
|
|
|
|
changes to run on the PinePhone. In fact, the project launched on the PinePhone! |
|
|
|
|
The overall goal of the project is to, first of all, make a mainline Linux distro |
|
|
|
|
that is geared towards the PinePhone. What "mainline" means here is that one can |
|
|
|
|
simply install the vanilla versions of programs - such as the Linux kernel itself - |
|
|
|
|
and they will work without any patches or changes. Secondarily, it would like to |
|
|
|
|
become an official Debian Spin, which means it would be supported by Debian as |
|
|
|
|
a whole. For those unfamiliar with the GNU/Linux world, this is a big deal - |
|
|
|
|
Debian is one of the oldest and most venerable distributions of the operating |
|
|
|
|
system, and it serves as the base for most other major distros, notably Ubuntu |
|
|
|
|
and therefore anything based on Ubuntu. In other words, by becoming part of the |
|
|
|
|
Debian project, Mobian would demonstrate to the world that the PinePhone is a |
|
|
|
|
first-class Linux platform worthy of being developed for, and provide it the |
|
|
|
|
support that implies. |
|
|
|
|
I chose Mobian simply because I love Debian. Further, I prefer to keep my software |
|
|
|
|
as vanilla as possible, something Debian and by extension Mobian both share. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Phosh is simply a spinoff of the GNOME Shell geared towards mobile devices. It |
|
|
|
|
was originally developed by <a href="https://puri.sm">Purism</a> for their own |
|
|
|
|
Linux smartphones, but has achieved broader community acceptance in large part |
|
|
|
|
thanks to the PinePhone. As a disclaimer, Purism have demonstrated themselves |
|
|
|
|
tolerant of a variety of bigotry on their social media and communications |
|
|
|
|
platforms, all under the guise of defending "free speech," and therefore I |
|
|
|
|
consciously avoid direct interaction with them or anyone representing them. |
|
|
|
|
Thanks to free software, however, I can benefit from their work without supporting |
|
|
|
|
them. Cool! |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
At this point you might be saying, "That's all very neat and cool, Trees, but |
|
|
|
|
what's the PinePhone <em>actually like?!</em>" And to that I say, "Well, hold on |
|
|
|
|
and I'll tell you!" Frankly, the PinePhone is great. I've annoyed my partner |
|
|
|
|
and others in my life because of its quirks - not having Venmo and Messenger, |
|
|
|
|
for example - but I personally would rather not use those sorts of programs anyway, |
|
|
|
|
what with their obsession with tracking users and selling the data gained. That |
|
|
|
|
said, there are some notable problems about which I've made a point of keeping notes. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Before I get too far away from discussing phosh, let me just talk about what |
|
|
|
|
the actual interface is like. When you press the power button to turn on the |
|
|
|
|
phone screen, by default you'll see the time, the date, an indicator of any |
|
|
|
|
data/wifi connections, and a graphic of the battery state, with an arrow and |
|
|
|
|
the instruction to "slide up to unlock" at the bottom. Upon sliding up, you're |
|
|
|
|
greeted with a number pad for your PIN and a simple "unlock" button. From there, |
|
|
|
|
you'll see the app tray, with local search bar and your "favorites" apps shown by their icons in |
|
|
|
|
a top section, and everything else shown as icons and names below it. When I |
|
|
|
|
first booted my PinePhone, I was able to close this and simply see the wallpaper |
|
|
|
|
and headerbar, but this has since been changed. At the top of the logged-in |
|
|
|
|
screen at all times is your headerbar, as is common for the smartphone metaphor, |
|
|
|
|
which shows, from left to right, data connectivity, wifi, date and time, current |
|
|
|
|
keyboard language (if you use more than one), and battery indicator. If you tap |
|
|
|
|
this bar, you will see icons for, from left to right and top to bottom, data, |
|
|
|
|
wifi, bluetooth, battery, screen rotation, notification on/off, the flashlight |
|
|
|
|
(although this only works under Purism's OS), and whether the phone is docked |
|
|
|
|
(that is, connected to a screen and keyboard so as to function as a computer). |
|
|
|
|
Below this are two sliders, the top one for sound and the bottom one for screen |
|
|
|
|
brightness. Now, on to complaints! |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
On the hardware side, there are a few things which might be annoying to most |
|
|
|
|
users. Most glaringly, the actual CPU and chipsets are older - they come from |
|
|
|
|
2015 and were roughly mid-tier even then. Perhaps more painfully, the battery |
|
|
|
|
is pretty small, and kernels earlier than 5.10 have pretty terrible power usage |
|
|
|
|
optimization for the PinePhone. I've heard 5.11 is supposed to change this, |
|
|
|
|
but due to the Debian Bullseye freezes, I've yet to try it myself. The next major |
|
|
|
|
issue - and one which does bother me - is the camera. Now, I'd become habituated |
|
|
|
|
to the quality of Pixel phones, which combine excellent physical cameras (for |
|
|
|
|
smartphones, anyway) with Google AI which optimizes them to be even better. The |
|
|
|
|
PinePhone camera, by contrast, is 5 megapixels, and the Mobian camera app, |
|
|
|
|
Megapixels, requires some C hacking that ultimately passes images to a shell script. This means the |
|
|
|
|
pictures it takes tend to be rather lackluster. Don't get me wrong, they're |
|
|
|
|
sufficient for just snapping a quick pic of an interesting scene, but you probably |
|
|
|
|
won't be doing artistic or professional photography on it, at least not yet. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Megapixels brings me to the software problems I've encountered. Megapixels itself |
|
|
|
|
has a habit of freezing up the phone while saving a picture, and sometimes the |
|
|
|
|
saving itself fails. Other times, it crashes or phosh itself. When it does |
|
|
|
|
work, though, it's... Fine. There are no fine-tuning controls yet, settings aren't |
|
|
|
|
enabled, and the GUI doesn't recognize screen orientation. Additionally, if one |
|
|
|
|
has a preferred format for saving their pictures, it's not obvious that |
|
|
|
|
this has to be changed in the actual script - and some formats require |
|
|
|
|
other programs to work properly. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
On the note of crashes, while writing this, |
|
|
|
|
the podcast app I use, GNOME Podcasts, just crashed phosh, so let's talk |
|
|
|
|
about it a bit. I drive for my job, so I listen to a lot of podcasts, and the |
|
|
|
|
only app I've found in the GNOME ecosystem that has paid attention to smaller |
|
|
|
|
screens is GNOME Podcasts. This would be fine, except for a few things. Firstly, |
|
|
|
|
it's only available (on Mobian so far) as a Flatpak. This means it has higher |
|
|
|
|
on-disk overhead and runtime overhead than something downloaded through the |
|
|
|
|
Debian package manager apt - although updates are nicer because it only downloads |
|
|
|
|
the binary data that has actually changed. The other problem with this is that, |
|
|
|
|
as of now, it doesn't disable suspend, so the phone will go to sleep without some |
|
|
|
|
help to make it see that something's being played. I use <a href="https://src.jayvii.de/Hobby/PinePhoneScripts/src/branch/main/sguard"> |
|
|
|
|
Suspend Guard</a>. However, I've noticed that when podcasts are playing, the |
|
|
|
|
phone becomes less responsive - it takes longer to load the login screen, it |
|
|
|
|
takes longer to register my PIN, and sometimes it doesn't work at all or |
|
|
|
|
crashes randomly if I try to login while something is playing. Additionally, |
|
|
|
|
there are odd bugs around phone calls - I usually can't hear the other person |
|
|
|
|
if I receive a call, and sometimes the system doesn't switch back to the |
|
|
|
|
rear speaker after a phone call. I suspect this is a side-effect of the |
|
|
|
|
interaction between Flatpak and Suspend Guard. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
I mention these two programs together because they are exceptions which should |
|
|
|
|
disappear as more development time goes into the broader PinePhone ecosystem, |
|
|
|
|
but which are exceptionally annoying for the time being. Other than these, |
|
|
|
|
there are really only two complaints I have about the default Mobian software, |
|
|
|
|
both related to the keyboard, Squeekboard. The French Squeekboard layout lacks |
|
|
|
|
guillamettes, the French equivalent of quotation marks. While modern French |
|
|
|
|
people tend to use guillamettes and quotation marks interchangeably, I prefer |
|
|
|
|
the more classic notation, so I find this bothersome. Of course, Squeekboard |
|
|
|
|
layouts can be modified by the user, so I could simply add these to the French |
|
|
|
|
keyboard layout and open a pull request to have them merged into the mainline |
|
|
|
|
app - probably not a bad idea. The other complaint is that the Squeekboard |
|
|
|
|
emoji set is relatively limited, but this is a very minor issue that, again, I |
|
|
|
|
could theoretically resolve myself with just a bit of research and typing. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
There is one major failure of Mobian and, as far as I know, all PinePhone |
|
|
|
|
operating systems at the moment which must be noted. Namely, there is |
|
|
|
|
little to no accessibility software. This came to my attention when a |
|
|
|
|
blind user on Mastodon mentioned it in a broader thread on the failures of |
|
|
|
|
the FOSS community to take into account the needs of disabled people, |
|
|
|
|
specifically himself, when writing software and developing systems. Indeed, |
|
|
|
|
some of the responses to that thread were so hostile, tone-deaf, or ignorant |
|
|
|
|
that they serve as perfect examples of the stereotype that FOSS developers are, as a |
|
|
|
|
rule, assholes. I care about this for two reasons. First and foremost, I |
|
|
|
|
truly believe in the ideals behind software freedom, which initially and |
|
|
|
|
most fundamentally seeks to ensure that everyone may use any software. |
|
|
|
|
Indeed, the GNU Project came into being to ensure everyone would have |
|
|
|
|
access to the Unix operating system, or at least something very similar |
|
|
|
|
to it. By failing or outright refusing to make the necessary accommodations |
|
|
|
|
for disabled users, these developers are failing to live up to that most |
|
|
|
|
fundamental ideal. Secondly, I will one day - should I live long enough - |
|
|
|
|
lose my sight. I would like for that not to kick me out of the FOSS club, |
|
|
|
|
too. If you are a developer reading this, please take into account all the |
|
|
|
|
challenges your users may face, whether those be vision, hearing, motor |
|
|
|
|
control, developmental, or any other, insofar as you are able. Seek out the |
|
|
|
|
input of users from the broadest spectrum of humanity that you can (within |
|
|
|
|
reason - there's no need to consult laypeople on, say, software used for |
|
|
|
|
quantum physics research, for example). In doing so, you will help live up |
|
|
|
|
to the core, implicit, beautiful ideals which have created so much of the |
|
|
|
|
world's software today. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
As for the future, I think all of us are looking forward to a PinePhone 2 with |
|
|
|
|
more modern and, ideally, performant hardware. I know I'll gladly upgrade even |
|
|
|
|
if the PinePhone 2 costs significantly more. In the meantime, there is <em>a lot</em> |
|
|
|
|
of optimization to be done on the software front. As I already mentioned, battery |
|
|
|
|
support is improving, as is mainline kernel support; apps are being transitioned |
|
|
|
|
to more friendly GUI toolkits; and there are plenty of things most people expect |
|
|
|
|
from a smartphone which have yet to be implemented for the PinePhone. For example, |
|
|
|
|
just the other day someone asked me about OTP apps. I don't use this technology |
|
|
|
|
and so couldn't point them to a solution, but from what I can tell their usecase |
|
|
|
|
isn't yet supported. The other major thing I'm looking for in terms of PinePhone |
|
|
|
|
development is a *BSD-based OS. While the BSDs tend to lack the kinds of things |
|
|
|
|
smartphones - especially budget-tier smartphones like the PinePhone - need - |
|
|
|
|
namely power optimization and respect for limited hardware - the overall design |
|
|
|
|
of BSDs tends to be more stable and efficient from the start. There are no |
|
|
|
|
duplicate syscalls as in the Linux kernel, for example. Besides, Darwin underlies |
|
|
|
|
iOS and is a fork of FreeBSD, so there's already a demonstrated success story |
|
|
|
|
for a BSD on a smartphone. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
I can't really think of anything else to say about the PinePhone at the moment, |
|
|
|
|
so to summarize, the PinePhone, specifically running Mobian, is a cheap, low-powered |
|
|
|
|
Linux smartphone that can do pretty much all the basic things a phone is supposed |
|
|
|
|
to do while existing in the broader Linux ecosystem. If you're looking for a |
|
|
|
|
new phone and aren't deeply bought into the Google or Apple ecosystems - and |
|
|
|
|
don't mind waiting for pre-orders to go to production and then ship, which may |
|
|
|
|
take several months - I'd say go ahead and get one. The regular package is only |
|
|
|
|
$150 US before shipping, so for a lot of people this wouldn't be a ridiculous |
|
|
|
|
investment even as a secondary phone. And if you're a developer, you'll be able |
|
|
|
|
to participate in the birth of a new smartphone ecosystem, helping shepherd it |
|
|
|
|
into the mainstream. On the other hand, if you regularly use your phone for |
|
|
|
|
photography or use a lot of proprietary, smartphone-specific apps, you might |
|
|
|
|
want to give it a pass, at least for now. While many apps also have websites, |
|
|
|
|
the fact that the phone is the size of a phone and its browsers report themselves |
|
|
|
|
as Android or iOS means it's very difficult to use most of them from the phone. |
|
|
|
|
If you want to see if there are compatible apps for your usecase, check out |
|
|
|
|
<a href="https://linmobapps.frama.io">this list</a>. |
|
|
|
|
</p> |
|
|
|
|
<p class="blog-paragraph"> |
|
|
|
|
Well, thanks for stopping by Trees' Street; I hope you've found something helpful |
|
|
|
|
here. Until next time! |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Firstly, let's just be honest about what the |
|
|
|
|
<a href="https://pine64.com/product/pinephone-beta-edition-linux-smartphone/">PinePhone</a> |
|
|
|
|
is at the moment. Right |
|
|
|
|
now, the PinePhone is a fully-functional smartphone, meaning it can make |
|
|
|
|
phone calls, receive and send text messages (though not, as of now, MMS), |
|
|
|
|
access maps using GPS (although not directed GPS navigation - yet), and access |
|
|
|
|
the internet via browsers and apps. However, what the PinePhone lacks is a well-developed |
|
|
|
|
app ecosystem such as those of Android or iOS. For example, I have yet to find |
|
|
|
|
a way to access Facebook Messenger from my phone, a communication app that was |
|
|
|
|
previously one of the central pillars of my digital communications. Additionally, |
|
|
|
|
I can't use Snapchat or Instagram or Venmo or CashApp or any of the other apps |
|
|
|
|
that are staples on almost any young person's (and most any older person's) phone |
|
|
|
|
these days. In fact, I would argue that it's better to think of a PinePhone as a tiny Linux |
|
|
|
|
computer that can make phone calls and send text messages and use mobile data. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Now, for those familiar with Linux, this might not sound so bad. There's at |
|
|
|
|
least one program for almost anything a computer can do, often many more; that's |
|
|
|
|
a pretty big app ecosystem! Alas, Linux developers are stretched incredibly thin |
|
|
|
|
and there is as-of-yet little support for the kind of adaptive/reactive scaling |
|
|
|
|
needed to make apps usable on a tiny screen like that of the PinePhone. While |
|
|
|
|
Mobian's default shell, phosh, provides `scale-to-fit`, and other shells |
|
|
|
|
provide similar functionality, this just makes the actual elements of the app |
|
|
|
|
GUI smaller. So, for example, if you `scale-to-fit` GNOME Calendars, it will |
|
|
|
|
all fit on the screen, but each day of the month will be miniscule, the |
|
|
|
|
headerbar will be virtually unusable due to size, and so on. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Fortunately, this is changing. The recent libadwaita from the GNOME project - |
|
|
|
|
which is functionally GTK 4, a graphical user interface (GUI) toolkit library - includes elements from |
|
|
|
|
libhandy, a GTK 3-friendly GUI library that helps develop reactive apps. Personally, |
|
|
|
|
I've tried to develop with libhandy in the past, and while it's fairly simple |
|
|
|
|
to do using the old-fashioned method of handwriting code to layout one's GUI, |
|
|
|
|
it's much less friendly to the now-preferred GNOME development method of using |
|
|
|
|
XML files to layout an app interface (somewhat like writing a website in HTML |
|
|
|
|
then scripting it with JavaScript). Unfortunately, the GNOME XML format is far |
|
|
|
|
less friendly to handwriting than HTML, and libhandy has to be specially compiled |
|
|
|
|
to work with Glade, the GNOME tool for laying out interfaces, which in turn may |
|
|
|
|
not support libhandy as a first-class citizen depending on version, and so on |
|
|
|
|
and so on. In other words, libhandy was difficult to use due to tooling issues. |
|
|
|
|
As libadwaita displaces GTK 3 and, presumably, libhandy, this should change, |
|
|
|
|
and as it does, apps should be rewritten to be more friendly to mobile usage |
|
|
|
|
by default. Very exciting stuff if you ask me! |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
That's about all the knowledge I have of developing for the PinePhone, so let's |
|
|
|
|
turn to my preferred OS and its shell, that being |
|
|
|
|
<a href="https://mobian-project.org">Mobian</a> and phosh. Mobian itself |
|
|
|
|
is just <a href="https://debian.org">Debian</a> with necessary |
|
|
|
|
changes to run on the PinePhone. In fact, the project launched on the PinePhone! |
|
|
|
|
The overall goal of the project is to, first of all, make a mainline Linux distro |
|
|
|
|
that is geared towards the PinePhone. What "mainline" means here is that one can |
|
|
|
|
simply install the vanilla versions of programs - such as the Linux kernel itself - |
|
|
|
|
and they will work without any patches or changes. Secondarily, it would like to |
|
|
|
|
become an official Debian Spin, which means it would be supported by Debian as |
|
|
|
|
a whole. For those unfamiliar with the GNU/Linux world, this is a big deal - |
|
|
|
|
Debian is one of the oldest and most venerable distributions of the operating |
|
|
|
|
system, and it serves as the base for most other major distros, notably Ubuntu |
|
|
|
|
and therefore anything based on Ubuntu. In other words, by becoming part of the |
|
|
|
|
Debian project, Mobian would demonstrate to the world that the PinePhone is a |
|
|
|
|
first-class Linux platform worthy of being developed for, and provide it the |
|
|
|
|
support that implies. |
|
|
|
|
I chose Mobian simply because I love Debian. Further, I prefer to keep my software |
|
|
|
|
as vanilla as possible, something Debian and by extension Mobian both share. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Phosh is simply a spinoff of the GNOME Shell geared towards mobile devices. It |
|
|
|
|
was originally developed by <a href="https://puri.sm">Purism</a> for their own |
|
|
|
|
Linux smartphones, but has achieved broader community acceptance in large part |
|
|
|
|
thanks to the PinePhone. As a disclaimer, Purism have demonstrated themselves |
|
|
|
|
tolerant of a variety of bigotry on their social media and communications |
|
|
|
|
platforms, all under the guise of defending "free speech," and therefore I |
|
|
|
|
consciously avoid direct interaction with them or anyone representing them. |
|
|
|
|
Thanks to free software, however, I can benefit from their work without supporting |
|
|
|
|
them. Cool! |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
At this point you might be saying, "That's all very neat and cool, Trees, but |
|
|
|
|
what's the PinePhone <em>actually like?!</em>" And to that I say, "Well, hold on |
|
|
|
|
and I'll tell you!" Frankly, the PinePhone is great. I've annoyed my partner |
|
|
|
|
and others in my life because of its quirks - not having Venmo and Messenger, |
|
|
|
|
for example - but I personally would rather not use those sorts of programs anyway, |
|
|
|
|
what with their obsession with tracking users and selling the data gained. That |
|
|
|
|
said, there are some notable problems about which I've made a point of keeping notes. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Before I get too far away from discussing phosh, let me just talk about what |
|
|
|
|
the actual interface is like. When you press the power button to turn on the |
|
|
|
|
phone screen, by default you'll see the time, the date, an indicator of any |
|
|
|
|
data/wifi connections, and a graphic of the battery state, with an arrow and |
|
|
|
|
the instruction to "slide up to unlock" at the bottom. Upon sliding up, you're |
|
|
|
|
greeted with a number pad for your PIN and a simple "unlock" button. From there, |
|
|
|
|
you'll see the app tray, with local search bar and your "favorites" apps shown by their icons in |
|
|
|
|
a top section, and everything else shown as icons and names below it. When I |
|
|
|
|
first booted my PinePhone, I was able to close this and simply see the wallpaper |
|
|
|
|
and headerbar, but this has since been changed. At the top of the logged-in |
|
|
|
|
screen at all times is your headerbar, as is common for the smartphone metaphor, |
|
|
|
|
which shows, from left to right, data connectivity, wifi, date and time, current |
|
|
|
|
keyboard language (if you use more than one), and battery indicator. If you tap |
|
|
|
|
this bar, you will see icons for, from left to right and top to bottom, data, |
|
|
|
|
wifi, bluetooth, battery, screen rotation, notification on/off, the flashlight |
|
|
|
|
(although this only works under Purism's OS), and whether the phone is docked |
|
|
|
|
(that is, connected to a screen and keyboard so as to function as a computer). |
|
|
|
|
Below this are two sliders, the top one for sound and the bottom one for screen |
|
|
|
|
brightness. Now, on to complaints! |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
On the hardware side, there are a few things which might be annoying to most |
|
|
|
|
users. Most glaringly, the actual CPU and chipsets are older - they come from |
|
|
|
|
2015 and were roughly mid-tier even then. Perhaps more painfully, the battery |
|
|
|
|
is pretty small, and kernels earlier than 5.10 have pretty terrible power usage |
|
|
|
|
optimization for the PinePhone. I've heard 5.11 is supposed to change this, |
|
|
|
|
but due to the Debian Bullseye freezes, I've yet to try it myself. The next major |
|
|
|
|
issue - and one which does bother me - is the camera. Now, I'd become habituated |
|
|
|
|
to the quality of Pixel phones, which combine excellent physical cameras (for |
|
|
|
|
smartphones, anyway) with Google AI which optimizes them to be even better. The |
|
|
|
|
PinePhone camera, by contrast, is 5 megapixels, and the Mobian camera app, |
|
|
|
|
Megapixels, requires some C hacking that ultimately passes images to a shell script. This means the |
|
|
|
|
pictures it takes tend to be rather lackluster. Don't get me wrong, they're |
|
|
|
|
sufficient for just snapping a quick pic of an interesting scene, but you probably |
|
|
|
|
won't be doing artistic or professional photography on it, at least not yet. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Megapixels brings me to the software problems I've encountered. Megapixels itself |
|
|
|
|
has a habit of freezing up the phone while saving a picture, and sometimes the |
|
|
|
|
saving itself fails. Other times, it crashes or phosh itself. When it does |
|
|
|
|
work, though, it's... Fine. There are no fine-tuning controls yet, settings aren't |
|
|
|
|
enabled, and the GUI doesn't recognize screen orientation. Additionally, if one |
|
|
|
|
has a preferred format for saving their pictures, it's not obvious that |
|
|
|
|
this has to be changed in the actual script - and some formats require |
|
|
|
|
other programs to work properly. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
On the note of crashes, while writing this, |
|
|
|
|
the podcast app I use, GNOME Podcasts, just crashed phosh, so let's talk |
|
|
|
|
about it a bit. I drive for my job, so I listen to a lot of podcasts, and the |
|
|
|
|
only app I've found in the GNOME ecosystem that has paid attention to smaller |
|
|
|
|
screens is GNOME Podcasts. This would be fine, except for a few things. Firstly, |
|
|
|
|
it's only available (on Mobian so far) as a Flatpak. This means it has higher |
|
|
|
|
on-disk overhead and runtime overhead than something downloaded through the |
|
|
|
|
Debian package manager apt - although updates are nicer because it only downloads |
|
|
|
|
the binary data that has actually changed. The other problem with this is that, |
|
|
|
|
as of now, it doesn't disable suspend, so the phone will go to sleep without some |
|
|
|
|
help to make it see that something's being played. I use <a href="https://src.jayvii.de/Hobby/PinePhoneScripts/src/branch/main/sguard"> |
|
|
|
|
Suspend Guard</a>. However, I've noticed that when podcasts are playing, the |
|
|
|
|
phone becomes less responsive - it takes longer to load the login screen, it |
|
|
|
|
takes longer to register my PIN, and sometimes it doesn't work at all or |
|
|
|
|
crashes randomly if I try to login while something is playing. Additionally, |
|
|
|
|
there are odd bugs around phone calls - I usually can't hear the other person |
|
|
|
|
if I receive a call, and sometimes the system doesn't switch back to the |
|
|
|
|
rear speaker after a phone call. I suspect this is a side-effect of the |
|
|
|
|
interaction between Flatpak and Suspend Guard. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
I mention these two programs together because they are exceptions which should |
|
|
|
|
disappear as more development time goes into the broader PinePhone ecosystem, |
|
|
|
|
but which are exceptionally annoying for the time being. Other than these, |
|
|
|
|
there are really only two complaints I have about the default Mobian software, |
|
|
|
|
both related to the keyboard, Squeekboard. The French Squeekboard layout lacks |
|
|
|
|
guillamettes, the French equivalent of quotation marks. While modern French |
|
|
|
|
people tend to use guillamettes and quotation marks interchangeably, I prefer |
|
|
|
|
the more classic notation, so I find this bothersome. Of course, Squeekboard |
|
|
|
|
layouts can be modified by the user, so I could simply add these to the French |
|
|
|
|
keyboard layout and open a pull request to have them merged into the mainline |
|
|
|
|
app - probably not a bad idea. The other complaint is that the Squeekboard |
|
|
|
|
emoji set is relatively limited, but this is a very minor issue that, again, I |
|
|
|
|
could theoretically resolve myself with just a bit of research and typing. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
There is one major failure of Mobian and, as far as I know, all PinePhone |
|
|
|
|
operating systems at the moment which must be noted. Namely, there is |
|
|
|
|
little to no accessibility software. This came to my attention when a |
|
|
|
|
blind user on Mastodon mentioned it in a broader thread on the failures of |
|
|
|
|
the FOSS community to take into account the needs of disabled people, |
|
|
|
|
specifically himself, when writing software and developing systems. Indeed, |
|
|
|
|
some of the responses to that thread were so hostile, tone-deaf, or ignorant |
|
|
|
|
that they serve as perfect examples of the stereotype that FOSS developers are, as a |
|
|
|
|
rule, assholes. I care about this for two reasons. First and foremost, I |
|
|
|
|
truly believe in the ideals behind software freedom, which initially and |
|
|
|
|
most fundamentally seeks to ensure that everyone may use any software. |
|
|
|
|
Indeed, the GNU Project came into being to ensure everyone would have |
|
|
|
|
access to the Unix operating system, or at least something very similar |
|
|
|
|
to it. By failing or outright refusing to make the necessary accommodations |
|
|
|
|
for disabled users, these developers are failing to live up to that most |
|
|
|
|
fundamental ideal. Secondly, I will one day - should I live long enough - |
|
|
|
|
lose my sight. I would like for that not to kick me out of the FOSS club, |
|
|
|
|
too. If you are a developer reading this, please take into account all the |
|
|
|
|
challenges your users may face, whether those be vision, hearing, motor |
|
|
|
|
control, developmental, or any other, insofar as you are able. Seek out the |
|
|
|
|
input of users from the broadest spectrum of humanity that you can (within |
|
|
|
|
reason - there's no need to consult laypeople on, say, software used for |
|
|
|
|
quantum physics research, for example). In doing so, you will help live up |
|
|
|
|
to the core, implicit, beautiful ideals which have created so much of the |
|
|
|
|
world's software today. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
As for the future, I think all of us are looking forward to a PinePhone 2 with |
|
|
|
|
more modern and, ideally, performant hardware. I know I'll gladly upgrade even |
|
|
|
|
if the PinePhone 2 costs significantly more. In the meantime, there is <em>a lot</em> |
|
|
|
|
of optimization to be done on the software front. As I already mentioned, battery |
|
|
|
|
support is improving, as is mainline kernel support; apps are being transitioned |
|
|
|
|
to more friendly GUI toolkits; and there are plenty of things most people expect |
|
|
|
|
from a smartphone which have yet to be implemented for the PinePhone. For example, |
|
|
|
|
just the other day someone asked me about OTP apps. I don't use this technology |
|
|
|
|
and so couldn't point them to a solution, but from what I can tell their usecase |
|
|
|
|
isn't yet supported. The other major thing I'm looking for in terms of PinePhone |
|
|
|
|
development is a *BSD-based OS. While the BSDs tend to lack the kinds of things |
|
|
|
|
smartphones - especially budget-tier smartphones like the PinePhone - need - |
|
|
|
|
namely power optimization and respect for limited hardware - the overall design |
|
|
|
|
of BSDs tends to be more stable and efficient from the start. There are no |
|
|
|
|
duplicate syscalls as in the Linux kernel, for example. Besides, Darwin underlies |
|
|
|
|
iOS and is a fork of FreeBSD, so there's already a demonstrated success story |
|
|
|
|
for a BSD on a smartphone. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
I can't really think of anything else to say about the PinePhone at the moment, |
|
|
|
|
so to summarize, the PinePhone, specifically running Mobian, is a cheap, low-powered |
|
|
|
|
Linux smartphone that can do pretty much all the basic things a phone is supposed |
|
|
|
|
to do while existing in the broader Linux ecosystem. If you're looking for a |
|
|
|
|
new phone and aren't deeply bought into the Google or Apple ecosystems - and |
|
|
|
|
don't mind waiting for pre-orders to go to production and then ship, which may |
|
|
|
|
take several months - I'd say go ahead and get one. The regular package is only |
|
|
|
|
$150 US before shipping, so for a lot of people this wouldn't be a ridiculous |
|
|
|
|
investment even as a secondary phone. And if you're a developer, you'll be able |
|
|
|
|
to participate in the birth of a new smartphone ecosystem, helping shepherd it |
|
|
|
|
into the mainstream. On the other hand, if you regularly use your phone for |
|
|
|
|
photography or use a lot of proprietary, smartphone-specific apps, you might |
|
|
|
|
want to give it a pass, at least for now. While many apps also have websites, |
|
|
|
|
the fact that the phone is the size of a phone and its browsers report themselves |
|
|
|
|
as Android or iOS means it's very difficult to use most of them from the phone. |
|
|
|
|
If you want to see if there are compatible apps for your usecase, check out |
|
|
|
|
<a href="https://linmobapps.frama.io">this list</a>. |
|
|
|
|
</p> |
|
|
|
|
<p> |
|
|
|
|
Well, thanks for stopping by Trees' Street; I hope you've found something helpful |
|
|
|
|
here. Until next time! |
|
|
|
|
</p> |
|
|
|
|
{% endblock content %} |
|
|
|
|
|
