AI is and will continute to be increasingly empowered with indifferent safety precautions because the power money confers is all that matters to techbros.

First world systems are far more fragile than they appear to humans. AI doesn't have that problem.

That's the point of the CXL memory expansion parts. Something like a Marvell Structera X 2404 is a CXL/PCIe 5 device with DDR4 controller so that you can add DDR4 to a system that would otherwise only support DDR5. There's a latency penalty and the part itself isn't free; but it allows you to make some use of DDR4 that you already have or can get for less than DDR5 without needing some custom CPU that combines current-gen features with a last gen memory controller.

The mention of a NUMA node has me unclear on whether this is a software or hardware implementation. There are several vendors either offering or showing around proofs of concept to try to generate interest, for CXL memory devices(which all essentially look like a NUMA node that is nothing but memory controller); mostly aimed at hyperscaler use cases where you want the improved performance and platform features of current gen servers; but your last gen servers were beefy enough that just disposing of them would be getting rid of a relatively titanic amount of DDR4 that is still faster than most NVMe. Some of those attempt to offer software-transparent compression, some just put CXL on one side and memory controller on the other and allow you to do (mostly) agnostic mixing of memory generations on anything new enough to have some PCIe lanes support CXL extensions.

I suspect that it's mostly my ignorance that is to blame; but what I don't understand about implementing memory compression(especially the schemes that try to do it transparently with high speed general purpose compression/decompression in hardware) is how you compensate for the fact that the amount of memory you need is no longer predictable without significantly more effort(potentially untenably more if you are using RAM because latency is critical).

With normal uncompressed RAM it just demands RAM in direct proportion to its size. Potentially hideously wasteful if there's some memory-backed XML-spew log that would zip down to 10% of its nominal size; but predictable unless you've got memory safety bugs. If you are compressing your RAM suddenly you've got some uses of RAM that are functionally uncompressable and require 100% of the space their nominal size suggests they will; other things might compress exceptionally well and save you 90%; and some might change unpredictably from moment to moment depending on what needs to be stored there.

When you are doing FS compression and dedupe for backups and stuff that is normally manageable; on average enough compression is possible enough of the time that you can safely assume that you'll do better than you would if you just didn't try; and you can just keep an eye on how quickly the big SAN appears to be filling up as versions accumulate and (if tapes or other fixed-sized media are involved) just change the backup media more or less quickly; do you do that for RAM? Just use the big slack area for FS caching or something you can drop on short notice in case a burst of incompressible data comes in? Do you essentially have to rebuild how your entire workload handles RAM so that it considers, at least approximately, how well a given use of memory will compress ahead of time?

Given the sorts of files and data structures you commonly encounter I can easily enough believe that compression is worth the trouble a lot of the time; but unless you are leaving a lot of slack in your available RAM it seems like a situation where, under certain circumstances, you could go from being fine because most of what is in-memory compresses well to suddenly needing as much physical RAM as you do logical RAM because you have a bunch of already-compressed or incompressible data would markedly increase the complexity or potential for things to go wrong.

No, not at all. The gender pay gap is in the training data thousands of times, from online comments, studies, news articles, etc. Since AI is a dumb machine replicating what it has in its training data, it replicates that.

I'm pretty sure you can find religious believe, superstitions of all kinds, human fallacies and whatever in AI if you provide it with the right setup.

There has never been an explanation of the motive for enshittifying Slashdot. It would be far more profitable with quality moderation.

It's as if Slashdot's owners hate money. While I respect the desire to do less work, even AI would be an improvement. Nerds wanting news and stuff that matters are a very large market.

This. No good game was ever created from a single prompt. Not to an AI, not a human development team. Every single person writing those damn "look which game my AI built from a single prompt and $x in tokens!" postings is a newbie and almost certainly has never actually shipped a single game.

Game development can be summed up as endless iterations. Every system you build, every visual you create, every sound, text, button, movement, weapon, skill, powerup needs polishing, refinement and changes. It is never, never good enough the first time.

No it is not, but it IS a very successful platform for a specific subclass of games. If I were in it for the money, I could probably AI refactor some of my earliest games and publish them on Roblox and make a quick buck. If your thing is the kind of games you played on your C64 back in 1793, then Roblox got you covered. Well, if you ignore the scams and money-grabbing.

*sigh* I wish Unity would actually complete some of their dozens half-finished sub-systems instead of constantly chasing the latest trend. It's become really, really annoying. The engine used to be really good. These days, it falls apart if you look at it the wrong way, and at least from the responses to my bug reports it's clear that fixing issues is way down on the agenda.

Maybe this is their attempt to regain grounds in the indie game market - the very market they pushed away by focussing on AAA requirements for years and ignoring the single devs and small teams. If so, I can already tell them that it won't work. We collectively laugh about all the "look what my AI built for me from a single prompt" postings on reddit, where people proudly show off some AI slop that would get them last place at a game jam.

Their AI efforts so far: Tried to build and sell their own AI tools, to a collective yawn from the audience. Built a barely-working MCP server, then deprecated it before it was even finished in order to push a CLI interface to the editor instead, which only works if it's run as the same user as the editor on the same machine. And completely ignores every single advise on workflows and good development practices you can think of.

Unity, I love your engine, I despise your management. Please return to when you were actually good and stop chasing butterflies.

These threads are space filler and have been for decades.

Since 1999. If Redmond built OS and applications as well as their hardware the world would be a better place.

The target audience for this particular rule of the AI Act isn't the producers or users of AI. It is the consumers of content that might be AI generated.

And frankly, letting people know if they see AI content or not is a fair thing to ask.

Fun fact: The EU AI Act considers this. It makes a difference between "AI generated" and "AI modified".

But it's hard to put this into the type of watermarking they are using. Because if you generate a text and then change a few things here and there what you are doing is degrading the watermark. But since the watermark is probabilistic, it's hard to tell if it was a weak watermark from the start or if it was degraded.

Many Rust Belt cities need investment. They've vast disused smokestack industrial areas with power, water and sewer. They have millions of obsolete structures begging for the wrecking ball.

Data center operators could be incentivized to demolish toxic eyesores and replace them with clean data centers. The low population impact from data centers won't overcrowd Rust Belt areas while contributing to their development.

Development deals could be generous while requiring demolition of areas not yet planned for development. The closer they become to greenfield sites the better. Obsolete cities whose reason for being evaporated still retain road, rail and power.
Adaptive reuse beats developing rural farmland etc.