clean up writing

blog/about.md

@@ -32,7 +32,7 @@ Friend me on [Project Euler](https://projecteuler.net/friends)! My code is `1997
 
 ## Skills
 
-* Programming in all cool languages (Python, JavaScript somewhat resentfully, Rust, Lua, Nim, Haskell).
+* Programming in all cool languages (Python, JavaScript, Rust, Lua, Nim, Haskell).
 * Programming in several uncool languages (C, Java), but only ironically.
 * Vague knowledge of contemporary machine learning frameworks and algorithms.
 * Expert knowledge of ComputerCraft (Minecraft mod).

blog/stack-rsapi.md

@@ -80,7 +80,7 @@ RSAPI has a wide range of functions, having grown from a short Flask application
 * RSS feed for random memes (for XScreensaver).
 * Better login system - multiple users, SSO for other services via [Nginx authentication subrequests](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/), basicauth option for non-interactive systems.
 * Key/value storage backend for PotatOS, due to the shutdown of the random free API it used before.
-* Internal LLM-based [Threat Updates](https://r.osmarks.net/threat-update) system[^8], to replace the archive of historical ones and Twitter scraper. I was too lazy to work out how to draw nicely line-wrapped text in images in Python, so this actually invokes a ComputerCraft emulator, runs the Threat Update implementation on that, dumps its virtual screen, and renders that to an image.
+* Internal LLM-based [Threat Updates](https://r.osmarks.net/threat-update) system[^8], to replace the archive of historical ones and Twitter scraper. I was too lazy to work out how to draw nicely line-wrapped text in images in Python, so this invokes a ComputerCraft emulator, runs the Threat Update implementation on that, dumps its virtual screen, and renders that to an image.
 * The new comments system, replacing [Isso](https://github.com/isso-comments/isso). It supports ominous AI faces (from StyleGAN2, thanks to [StyleGANCpp](https://github.com/podgorskiy/StyleGANCpp/)[^7]), leftvotes/rightvotes for greater user expression, SSO integration, better threading, and lower client resource use.
 * Lighting control orchestration.
 

blog/stack.md

@@ -2,7 +2,7 @@
 title: Site tech stack
 description: Learn about how osmarks.net works internally! Spoiler warning if you wanted to reverse-engineer it yourself.
 created: 24/02/2022
-updated: 11/05/2023
+updated: 08/04/2025
 series: stack
 series_index: 1
 ---
@@ -12,18 +12,16 @@ If you can't stand the heat, get out of the server room.
 
 As you may know, osmarks.net is a website, served from computers which are believed to exist. But have you ever wondered exactly how it's all set up? If not, you may turn elsewhere and live in ignorance. Otherwise, continue reading.
 
-Many similar personal sites are hosted on free static site services or various cloud platforms, but mine actually runs on a physical server. This was originally done because of my general distrust of SaaS/cloud platforms, to learn about Linux administration, and desire to run some non-web things, but now it's necessary to run the full range of weird components which are now important to the website. ~~The hardware has remained the same since early 2019, before I actually had a public site, apart from the addition of more disk capacity and a spare GPU for occasional machine learning workloads - I am using an old HP ML110 G7 tower server. Despite limited RAM and CPU power compared to contemporary rackmount models, it was cheap, has continued to work amazingly reliably, and is much more power-efficient than those would have been. It mostly only runs at about 5% CPU load and 2GB of RAM in use anyway, so it's not been an issue.~~ Due to the increasing compute demands of internal workloads, among other things, it has now been replaced with a custom build using a consumer Ryzen CPU. This has massively increased performance thanks to the CPU's much better IPC, clocks and core count, the 16x increase in RAM, and actually having an SSD[^2].
+Many similar personal sites are hosted on free static site services or various cloud platforms, but mine runs on a physical server. This was originally done because of my general distrust of SaaS/cloud platforms, to learn about Linux administration, and desire to run some non-web things, but now it's necessary to run the full range of weird components which are now important to the website. ~~The hardware has remained the same since early 2019, before I had a public site, apart from the addition of more disk capacity and a spare GPU for occasional machine learning workloads - I am using an old HP ML110 G7 tower server. Despite limited RAM and CPU power compared to contemporary rackmount models, it was cheap, has continued to work amazingly reliably, and is much more power-efficient than those would have been. It mostly only runs at about 5% CPU load and 2GB of RAM in use anyway, so it's not been an issue.~~ Due to the increasing compute demands of internal workloads, among other things, it has now been replaced with a custom build using a consumer Ryzen CPU. This has massively increased performance thanks to the CPU's much better IPC, clocks and core count, the 16x increase in RAM, and having an SSD[^1]. The main server currently idles at ~5% across cores and 30GB of RAM in use due to extensive caching.
 
-The main site itself, which you're currently reading, is in fact just a simple static website. Over the years the exact implementation has varied a lot, from the original not-actually-that-static version using Caddy, some weird PHP scripts for Markdown, and a few folders of HTML files, to the later strange combination of Haskell (using Hakyll) and makefiles to the current somewhat horrible Node.js program (which also interacts with someone else's Go program. Fun!). The modern implementation of the compiler does templating, dependency resolution, Markdown and some optimization tasks in about 300 lines of poorly-described JavaScript.
+The main site itself, which you're currently reading, is primarily a simple static site, though it consumes several backend services and integrates several pieces of JavaScript (vanilla JS and Svelte) for controls and comments, as well as for individual experiments. Over the years the exact implementation has varied significantly, from the original not-very-static version using Caddy, some PHP scripts for Markdown and a few folders of HTML files to the later strange combination of Haskell (using Hakyll) and makefiles to the current somewhat cursed [Node.js program](https://github.com/osmarks/website/blob/master/src/index.js). The modern implementation of the compiler does templating, dependency resolution, Markdown, search indexing and some optimization tasks in several hundred lines of very dependency-heavy and undocumented JavaScript.
 
-Being static files, many, many different webservers could have been used for this site. In practice, it's mostly alternated randomly between [caddy](https://caddyserver.com/) (a more recent, Go-based webserver with automatic LetsEncrypt integration) and [nginx](https://nginx.org/) (an older and more powerful but slightly quirky program) - caddy generally had easier configuration, but I arbitrarily preferred nginx in some ways. After caddy v2 suddenly required me to rewrite my configuration and introduced a bunch of weird issues, I permanently switched over to nginx and haven't changed back. The configuration file is now 600 lines or so, even with inclusion of includes to shorten things, but it... works, at least. This is mostly to accommodate the bizzarely large set of subdomains I now have for various people, and reverse proxy configuration for backend services. I also use a custom-compiled build of nginx with HTTP/3 (QUIC) support and some modules compiled in.
+Being static files, many, many different webservers could have been used for this site. In practice, it's alternated between [caddy](https://caddyserver.com/) (a more recent, Go-based webserver with automatic LetsEncrypt integration) and [nginx](https://nginx.org/) (an older and more powerful but slightly quirky program) - caddy generally had easier configuration, but I arbitrarily preferred nginx in some ways. After caddy v2 suddenly required me to rewrite my configuration and introduced several inconsistencies, I permanently switched over to nginx and haven't changed back. The configuration file is now 600 lines or so, even with inclusion of includes to shorten things, but it... works, at least. This is mostly to accommodate the many subdomains in use and their associated reverse proxy configuration for backend services. I also use a custom-compiled build of nginx with HTTP/3 (QUIC) support and some modules compiled in, though QUIC is not turned on due to systems limitations.
 
-Some of these backend things are only for personal use, but a few are related to the site itself. For example, the comment server is ~~a standalone Python program, [isso](https://posativ.org/isso/),~~ now part of [RSAPI](/srsapi/) with corresponding JS embedded in each page. This works pretty well, but has lead to some weird quirkiness, such as each separate 404-erroring URL having its own list of comments. There's also the Random Stuff API, a custom assemblage of about 15 different Python libraries and external programs which, while technically not linked on the site, does interact with other projects like [PotatOS](https://git.osmarks.net/osmarks/potatOS/), and internal services on the same infrastructure like my [RSS reader](https://miniflux.app/). The images subdomain also uses a [PHP program](https://larsjung.de/h5ai/) to generate a nice searchable index; in fact, it is <del>one of two</del> the only PHP thing<del>s</del> I have unfortunately not yet been able to purge[^1]. There also used to be a publicly available status page using some custom code, but this doesn't work very well and has now been dropped; previously I had a Grafana (and earlier Netdata) instance there, but this has now been cancelled because it leaks a worrying amount of information.
+Some of these backend services are only for personal use, but a few are related to the site itself. For example, the comment server is ~~a standalone Python program, [isso](https://posativ.org/isso/),~~ now part of [RSAPI](/srsapi/) with corresponding JS embedded in each page. This works well overall, but has led to some exciting features such as each separate 404 page URL having its own list of comments. There's also the [Random Stuff API](/srsapi/), a custom assemblage of about 15 different Python libraries and external programs which, while technically not linked on the site, does interact with other projects like [PotatOS](https://git.osmarks.net/osmarks/potatOS/), and internal services on the same infrastructure like my [RSS reader](https://miniflux.app/). The images subdomain also ~~uses~~ used a [PHP program](https://larsjung.de/h5ai/) to generate a nice searchable index; this has fortunately been purged along with [DokuWiki](https://www.dokuwiki.org/dokuwiki). There has been an on-and-off services status page, which is currently "on" thanks to running on custom code more reliable than the old custom code; previously I had a public Prometheus/Grafana (and earlier Netdata) instance there, but this has now been cancelled because it leaks a worrying amount of information.
 
-As for the underlying OS everything runs on, I currently use [Arch Linux](https://i.osmarks.net/memes-or-something/arch-btw.png) (as well as Alpine on a few lower-resourced cloud servers). Some form of Linux is inevitable - BSDs aren't really compatible with much, and Windows is obviously unsuited for server duty - but I mostly use Arch for its stability (this sounds sarcastic, but I've actually found it to be very reliable with regular updates), wide range of packages (particularly from the AUR; as I don't really run critical production infrastructure, I can generally afford to compile stuff from source a lot), and better general ease-of-use than Alpine. As much as I vaguely resent it, this is mostly down to systemd - despite it being a horrific bloated monolith, `journalctl` is very convenient and unit files are pleasant and easy to write compared to the weird OpenRC scripts Alpine uses.
+As for the underlying OS everything runs on, I currently use [Arch Linux](https://i.osmarks.net/memes-or-something/arch-btw.png) (as well as OpenWRT on some routing equipment - I used to use Alpine in some areas but these computers are no longer in service). Some form of Linux is inevitable - BSDs aren't compatible with much, and Windows is obviously unsuited for server duty - but I mostly use Arch for its stability (this sounds sarcastic, but I've found it to be very reliable with regular updates), wide range of packages (particularly from the AUR; as I don't run critical production infrastructure and have about two nines of uptime, I can generally afford to compile software from source), and better general ease-of-use than Alpine. As much as I vaguely dislike it, this is mostly down to systemd - despite it being a complex bloated monolith, `journalctl` is very convenient and unit files are pleasant and easy to write compared to the weird OpenRC scripts Alpine uses.
 
-I am actually considering yet another redesign, however; switching to a dynamic site implementation instead would allow me to integrate the comment system and achievement system better, make things like the "from other blogs" tiles actually update at reasonable intervals, and arbitrarily A/B test users, although it would break some nice things like this site's very aggressive caching and fast serving. Please leave your thoughts or lack of thoughts on this in the comments.
+Having considered a redesign to make the site partly dynamically generated rather than a static site for many years, I'm in the process of implementing it now, with a custom Lua and Rust program which will serve as a more flexible frontend server and be able to composite pages from multiple backends. This will allow for exciting* features such as more frequently-updating blogroll tiles, better-integrated comments and cleaner personalization mechanisms and interactivity, as well as less reliance on client-side JavaScript.
 
-[^1]: The previous one was DokuWiki, now replaced with [Minoteaur](/minoteaur/).
-
-[^2]: My next upgrade is probably going to be more SSD space, since I'm *somehow* running out of that.
+[^1]: Multiple SSDs now, in fact, due to ever-increasing storage demands.

experiments/tictactoe/index.html

@@ -1,6 +1,6 @@
 ---
 title: Tic-Tac-Toe (4³)
-description: Your favourite* tic-tac-toe game in 3 dimensions, transplanted onto the main website via a slightly horrifically manual process! Technically this game is solved and always leads to player 1 winning with optimal play, but the AI is not good enough to do that without more compute!
+description: Your favourite* tic-tac-toe game in 3 dimensions, transplanted onto the main website! Technically this game is solved and always leads to player 1 winning with optimal play, but the AI is not good enough to do that without more compute!
 slug: tictactoe
 ---
         <style>
@@ -494,4 +494,4 @@ slug: tictactoe
                 }
             }
             render()
-        </script>
+        </script>