Most maddening for open source projects is the number of false positives exacerbated by multiple people trying to 'help' by running effectively the same security audit as a bunch of other people have done and trying to open issues that are duplicate...

Huge pain in the ass dealing with contributions from people who don't understand enough to analyze their LLMs "findings" and just pass them through "in case they are helpful".

Might be nice once the fad of "everyone contribute by running duplicate reviews" subsides though.

Note that this isn't even new to AI, the kernel has always been a flood of CVEs. The AI spotlight puts a bigger spotlight on it, but it has been a mess.

The real problem is that the average security team is mismanaged and forced to use terrible tools that report on yet fail to reconcile the status of the CVEs on behalf of the user and instead drives the team to have to figure out how to take care of it themselves.

Some twisted security mindset of going direct with CVEs as 'the most thorough vendor neutral approach' without instead leveraging distribution security advisories. So you end up with a security tool claiming you have thousands of security issues on an up-to-the-minute patched instance of the latest enterprise linux distribution because they backport and tools don't understand the version numbers.

In the industry, so many security teams mandating CVE management software that is absolutely stupid and pushes off all the hard bits to the user.

It sees 6.12.0-211.34.1.el10_2... Well... none of that makes sense so it just assumes that it's just plain 6.12.0 and demands the user reconcile the reality. Now the security vendor *could* maybe integrate with the major linux distributions advisories... But no, more CVEs is better, when you demo that your product finds hundreds of CVEs, that just proves it is being thorough as far as upper management is concerned.

They offer up sound guidance here, skip direct CVE management and lean on your distributor. If you are doing CVEs direct, at *least* use the patched files to cross-reference against your build to see if it even in theory could matter. However the problem is the business of the security industry doesn't prioritize those, and so we have stupid tools inflicted on people, and pushing back against those tools carries a stink of "must not care about security then".

Depends on the number of realistically 'false positives'.

I've known a few people who find the kernel CVEs particularly unreasonable as they tend to aggressively assume security implications. If they grant a CVE to a 'mere bug', no one is going to get too grumpy over that specific item. If someone believes they have a vulnerability and do not see a CVE, then people get riled up. So some feel the kernel is just granting CVEs to avoid pushing back.

The other headache is the monolithic nature of the project. "Linux" covers just everything. A potential security issue in a device never seen outside of PA-RISC systems 20 years ago? It's a "Linux" issue, so every x86 system will be flagged as 'affected' by security software that cannot deal with nuance

Of course, we are here mainly because the kernel team largely recognizes the practice of trying to apply only security updates while avoiding 'only bug' fixes as pretty insane. So err on the side of caution make CVEs extra unmanageable because realistically it was a pretty crappy strategy for such a complex project anyway.

Broadly speaking, CVEs are usually pretty bogus, but a small percentage are very real and critical issues. You can't use the 'score' to really measure this either, it's not very good in the first place, and for example I saw the exact same issue in a C library and a python binding for that C library, and for whatever reason they graded the C library as 'minor' and python binding for that library 'critical', despite the python binding being nothing but a ctypes wrapper around the c library...

You expect very slop happy software developers to create effective safeguards?

Nothing you said precludes a bubble pop and investment problem, even if taken at face value. The fact that you are getting rate limited doesn't mean there isn't a bubble. That doesn't speak to the economics, how the demand is distributed, and whether or not that demand is durable as hype levels out.

As the post said, there may be "right" AI companies but there are certainly "wrong" AI companies and investors don't really know which is which and trillions of dollars are at stake with what will turn out to be the wrong companies. Some of the "wrong" AI companies are just stuff on top of the same provider you are using, so you are rate limited because they are also selling to less robust companies and when that less robust company goes poof, your rate limiting concerns may go away. Or your org is one of the less robust companies.

In the year 2000, plenty of folks got real strong value of the internet. But the bubble still popped and the markets dropped 40%. Hosting providers that were hugely constrained by the overwhelming demand at the time suddenly had capacity to spare. People continued to get value from the internet, but that was of little solace to folks whose livelihood was tied to one of the "wrong" internet companies of the day.

For some, *maybe*, but keep in mind:

I have met a fair number of folks making $200k+ who were supremely underwhelming. They would have a very narrow wheelhouse and *only* do things within that, single language, single framework, stuff like that. Even then, you ask them to do something that they can't find an example of online already and they would be lost. We had a scenario where work hired a few of these folks to replace the front-end work that our 'full stack' team had been doing, because we had more money and we should develop it 'properly'. They started from scratch, had a fairly basic tutorial-fodder front end and customers complained about loss of features and the front-end team rejected as "impossible with new framework, so won't be done". Meaning they couldn't find anyone who did that on stack overflow, and the old UI wasn't written with Angular so they decided it was not applicable. AI may well supersede such folks fine.

