Jonathan @jboi@fuzzy.systems

Maybe I'll just focus on making this library first of all, make it a nice wrapper around virt, and only *then after* start making the component for train

I'm fairly convinced that I can make this work in rust, I'm just not convinced I can make it nice right off the bat

I discovered the `virt` crate just now, and I went on a spree to discover stuff about libvirt and all

I p much have confidence that as long as I can wrestle it into a nice big crate that will handle everything nicely and ergonomically (as `virt` is literally just FFI C bindings to libvirt), XML stuff included, i can start using it as a train component

Oh, and the rust ecosystem will have a rust-made virtual machine library built on top of libvirt, heh

But i think imma make it git-only for now, and not yet put it on crates.io or something, though *maybe* I'll do it in 0.x fashion, and have a big banner saying "this is a work in progress", as my rust skills are kinda bad rn

alright so apparently `virt-manager` is made in python

perfect

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.)