I’ve never actually listened to the song, but I have heard a funny story about it, which you can find below (warning: some strong language).

Keep in mind that, by playing the video, your presence on this site (as embedder of the video) is recorded by Google. If you’re concerned about that sort of thing, you’ll be fine as long as you don’t click on it.

Changed Server, Again

I’ve switched my production server one more time™ to a new system, this time to Fedora Server. It’s got the new packages I was looking for before, plus it’s Linux, so things are going to work better. I forget what problem I was having - something related to services - but I got so tired of wrestling with the FreeBSD server that I threw in the towel. Again.

I’ve also switched my development server software from Phabricator to Gitea. Gitea is written in Go and not PHP, so it’s a single binary to worry about, and one that runs well and with low resource usage. Compare that to Phabricator, which I found constantly hogging 100% of the CPU…

The reason I didn’t use Gitea in the first place was because there isn’t a user role for “can add issues but not create repos” - I found out that I can work around that by limiting users to 0 repositories.

I have also implemented GitHub and GitLab OAuth2 logins on my Gitea instance. They will pull your username and email address from the OAuth2 account and use them to populate a signup form. This is so Gitea has its own account record to tie issues, repositories, etc. to. Further logins using GitHub or GitLab will then authenticate you with that Gitea account.

I apologize for any confusion or frustration that this shuffling has caused. I understand how it makes me look inexperienced and unorganized, and frankly I kinda am. This is a learning experience for me, being a sysadmin for my own public server.

Writing a Form Handling Server

My big project recently has been [static-forms][static-forms], my creatively-named server that handles forms for static websites (like this one). It’s written in Go and currently is only able to send emails based on form submissions. It does, however, have the following features:

  • Multiple handlers for one form
  • Domain-name filtering per handler
    • This means that I can have multiple handlers set up for /contact, with different domains allowed for each one, so submissions from shadow53.com go to a different handler than bluestnight.com
  • Support for Go’s templating system
    • Currently this means that generated emails can take information from the form submission and place it into the template, for instance to create a confirmation email to the form submitter based on the contents of the Email field, or setting the given email address as the Reply-To header in the email sent to the site administrator.

There’s still plenty of work to be done, of course, such as creating proper honeypots for spam filtering, rate-limiting IP addresses, and allowing templates to send their own error messages back to the form submitter. The mostly-stable-alpha version of this server is currently used to handle the contact form submissions on this site, though. That external survey link was annoying all around and needed to be removed.

Updates Regarding MicroG/No Gapps

I’ve been focusing my development energy toward the above form-handling server, so not much has been coming from me in the world of Google-less Android. I’ve been monitoring things, though, and I want to take some time to talk about it.

Radio Silence from MaR-V-iN

Marvin (username MaR-V-iN on XDA Developers and GitHub), the creator of MicroG, has not been working on MicroG much lately. I’m not repeating any of the reasons I’ve heard because I cannot confirm them myself, but I think it’s safe to assume that something in life has come up to take his attention. Still, the community has responded with concerns about the life of the project, especially given setbacks outlined below. I am confident Marvin will return to the project, however I would like to see one or two long-standing members of the community added to the microg organization on GitHub to be able to merge pull requests and otherwise add code.

And for the record, I don’t think I should be one of those people. I’ve documented how to use the software and helped create unofficial packages for it, but I have no experience with the actual codebase - or Android development, for that matter - while others do have that experience.

The Deprecation of GCM for FCM

Users of MicroG on Android Oreo will notice that their apps using Google for notifications are no longer receiving them. This is because of Google pushing Firebase Cloud Messaging (FCM) as a replacement for Google Cloud Messaging (GCM) for notifications. MicroG currently only has support for the older GCM protocol, so apps using the newer FCM cannot register for notifications.

Some people have found that installing older versions of the app will cause it to register via GCM, then an update will continue using GCM. The problem of lacking support for FCM still remains.

A solution to this problem is to just not use apps that require Play Services at all, and request that developers of apps you use requiring Play Services implement an alternate method of pushing notifications.

This doesn’t work if you need a certain app that still requires Play Services, and certainly won’t work if trying to convince someone to switch to using MicroG. So, we need to get FCM implemented. Open Source enthusiasts will suggest that I do it if I think it needs to be done - I would, and I may in the future, but not any time soon. I have too many projects already that need to be worked on. So here’s hoping someone else is able to get something working…

Reporting Outdated Version of Play Services

The current official release of MicroG reports itself as an old version of Play Services, so some apps refuse to run. There are a few unofficial forks that have updated the version, among other things. To make things easier, I also now provide a separate “unofficial” microG installer based on one of these forks. This is a temporary measure, until such time as the main project gets updated.

Liberapay In Trouble

According to their official Medium blog, Liberapay is in a bit of trouble:

Our payment processor (Mangopay) is throwing us out. Liberapay won’t shut down, but the service will be disrupted until we can fully migrate away from Mangopay.

By the time this blog post is published, it may be too late to do anything about this - though hopefully donors received the same emails creators did about this, so they could make sure everything on their accounts were either withdrawn or donated.

Until such time as Liberapay integrates with a new payment processor, I will no longer be able to accept donations through Liberapay. If you’d like to donate via credit card, your only option is currently through Patreon, though plans are still in the works for integrating payments through Stripe.

New Patron!

Finally, a huge thanks to andacro on XDA Developers for becoming a Patron!

If you want to help support me and my various projects, head on over to the support page and choose whichever you feel comfortable doing.