CGamesPlay

My approach is similar. I review all changes that touch persisted data formats, wire protocol, and/or public API surface: things with bad consequences if they are wrong and neatly divide the project up. The exact boundaries vary by the project, but once I establish what they are, I can really relax about the other parts of the code, because I know they will be cheap to fix if wrong.

> just think about all the exploits in JS engines, as well as the recent PHP vulnerabilities

Can you name some of these JS engine vulnerabilities? And the PHP one had nothing to do with JIT.

This looks like it's using the emSign root path, which is useful, but the AAA root path is equally useful in different cases. The AAA root path was disabled for https on root stores newer than February 2025, but has been in root stores since forever. Meanwhile the emSign root path was only included in root stores since ~2018 and got removed in October 2026.

So from the perspective of hacking old IoT devices, if your device hasn't been updated since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.

Not trying to throw shade at curl, although I don’t think this feature can realistically be done by a drive-by contributor.

No, the article listed some apps that were not vulnerable, and the first question to me is “so what is vulnerable?” And the answer is “every curl | sh installer on the internet since April 2025” (among assuredly many other less prolific apps).

I don't really know why it's important to "provide a durable record of a decision made during the implementation of a feature", but other than that I do something similar. I have the agent write a PLAN.md which looks just like this IDR template. It's written before implementation begins, and I approve it before the agent goes. I don't save them after the session ends.

For each project, I define "review surfaces": parts of the code that I have a strong opinion about. These get resolved in detail before implementation begins; the LLM can do whatever it wants to other parts of the code, but the parts I list can't change without another review. Typically, these are things like the public API or database schema.

Georgian is really easy. Each of its 33 letters makes one and only one sound, words are spaced, and there's no capital/lowercase. The most difficult part of reading it is pronouncing: the language does not care about syllables. Example: a popular Georgian band is მგზავრები ("Mgzavrebi" / Passengers).

I don't' know what "that" you're referring to, but in the USA it is against the payment processor agreement to give a discount for cash. So not illegal, but a contract breach.

I think it’s just for consistency. A fork and a tree navigation are the same operation conceptually. Now, unlike older Pi, a fork is not a copy of the session, it just has a pointer to the older session. The only losses that I can see are: now /resume shows every conversation rewind; and /tree is harder to implement. Neither of those is provided by Durable, so the gap is left to the implementor.

In all of the cases that people are referring to in this thread: HuggingFace, that german wiki, Ruby Gems, the Australian statistics page, this UN statistics page... those two parties are OpenAI. OpenAI running their own agents on their own instructions committing crimes with their own computers. This is cut and dry.

The other iPhone mini user here, and agree that this phone looks nice. It looks like the keycaps form a capacitive touchscreen or something, so you can actually swipe to type over the keycaps. Marketing videos show using it to scroll the screen. But, seems like it could work for one-handed use.

I might pick one of these up in the de-Googled variant and keep my iPhone around for all the "attestation required to view your bank balance" apps that I have.