wereHamster
wereHamster on Hacker News
I looked at our GitHub Actions monthly expenses, then at the price of a M4 Mac mini (just when they were released, and still cheap), and decided to buy one as it would pay for itself in less than a year. There are definitely still cases when buying hardware still makes sense, over renting in the cloud.
Last week I got a report about a vuln in one of our products. Asked Claude to confirm it. It refused, so I told it "fuck you, I'm switching to a chinese model to help me out here". It replied, I'm paraphrasing, that it's "not offended, but doesn't like the tone of voice I used towards it, and still refuses to serve my request". Fine, so be it. I sent ^D^D back to it, switched to deepseek-v4.1-flash from within opencode and a minute later had my confirmation, along with a really nice explanation. If Anthropic thinks even for a second that they are preventing something really bad from happening... somebody needs to wake up real quick.
If they fix the devtools. Because Safari devtools are worse than junk.
I was in Kazakhstan, Uzbekistan not too long ago (both countries just to the south of Russia, for those not savvy of geography). Met plenty of young russians who moved there recently. I didn't have to ask why. Many of them used to work in the tech sector, it's easy for them to find new work.
EU is not necessarily dependent on the US in all the cases that are listed in the article. Take AXA, the insurance company. They could probably survive doing business just in the EU and withdraw entirely out of the US market. But for them it's more lucrative to piss off one judge rather than lose the US share of profits. As the article describes, it's a business decision. But not one that necessarily means life or death (for the company).
I wonder why larger companies don't use self hosted github runners. You can buy a pretty beefy machine (TB of RAM, 256 cores, fast NVMe disk) and tests will run faster than on any hosted platform. Plus you don't have to shard as aggressively because more fits into one machine, benefit of shared page cache, shared persistent disk, can easily preserve working directory (for example my pnpm install takes 0 seconds, because the node_modules folder is already present from the previous run).
> Add a mechanism to donate tokens
Or donate money. Crazy idea, eh?
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/381edit: 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.
I bought a light HF acid (rust remover) so I can properly clean titanium parts before anodizing. Worked like a charm...
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.
Such arrogance…
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?
Now I understand :) thanks for clarifying
A lock file, in my world, contains a cryptographic hash of dependencies. go.mod does not, it only lists tags, which are (in git) movable references.
If go.sum has "no observable effect on builds", you don't know what you're building and go can download and run unverified code.
I'm not a go developer and must be misunderstanding something...
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).
We just managed to shut down our last Heroku service a week ago. Good riddance.
AGPL is a no-go for many companies (even when it's just a tool that touches your code and not a dependency you link to).
Could it be that they removed /all/ comments from the codebase when they made it public, to not release some sensitive information that was in them?
A year ago I was traveling through Uzbekistan while also partly working remotely. IKEv2 VPN was blocked but thankfully I was able to switch to SSL VPN which worked fine. I didn't expect that, everything else (people, culture) in the country seemed quite open.
> Either way, scanning that space is probably a waste of bandwidth
That's what the DoD wants you to think ;)