In some ways, I cannot help but be disappointed: I do not trust what I've built
as a daily driver yet. sleepd is not finished and integrated, no UI for SMS
exists yet, and I simply have not tested the system as a whole enough to believe
that it should work reliably. calld also still has a few issues that need to
be worked out: for example, it can't deal with an incoming call timing out.
smsd should probably do more than write incoming texts to a file whose name is
the sending phone number.
There were however, some things that I see as successes. I was successfully able
to implement some Wayland protocols that weren't supported in swc or st. I
was able to port svkbd to Wayland. atd can perform core telephony
functionality in less than 2,000 lines, and only depends on libc. For context,
the ofono git repository contains 174,000 lines of C (although I think that to
get the equivalent functionality of atd, it's much smaller), and depends on
glib and dbus. ModemManager is even larger.
Over the course of development, I've grown more sympathetic to the existence of
dbus because I've had to come up with my own socket protocols, which I would
have gotten for free with dbus. However, I still wouldn't consider using it.
It does several things that really should be the job of the system service
manager, and it depends on glib.
I still have no sympathy for glib as a dependency. I still haven't quite
figured out what it does besides making C less readable.
I learned a trumendous amount about Linux that I wouldn't have had any reason to
learn otherwise. After figuring out how to get mowc to start as a service on a
TTY, the Linux bootup process finally clicked, and I feel like I have a solid
understanding of how it works now. I have a better understanding of the /sys
hierarchy, and how to figure out where different devices end up. For example,
the Pinephone has a proximity sensor and magnetometer, which I learned how to
read input from. Being i2c devices, the device tree contains their addresses,
which is how they are referenced in the /sys/class hierarchy. Maybe one day I
can add a compass program using the magnetometer.
I think Musk deadlines are an excellent idea. Setting an impossible deadline means that far more progress will be made than if a reasonable deadline is set. Of course this only works if the proper motivation exists, and the people working on the project believe that the deadline is achievable. I don't believe that I would have made nearly as much progress if I had set a more relaxed goal, even though I didn't meet the goal.
One thing that I was still thinking through by the end was service management.
I never really figured out a great way to manage atd, calld and smsd.
Initially, intending it to be temporary, I made it so that atd and calld
would start whenever the modem button was pressed in the mowc overlay menu. This
seemed to work well, but I never thought that it was a good idea for mowc to
effectively be doing service management. Ideally, it would work as follows: if
the modem is powered on, atd should automatically be started (it will die
automatically if the modem is powered off). When atd and mowc are up,
calld and smsd should be started as well. If atd dies, calld and smsd
should be killed as well. This would work nicely if the kernel had a way to
notify userspace when the modem was up, but I don't know enough to know where to
start. Without such a mechanism, the atd service would have to poll the
/sys/class/modem-power/modem-power/powered to determine when the modem was on
and off. Since perp can arbitrarily complex service management, I think my
desired setup is possible, it's just a matter of implementing it.
I learned about the absurdity of SMS messages, specifically how insanely limited they are. I did not learn about MMS, because I now shudder whenever I hear those 3 letters in that order. As far as I can tell, there is no way to send texts or make phone calls using QMI on the Quectel EC25, so we are forced to use the antiquated AT interface, which is poorly documented and not a very efficient way to move information between the modem and main processor. I'm convinced that the only reason phone calls and SMS still happen over special carrier infrastructure is to keep them relevant. Imagine how much lower congestion on cellular networks would be if a nearby wifi network was used for voice or text.
So here we are, at the end of this thing. The whole point of this project was to get out of the Android-iOS duopoly using what I've learned about Linux over the past several years. Smartphones can be incredible tools, with the right software, and used correctly. In this vein, I intend to continue developing this project, just not with the same vigor as the summer. Hopefully I can get it done. This is it for now.