jj4211

That's information superhighway thank you very much.

Like the comment said, half.

Maybe I just don't get it, but I just don't see there being anything vaguely inspiring of that sort of chemistry between the caracters of that specific show. Other duos in other shows, ok, but Sherlock just seemed so far from that dynamic.

I feel like you could have just rolled with the clarification that the comment referred to all fan-shipping. Alternate is a perfectly reasonable word for "non canon"

Your initial reaction was perfectly understandable, and and relief at the clarification would have been great. Just seems unfortunate to get weird about seeming put out by "alternate" as a way to say "non canon".

Probably not even that.

For example: https://nvd.nist.gov/vuln/detail/cve-2026-43073

The short of it is they declared the name of a function to be a vulnerability, because some developers were confused by the name and used it when they shouldn't.

A fine critique of things, but the CVE is considered closed by merely renaming the function, and downstream misuses were considered separate issues.

A "vulnerability" fixed by:

-SYM_FUNC_START(__copy_user_nocache)
+SYM_FUNC_START(copy_to_nontemporal)

I saw a headline where one of the big AI people said AI could do everything better than a human... Except make decisions. So the "executive" class is the only class that is "fine" by the logic.

I don't think they half the self awareness to realize they are in fact frequently pretty pointless even ignoring AI.

Curl guy has written about a couple of these stupid CVEs, for example: https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/

One I recall was that if you asked curl to write out c code example of libcurl usage, you could get it to write out arbitrary code of your choosing. Note that this required you to have write permission and curl and then with your malicious c code, you then had to compile it and make it executable and run it yourself. So a very roundabout way to use curl as a text editor, and they considered it an arbitrary code execution issue, despite not actually executing the code.

Yeah, CVEs are usually nothing when you get down to understanding, especially kernel CVEs, which almost always declares a CVE for almost any bug, because it is easier that trying to think if it is a security issue or not and basically just assume it could be.

Huge pain as in my work we have a security policy where any unpatched CVEs that cannot be updated away must have a fairly significant writeup delving into the nuance of the CVE and what mitigation has been applied or a rationalization of why it isn't a risk and by policy we have to second guess every CVE assessment from our vendor, who we explicitly pay to triage and fix this stuff so we don't have to... They used to at least allow us a pass on "low severity" (that's still pretty flawed), but they decided that didn't sound "tough" enough and now every single one must have an answer. So every month a few people have to spend a few days just reading tons of CVEs that are not yet (and frequently never will be) patched by vendor and rationalize it away for the security team. Sometimes the security team will get odd and demand we build our own from upstream (most recently, vim of all things we were mandated to build from source).

The content on Internet will invariably biased towards the novelty. Between that bias and enormous marketing spin and the most self important people gravitating towards it, it's an expected reality. One that will be applicable to some scenarios.

Content saying that for some situations, the existing methods remain best isn't going to light the world on fire. Also, tech folks tend to be more shy about "not getting" a seemingly great new tech.

In terms of how much it applies to an individual situation, it's too nuanced to really make a universal judgement. But in my local circle where I can grasp the nuance, the teams that have gone all in on deeply agentic are teams that already were kind of crappy.

I have both used agents and have been the "victim" of heavy agent users.

If you can provide an utterly well bounded problem with perfectly verifiable criteria for it to retry against until the tests pass and the tests are full and valid for the use case, it can work. Similarly, if your code's reality is forgiving and flexible, and a 'close enough' result is good enough to get the human software user in the right ball park, you might be able to extract decent behavior.

However, if there is a means by which the answer can 'look correct' yet be wrong in the real world and the real world scenarios require accuracy and precision, there's huge gaps.

Especially if the agents control the coding and the test case generation, seen plenty of times where it talked itself out of a test case that was failing when the test case was in fact correctly showing a flaw.

A number of people have shared their experience with you and you seem to be unwilling to acknowledge that your assertion of universal slopping it up as reality is not utterly universal.

Frankly, your use case sounds like something has gone horribly wrong from the outset. If something needs several thousand regex patterns, then something is very very wrong, and there's zero chance you have a comprehensive solution as it stands. Either trying to use regex for a use case that some natively AI approach might actually be warranted for, or regex is being used poorly and each one is too limited, or some other approach entirely is warranted.