There’s a recurrent pattern with these package compromises: the attacker exfiltrates credentials during an initial phase, then pivots to the next round of packages using those credentials. That’s how we saw them make the Trivy to LiteLLM leap (with a 5 day gap), and it’ll almost certainly be similar in this case.The solution to this is twofold, and is already implemented in the primary ecosystems being targeted (Python and JS): packagers should use Trusted Publishing to eliminate the need for lo

PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages.I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default.Here's how to set global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ignore-scripts=true ~/Library/Preferences/pnpm/rc minimum-release-age=10080

It's relatively straightforward to fix this for Big Tech. Commit to legally binding agreements with electrical grid operators that consumers will share no financial burden for data center power consumption. Commit to no local water usage for cooling needs, and perhaps even offering district heating for free where relevant (Meta's new datacenters in Dekalb, Illinois are close enough [~5 miles] to provide district heat for the college there, NIU). Commit to brownfield use or otherwise not using la

> Separate Accounts for your OpenClaw> As I have mentioned, treat OpenClaw as a separate entity. So, give it its own Gmail account, Calendar, and every integration possible. And teach it to access its own email and other accounts. In addition, create a separate 1Password account to store credentials. It’s akin to having a personal assistant with a separate identity, rather than an automation tool.The whole point of OpenClaw is to run AI actions with your own private data, your own Gmail, your ow

> What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts?> What do teams of 1, 10, 100, 1k, etc care the most about?Oh god no! That would be about the worst way to do it.Just make it conceptually sound.

Team scale doesn't tend to impact this that much, since as teams grow they naturally specialize in parts of the codebase. Shared libs can be hotspots, I've heard horror stories at large orgs about this sort of thing, though usually those shared libs have strong gatekeeping that makes the problem more one of functionality living where it shouldn't to avoid gatekeeping than a shared lib blowing up due to bad change set merges.

> Although, surprisingly, built on top of absolutely incredible silicon.To me that's because thats a capital E "Engineering" driven task that Product can't get their grubby little mitts on and ruin.

> I find LLMs so much more exhausting than manual codingI do as well, so totally know what you're talking about. There's part of me that thinks it will become less exhausting with time and practice.In high school and college I worked at this Italian place that did dine in, togo, and delivery orders. I got hired as a delivery driver and loved it. A couple years in there was a spell where they had really high turnover so the owners asked me to be a waiter for a little while. The first couple month

I find LLMs so much more exhausting than manual coding. It’s interesting. I think you quickly bump into how much a single human can feasibly keep track of pretty fast with modern LLMs.I assume until LLMs are 100% better than humans in all cases, as long as I have to be in the loop there will be a pretty hard upper bound on what I can do and it seems like we’ve roughly hit that limit.Funny enough, I get this feeling with a lot of modern technology. iPhones, all the modern messaging apps, etc make

AI slop DNR