Refactor to use tabs for indentation

main
J. Sims 1 year ago
parent 26e225499c
commit f73b1d4e06
  1. 6
      templates/blog-post.html
  2. 22
      templates/blog.html
  3. 22
      templates/feed.xml
  4. 8
      templates/index.html
  5. 56
      templates/layout.html
  6. 488
      templates/posts/2021-04-29.html
  7. 190
      templates/posts/2021-05-04.html
  8. 10
      templates/rss-item.xml

@ -1,7 +1,7 @@
<h2 class="blog-title">
<a href="{{ url_for('blog', post_name=self.date()+'.html') }}" tabindex="0">
{% block title %}{% endblock %}
</a>
<a href="{{ url_for('blog', post_name=self.date()+'.html') }}" tabindex="0">
{% block title %}{% endblock %}
</a>
</h2>
<h4 class="blog-date">{% block date %}{% endblock %}</h4>
<summary class="blog-summary" tabindex="0"><p>{% block summary %}{% endblock %}</p></summary>

@ -1,16 +1,14 @@
{% extends "layout.html" %}
{% block main %}
<div class="blog-feed">
{% for post in posts %}
<article class="blog-post" id={{ post.lstrip("blog/").rstrip(".html") }}>
{% include post %}
</article>
{% endfor %}
<!--
<form method="post">
<button class="blog-show-more">Show more</button>
</form>
-->
</div>
{% for post in posts %}
<article class="blog-post" id={{ post.lstrip("blog/").rstrip(".html") }}>
{% include post %}
</article>
{% endfor %}
<!--
<form method="post">
<button class="blog-show-more">Show more</button>
</form>
-->
{% endblock %}

@ -1,14 +1,14 @@
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<title>Trees' Street - Blog</title>
<link>https://trees.st/blog</link>
<description>Trees' personal blog</description>
<category>personal</category>
<copyright>CC-BY-SA 4.0</copyright>
<language>en-us</language>
{% for post in posts %}
{% include post %}
{% endfor %}
</channel>
<channel>
<title>Trees' Street - Blog</title>
<link>https://trees.st/blog</link>
<description>Trees' personal blog</description>
<category>personal</category>
<copyright>CC-BY-SA 4.0</copyright>
<language>en-us</language>
{% for post in posts %}
{% include post %}
{% endfor %}
</channel>
</rss>

@ -1,9 +1,7 @@
{% extends "layout.html" %}
{% block main %}
<div class="about-text">
<p>
Hello and welcome to Trees' Street! Here's where I put the stuff I do. Enjoy!
</p>
</div>
<p>
Hello and welcome to Trees' Street! Here's where I put the stuff I do. Enjoy!
</p>
{% endblock %}

@ -1,32 +1,32 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link href="{{ url_for('static', filename='styles.css') }}" rel="stylesheet">
<link href="{{ url_for('static', filename='favicon.ico') }}" rel="shortcut icon">
<title>Trees' Street</title>
</head>
<body tabindex="0">
<header>
<h1>You find yourself on a winding path deep in the forest...</h1>
<nav>
<a class="nav-item" href="{{ url_for('index') }}">Home</a>
<a class="nav-item" href="{{ url_for('blog') }}">Blog</a>
<a class="nav-item" href="https://github.com/Marie-Joseph">Projects</a>
</nav>
</header>
<main>
{% block main %}{% endblock %}
</main>
<footer>
<small>
Subscribe to my <a href="{{ url_for('feed') }}">RSS feed</a><br />
All code (Hy, HTML, Jinja, CSS) for this website is licensed under the <a href="https://www.gnu.org/licenses/gpl-3.0-standalone.html">GPLv3</a>
and available <a href="https://github.com/Marie-Joseph/hy-website">here</a>.<br />
All blog posts (the raw text) are licensed <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">CC-BY-SA 4.0</a>.
</small>
</footer>
</body>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<link href="{{ url_for('static', filename='styles.css') }}" rel="stylesheet">
<link href="{{ url_for('static', filename='favicon.ico') }}" rel="shortcut icon">
<title>Trees' Street</title>
</head>
<body tabindex="0">
<header>
<h1>You find yourself on a winding path deep in the forest...</h1>
<nav>
<a class="nav-item" href="{{ url_for('index') }}">Home</a>
<a class="nav-item" href="{{ url_for('blog') }}">Blog</a>
<a class="nav-item" href="https://github.com/Marie-Joseph">Projects</a>
</nav>
</header>
<main>
{% block main %}{% endblock %}
</main>
<footer>
<small>
Subscribe to my <a href="{{ url_for('feed') }}">RSS feed</a><br />
All code (Hy, HTML, Jinja, CSS) for this website is licensed under the <a href="https://www.gnu.org/licenses/gpl-3.0-standalone.html">GPLv3</a>
and available <a href="https://github.com/Marie-Joseph/hy-website">here</a>.<br />
All blog posts (the raw text) are licensed <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">CC-BY-SA 4.0</a>.
</small>
</footer>
</body>
</html>

