This is true, but in part because a lot of 'security' reports are pretty bogus, even if they get CVEs and 'security researchers' call it a vulnerability, others may be inclined to roll their eyes. For example, the curl project had a write up:
https://daniel.haxx.se/blog/20...

So LLM findings I anticipate to be similar, but just a firehose of stuff to dig through to separate the real findings from the innocuous ones.

We likely will never have a grip on that, as it's generally easiest to patch the report and not think about whether it *really* was a security risk. The patch may confirm incorrect behavior being acknowledged, but not whether it was realistically a 'security' risk or not.

Yeah, I hate this in general about EV coverage. Everything fixates on 'time to charge to full' instead of 'miles replenished per time'.

To be useful, miles per minute of charge is a better figure.

You can definitely see it in stores though.

When it gets dark at 5ish people seem to go home and then stay home.

When it gets dark at 8 or 9ish people seem to go home and then maybe go do a chore or go to a bar or something.

I'm skeptical for it leading to extra retail shopping though (rather than time shifting away from the weekends). You can definitely see the difference in restaurants/bars though.

It tends to be the weeks where people come home to light or just dusk and it quickly gets dark most impacted (early spring/late fall).

i would generally agree that recomputing a contract is generally good, IF the competing entities have the experience and expertise in executing the terms of the contract. I think the thought process here is that the contract will be steered towards one of Trump's political allies that has no experience or business running JPL.

$100k gives a lot of space to pay people for 2 weeks.

Is google really that much better of a gatekeeper?

Somebody's gonna gatekeep what of the 1000x more content you see.

I really like how they summed it up at the end though "that was terrible". At least they were self aware. I feel sorry for anyone that needs to watch 90 minutes of it.

Generally IPOs don't have great 1 year performance (as pre IPO investors cash out).

This is the reason that indexes usually wait (and have rules about it). Not wanting to be forced to buy in at the IPO price is pretty reasonable.

Nothing to do with Musk or SpaceX.

The kernel isn't really worth keeping closed source.

They have to weigh the logistical burden of sharing source code they don't really care much about versus the very large and real technical burden of changing their technology stack.

I know, he didn't seem that human, but I'm pretty sure he is.

On the one hand, love seeing Musk lose, on the other hand, I hate seeing Altman win..

The problem is that you have hundreds of folks now running the exact same checks with the exact same tools and all submitting without a care for what any of the others are doing.

Dupes are nothing new, but the scale of dupes becomes gigantic because now everyone thinks "I can be a kernel security researcher now" and all have the same tools at their disposal that tend to find the same things.

As to the 'genuine bugs', don't know about this current crop, but historically "security researchers" have already been bad for "crying wolf" and reporting non-issues that they didn't understand. The highest profile I can think of was when some "security researcher" started telling everyone in the world that nintendo stores passwords in clear text because he thought the 'OK' button only activated when the password entered matched successfully, but it just lit up as soon as *any* password that passed the rules was entered. AI code review is still pretty inclined to report non-issues in a similar way, so I imagine not just dupes, but lots of nothing coming along too. Those would be *harder* to have a system automatically handle, since a human actually has to understand the report and reconciling with reality. An LLM isn't going to be very good at dismissing bogus LLM complaints.

Well, it would be nice if the submitter was on the hook for the token budget to find dupes, but practically speaking the project probably runs it.

I would probably not have an LLM automatically merging duplicate tickets. The flow should be 'pass on to human review as no apparent duplicate was detected' or 'pass back to submitter with indication of probable dupe, to let the submitter decide if they have something to add to the original ticket and/or to subscribe to that ticket. I have seen enough problems when *humans* unilaterally merge tickets that end up being unrelated, and that clutters up and confuses an issue. Don't need LLM that may be pretty good, still would be even worse than the humans at messing up 'dupe or not'.

It's a matter of what the LLM operator is pointing it at.

The LLM operator submitting the bugs aren't paying attention nor feeding their instance of LLM anything about others' submissions. So they are flooding with dupes, and the LLM has no reason to detect duplicate submissions, since it's not fed that data.

An LLM fed the mailing list and new submissions could credibly find dupes. If it fails, oh well, a dupe made it through and was annoying. If it erroneously detects a dupe, oh well, the submitter has to re-assert that it is not a dupe and is somewhat annoyed.

LLM ability to identify roughly duplicate bugs is decent enough. I don't like the hand waving of "AI can write the code, AI can review the code, AI can test the code" to absolute confidence (finding ways to expend more tokens does improve it's success a bit, especially if you can give it a 100% perfect pass/fail test to run and and let it retry), but here it's a pretty straightforward application, just a better fuzzy match at finding duplicate reports.

They haven't taken pride in their work in many, many years. Just like the rest of the world.