Comment Re:Even if the features appealed... (Score 1) 105
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.
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.
Why would I want a device that deliberately handicaps itself by not bothering to have a screen?
Especially with how verbose AI responses are, I couldn't imagine having to just wait for it to read out the information asked of it.
I don't get the AI companies' fascination with voice-only input and audio-only output. It's a strict subset of what the device in people's hands can already do. Further, every single product that has aimed for this has flopped and you would think they would get the hint by now...
They would have a very uphill battle.
For the common customer, it's generally 'nvidia or bust'. That being said, supply chain limitations might have people looking for a more affordable and accessible option, which isn't exactly a huge appealing prospect for IBM, particularly since the market has AMD trying to already fill that niche. General problem is it isn't just about specs, if it isn't CUDA then people are just not confident.
IBM hasn't really been known for in-house top performance in about 20 years. Last time they bothered to go for top performance was almost a decade ago, and even then it was tossing nVidia GPUs into POWER9 systems, and nVidia was the real meat of the solution.
To get traction, they'd need a market opportunity of folks that aren't afraid to try to leave nVidia behind, but not so adventurous as to just make their own chips instead, and for whom AMD offerings are not good enough. IBM would have to go from zero software in the space to credible. They'd have to scale out even bigger than they used to despite largely giving up on scale out years ago.
IBM hasn't really done anything to earn the benefit of the doubt in a very long time. People's memory of the once potent tech giant has faded. They've alienated all but their most loyal customers by ditching anything where they had to be vaguely in competition with other companies, so they volunteered themselves into obscure niche, and the niche is high-priced, highly compatible, but not necessarily top performance offerings.
I suppose some of us old timers would be stoked if IBM actually made a serious effort, but I think the prevailing sentiment would be skepticism after decades of neglect on this sort of effort.
PC succeeded pretty much because IBM broadly didn't take it seriously. If IBM believed in the market opportunity, they would have screwed it up by making it all in-house and proprietary. See when it did start to get traction and they decided to try to lock it down with MCA.
Their hardware though is just refresh fodder for mainframe/mini/aix. Sure they toss it some concessions to hype but ultimately customers are currently looking for the most cost effective platform to enable running stuff on nVidia Blackwell, and IBM isn't even vaguely in that game, not since a brief time with POWER9 where they tried to foster a close nVidia relationship.
No fab, no x86 systems, no resell of third party stuff that would work for getting in on Grace/Vera based systems. There's not really an angle for their hardware to get in.
If nVidia were still a bit hungry then IBM enthusiasm might have helped, but nVidia in-housed CPU aspirations and broadly do not care a bit about who their partners are and what they want, they correctly see themselves as the center of the universe for now and have pretty much sold every chip they plan to make for a long time. In that circumstance, there's just no way in unless IBM pulls off a long shot with an nVidia alternative (not just technical, people actually have to *believe* in it, and IBM has squandered their credibility over time).
IBM has offloaded the hardware that would have had them most relevant to the boom. They basically just have hardware to cater to long term mainframe and AIX customers. Even many of those customers are probably deciding to postpone their IBM hardware refresh to secure more hype-compatible gear from other vendors.
IBM chased what they saw as more plush software and services margins and chopped away to fixate on those fronts, except the locked in mainframe/mini/aix customers that they can keep gouging without fear of strong competition.
There's a way, but it doesn't jive with AI not becoming radically more powerful.
LLMs would evaporate if something superseded it by being appreciably better.
But if one asserts AI isn't going to become radically more powerful, then it is a silly statement to say LLMs won't be a thing. There's clearly *some* appetite and use for them. The bubble may pop and maybe some LLM applications will back off, but they are certainly going to hang in there.
That is true, out of 70 reports, only 1 was spot on and only one other was technically incorrect, but it was adjacent to a real problem.
The thing was that as maddening it was to review the 70 reports, the two issues either directly or indirectly responsible were worth it.
However, in an open source ecosystem, you have a whole bunch of users so those 68 bogus 'findings' get repeated for every rando that feels like 'helping' with issues... So open source gets hit harder due to the higher chance for duplicates...
Suppose the question is 'high quality'.
It absolutely floods the field with false positives.
However, depending on the context, you can still see some issues a human is likely to miss. It's an idiot with crazy attention to detail.
So you can't count on it to catch things a human would and in many scenarios it will fire off more false positives than anything vaguely right, but it does represent a value in a more manageable haystack to catch certain issues.
But go back to a reasonable level of skepticism about suggested fixes, and ensure even if you agree with the LLM on an issue, that you understand it well enough to not get screwed over by the LLM suggestion...
Note that even if it is motivated by dubious ways, even if it is propaganda, that doesn't *necessarily* mean it is disinfirmation.
As they say, the best propaganda is true.
It's not sufficient, and it has a lot of false positives, but it can help get a smaller haystack with some of the needles that a human review can miss.
Code review for quality and security is something the LLMs can help without much inherent downside, so long as you do not trust the review but use it instead as an additional pass and make sure you follow up and understand any 'finding'. It *is* a risk if you take it as replacing the need for carefully considered human review, but with discipline you can have the best of both worlds: actually intelligent human review and the detailed coverage an LLM tends to get.
I've found that it's usually wrong, but a fair amount of time despite being wrong, understanding the area it was wrong about yields an a real problem it didn't catch. Then of course, upon occasion it is simply correct.
I would be extra wary of suggested remediations just like other generated code, but I would look into things it flags as somehow tricky.
I work with people, not tools.
But what about when the people *are* tools?
I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks.