when writing modular software, you might initially have an idea for how you'll split your modules. "oh I know, each group of commands can be its own module" you *will* want to do something different later. to design for the future: modules are just Bits Of Code, you shouldn't demand anything of them
one of the decisions I regret most from discordbot-lua is that I chose to do everything Declaratively. turned out I wanted a module that just does background stuff, no commands. okay let's add a util thingy for those. ok now I need command groups. oops this is a pain to implement. now it's a mess
is there a like real name for this tho as in, for the initial gain you get from something which you only later learn is tech debt
where does tech debt come from? well clearly it's created by tech loans
yeah... thankful that my only customer is myself and I don't need to deal with that kinda stuff
lmao i can't imagine switching distro to be that much effort (effort that went into the images that became unwanted notwithstanding) but that's such a weird reason to want a switch
well hey, if anyone needs a small (alpine-based) up-to-date (perpetually; built daily by github actions) base docker image for luvit.iohub.docker.com/r/technojo4/...
they actually consume 10mb ram so i guess they're gonna take more ram space than disk space lmao
having used EP, ED, BDv2, etc. i kinda just got tired of using the cool stuff and it dying so now i'm just on the basic vencord, barely customized cause i don't wanna bother updating a bunch of css tweaks, etc. but it is really cool and if i could be assured it wouldn't die i'd definitely go for it
really cool stuff happening here (i was an endpwn3 user and i like how the approaches it pioneered are being dug up again and innovated on further) but i will probably not be using it any time soon because i have no faith it will be maintained long-term moonlight-mod.github.io/blog/2024/10...
New libraries and utilities for a new version of moonlight