WYGIWYG

  • 0 Posts
  • 110 Comments
Joined 2 years ago
cake
Cake day: September 24th, 2024

help-circle





  • It’s not like Mastodon; there aren’t superior communities. Outside of hexbear or .ml, there’s no meaningful difference between lemmy.social and lemmy.zip you just join one and follow what you want of all the options.

    The part the general public isn’t ready for is curating their own feed.

    There’s no AI shoving things at you so you can doomscroll. They want that.

    There’s also no ads paying for the servers, so we keep is small and enough of us dontate to keep it runnings.

    You get a couple million twitter/reddis assholes over here burning server costs up with not donating shit; the nice, quiet, pleasant community we have goes to shit.

    Don’t borrow trouble.



  • AI produces cookie-cutter bullshit.

    That said, at least for the time being, it gets down to brass tacks in the first paragraph or so. I guess they haven’t felt the need to keep your eyes on the page longer.

    Capitalist enshitifed journalism is the reason they’re ‘starving’ for readers. You can’t find a meat-created news article or a fucking recipe without sifting through 10 pages of hyperbole and nostalgia.

    Bring back the fucking newspaper article format where every word cost somebody money. Spend the money on paying someone to make sure the news is right and condense it into an article where your primary goal is conveying exactly what’s going on with a close fucking second goal of not wasting everyone’s time.







  • You’re absolutely correct, 100% It’s entirely scriptable. And I have done that work many, many times in the past 15 years

    The interesting differences:

    I didn’t write the ansible jobs, it did to my specifications, i just had to review them. It can generate an Ansible job that would take me 30 minutes to properly write/document in less time than it takes me to review its output.

    It knows how to do AWS AMI and RDS images without details. If Amazon changes something and it errors making the ami, it will, without intervention, find amazon docs and update it’s process.

    My playbooks are essentially Word documents (md tho) telling it to make an AMI backup and disable notifications using the monitor server who’s name and IP are documented the neo4j. I don’t tell it where the logs are, it knows. It’ll fire up a Cloudtrail to hunt something down if it needs it.

    The diffs on the health checks aren’t binary. If it sees something it can’t explain, it will go back further in time, inspect other nodes, even start going down the debugging route for the app, (as long as I give it docs on how it should debug). It doesn’t miss a line. It doesn’t blindly ignore things. I was doing a rebuild on a server the other day, and during the post-health check, it noted that a certain error on this node is present on 5 other nodes and that the most common cause is a minor config issue. I asked it to diagnose; it found a config file from the old image that we never touch. I’ve been running with that issue on 6 servers for years. By my hand alone, I’d never have gone back, researched it and fixed it. It’s truly trivial, but it’s also things like that I don’t have the time to invest in that make this so useful.

    And it goes through this level of detail for every node. It only bugs me if it finds something outside of scope that’s unexplainable.

    I don’t give it any passwords or hard config. It queries Amazon or Neo4j, which are kept up to date programmatically.

    The real terror is I can do this on several different projects at once. As my documentation, guardrails, and automation get better, I’m getting multiple times my own hours’ work done every day, and I was really big on automation and self-healing stuff before this ever came along.

    Could the node classifier go bonkers and wipe out everything? It could. But I’m careful not to just cron up a bunch of jobs and take a nap. Probably the next step would be to make some overseers to verify backups are being made and it’s waiting between jobs.




  • I don’t have a known good resource, but you should look into K3S. https://docs.k3s.io/

    The documentation is very dense, I fear. I would probably go hit youtube search for “k3s cluster” and find a beginner that doesn’t annoy you too badly.

    The general path you’ll have to do is:

    Translate Configuration: Convert your docker-compose.yml settings into Kubernetes YAML manifests

    Install k3s

    Map Storage and Secrets. Replace local Docker volumes with PersistentVolumeClaims (PVCs) and .env files with Kubernetes Secrets and ConfigMaps.

    Deploy and Verify: Apply your manifests using kubectl apply and verify routing through the built-in Traefik ingress.

    Then you can install and add a new node.

    depending on how you set it up, it’ll move the containers around for you automatically.

    Note: all your k3s nodes need to be very close network wise. you can dump one at a friends house and make a cool geo-diverse setup, they need REALLY low latency



  • Yeah, there are a bunch of ways to tackle that. Chunk-Based Content-Addressable Block Storage (that weird thing where they put a folder of 0-A the folders under that with hex-based naming and small chunks of data wouldn’t be horrible keeping update sizes managable. The real problem there is dealing with Syncthing conflict files. The monobinary is either new or old. Maybe a local-only CBC with deltas delivered by syncthing so they can overwrite each other and a rollback/history option.

    P2P anything is complicated. Something as damning and imporant as password management makes it so much worse.


  • Anthropic enterprise models are very strong at following runbooks and managing infrastructure. To frame this properly, I spent about a month documenting the environment and creating runbooks. I can currently do things like the following:

    Follow the steps below to roll over this cluster. {

    Choose a server in this cluster by ID in numeric order (this server)

    Use Ansible+vault to create a backup AMI of (this server)

    Use Ansible+vault to collect health data on (this server) according to the server health runbook

    Use Ansible+vault to disable notification for this server

    Use Ansible+vault to preform a full kernel update and reboot the vm according to the update runbook.

    Use Ansible+vault to collect health data on this server according to the server health runbook post update

    Compare the pre and post health and server alarms for (this server), if there is an issue, pause, SOS notify oncall

    Use Ansible+vault to enable notification for this server

    }

    Each runbook contains exact steps required, how to verify success, each one of them is able to pull the E-stop, freeze on that step and SOS notify.