Jonathan @jboi@fuzzy.systems

currently thinking about the train-to-vm daemon like so:

train > railcar (vm daemon) > qemu?

except i dont know what a good way would be to interface inbetween processes like this (with failover and all) in rust, and how to kick off a sub-process like that in a consistent manner, maybe i need to look into rust subprocess management

this is basically going to be a test on my ADHD, to see if i can keep focus on this, but a big upside is that all of these are different components that just build on eachother, so there's not much fucking around in terms of "you need to use these parts to support this" or something

main focus is efficiency, stability, extensibility

The first stage of this all is basically the "alpha" one, me figuring out how to work with rust in a fashion, and getting people on-board if they're interested, nothing's stable yet, and nothing is intended for production or anything

maybe then, once i think i can write it better, i do a hard cut-off and do a "beta" phase, where i/we rewrite everything from scratch, and focus on making it stable and professionally accessible (yes, i dont want to focus on "enterprise" only lol)

Alright so these are my notes so far on RRCIP

Basically, have a system of components that're low overhead, written in rust, extendable, and managed on a scale where it makes sense

Main inspirations are: Kubernetes, VMWare, Openstack, and the majority of cloud services

Just got thinking about the "progress bar" you often see in movies and games, like "hacking ... done" with the progress bar being linear or something

Funnily enough, i just realised it has a direct relationship with P=NP and the halting problem, because before the computer can ever display that bar, it has to know how long or how "much" each step of the progress bar has to take for it.

(cont.)