Comment Re:That old idea again (Score 1) 77
This is exactly the wrong way around. On reading, you cannot avoid the latency. On writing you can by buffering. Hence this is most suitable for data structures that are primarily written but rarely read.
This is exactly the wrong way around. On reading, you cannot avoid the latency. On writing you can by buffering. Hence this is most suitable for data structures that are primarily written but rarely read.
Don't worry. LLMs are complete crap at writing secure software but are pretty good at attacking software. Hence the people using them for actual coding will not be around anymore in a few years.
... such an event is actually possible. Far too much critical infrastructure is not even remotely secured as well as it should be. Hackers usually do not go after it, because there is no profit in it and scary people may come looking for them. But AI, while not very competent as attacker, may not understand that and may attack anyways.
You do realize where the WWW was created, right? Well, you probably do not.
Truth matters. That is not the truth. All you are doing by lauding somebody that made a good contribution beyond all reason is adding lies. That is not good.
So, no, here contributions were not "incredible". That requires a bit more.
Better programming means better programmers. We are currently going the other way with bad programmers being replaced by even worse slop.
It seems enough time has passed since the last catastrophic failures in this space that people do not remember. No, this does not work except in some very specific scenarios. What Meta is probably doing is get hardware done for their very special and very irrelevant elsewhere use-case. That does not even merit a story.
A good place to see that politicians are generally clueless and incapable or unwilling to see facts. I mean, I can run my own recursive DNS with no problems and the only thing I lose is some performance from caching. There is not even a reasonable possibility to block this in the network.
To calculate something and to do a calculation is _very_ different. The second part is maybe 10% of the job.
Sure. But if they get faked, it will come back to be counterproductive. Honesty matters.
The first step is understanding that we're all basically the same, with the same wants and the same imperfections.
Very much not so. I am sorry, but you failed catastrophically right there in your first step.
And there you are wrong and quite obviously so. I will not even argue that point, if you chose to ignore the blatantly obvious, there is nothing I can do.
Note that this is "different" not "better" or "worse".
Software Engineering still is not even remotely real engineering. It is too messed up, to chaotic and too clueless about its main object. Hence, no, she cannot have established it as a proper engineering discipline, because it still does not qualify as one.
Seriously, I am getting really tired of some people being lauded all out of proportion just because they were women in tech. I have no problem with them being recognized, but this type of story is just propaganda and deeply dishonest.
What he did is make up some "facts" and then throw some math on top to obscure that the "facts" are pure hallucinations. Works on the stupid and is something regularly done today. It does work better when the math used is statistics, because that is hard to really understand even for experts. But, if sone right, you get all kinds of magical symbols and an end-result that _surely_ must be true...
That said, the already started human-made climate change will reduce population, probably pretty strongly. When agriculture stops working in mist places, that tends to have rather strong limiting effects. Hence regulation mechanisms are coming active before things are getting close to the point were only fast collapse is possible. This seems to be an universal property of finite complex systems, such as we have on this planet.
PL/I -- "the fatal disease" -- belongs more to the problem set than to the solution set. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5