Most anyone involved in computing has heard about the P-NP problem, but fluid engineers and mathematicians would love to know if the Navier-Stokes equations have smooth, globally defined solutions. Both questions are part of the Millennium Prize Problems, solutions to which are worth a cool $1 million and eternal renown. OpenAI is claiming that its staff and internal models have solved the conditions of Navier-Stokes solutions set forth in the Millennium Prize. But the company's shouting from the rooftops is being met with a chorus of boos over claims it might have plagiarized the work of a research team that had been toiling on a related, stepping-stone problem for a year.

Tristan Buckmaster (a scientist at NYU) and Levent Alpöge (a member of Anthropic's staff) had been quietly working on proving Euler's equations — another long-standing mathematical problem, and one that is generally acknowledged to be a stepping stone to solving Navier-Stokes.

According to Buckmaster, his work with Alpöge was "a purely personal collaboration, free of any institutional agreements or official involvement by either of our employers." The researchers used Anthropic Claude and OpenAI Codex as assistants, as is apparently now common in the field, to perform busywork (documentation, searching, etc.) as well as running through logic steps. The substantial amount of compute time the project required was paid from Buckmaster's own pockets, too.

The pair worked for roughly a year until August 15, 2026, when it obtained "the blowup results, with smooth forcing, for both Boussinesq and Euler." Buckmaster says the novel approach was based on previous work by Diego Córdoba and Luis Martínez-Zoroa, and he believes Zoroa should be eligible for a Fields Medal.

Although the team was presumably happy with these achievements, Buckmaster said that the LLM-generated proof was "the most horrendous" he'd seen, calling it "AI slop," and meaning to rewrite it for clarity. Nevertheless, they verified it on August 22 using Lean, a standardized programming language designed specifically to verify mathematical proofs.

Come September 3, Alpöge told Buckmaster of rumors going around that Anthropic had solved an important mathematical problem. This almost certainly alluded to the team's work, and some apparently took it to mean the company itself was working on the problem. The rumor-mongers even theorized that the problem that Anthropic had solved was Navier-Stokes. Alpöge further believed that OpenAI had gotten wind of the news.

This prompted Buckmaster to email an unnamed "prominent mathematician" at OpenAI, clarifying that the effort was a personal collaboration between him and Alpöge and was unrelated to Anthropic. The mathematician replied asking for details, saying "it would be useful to avoid competing," and offering OpenAI compute time. After a few days, on September 6, Buckmaster, the unnamed person, and OpenAI's Sébastien Bubeck talked twice, without Alpöge. He was told that OpenAI had proven a finite-time blowup for the forced Navier-Stokes equations, a subset of the problem.

Alpöge asked by text for the precise statement and was told "existence of forced blowup in R³ and T³", and that "the forcing function is smooth option [C] and [D] in Fefferman," referring to one of the four possible categories established by the Millennium Prize, with any one of them being valid as eligible for the prize, but not constituting a full solution for all scenarios, a distinction remarked on by other scientists.

This is where the story becomes interesting. Buckmaster claims that that idea (forced blowup) was exactly the same one his team had "quietly" chosen, and that nobody else he knew was working on it. Perhaps most importantly, he says that that was "not the direction one arrives at in a few days by giving a model the problem statement," indicating that running the general problem through a bot wouldn't quickly reveal that potential approach.

In fact, Buckmaster claims that over the calls, Bubeck ultimately revealed that instead of just AI models and agents with a couple of handlers, there was an entire team of live humans working on Navier-Stokes. The OpenAI team first had the models try to work through easier paths, and the text prompt that generated the Navier-Stokes proof had itself been generated by prompting Codex, with an "insane" amount of computing needed.

Buckmaster then asked when the initial prompt was issued, and OpenAI's response of "in the past few days" did not arrive until "some time" passed. He proceeded to ask if the model "had been trained on, or had access to, our sessions in Codex," and was told by OpenAI that Codex does not access user data. Finally, he asked if the data was used for model training more generally and, crucially, apparently did not get an answer.

OpenAI allegedly offered Buckmaster two options: one, that Buckmaster and Alpöge publish their Euler proof first. The following day, OpenAI would post its Navier-Stokes proof, giving the two priority. The second option was that Buckmaster alone, without Levant, was to write a paper with the Navier-Stokes proof, acknowledging that an internal OpenAI model resolved it. Bubeck was apparently adamant about Levant's removal from the Euler proof, as his employment at Anthropic was "annoying." Buckmaster opted for neither, and told OpenAI that if it chose the first option, he'd go public with his findings, as has since occurred.

This prompted what Buckmaster interpreted as a threat from Bubeck, who asked him "why [he] would ruin [his] career." After Buckmaster asked why that would happen, Bubeck told him, "If you don't want me to be nice, then I don't have to be nice." Bubeck then allegedly reached out to Alpöge, questioning Buckmaster's sanity, to which Alpöge responded with a refusal, pointing inquiries back to his colleague.

The entire story raises pointed questions about what OpenAI (and others) are actually doing with user data collected via its LLMs, despite the toggle switches that are supposed to disable it. Not only has OpenAI neglected to tell Buckmaster whether it used his team's data for training, in its PR about Navier-Stokes, the company says while it "no specific user data was accessed in order to solve this problem," it "cannot rule out that de-identified data derived from their usage of our products helped improve [its] models."

OpenAI's proof still needs to undergo a likely years-long peer review before any party can take the Millennium Prize home. The firm has stated it does not intend to claim it. As for Bubeck, he predictably paints the story in a very different light, but insists that his pushing away of Alpöge is justified on the basis that "it would be inappropriate for an Anthropic employee to author OpenAI's work," a puzzling statement that some could take as meaning a double standard regarding scientific authorship, based solely on corporate rivalry.

For his part, OpenAI CEO Sam Altman claims his team was well-intentioned and cooperative, and supported Bubeck, saying "it was challenging to offer [the same publication options] to Levent." Neither person opted to discuss the matter of whether OpenAI used the research of Buckmaster and Alpöge as training data, or offered any further explanation of why Alpöge didn't deserve credit for his work as an equal to Buckmaster.

Given the groundbreaking nature of this apparent discovery and the ensuing fight for priority that these competing accounts have sparked, it'll likely take quite some time and review before we know whether and how OpenAI or Buckmaster and Alpöge will be credited with this discovery. But given the inter-lab rancor already on display, the process will surely be ugly.

Anyone keeping track of world news in the early 2010s, and reports on tech in particular, has probably heard about Stuxnet. That malware spawned a large number of conspiracy theories — with the kicker that some of them were actually true. The malware targeted Iranian nuclear facilities and is believed to be the first digital worm to cause direct physical damage in meatspace. An unknown security researcher has now published a source code reverse-engineering of Stuxnet in all its glory.

The worm's ultimate target, allegedly a successful one, were industrial controllers from Siemens that were reportedly used in Iranian's Natanz nuclear enrichment plant. Once it reached the target, Stuxnet's payload manipulated the frequency converters in industrial centrifuges, in a bid to subtly damage the rotors — all while keeping the plant staff in the dark by reporting normal operation.

The repository contains build instructions so interested techies can try it out for themselves and learn all about its inner workings. You'll need a Windows XP or Windows 7 virtual machine, and for obvious reasons, you shouldn't configure any network connectivity for it. To witness the full effects of the payload rather than just the spreading mechanisms, you'll need the appropriate Siemens software, and ideally hardware — though we figure that industrial-scale centrifuges aren't exactly common in techies' cable drawers.

In its heyday, Stuxnet spread via three mechanisms. The primary infection vector was USB sticks with Windows shortcuts and autorun.inf files. Upon plugging one of those sticks in, just viewing the drive's contents would immediately trigger infection thanks to a zero-day vulnerability.

Infected systems then autonomously tried to spread the worm further via the network using a zero-day Windows Print Spooler vulnerability that would let an attacker write system files into any machine sharing a printer. It would also copy itself into accessible network shares. To evade Windows driver signature checks, Stuxnet used two digital certificates stolen from Realtek and JMicron.

The worm also had code to inject itself into Siemens software, by way of the WinCC SQL Server database, and embedding its code in Step 7 project files that automatically ran when engineers opened them. Since those files were almost guaranteed to be shared among more than one engineer, it made for an excellent internal infection vector that didn't depend on having network share control.

The final step was taking charge of the DLL that communicated with the actual centrifuges and injecting malicious code into the PLCs (Programmable Logic Controllers) of those machines to stealthily mess with the rotors.

Stuxnet was part of Operation Olympic Games, an alleged coordinated effort between the U.S. and Israel to try and curb Iran's purported progress in creating nuclear weapons at its Natanz facility. The initiative seemingly ran under both the Bush and Obama administrations, and was supposedly a way to dissuade Israel from launching its own preemptive strike against Iran. The software was allegedly developed by both the Pentagon and Israel's Unit 8200, and was reportedly successful in bringing down about 10% of Natanz' centrifuges by ultimately seriously damaging their rotors.

However, the worm had a nasty bug: it didn't have sufficient checks about which environment it was in, and failed to notice it was no longer in a local network environment. When engineers took their laptops home, it escaped out to the internet at large, at which point security researchers worldwide let out a collective "huh, that's odd" and proceeded to investigate. Mercifully, the worm contained a hard-coded self-destruct date set for June 24, 2012.

Musicians and synth-heads in the audience, rejoice. A new vintage synthesizer plugin has arrived that has the potential to blow many commercial offerings out of the water — and it's completely free, to boot. Audio software maker Autodafe has released the Vintage Emulator Studio (VES), a fresh new plugin that integrates a fair number of the open-source MAME emulator's synthesizer cores in one neat package.

The entire list of emulated synths is below, but it includes iconic entries like the Akai MPC3000, LinnDrum, Oberheim DMX, and Roland TR-707 — used by names like Dr. Dre, New Order, The Police, INXS, and Prince, among many other high-level acts. There are a total of 44 machines, all with component-level emulation.

What makes VES different from most other synth plugins is that instead of presenting a facsimile of the final output or a hybrid mix of component- and output-stage emulation, it employs — by way of MAME — full component-level emulation. Each processor, tone generator, envelope generator, filter chip, and converter should be faithfully reproduced, potentially resulting in a "perfect" emulation of the gear in question, more or less depending on the status of each driver core.

Notably, on machines whose MAME emulation is farther along, analog and/or digital output stages are faithfully recreated, meaning you won't need additional low-pass filters or any other trickery to make the synth sound like the actual hardware. Additionally, the skeuomorphic, HiDPI-ready UI replicates the units' control panels, dials, buttons, and LCD displays, making them easy to interact with if you're familiar with the real hardware — and probably a nightmare if you're not, as "ease of use" wasn't high on the list of priorities back then. Floppy disk, CD-ROM, and peripheral emulation ought to be included too.

If by now you're thinking this is all too good to be true, there are indeed a couple or three catches. First and foremost, as with any emulator, you'll need to provide your own ROM/firmware, and depending on the synthesizer, any associated sample packs. Although obtaining those is not too difficult, having a copy of that data is a legal gray area if you don't own the original hardware. Although we haven't tested it ourselves, the CPU usage of the plug-in ought to be somewhat high, considering all the work it's doing simulating every single component.

Additionally, while MAME's emulation cores aim for full component-level emulation, not every synth driver has had the same amount of work put into it. For example, the Akai MPC-3000 driver is nearly complete, while the Prophet-5's has only been introduced to MAME fairly recently — so your mileage may vary. We'd expect this VST to be updated somewhat frequently as work on its MAME core moves forward.

For the sake of argument, though, if only a handful of synths are fully emulated, that's still an impressive showing out of a list of 44, given that in theory you'll get output that tracks exceedingly close to that of the original hardware, all from one plugin. You can download the Vintage Emulator Studio right here, in VST3 or AU format, for every major OS: Windows, macOS Intel/M-series, and Linux. It's also available as a handy standalone application.

Data center builds are one of the hotly contested items worldwide. Many states and cities have upheld moratoriums on new buildouts due to power usage, water consumption, and noise concerns. Thailand is the latest nation to pump the proverbial brakes, with the government requesting that existing buildouts hit the pause button while coming up with a more precise regulatory framework.

Government heads requested that agencies compile information about current and future data centers during this week, in a bid to create unified legislation. The country currently has few laws specific to data centers, leading to legal voids like zoning a data center as a "warehouse" right next to a hospital. Much like everywhere else, the country has seen growing complaints about data centers' water and power usage.

After the week is out on September 11, the government expects to take about a month to come up with a regulatory draft, making the pause technically an indeterminate timeframe — though further delays wouldn't benefit either party, as Thailand considers the industry critical to the country’s competitiveness. The catch is that pausing construction isn't enforceable, so companies can elect to plow ahead regardless while the legislation is discussed.

NESDC (National Economic and Social Development Council) secretary-general Danucha Pichayanan is very specific: "we don't have the power to suspend the construction of the 49 data centers" currently under construction. However, when the legislation arrives, it will apply retroactively to ongoing projects, though with an adjustment period for in-progress builds. New builds will naturally need to comply with the legislation from the get-go.

Some companies may elect to soldier on with the belief their buildouts will be in compliance with the reasonably predictable content of the new laws, or betting that they could win future legal challenges — a dynamic that's already in play elsewhere with Project Jupiter. The incoming legislation is expected to cover power consumption (and possibly generation), closed-loop cooling, and water-surplus guarantees, meaning builders already have a fairly good idea of what they'll need to do.

Not complying with the request for a pause might be a game of political chicken, though, as the government may retaliate with regulatory delays and additional costs to power connections. Just last Thursday, Thailand's energy ministry raised concerns over a Bangkok data center that may be planning to hold diesel stockpiles far in excess of the 200,000 liters it has permission to.

On that topic, Thailand revised laws on industrial power delivery last July, and among other requirements, demands a bank guarantee of ฿4.5 million ($134,000) per megawatt. Half the money will be refunded when the actual usage reaches 50% of proposed utilization, and the rest when usage hits 70%. This mechanism is meant to stop preemptive allocation of power delivery capacity that might remain unused for months, years, or not at all — once again, mirroring datacenter playbooks elsewhere around the world.

At face value, the amount of $134k per megawatt sounds like a small price to pay for a builder to get ahead of the pack, but its per-megawatt nature means that a hyperscale facility pulling 200 MW or more needs to place around $27 million in escrow.

With the power laws recently revised, water consumption is seemingly the largest concern, as the current legal framework allows companies to make deals directly with utilities without additional safeguards. For example, in Chonburi, an operator signed a decade-long deal with Eastwater Stecon Utilities for 3.3 million cubic meters annually, or about 36,900 residents. It's expected that the new laws will add much stricter requirements to avoid localized deserts.

Not that long ago, we reported that Nvidia was dusting off the blueprints for the RTX 3060, in its 12 GB form. At the time, we'd spotted it in stores for about $339.99, but just like with ever-climbing memory, hard drive, and SSD prices, two months passed is an eternity. The same cards are now selling for $489 new, and one particular specimen is the SRhonyra RTX 3060 12 GB Low Profile card, for $495.59.

• SRhonyra RTX 3060 12 GB Low Profile card - $495.59

This card and its price may raise more than a few eyebrows, but there are reasons why it exists. First off, it's a one-slot model, making it easy to put many of them to work in the same machine with relatively little concern for airflow. They have no power inputs and rely on 70 W delivered by the PCIe slot alone, eschewing the need for a high-end PSU and lots of cables. Third, the low-profile form factor makes it possible to place them in potent puny personal computers.

Attentive readers might surmise that one (or more) of these would be good candidates for an entry-level local LLM rig. That's precisely how SRhonyra is pitching the card, calling it "capable of local AI" and "running 7B [to] 13B LLMs." A standard-dimensioned, fully powered RTX 3060 is capable of drawing a maximum of 175 W, so it's fair to assume the performance of the diminutive variant will sit below that of its full-sized brethren, given it ought to only draw 70 W of juice from the PCIe slot.

Even then, it's likely that people interested in these cards are looking to use them either as secondary GPUs, or use more than one in the same box to be able to virtually pool their VRAM and use larger models than you'd otherwise be able to. The low power draw also means they're a simple, thoughtless drop-in to an existing system, whereas larger, more power-hungry cards require careful consideration with physical spacing (or lack thereof), power supply sizing, and ever-annoying cables.