That's it, I'm done with Ubuntu.

So many shitty things are being done "with AI". I love AI, but it doesn't help that the devs doing all these AI Rust tools seem to have little to zero experience with development, or thoroughness.

And for encryption? Fuck outta here.

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.

We measured the same thing: a hardware raid controller performed better software raided, and the vendor would tell us "were were measuring wrong, here is a super synthetic benchmark that is faster".

My best guess is that the hardware raid inevitably collapsed all the disks into a single IO queue, so workloads with independent IO could be more independently scheduled and serviced in software raid. Alternatively, the software stack has more visibility to the topology and can default to better aligned data layout without the user having to manually tune.

I wondered if, theoretically, the hardware raid could have done better abstracting it to an nvme target. Ultimately though, just not worth the hassle.

I am talking about optical processors.
The processor China uses to crank out a new LLM in a day.

Google it, it is not complicated.

No idea why you think Europe, or its politicians, are afraid about or are against the internet.

That does not make any sense.

It is exactly the same.

Just one technology lost and the other one won.

Similar to VHS versus .... well, don't remember how it was called.

I do not know much about the protocols of Gopher, but instead of HTML they used TeX/LaTeX.

Not sure about what you want to argue.

The processors will soon all be optical.

Anyway, *using* an LLM does not cost much.

So, I do not what your point is. I would assume that people/companies that spent the money to try that, know what they are doing.

Tim Berners-Lee invented hypertext while working at CERN.
Which has nothing to do with internet, but is a protocol and mark up language that runs

on top of the internet.

He invented the world wide web. And that is actually only a reinvention: as we had gopher already, and wide area information services (WAIS/WISE?)

The internet is DARPA and the follow ups: TCP/IP and the surrounding infra structure protocols like DNS.

I mean, proofs are just "rearranging theorems". So you're kind of saying that they're really well suited to the work.

But humans won't thrive when this ice age ends.
Most of them will perish.

Nope.
The artic stays the artic.
Much to short growth time to grow anything meaningful.
And: the soil there is not fertile at all. It is frozen swamps and moors.

To click where the troops should go, for everything else you use the keyboard.

Radiation hardening is only a extra thick extra layer of silicon on top of the chip.

Also keep in mind: the idea is to answer AI questions, not to train ANNs.

And those corrections require atomic clocks.