@ -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 %}

@ -1,49 +1,49 @@
{% if type == "rss" %}
{% extends "rss-item.xml" %}
{% extends "rss-item.xml" %}
{% else %}
{% extends "blog-post.html" %}
{% extends "blog-post.html" %}
{% endif %}
{% block title %}What a Hy!{% endblock title %}
{% block date %}2021-05-04{% endblock date %}
{% block summary %}
I rewrote my website. In Lisp! In two hours!! Using Flask!!! WTF????
I rewrote my website. In Lisp! In two hours!! Using Flask!!! WTF????
{% endblock summary %}
{% block content %}
<p class="blog-paragraph">
Recently, I've been listening to a lot of <a href="https://fossandcrafts.org/">
FOSS and Crafts</a>, a podcast about free software and broader free culture as well
as a variety of other nerdy topics hosted by Morgan Lemmer-Webber, an art historian
studying Roman textiles, and her spouse Chris, who you may know from their work on
the <a href="https://wikipedia.org/wiki/ActivityPub">ActivityPub</a> standard and the
<a href="https://spritelyproject.org">Spritely</a> project. This latter (or, rather, a
talk on it where Chris mentioned using <a href="https://racket-lang.org">Racket</a>)
inspired me to try to pick up Racket, and
I decided to start by working my way through <a href="https://htdp.org">How to Design
Programs</a> second edition (2htdp). Long story short, the
<a href="https://wikipedia.org/wiki/Lisp_(programming_language)">Lisp</a>-y language
used for teaching in that book led
me to really fall in love with Lisps (even though, disclaimer! I'm still very much new
to them). While working my way from Wikipedia article to Wikipedia article on the
various Lisp families and implementations, I came across
<a href="https://docs.hylang.org">Hy</a>, a "Lisp" (we'll get to that)
which runs on the <a href="https://python.org">Python</a> interpreter.
Seeing that it could use Python modules just like normal, and given my newfound interest
in Lisps, I decided to rewrite my website in it. And, being the FOSS-y advocate I am, I
figured I should write about the experience. So here's that write-up!
</p>
<p class="blog-paragraph">
Firstly, let's discuss Hy a bit because I think it's pretty kick-ass. Basically, the
language core parses traditional Lisp
<a href="https://wikipedia.org/wiki/S-expression">S-Expressions</a> and translates them
into a Python Abstract Syntax Tree (AST). This AST is then handed off to the Python
interpreter which compiles it into bytecode (files in the <code>__pycache__</code>
directory). This code can then be called from regular Python. Some language
features require Hy to be imported as well - practically speaking, one
should always import the Hy module when calling Hy code from Python.
It would be easier to show than tell, so here's a function written in Hy which
produces a Fibonacci sequence:
<pre><code>
<p>
Recently, I've been listening to a lot of <a href="https://fossandcrafts.org/">
FOSS and Crafts</a>, a podcast about free software and broader free culture as well
as a variety of other nerdy topics hosted by Morgan Lemmer-Webber, an art historian
studying Roman textiles, and her spouse Chris, who you may know from their work on
the <a href="https://wikipedia.org/wiki/ActivityPub">ActivityPub</a> standard and the
<a href="https://spritelyproject.org">Spritely</a> project. This latter (or, rather, a
talk on it where Chris mentioned using <a href="https://racket-lang.org">Racket</a>)
inspired me to try to pick up Racket, and
I decided to start by working my way through <a href="https://htdp.org">How to Design
Programs</a> second edition (2htdp). Long story short, the
<a href="https://wikipedia.org/wiki/Lisp_(programming_language)">Lisp</a>-y language
used for teaching in that book led
me to really fall in love with Lisps (even though, disclaimer! I'm still very much new
to them). While working my way from Wikipedia article to Wikipedia article on the
various Lisp families and implementations, I came across
<a href="https://docs.hylang.org">Hy</a>, a "Lisp" (we'll get to that)
which runs on the <a href="https://python.org">Python</a> interpreter.
Seeing that it could use Python modules just like normal, and given my newfound interest
in Lisps, I decided to rewrite my website in it. And, being the FOSS-y advocate I am, I
figured I should write about the experience. So here's that write-up!
</p>
<p>
Firstly, let's discuss Hy a bit because I think it's pretty kick-ass. Basically, the
language core parses traditional Lisp
<a href="https://wikipedia.org/wiki/S-expression">S-Expressions</a> and translates them
into a Python Abstract Syntax Tree (AST). This AST is then handed off to the Python
interpreter which compiles it into bytecode (files in the <code>__pycache__</code>
directory). This code can then be called from regular Python. Some language
features require Hy to be imported as well - practically speaking, one
should always import the Hy module when calling Hy code from Python.
It would be easier to show than tell, so here's a function written in Hy which
produces a Fibonacci sequence:
<pre><code>
<!---->(defn fib [l n]
<!----> """
<!----> Produce a list of Fibonacci numbers
@ -51,68 +51,68 @@
<!----> and n as the limit
<!----> """
<!----> (if (&lt; (len l) n)
<!----> (fib (+ l
<!----> [(+ (get l -2) (get l -1))])
<!----> n)
<!----> l))
</code></pre>
And here's how you would use that in regular Python, assuming it's in <code>fib.hy</code>:
<pre><code>
<!----> (fib (+ l
<!----> [(+ (get l -2) (get l -1))])
<!----> n)
<!----> l))
</code></pre>
And here's how you would use that in regular Python, assuming it's in <code>fib.hy</code>:
<pre><code>
<!---->from fib import fib
<!---->print(fib([1, 1], 8))
</code></pre>
Super simple, right? For good measure, here's the above code in Hy:
<pre><code>
</code></pre>
Super simple, right? For good measure, here's the above code in Hy:
<pre><code>
<!---->(import [fib [fib]])
<!---->(print (fib [1 1] 8))
</code></pre>
</p>
<p class="blog-paragraph">
It bears mentioning what Hy is and isn't. It isn't (technically) a Lisp.
Rather, Hy is a Lisp-like syntax for Python. This is summarized well in
the project's motto: "Lisp-stick on Python." Practically, this means that
Hy code works like Python, not like Lisp; so, for example, functions passed
to functions are executed and their results evaluated by the first
function, rather than being passed <em>as functions</em>. This means some
language features are a bit less powerful than in a true Lisp. However,
to support the illusion of being a Lisp, Hy does provide some built-in
functions and macros so things look more Lisp-y.
</p>
<p class="blog-paragraph">
With the above example in mind, it shouldn't be too surprising that one can use
Hy to write a <a href="https://flask.palletsprojects.com">Flask</a> app like this
website. In fact, the only requirement as far as Flask itself goes is to have a Python
"shim". Here's mine:
<pre><code>
</code></pre>
</p>
<p>
It bears mentioning what Hy is and isn't. It isn't (technically) a Lisp.
Rather, Hy is a Lisp-like syntax for Python. This is summarized well in
the project's motto: "Lisp-stick on Python." Practically, this means that
Hy code works like Python, not like Lisp; so, for example, functions passed
to functions are executed and their results evaluated by the first
function, rather than being passed <em>as functions</em>. This means some
language features are a bit less powerful than in a true Lisp. However,
to support the illusion of being a Lisp, Hy does provide some built-in
functions and macros so things look more Lisp-y.
</p>
<p>
With the above example in mind, it shouldn't be too surprising that one can use
Hy to write a <a href="https://flask.palletsprojects.com">Flask</a> app like this
website. In fact, the only requirement as far as Flask itself goes is to have a Python
"shim". Here's mine:
<pre><code>
<!---->import hy
<!---->from app import *
</code></pre>
In this case, "app" refers to a file called <code>app.hy</code>. I just stuck the above
code in <code>shim.py</code> and pointed the <code>FLASK_APP</code> environment
variable at it. Everything else is the same from the Flask perspective.
The actual code translation was pretty simple, too. Besides switching to the Hy syntax
and adjusting some value testing to take advantage of Hy built-ins like <code>none?</code>,
I didn't have to change anything. And even the syntax translation was quite simple
since, firstly, this website is extremely simple (if it weren't for some features of
this blog which are as-yet unimplemented, I could just make it a static site), and,
secondly, I already had tried to use a more functional style of coding I'd learned
from 2htdp. The only problem I ran into was a strange parsing bug that I discovered
was caused by a typo in one of my route decorators. Rather than setting the homepage
URL extension to "/", I set it to "index", which was incorrect no matter the language.
</p>
<p class="blog-paragraph">
Overall, my limited experience with Hy has been wonderful, and I'm very excited to use
it more in the future. Given my discovery of my love for s-expression syntax, I'll be
reaching for Hy anytime I previously may have reached for Python. And, Hy is quite
mature; the version I'm using right now is 1.0a1 - or in English, the alpha release
of 1.0. Hopefully in the next couple months the 20-ish outstanding issues will be
cleared up and this delicious Lisp will be a full-fledged release language. I for one
am looking forward to it. If you're looking for a Lisp to pick up with a great standard
library, I would highly suggest giving Hy a look. It can even be run on
<a href="https://www.pypy.org">PyPy</a>!
</p>
<p class="blog-paragraph">
Well, that's all I've got for now. Thanks for stopping by, and as I have a habit of
saying, have a good one!
</p>
</code></pre>
In this case, "app" refers to a file called <code>app.hy</code>. I just stuck the above
code in <code>shim.py</code> and pointed the <code>FLASK_APP</code> environment
variable at it. Everything else is the same from the Flask perspective.
The actual code translation was pretty simple, too. Besides switching to the Hy syntax
and adjusting some value testing to take advantage of Hy built-ins like <code>none?</code>,
I didn't have to change anything. And even the syntax translation was quite simple
since, firstly, this website is extremely simple (if it weren't for some features of
this blog which are as-yet unimplemented, I could just make it a static site), and,
secondly, I already had tried to use a more functional style of coding I'd learned
from 2htdp. The only problem I ran into was a strange parsing bug that I discovered
was caused by a typo in one of my route decorators. Rather than setting the homepage
URL extension to "/", I set it to "index", which was incorrect no matter the language.
</p>
<p>
Overall, my limited experience with Hy has been wonderful, and I'm very excited to use
it more in the future. Given my discovery of my love for s-expression syntax, I'll be
reaching for Hy anytime I previously may have reached for Python. And, Hy is quite
mature; the version I'm using right now is 1.0a1 - or in English, the alpha release
of 1.0. Hopefully in the next couple months the 20-ish outstanding issues will be
cleared up and this delicious Lisp will be a full-fledged release language. I for one
am looking forward to it. If you're looking for a Lisp to pick up with a great standard
library, I would highly suggest giving Hy a look. It can even be run on
<a href="https://www.pypy.org">PyPy</a>!
</p>
<p>
Well, that's all I've got for now. Thanks for stopping by, and as I have a habit of
saying, have a good one!
</p>
{% endblock content %}

@ -1,6 +1,8 @@
<item>
<title>{% block title %}{% endblock %}</title>
<pubDate>{% block date %}{% endblock %}</pubDate>
<link>https://trees.st/blog/{{ self.date() }}</link>
<description>{% block summary %}{% endblock %}</description>
<title>{% block title %}{% endblock %}</title>
<pubDate>{% block date %}{% endblock %}</pubDate>
<link>https://trees.st/blog/{{ self.date() }}</link>
<description>
{% block summary %}{% endblock %}
</description>
</item>