Comments URL: https://news.ycombinator.com/item?id=47724705

Points: 3

# Comments: 0

It seems like a lot of the discussion is arguing in favor of API usage without realizing that MCP basically standardizes a universal API, thus enabling code mode.

https://news.ycombinator.com/item?id=46936105 Billing can be bypassed using a combo of subagents with an agent definition

> "Even without hacks, Copilot is still a cheap way to use Claude models"

20260116 https://github.blog/changelog/2026-01-16-github-copilot-now-...

https://github.com/features/copilot/plans $40/month for 1500 requests; $0.04/request after that

https://docs.github.com/en/copilot/concepts/billing/copilot-... Opus uses 3x requests

> MUCH MORE IMPORTANT

I haven't done the exhaustive research but props in advance for being the only person shouting in caps on HN. Definitely one way to proclaim one's not AI-ness without forced spelling errors.

Comments URL: https://news.ycombinator.com/item?id=47604157

Points: 2

# Comments: 0

A system for using Federated and Independent Repositories in WordPress

It remains one of the most reliable Microsoft products, but few would claim that is a high bar.

Corporate interest is primarily financial, anything beyond that is unfortunately all too often only (financially motivated) virtue signalling.

I interpret your comment as emphasizing that the current norm relying on publicly accessible (GitHub) infrastructure building releases in public and thus allowing public review of logs and artifacts provides tremendous value (and I admit that true 100% binary reproducibility is an often nearly unreachable goal still not yet typically expected as the norm).

> Breaking that chain via a private repo is a step backwards

I was stating that performing a reproducible build elsewhere and distributing the output could in theory still be validated though it would require re-running said build for one's self and comparing the outputs. This might encourage the pursuit of 100% reproducibility! The chain need not be considered broken just because the final link is private.

> the public has been deprived of this verifiability

This is not what I was trying to point out, though I agree the cost of verifying reproducibility would be higher. My point was that anyone could still perform the same steps themselves and verify the output. Yes this would be more work than reviewing logs on GitHub.

OP's primary concern with today's standard approach appears to be the automated connection from GitHub build action -> release. Even simply requiring manual maintainer intervention to copy the action output over to a release seems to satisfy both their and your concerns.

> If the public had the ability to audit that the release tarball was correctly built from the version-controlled code

I am not intimately familiar with all the details of the XZ fiasco but agree that it offers an opportunity to learn and make changes to work toward making sure nothing similar can happen to any project again. If I am reading your link correctly, it serves as an example of members of the public (not a maintainer of XZ) doing exactly what you said: auditing the release tarball. IIRC this occurred only after an additional point release (apparently allowing the attacker to fix a bug in their backdoor) because of a performance regression.

"No s̶o̶u̶p̶ internet for you!"

Good luck!

> I agree—they're not all the same story. On the other hand: stories in an ongoing sequence usually lead to repetitive discussion, which is bad for HN