CGamesPlay
CGamesPlay on Hacker News
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).
What a crazy coincidence!
> This would have been possible since the certificates were created in April 2025. ... CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.
Meanwhile, back in April 2025: "Is it possible to enable CT checks in curl?" "No." https://github.com/curl/curl/discussions/17078
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, this 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.
It's not just tolerable, it's even enjoyable!
> There are circus lions in circuses trained to jump through hoops on command. But once in a while they decide to eat their trainers instead of jumping.
This is a terrible analogy, because yes you absolutely do hold the trainers criminally liable when they bite somebody else's face.
Intent is the difference between murder and manslaughter, in that case. Drunk driving is common enough that prosecutors will argue that getting drunk in a situation where you have to drive is intent. Get OpenAI convicted of unintentional CFAA first, then say that the negligence qualifies as intent, I suppose.
I for one am excited to learn more about how it spreads up to 50% between nights, and how nothing between the lean arms is a finding.
The useful training data is when you clarify your intent, when you tell the model a different approach would be better, when you consistently refactor towards Y and away from X, and so on. The training data isn’t the code, it’s the session transcript. (Anthropic would call this a “distillation attack” against their model, but in this case the model is you!)
Are embeddings useful for something of the scale compared to just keyword search (aka grep)?
This is a much more substantial critique :) I definitely don't think this is a trivial idea. I did a quick analysis and the naivest possible solution isn't very good: only looking at uncompressed objects requires scanning ~340 MB to deliver the <1 MB answer the question "show me the diffs by user Zhang Yi in file fs/ext4/inode.c on branch master in 2025". The bulk of that is scanning commit objects for commits by Zhang Yi in 2025 (171 MB), then fetching trees to filter those to just fs/ext4/inode.c (159 MB).
But this begs the question, why is cgit scanning 340 MB to answer this question? Is cgit not using good indexes? (Making a space-time tradeoff that doesn't make sense on a public-access website in a post-stupid-AI-scraper world?)
1. Preventing access to open-source code by scrapers is not the goal behind this idea. The goal is to reduce the server load taken by the scrapers.
2. Why would you need a full clone to access /blob/cee9395acd8043be0644b25c34bfa86623f2b935/block/badblocks.c?
Git forges seem especially prone to this: tons of information, highly valuable to scrapers, rendered through several different lenses, gives a combinatoric explosion of URLs. Obviously scrapers could just be less stupid and clone the repo, but it's not happening.
It feels like turning these frontends into JS-only viewers would resolve this, for the most part. The JS clones the repo in memory and renders whatever lens the requestor wants, and the server becomes a dumb object storage that uses less resources. The anti-JS folks are free to clone the repo still, and view whatever lens they want, so that minuscule slice of the legitimate requests is still served, albeit with a degraded experience.
Several factual errors about the model here. The input modalities are listed as text only, but the headline feature is image support. The context length should be 1048576 (so should GLM-5.3's, also wrong on the charts).
https://docs.z.ai/guides/vlm/glm-5.3-flash#model-api
> 3.) Fictitious Domain Considerations: As you may know, domains that has ".web" have faced issues related to fictitious domain name usage. While ".one" is not ".web" the combination of the subdomain and TLD triggers similar security protocols.
This is an LLM response. It's the classic pattern where the LLM says something completely unrelated to the topic at hand, realizes that it doesn't have a backspace key, and tries to hedge it in.
Different underlying mechanism. The LinkedIn one (and almost all ads on Instagram/Facebook these days) use a gain map to increase the brightness of the image. Here's a site demoing the tasteful application of this [0], you can see the difference viewing it live versus taking a screenshot of the result.
[0]: https://gregbenzphotography.com/hdr-gain-map-gallery/
> Are we on two different internets? Is the author simply immune from the hypnosis of social media?
Yes; and either yes or the author is separating walled social network gardens from "the internet". The "real internet", as you say, is not the addictive algorithmic feeds.
I believe that the "real internet" you're talking about is larger than it's ever been, but the signal-to-noise ratio of the whole internet has been killed by even larger amounts of noise. So it's difficult to find these smaller forums and get involved with them.