Cover photo courtesy of cat-milk/Anime-Girls-Holding-Programming-Books.

This post is going to be a bit different than the usual programming posts. It’s more for myself to organize my thoughts on things that need to be done.

Overall, there are quite a few technological things that require maintenance. For a long time I’ve just been doing what’s easiest and what works, and now the side effects of that are piling up. Things I’ve put off doing, etc. So here’s a list of what needs to be maintained, in no particular order.

I’m probably forgetting something, but this all I can think of for now. I’ll be checking off and amending to this list with dates as I go along in the future.

Having a clear, fresh start with the server.

Currently, the server is running Ubuntu Desktop and still keeps quite a few unneeded GUI applications, which require updating. In addition, my desktop Linux distribution is now Arch Linux, so for having a more streamlined set up on desktop & server it’d be best to put Arch Linux on it. (However, here.) Not to mention how much of a pain Debian package repositories are: I need to install brew on the server just to be able to get the latest version of Hugo.

Backups.

I need to have a solid, reliable backup system for both my server files and desktop files. Ideally, this would comprise of a secondary drive on the server on which periodic updates can be run (perhaps with rsync?) both from desktop and from the server. This drive should ideally by a terabyte, but something smaller could do in the meanwhile.

Beginning the transition away from GitHub.

For a variety of reasons already explained here on the Software Freedom Conservancy’s website, it’s time to move away from GitHub. Git was originally intended to be a free and distributed version control system, but the prevalence of the sentiment “Git = GitHub” shows how Microsoft has exploited the FOSS community into becoming dependent on a completely proprietary platform, using its unfettered access to the code of developers around the world to its benefit by training GitHub Copilot on that data without consent. The obvious easy solution is simply setting up headless Git repositories with SSH access on one’s own server as described here by Luke Smith. However, this only covers the easy backup aspect of GitHub as a service, not the web-based UI and repository aspect. This is where Gitea comes in. It’s a FOSS self-hosted GitHub alternative that from what I’ve seen seems a bit more lightweight than GitLab. However, even once Gitea is all set up and all my repositories are migrated to it, I unfortunately cannot delete my GitHub repositories right away. Soon, I’ll need to make university applications to major in Computer Science, and it’s likely that a GitHub account will be expected to act as a portfolio. So, I should instead set up all my GitHub repositories a mirrors of my primary Gitea repos until they are no longer necessary. Speaking of portfolios, this leads to my next point.

Remake my website.

Yes, again, I know. My current website setup is a simple landing page at elnu.com with links to Tegaki Tuesday, etc. and some recently watched anime using AniList’s API, along with blog.elnu.com for miscellaneous content (been a while since I posted there). What I need to do is once I have all my public repositories on GitHub cleaned up and migrated to Gitea, I should make a portfolio list of all the various projects I’ve worked on of note, since I don’t really have something like that at the moment.

Set up an email server.

(TODO: look into Luke Smith’s video on the matter) Currently, I’m using ProtonMail. It’s good and all, but unfortunately I have to pay in order to be able to use my own [cite/t:@elnu.com] address, and my parents need vanity URLs for another domain name, so it’d be rather annoying to have to pay for other accounts since my plan is only limited to one domain. In the past we’ve tried doing email through DreamHost, but it seemed like Gmail would shadow block all of those emails. I’ve heard that self-hosting email can be a huge pain and Gmail (and potentially even setting up Cloudflare reverse DDNS) may be an issue, but it’s worth giving a go.

Look into NixOS’s viability as an Arch alternative, both for desktop and server use.

My one point of frustration with Arch Linux is a “do it yourself distro” is the lack of a built-in way to keep track of configs. In your configuration process, you have to install various packages, run commands, and edit config files across your system. If you didn’t keep a meticulous record of all of your steps, then you might have trouble settings everything up again on a second system. Even if you did, then you still have to make record of those tweaks that are made past the initial setup. The fact of the matter is, I’m lazy. I haven’t bothered to create an install script for my current Arch configuration, or even a dotfiles repository.

Now, I’ve just gotten a new laptop, a Lenovo ThinkPad X220, and I’d like to have a painless method of keeping my system configurations synced between my desktop and laptop.

This is where NixOS comes in: a Linux distribution based on the Nix package manager that provides reproducible, declarative, and reliable system configuration. Instead of installing packages in the command line (though you can still do that if necessary for packages you only need temporarily), you declare them in the system configuration file /etc/nixos/configuration.nix. In this file, you can configure anything you can imagine: users and their permissions, what display manager and window manager/desktop environment you want (if any), how GRUB should be configured, etc.

In addition, NixOS provides Home Manager (which I haven’t much looked into yet), a similar system, except for particular users’ configuration. It gives much more fine-grain control, and lets you manage individual programs’ configurations, and even have programs installed for one particular user.

The magic of this is you can set up a Git repository for all of your Nix (.nix) configuration files and keep it synced between multiple devices, meaning you can maintain a consistent user experience across devices. Just partition your drive, copy over your configuration, build, and you’re ready to go. And I haven’t even mentioned NixOS’s rollback system!

Currently, I messing with NixOS in a virtual machine following this (lengthy) tutorial by Matthias Benaets. Hopefully, once I get a configuration set up in there more or less matching my current desktop setup, I can get it transferred to & and set up on the ThinkPad! We’ll see; I’m still not completely certain whether NixOS is practical as a desktop distribution.