infogulch

What about mobile apps?

Maybe CAs should spend a few thousand CPU hours trying to crack submitted intermediates before actually signing them.

If it delivers on being faster than the version accused of cheating with reasonable cache settings and no SQL feature limitations, I would say that resolves the accusations, regardless of the source code of -preview.

The remaining lesson here is that one should temper one's excitement with pre-release software, whether the software was built with AI or not (rather, especially if its built with AI). The preview results would have been more appropriate to announce on a social media platform than as a PR to the ClickBench repo.

Same-binary / external service seems to be the split.

If you're building one binary you can choose when to update and fix all the referents at the same time. A distributed system does not have that luxury and it makes more sense to require forward compatibility.

I guess another option is a two-phase update where you first update all the services to accept the new enum variant without ever emitting it, then you can phase in services that use it. The downside with this strategy is that you're locked into upgrades and you can't roll back individual service versions, so to be safe you probably need to delay use of the new enum variant by 2-3 releases (at some point rolling back is not a viable option and you have to publish fixes in a new release anyway).

So in a service world the only options are either "require forward compatibility" or "delay rollout of a new feature to 3 release cycles after all services in distributed system are updated" which is like a month minimum. I can see why forward compatibility is the default, and also that you might want to keep the two-phase deployment strategy for certain cases.

I'm curious about polymorphism. Should it be default on for debug builds just to save storage and compile time? How will rust decide whether to enable polymorphism? Will it be possible to provide source-level polymorphism hints to the compiler?

So the thesis is that crates massively oversubscribe the features of their dependencies, and that if features were managed more carefully and maybe dependency features exposed through each crate's own exposed feature list, that would cut down on dependency bloat and compile times a lot.

My idea above is roughly equivalent to the "zero-config" strategy you mention.

It's kinda crazy that if a direct dependency doesn't use some feature from a transitive dependency and the direct dependency forgets to disable it or expose a way to disable it you're still stuck with it.

The paper shows that the Lean proof and the prose (pdf) proof do not match exactly. But if the Lean theorem Lean accepted is equivalent to original problem statement published by the Clay Institute, this mismatch is of no consequence to the validity of the proof itself. That's not a trivial if: stating the problem precisely is often as hard as the proof. Validation efforts should concentrate on whether the Lean theorem is equivalent to the one published by the Clay Institute.

That said, a gap between the Lean proof and the pdf is annoying for interpretability, and interpretation is a valid aim, but that does not factor into the proof's validity.

How much code is never used and compilation could be skipped entirely? Maybe applying a reachability pass to skip compiling unused code would be helpful.

Borg + Backblaze B2

It seemed like this part gives you the exception you wanted:

> provided that you may display Output to your authorized end users within your own application so long as such Output is integrated into your application's functionality, is incident to the end user’s real-time query ...

but it continues:

> ... and is not independently accessible, extractable, or downloadable by end users or third parties

How can you prevent end users from extracting it if its visible? Why even have the exception if you just throw it out with an impossible to meet restriction like this?