For a fair number of these companies, if the realization comes that AI couldn't replace the personnel they thought it could, then the bubble is likely popping and taking some of these companies with it. If not completely, having to scale back offerings. AI isn't going away, so the people in the above example can't celebrate too much, but the realization that it won't replace the entirety of white-collar work will be crushing financially.

Even assuming they can and want the talent back, they may see their position as strong with all those other unemployed/underemployed developers out there, so they may not relent to an exorbitant consultant rate. It *can* work and work long term if things line up right. For example they begrudgingly get gouged on what they think is short term then realize they can't just bandaid it and let the consultant go. But it's far from guaranteed.

Sure, if someone is in their fifties and has spent their career at $200k+, then your perspective carries weight, one might reasonably expect such a person to be able to retire or at least not sweat a big drop in pay. "Silicon Valley" standard of living may screw the numbers up (I explicitly declined an offer because I checked the real estate market and realized just how deep a cut I'd take in standard of living despite the "raise")

However, if someone graduated with their CompSci degree in 2022, well, all they built is probably a lot of student debt with nothing to show for it.

Note that companies find recent hires the "safest" to fire because they likely haven't become important in ways management doesn't understand.

I've learned not to expect much out of Aptera, they've been at this two decades of "just about to launch" and never getting anywhere.

That said, if something did charge at 5mph from integrated solar, well that's on par with level 1 EV charging and some folks get by on that. So going to work and parking in the parking lot might get the morning commute replenished over the day, maybe some of the return trip. For some lightly driven vehicles, they might almost never plug in, in that hypothetical.

Used to be that automatics shifted poorly, had fewer gears, losses to make it less fuel efficient, and higher maintenance.

Now they shift well (if they "shift" at all, CVT and single speed EV transmissions), let the operator manual shift all they want, and between more gear ratios and better tech all around, they are more efficient. They will tend to out last a typical human operator clutch nowadays too.

I still love driving stick, but I must confess there's no good practical defense any more.

Politicians have been no strangers to sticking to the letter of the law against the spirit of the law, this administration blatantly blows past the letter of the law, and the other branches are enabling them. Yes there are certain unwritten presidential norms that were honored that this administration also blows past as well, but bending the spirit of the law is a comparatively lesser problem.

The founding framework expected that everyone would distrust everyone else and take any leverage they could to prevent adversaries from having too much power, this seems to be the assumption that is falling apart as everyone happily sees corruption and feeds the administration pass after pass.

Besides, even with text, waiting for a person to finish talking can be tiresome. "This could have been an email" being a supremely popular sentiment.

Fair point, though in the case of datacenters, there's not a whole lot they need to even exaggerate in terms of downsides.

Whatever the upsides may be of these datacenters, those are diluted across the reach of the internet and the local community does not particularly benefit. That's the whole point of modern technology, that the reach of a datacenter is far and is run so efficiently you don't even need local labor.

The downsides are conversely concentrated. In global context, the datacenter downsides are generally not even notable, but the datacenters focus those downsides into select local areas. Strains on local power grids and water systems, demanding new power lines be ran, blight on the landscape, and so on.

Instead of trying to create local upsides, they call the criticism fabricated by foreign actors. They could be doing things like proposing municipal "permanent funds", *actually* paying for all of the inflicted infrastructure costs (when they do claim to, usually they do a dance like "well *that* new power plant is for residents, *our* power comes from the existing plant so we shouldn't have to pay for it)", or at the very bare minimum at *least* paying the taxes they are supposed to pay instead of getting breaks.

If only there was something about FreeBSD that might provide a clue about what license they would be wanting the software to use...

While I'm all about the Microsoft hate, in this scenario, it's not exactly unique, nor does a count tell the whole story.

Famously the kernel had a handful of high profile security issues discovered, so Microsoft has company. If you are floored by the number of security 'flaws', well, many projects are dealing with those and while higher than usual (largely due to AI findings), a lot of 'security' findings have long been dubious and the AI findings are no exception.

For example, a parser for a comprehensive script engine that is explicitly designed to allow arbitrary code execution had a handful of flaws where malicious scripting could overflow and run arbitrary code. The script just had to have binary data in it, be over 4 gigs in size, stuff like that. None of the flaws were subtle, and would be *obvious* on review. A malicious script could have just instead included precisely the malicious stuff. Nonetheless, there were several CVEs granted and the project released fixes for a CVE that let a script do exactly what the engine was designed to do, but in a weird way that's even more obvious than just putting the malicious code in directly.

The thing is, once you have a "security" finding that you know how to fix, it is far easier just to fix the bug and not argue the security facet. The curl developer has, historically, pointed out a few of the crazy CVEs that have been inflicted on him, but most developers shrug and move on, fearing the perception of 'arguing with a vulnerability'.

Practically speaking, stay up to date, pay special attention to the "famous" vulnerabilities but otherwise, it's not really that informative to think about the quantity of "vulnerabilities" published.