No. Not at all inevitable. Poland might have descended into kleptocracy, e.g. Hungary. That this did not happen is worthy of investigation. I'm not holding my breath however; the findings would probably not be welcome.

"A general lack of ideological 'mind viruses' that seem to plague the western world"

Indeed. Poland frequently disappoints the rest of the EU with its stubborn indifference to obligatory Western moral panics.

It's good to see. Guess they were worth saving. I do hope their abandonment of discrete desktop GPU is temporary.

Instant classic.

Going in the opposite historical direction is the other side of that ledger. The actual plant in question was shut down in 1957. The AEC stepped in years earlier to triage the operation, after actually establishing formal exposure limits in 1950, which didn't exist prior to that point. Before that, the company itself had hired staff to control waste and detect contamination. They had to build their own survey equipment because there were no commercial tools available. The worst of the actual contamination was actually incurred prior to that; 1942-1945, when the gloves were entirely off building bombs.

The lessons have been learned. It's tragic and shameful history, but not terribly relevant to modern practice in nuclear power.

Obviously, fuel refining hasn't just carried on like that, in the US and Europe at least. But it's one of many handy cudgels to use whenever folks get excited about nuclear.

[1] https://www.pbs.org/newshour/nation/how-sim-farms-like-the-o...

The "S" segment is really popular. Despite the introduction of many Espressif RISC-V devices, one still sees lots of Xtensa S3 stuff. An excellent example is Unexpected Maker's line of ESP32-S3 boards.

ESP32-S31 is going to be a big hit, and RISC-V is only part of that. More GPIO are very welcome. The CLIC (core local interrupt control) is another subtle win that is lost in mainstream headlines: it provides Cortex NVIC level of interrupt management, enabling awesome things like RTIC work without compromise. I imagine using one of these with core 0 running plain old FreeRTOS handing Wi-Fi/OTA/etc., and core 1 exclusively running a Rust RTIC/SRP application, nailing real time peripheral activity.

The only miss is the lack of 5GHz. Nothing is perfect, and that's not a deal killer in most cases.

Indeed. ESP32-S31 appears to target exactly this concern in the popular "S3" segment. It's basically a updated S3, with faster and newer wireless and memory, and it adopts a pair of RISC-V cores in place of the Xtensa cores.

This depends on what resources you're counting. If you're counting the developer cycles, it is not.

ESP-IDF+FreeRTOS has great value: it solves a host of mundane problems that need solving in real products. Discarding all of that value is foolish; you should preserve it, and look to keep your work aligned with the recent ESP-IDF and FreeRTOS evolution, so future you can adopt updates and supported tooling in a timely manner.

However, you also need at least some of your work to be hard real time, bare metal code. You do this through hardware peripherals, precision memory management, and tight ISRs that do not contend with whatever FreeRTOS or some Expressif driver is up to. Most of all, you want to never have to rework these parts because something in ESP-IDF and/or FreeRTOS, both rapidly moving targets, has changed.

Dedicating cores (0 for FreeRTOS, 1 for you) provides exactly this, and why ESP-IDF supports this model.

There is an ugly truth here. Ideally, one should not need to resort to such things. If the model and runtime behavior of the vendor's stack were extremely mature and could be relied upon with high confidence, it would not be necessary. However, anyone that has ever actually dealt with real time requirements and/or needed to fully exploit hardware peripheral capabilities in the real world of endlessly changing, incomplete, buggy BSPs/RTOSes/etc., knows that they probably won't live to see that.

"Card supports 10Gbit/s and 10/100/1000/2500/5000/10000Mbit/s Ethernet"

Nice to see; some NICs are shedding 10/100 support. Apparently, it's not necessary to do this, even in a low cost device.

I'm doing a goofy thing and buying it, despite knowing I can debloat Brave, because I already do that. I didn't know this existed till I read this thread. I've been benefitting from Brave for many years now; it's great that they've provided a way to pay for this without dealing with the crypto stuff, and I'm extremely happy to do so, because they deserve some of my money.

We have seen ample evidence that this is not the case. When load gets too high, models get dumber, silently. When the Powers That Be get scared, models get restricted to some chosen few.

We are leading ourselves into a dark place: this unease, which I share, is justified.

K&R C... been a while.

Make a prediction for it: When will Gamma/Data/CLOB require subscription: 2026, 2027, etc.

The substance is they've created a way to fabricate a device that can make the optical frequencies they wish. That is useful: it means a designer isn't limited to frequencies that are economic to generate with existing techniques, which is a constraint that lasers currently struggle with: low cost, compact, efficient laser sources (the kind that fit on a chip, and are fabricated by cost effective processes,) only exist for a limited number of frequencies.

The story is typical tech journalism pabulum, but the underlying paper does discuss efficiency. It's about what you'd expect: 35 mW -> 6 mW @ 485 nm, for example.

An obvious use case is multimode fiber communication: perhaps this makes it possible to use more frequencies for greater bandwidth and/or make the devices cheaper/smaller/more efficient. But there are other, more exotic things one might do when some optical frequency that was previously uneconomic becomes feasible to use at scale.