VictoriaMetrics and Logs have worked fine in my quiet homelab, and VictoriaMetrics appeared to work great for the infrastructure team of an open source online video game I contribute to (say about 10 physical nodes and 20 applications/services ) ... I was going to suggest VictoriaLogs to them next but wanted to ask what roadblocks could come up.

I can definitely see exploring this for some homelab use.

(b) dodging Amazon co-mingling of inventory. Do I trust Amazon doing whatever it wants in a warehouse, or some eBay seller with a few years of built-up-reputation to lose but who specializes in the part I want? Let me tell you I have gotten a lot more handwritten thank-you-for-your-purchase notes from eBay sellers than Amazon. 3D printer parts, used computers+parts for the homelab, laser printer replacement parts, etc.

(Yes Amazon said they would stop recently... Not sure I believe it's fixed yet)

Plausible answers: $10

Good, useful answers: $100

Validation and Verification is what separate "should work" from "is shown to work".

Anyone can write non-functional code.

It's functional useful code that takes more work.

Once I got that running on my machine it was also easy (literally a drop-down+ API key) to switch and explore using models on OpenRouter.

But also definitely start setting up linting rules / labels to indicate how healthy or close something is to being merged.

The goal is to limit work-in-progress, and focus on getting PRs that are easy to merge over the finish line.

Edit: and yeah, a weekly review cadence goes a long way to triage tickets and PRs and get some initial feedback to developers. I also like the "next review on this date" proposal to push certain problematic PRs to a slower cadence so they're not occupying too much bandwidth.

(Not a residential inbox, the "I work in IT" sized inbox with all the email alerts about jobs failing...)

Any LLM not sufficiently likable and helpful in the first two minutes was deleted or not further iterated on, or had so much retraining (sorry, "backpropagation") it's not the same as it started out.

So it's going to say whatever it "thinks" you want it to say, because that's how it was "raised".

It then turns into a slowly-growing problem if you never ever clean up the soft-deleted records, but just being able to gain auditability nearly immediately is usually well worth kicking the can down the road.

Clearly removing C02 is expensive, but can we just paint some of the desert with paint that reflects in the infrared window? Or make clouds as Neal Stephenson talks about in his fictional novel Termination Shock?

https://en.wikipedia.org/wiki/Infrared_window

https://www.parkytowers.me.uk/thin/wyse/5070/

Having a second pair of "eyes" to read a log error and dig into relevant code is super handy for getting ideas flowing.

Terraform is working on that - burstable synthetic methane generation using cheap catalysts that you can afford to idle, only generating methane when electricity is cheap.

"I am learning Elixir, can you explain this code to me?" (And then I can also ask follow-up questions.)

"Here is a bunch of logs. Given that the symptom is that the system fails to process a message, what log messages jump out as suspicious for dropping a message?"

"Here is the code I want to test. Here are the existing tests. What is one additional test you would add?"

"I am learning Elixir. Here is some code that fails to compile, here is the error message, can you walk me through what I did wrong?"

I haven't gotten much value out of "review this code", but maybe I'll have to try prompting for "persona: brief rude senior" as mentioned elsewhere.