mwpmaybe

I just wish Rust were slightly more readable...

> Ruby is the best because it's token-efficient

Is one I've heard...

Interesting. I use `--greedy` for casks but not regular formulae.

So much of GNU et al is already in Homebrew that I wonder how close you are to being able to support Intel Macs using the Linux/amd64 branch (or backend or whatever you call it) of Homebrew or something close to it, possibly after installing a few base libraries and utilities from MacPorts.

ETA: I've got Homebrew 7 building packages from source on an Intel Mac running Monterey; nothing yet required from MacPorts and a pretty minimal patch to the installer. I'd probably want to add legacy-support from MacPorts and update the macOS build environment to add it as an extra library on Intel Macs if I were to continue.

That being said, I'm sure y'all talked about continuing to support Intel Macs as source-based and ultimately decided against it, so it's unlikely that this will be interesting to the team. But let me know if I'm wrong and I'll open a couple PRs for further discussion.

Ahh, interesting. I have an issue today where my GitHub agentic workflows keep blowing through the context window that my local models can support; it ends up spending most of its runtime compacting over and over again. I've done all the usual stuff to slim down the fixed context and prevent it from slurping up too many files but it's still a recurring issue. Now I'm wondering if I can put engrim in the gh-aw container (or in the DinD sidecar it uses on ARC) and teach the headless claude harness how to use it, possibly even: "keep persistent context in engrim and use `/clear` instead of `/compact`". I'll play around with it. Thank you!

I hope you don't mind me asking you some ELI5 questions because I'd like to understand how this fits in with everything else.

I generally discourage my agents from storing memories locally because they don't travel; I'd much rather have a small in-repo document—whether it's an architectural decision or TODO or session log entry or runbook or environmental quirk or something else—that the prompt/CLAUDE.md/whatever can guide agents to grep and sed. Then I can dispatch work to a local agent, or a local agent running in a sandbox, or an agent running in a provider's cloud environment, or a GitHub agentic workflow running a headless harness, etc. and they all have access to it. Another benefit is that memory updates get PRs and reviews like everything else.

So what am I missing by not using something like engrim or gbrain?

Add a PoE switch and PoE splitters for IP-KVMs that don't already have PoE-in?

I went with Sipeed NanoKVM (PCIe) units across my homelab as well and I've also been happy with them. For a while it's been the best value option (not to mention the most consistently available option) cf. GL.iNet, PiKVM, and JetKVM. The PoE versions are great in a rack and the integrated ATX control is fully-featured (including the little power switch icon in the web UI turning green when the system is powered on). I set up an isolated OoBM VLAN with no Internet access and any switch ports assigned to it are isolated by default as well.

Have you played around with OpenBMC or any of the open-sourced BMC firmware alternatives?

ETA: specifically on older server/workstation boards instead of the stock firwmare

The memory controller is integrated into the CPU, so the motherboard chipset is irrelevant. There are some OEM-only v3/v4 parts with dual memory controllers, but the E5-2620 v4 is not one of them.

There are some OEM-only v3/v4 parts with dual memory controllers (because of a RAM supply crunch at the time, funnily enough), but the E5-2620 v4 is not one of them. The classic example is the very popular 12-core E5-2678 v3.

They've been stable for me but I'd be lying if I said I'd only heard good things.

Looks like prices on the E810-XXVDA2 have come up since the last time I looked while prices on the ConnectX-6 Lx have come down, so that'd be a good option!

You can't punch down twinax and the connectors are too big for keystones.

> Nowadays I'm not actually sure if DACs are cheaper than fibre now

Yep still are, although fiber transceivers are surprisingly affordable, and of course you can usually re-use jumpers when you upgrade transceivers so TCO over a couple generations might be comparable.

> I'm getting a really bad taste in my mouth for 10GBASE-T RJ45 SFP+ modules mostly due to the god awful heat they pump out

It's truly bananas especially in a homelab environment. Nearly every time I've thought to myself "oh I can just do a copper gbic for this" it's been the wrong thing to do.