I was just looking into microvm (via microvm.nix) to isolate coding agents. While the machine starts quickly, as in the article, the userspace (nixos) takes much longer. I'd probably need to spend some time to strip the system of all non-essential services. I also briefly considered running the agent harness as PID 0. That would speed things up, but also mean a lot of responsibility on my end. My biggest struggle is how to imperatively manage agent microvms on nixos. microvm.nix isn't really well suited for that task. For longer-running VMs, that I can manage via my nixos config, I'm quite happy with microvm.nix. Related article by Michael Stapelberg: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-...
After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.
I'm looking forward to the analysis how the attacker managed to compromise CI. I was reading through the workflow and what immediately jumped out was a cache poisoning attack. Seems plausible, given https://github.com/TanStack/config/pull/381
edit: two hard things in computer science: naming things, cache invalidation, off-by-one errors, security. something something
CDN wouldn't help much. These days browsers partition caches by origin, so if two different tools (running on different domains) fetch the same model from the CDN, the browser would download it twice.
China is already slowing down the addition new fossil fuel power plants. Yes, they still build new ones, yes they generate a lot of emissions. But they are also adding more than the rest of the world combined of renewable (solar, wind) electricity generation each year. Realistically, if China stopped 100% of emissions tomorrow, they'd be in much better position to replace it with clean alternatives than most other countries.
A loooong time age (OpenSolaris days) I had a system that had corrupted its zfs. No fsck was available because the developers claimed (maybe still do) that it's unnecessary.
I had to poke around the raw device (with dd and such) to restore the primary superblock with one of the copies (that zfs keeps in different locations on the device). So clearly the zfs devs thought about the possibility of a corrupt superblock, but didn't feel the need to provide a tool to compare the superblocks and restore one from the other copies. That was the point when I stopped trusting zfs.
Ok. So to answer the question whether the code for v1.0.0 that I downloaded today is the same as I downloaded yesterday (or whether the code that I get is the same as the one my coworker is getting) you basically have to trust Google.
Let's assume I publish a github repo with some go code, and tag a particular commit with tag v1.0.0. People start using it and put v1.0.0 into their go.mod file. They use the golang proxy to fetch the code (and that proxy does the "verification", according to your comment). Now I delete the v1.0.0 tag and re-create the tag to point to different (malicious) commit. Will the golang proxy notice? How does it verify that the people that expect the former commit under the v1.0.0 tag will actually get that and not the other (malicious) commit?
I just recently learned of Meshtastic (https://en.wikipedia.org/wiki/Meshtastic) and MeshCore (https://meshcore.nz/), which provide a platform for private and group messaging over P2P LoRa. They don't depend on internet, rely on the community to provide routing nodes, and thus harder to block for governments. It's gaining steam in Europe and can already be used for messaging across wide distances. It's slow though, so forget streaming videos or images. It can only carry messages. But that's often enough to coordinate or spread news.
I repurposed old M1/M4 Mac Mini's at my workplace into GitHub action runners. Works like a charm, and made our workflows simpler and faster. Persisting the working directory between runs was a big performance boost.
I just ordered the BD790i X3D mainboard. A while ago Minisforum has been known for their slow BIOS updates, but hope that they have improved their processes since. I'll see…
We got rid of all Rails apps (that needed a backend). We've moved our Postgres databases to Neon, and run our docker containers on Google Cloud Run (these are containers that don't need to run 24/7, we're paying just a few cents each month, also cold starts are much faster and more reliable than on Heroku).
Or donate money. Crazy idea, eh?