NohatCoder

It is obvious, yet so many people don't understand it.

There is no secret ingredient, writing a website, or anything really, without a framework is not wildly more difficult than using a framework.

Save for a few cases where all you really want to do is covered by the default configuration, you generally don't end up writing a lot less code with a framework. Worst case, you end up spending most of your time working around the framework.

So it is a port of libdeflate, that is indeed not very clear.

Looking at it again, do you actually have any working correctness check? If you simply ask the AI to test the code for correctness and speed against the benchmark suite, it could easily hyperoptimise for the suite in both regards.

Uh, so the program is almost as fast as libdeflate at compressing at a given level. But the post makes absolutely no attempt at establishing that a given level compresses as well as the corresponding level in libdeflate. In the linked post there is a graph detailing that libdeflate does indeed compress quite a lot better than the original lean-zip at the same level.

Without data on compression levels it is hard to make any useful conclusions.

This is such a bad take.

1. A proof of concept is not an exploit kit, it simply needs to demonstrate that there is an issue, improving it to be more reliable only serves to help bad actors get to real exploits sooner.

2. Memory corruption bugs are notoriously flakey, crashing the target without getting code execution is generally always a possibility. Sometimes it is random from run to run, sometimes a particular attack pattern simply won't work against a particular target. Failure to find a working pattern does not imply that no such pattern exist.

3. Attacks only get better. This is usually said about cryptography, but applies just as well in this case. Data execution bugs have this tendency to make idiots assert confidently that it is improbable that such a condition would occur without the program crashing. And so the bugs get to live on until someone finds out how to tickle the program in just the right way to make the improbable a lot more likely. Even if existing attacks were as bad as the author implies, it would almost certainly only be a matter of time before someone managed to tweak them to become a whole lot better.

4. A big part of why this gets so much attention is the sheer number of high value targets, so many servers run PHP, and they were pretty much all vulnerable. Usually bugs like these still require that the PHP runtime is configured in a particular way and/or the actual PHP code run a particular function using attacker controlled data. That is still bad, but attackers will need to do a lot of digging to find the vulnerable servers.

I can assure you that a lot of mathematicians are spending time on this, but research level maths just don't move that quickly. As of writing this, the initial drop happened 41 hours ago, that is under normal circumstances not a lot time for reading and understanding a proof paper, and it is most certainly not enough time for publishing a rebuttal. One does not claim that someone else's paper is wrong lightly, you sleep on it, you discuss it with colleagues, you discuss it with the author (not sure how that part works in this case) before posting stuff on the internet that you might come to regret.

Because, between all of these expenses, it is the one the customer controls. The customer chooses what card to use, but the merchant pays the associated cost.

This is the age old problem with proving correctness. You can (sometimes) prove that two programs have identical behaviour. One of the programs can be slightly simpler in that it is only concerned with what the correct result of a given operation is, not how to get there. But this doesn't fundamentally change that the complete specification is almost as complicated as the program itself.

Yeah, this very much gives the vibe that the original plan was to design a CPU, then suddenly AI AI AI happened, and they squeezed some matmul units into the design at the last minute in order to please the higher ups.

As a normal investor it isn't, but once you get to double digit percentages and start getting real influence it is a different story.

I suspect you are right, but it is getting really difficult to tell the difference between AI and someone who simply don't know what they are writing about.

The power density has been steadily increasing over the years, and then going from CPU to GPU makes it even bigger. This wouldn't be such a big issue if they actually took the time to build the infrastructure. But nobody has time, so it is gas turbines and evaporative cooling, and that makes a horrible neighbour.

Nah, "selling shovels" is mostly a metaphor, the amount of iron that went into mining equipment was insignificant, beyond some local demand peaks. The majority of the business was consumables.

A key thing to understand about the gold rush is that it was not a major economic event, or at least nowhere near as big as the participants thought it would be, hence the tradegy.

The AI gold rush is different in that there actually is a mountain of "shovels" large enough to flood the global market quite severely.

I guess we can go the long way round. How often does the bakery use 12 million therms of natural gas?

You "suspect", but your suspicion comes with a unit of energy, which simply does not make sense in the context. The rest of us are talking about effect.

First thing missing from this "article" is a number indicating how many people don't want AI datacentres anywhere. You can't claim that someone is a NIMBY if their stance is that the damned thing shouldn't be built anywhere.