We'll start getting things up and running little by little this term. The first thing will be to add to the database all the hardware that the staff has been validating on the test bench during the summer. I see quite a few processors, a good number of motherboards, and countless RAM models. I'll get to work on that in the coming days.
Software Update
The first major undertaking will be working on the servers. This will likely happen during the week of September 7th (the exact day will be specified later). Currently, all web requests pass through a caching proxy on a VPS. The initial idea was to reduce the load and bandwidth on the backend, but it hasn't worked as expected. On one hand, there are prolonged bursts of transfers between the backend and the VPS that saturate the connection (the exact opposite of what I intended). This is because when someone downloads a large file, the entire file is copied to the cache while being served. On the other hand, countless issues have arisen (mainly on the museum site) for reasons I still don't fully understand (it's my first time configuring Nginx's cache and there's something I'm not doing right).
That means we'll go back to the previous setup: using the VPS as a gateway to take advantage of its better connection routing, and that's it.
In parallel, the main server's OS will be updated (now acting as the backend). This operation is usually quite tedious and will likely take up almost a full day.
There are also pending updates for NodeBB (forum) and Mastodon.
Hardware Update
Regarding the current hardware, we'll be rotating hard drives. In recent months, a couple of drives have failed (one of them suddenly and disastrously). There's likely a methodological flaw on my part here: I've taken for granted that hard drives are permanent as long as operating conditions are adequate, and having backups has made me complacent. It's also true that the number of hard drives has multiplied over the past year: we used to just have the NAS and the system drive. Now, there are also dedicated drives for Mastodon resources, PeerTube, Redis, the museum, the web server, and the Ryzen 9900X. The probability of failure multiplies accordingly.
Anyway, after that, I was left without hard drives suitable for these tasks, so I've replenished the reserves (they aren't new, but have very little usage). I still need to figure out how to distribute the services and data, but that's irrelevant for now.
Regarding the hardware renewal campaign that was left unfinished last term, given the current situation, it won't be resumed anytime soon. A few months ago, I was hoping things would start normalizing around this time of year, and although there are signs of a cycle shift and some macroeconomic forces seem to be emerging that could help restore balance, the harsh reality is that it won't happen by 2026.
Development
I still don't know how much time I'll be able to dedicate to this over the coming months. I hope it'll be something similar to what I've been doing recently, but nothing is guaranteed.
Last term, the test bench project was shelved. Some beta versions were released, but issues arose when trying to reproduce results after making structural changes to the program (threading vs. process architecture). The initial idea is to keep the core intact for tests 1 through 4, add a new test (large memory) within a multithreaded framework, and gradually add features to the GUI. There are also pending details on the website (layout, graph aesthetics, and other minor issues).
In parallel, the homepage will be reimplemented to abandon the DBMS I originally created, which has proven a pain to maintain, slow, and insecure, in favor of migrating to the same structure used for the test bench and the museum. As for content, the idea is to experiment with AI (remember that at Hardlimit, only open-source models run locally are used). I want to run some tests to see how it works. If the results aren't as expected, we'll revert to the manual method. The idea is also to offer an English-translated version. All of this will require massive amounts of processing power, so that might be where the plan falls through. We'll see.
And to wrap this up, all the code related to forum translation and PeerTube subtitles will be refactored. This has always been done experimentally, in bits and pieces, throwing things together haphazardly. It has ended up resulting in a somewhat chaotic file and directory structure.
I also want to experiment with more flexible forum translations, meaning giving the model more freedom to split and merge sentences to make the translations sound more natural. Currently, it's instructed to respect the original text's structure, which sometimes leads to unnatural translations in the target language. It's a delicate topic (from the standpoint of preserving the fidelity of the information being conveyed), which is why I want to run some tests before implementing it.
The entire forum translation project will have higher priority than last term, as there's finally some activity (very little, but it's there), which leads me to believe that the number of English-speaking readers on the forum must also be increasing.
Anyway, there are more things on the back burner (promoting certain types of content on PeerTube, encouraging people to participate in the forum, pushing to use the Mastodon instance, etc.). But the current infrastructure calls for caution when pushing for even moderate growth in activity, especially on PeerTube. Since the ultimate goal is for everything to mutually reinforce each other, this has been put on hold for now.