This guide is mostly a reference for myself as it’s a workflow that I find myself following whenever I set up a new Linux machine. I’m sharing it here as I’m sure many will find this useful, and it will save me from looking up each distinct step in the future.

I also took the opportunity to add some bonus network configuration tips to get the most out of the setup.

I recently installed Fedora on my personal laptop to replace Manjaro as I found Manjaro to be a just a little too flaky for my liking and I know Fedora to be a solid alternative. During installation I was asked if I wanted to encrypt my drives. Now I’m not harbouring anything particularly sensitive but I thought it was worth doing, security first and all that; after all, we expect every website to support HTTPS these days so why not?

Well there is the matter of that mildly pesky login prompt on every boot…

When I set up my own SD-HDD solution based on the wonderful ACSI2STM project, I found the hard drive was becoming corrupted pretty soon after setting it up. I thought it might have been my dodgy soldering or something funny about the way I had everything set up. Turns out I simply hadn’t heard about Bad DMA. A local Atari enthusiast meetup later and a solution was proposed; swap the 68000 chip for a newer, lower power and subsequently less noisy version.

It worked!

Fluxor is a Flux implementation for Blazor in the vein of Redux. It is a state management system designed for larger software systems that encourages immutability of state, pure functions and clean separation of code. Given my fairly basic understanding of the Flux pattern I thought it would be valuable to document what it is at a high level and what’s required when using Fluxor to implement the various concepts.

MVVM is a development pattern that has been around for a while now. It was designed to facilitate the development of WPF applications for Windows and is still used for the likes of Maui apps. I reckon it has a place in Blazor apps as a neat way to separate view from logic, and as a sort of volatile state management for when you don’t want state to persist between pages.

A published Blazor WebAssembly instance is just a collection of files that can be loaded into a browser. If these files are hosted on the API, running the API means the UI is running as well, probably from the same address. In this case it’s a little different to debug compared to launching it standalone, but not any more complicated.

I never noticed it growing up but I see it now, TOS is profoundly flakey. My ST has a TOS 1.62 ROM built in and it does not play nice with hard drives.

There’s a simple solution to this, use the wonderful open source EmuTOS instead. Now I’m not resourceful enough to go writing EmuTOS to a flash ROM but my ST does have enough RAM that I can easily get away with loading it up from the hard drive.

I couldn’t find a single-page cheat sheet that summarised SOLID software development principles, so I made one. For each of the letters in SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) there are a couple of bullet points explaining the benefits of adopting them and the smells that betray their violation.

Today I spent a bit of time fighting with certificates in an ASP.NET application I’m working on. The scenario is we have Blazor Server communicating with a Minimal API. Debugging locally I was struggling to get the two to communicate, with errors like:

The remote certificate is invalid because of errors in the certificate chain: UntrustedRoot

A quick tip here for when a bluetooth mouse takes a moment to react after not being used for a few seconds. Bluetooth autosuspend can be disabled with a negligible power consumption penalty by setting a kernel parameter on boot.