Jonathan @jboi@fuzzy.systems

I'm currently working on something along the lines of a "hidden variable toolkit", I realise, to basically have something which you can rely on having a hidden variable for a while

Currently documenting rust code and feeling good

if y'all confused about chute: its basically a git-to-production-ease-of-use-whatever manager to make your job to setup all of your python projects as easy as:

chute add <name> <git url> -b master
chute start

which will clone/fetch the requested repo (if it hasnt done so already), check it out to an internal directory, and then start it according to .chute.yml which specifies some setup commands and then an entrypoint command

its meant to be containers lite, basically "i dont give a shit how this is supposed to be set up, just do it" kinda deal without the whole infrastructure of images in place, its kinda jank as fuck, but its mostly meant as a "i dont care, just do it" attitude i often have to running my stuff on servers

oh yeah, and when pulling (cuz it does that automatically), it stops the container/process, then swaps out the layers (the git "root" layer when an additional "data" layer) to the new commit, and restarts it

im kinda tempted to make a nicer runc or container abstraction for rust, because the current crate (rust-runc) does NOT clarify anything, its just a straight copy of go-runc

Do any of y'all know some good practices and/or crates to achieve easy and reliable interprocess communication in rust?

http://dtrace.org/blogs/bmc/2020/10/11/rust-after-the-honeymoon/

Found something cool

Not only some notes about what rust is like, but also a start of a probable interesting company: oxide.computer

👀

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