im basically just making it cuz i want to yeet my shitty bots at servers and then never really care about them ever again after that, so i can keep pushing stuff to repositories and the changes will land nicely and automatically in the respective places
in-place CI/CD bois
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
Rust stuff, oxide.computer
Rust stuff
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
👀
rrcip
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
rrcip
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
rrcip musing
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)
In older systems, this bar mainly worked around the amount of "tasks" you'd put in an array or something, and the system would sign off and display the progress bar accordingly.
With files, its just % of bytes transferred so far, the read head.
But with other things, you dont *know* how much it's going to take, unless you know all the variables, in which case you can reduce the tasks to some degree that it'd skip those "time-taking tasks" in some efficient manner anyway.
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.)
(relatively) more serious and articulated account of @ShadowJonathan
prepare for nerdery, and SCIENCE
also lots of thoughts about systems and stuff
hmu on matrix @jboi:jboi.nl
#nobot, unless you're one of the ones that likes to cuddle