Projects in progress

This page changes a lot and is very rough as I write things down here while they are in progress and I update the blog after they have happened.

Athena

Currently adding additional time management, time reporting, and time controls to the project. The project in its current state written up here. For those who don't know, Athena is a program I use to launch applications both locally and across my cluster of machines which are then streamed back to me across multiple OSes. It is heavily used as part of my efforts in game preservation. It is effectively a VDI application which was written to streamline applications for quality of life during a surgery I had. It includes: a ncurses interface, CLI, rest API, and python library.

Mostly doing this because it's functionality I would prefer to be in the application, and it gives me more fine-grained control over how I spend my time.

Software defined networking

The current home lab requires that networking be defined manually in multiple routers we have. I find this to be very tedious and error-prone as anytime a router fails we without fail find something that was not backed up or documented. If this could live in git then we would not have this issue. Additionally, it would reduce the single points of failure on our network by allowing us to easily implement HA to things like our databases, NFS, and docker registry. While yes, we can just migrate virtual machines that will cause guaranteed downtime which is not ideal. I run pfSense and Ubiquiti routers which both have REST APIs (official and unofficial depending on which) available.

This is partly for fun, but also partly because currently if the server running NFS and the databases flips off most of our K8s deployments are failing, and I'm not always home. So if I am not home and something like the database for my photo gallery fails to load then that is a real issue because I cannot load my library. As for why this we are doing this rather than just live VM migrations, parts of our network cap at 1GB so we can keep data in sync, but not an entire operating system in a reasonable time. And the time to restart a VM is higher than I would like.

Home lab improvements to HA

The current home lab has a number of single points of failure. Currently, I'm in the process of migrating most of the K8s storage to Longhorn (Ceph is overkill for my network). Additionally, I intend to move away from having the MariaDB database I use hosted on a virtual machine as this single point of failure is a bit of a concern when I am away from home, specifically long term plans include the MariaDB Operator. Also migrating Piwigo to be in K8s (this was merely migrated from an old VM). Finally...setting up replicas for my kiwix deployment, reverse proxy, DNS, and the internal docker registry.

Mercury

I do make some use of AI tooling for proof of concept or simple utilities, but I do this primarily with local compute. My partner and I also have an AI agent we use for memory\reminding us of tasks (the memory of the agent is also backed in git which we periodically audit for inaccuracies). We've been hitting limits with respect to the stability and capabilities of off the shelf options.

Mercury harness is intended to be resilient to software\hardware failure, contain proper security isolation, and able to run distributed across multiple inference backends in high availability itself. One primary goal is to improve recall by maintaining an automated database of summary information for keywords that hot loads into the current conversation (ex user talked about Talos, here is there previous notes on Talos loaded into memory). Additionally, to provide limited scope\context for specialized tasks such as live migrating between machines when debugging. The intent is to provide a system which can reliably stay online, execute on whatever hardware\provider is available, and be useful within the limits of the technology.

To me this is just a tool to augment my own capabilities in templating applications, basic scripts, and assist in network maintenance. Security safeguards are hardcoded limits that are not writable by the harness itself. It will make errors, but that's just the nature of the tech. For context on my thoughts of AI and my current use case please take a look here.