Joined 14 years ago
I have no real data to back this up, but that has always been my assumption.
Claude says that K3 can be assumed to have required 10-100M GPU hours. If you have 100k GPUs that would mean like 6 weeks of training. 100k GPU's can serve 3-30 trillion tokens of K3 per day. Google apparently serves ≈100 trillion per day [0].
The big labs probably want to have capacity to fairly quickly train / post train different SOTA models continuously + being able to serve peak inference demand in valuable markets (US daytime?).
[0]: https://blog.google/innovation-and-ai/sundar-pichai-io-2026
In the darker northern parts of Europe, the German transition to renewable haven't really been a cost-saving success story (right?).
From my (very) casual Swedish vantage point, the wind build out here was a very government subsided race to zero marginal prices that barely helped anything?
It's easier to protect a power substation from being stolen then a Rolex watch
I think the etymology is from "rice burner" cars [0]:
> Riced out is an adjective denigrating a badly customized sports car, "usually with oversized or ill-matched exterior appointments".
The key material must be DRM'ed, especially if some ZKP solution is used.
Otherwise all underage kids would download the cool older brothers private key and load it into their GNU Taler client, buy wine and be gateway'ed into heavier Stallmanisms. Before soon EMacs would be all the rage in highschool.
(Of course we can argue the bigger points, if X should require age checks, or if this even should be done digitally etc. But there's a reason why we don't allow the physical equivalent of self-signed keys for physical ID's, they're not trustworthy)
> This is slightly different from what OpenCode was banned from doing; they were a separate harness grabbing a user’s Claude Code session and pretending to be Claude Code.
> OpenClaw was still using Claude Code as the harness (via claude -p)[0]. I understand why Anthropic is doing this (and they’ve made it clear that building products around claude -p is disallowed) but I fear Conductor will be next.
I agree with GP that this is hard to take seriously.
1 TB is roughly 20-30 USD per month at AWS/GCP only in storage, plus traffic and operations. R2 is slightly cheaper and includes traffic.
Compared to e.g a Google AI plan where you get 5 TB storage for the same price (25 USD/month) + Gemini Pro thrown in.
Also, considering how prevalent TPM/Secure Enclaves are on modern devices, I would guess most package maintainers already have hardware capable of generating/using signing keys that never leave hardware.
I think it is mostly a devex/workflow question.
Considering the recent ci/cd-pipeline compromises, I think it would make sense to make a two phase commit process required for popular packages. Build and upload to the registry from a pipeline, but require a signature from a hardware resident key before making the package available.
And while geofencing + allow-listing for sure provide value in e.g the Ukrainian conflict, it's a weak protection compared to goods that are actually under strict export control (e.g ITAR), and will always have to be done after the fact. Russia could for example put Starlink on drones launched from the Baltic Ocean targeting Poland or whatever.
Thankfully for my blood pressure, whoever had set it up had left some kind of management portal accessible on a random high port number and it contained some strings which led me back to the Xray project.
Any many CRDT implantations have already solved this for the styled text domain (e.g bold and cursive can be additive but color not etc).
But something user definable would be really useful
But at the same time, me as a customer of Github, would prefer if Github made it harder for vendors like CodeRabbit to make misstakes like this.
If you have an app with access to more than 1M repos, it would make sense for Github to require a short lived token to access a given repository and only allow the "master" private key to update the app info or whatever.
And/or maybe design mechanisms that only allow minting of these tokens for the repo whenever a certain action is run (i.e not arbitrarily).
But at the end of the day, yes, it's impossible for Github to both allow users to grant full access to whatever app and at the same time ensure stuff like this doesn't happen.
