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.

The fact that this approach is catalytic rather than requiring a binding agent seems positive in terms of longevity and not being directly depleted by repeat exposure; but I'd be curious how durable the material is under real-world conditions(clothing that gets hard wear tends to get hard washes) and also how specific it is. 'Organophosphate' means something moderately specific in the context of chemical warfare; but a lot of fairly prosaic compounds are, technically, 'organophosphates'(like DNA and RNA when held together by phosphodiester bonds); and this would be considerably less helpful in practice if it is busy chewing up the genomes of random soil bacteria; and markedly less helpful in practice if there's a "do not perturb the nanites in your clothing if you want them to not migrate into your cells and start mitigating the harmful effects of your DNA" user notice on the treated article.

This doesn't seem like a lie, a NIC is in a pretty good position to knock something off the network if it feels like it and the 'bluefield' devices have enough punch onboard to run some rules regarding whether or not to do that; but it seems like a wild exaggeration of how helpful it actually is.

If you actually have a set of rules that detect your bot being wicked it will presumably save you some CPU time to run them on the NIC rather than having the host CPU watching the traffic; but the hard part is the set of rules that detect your bot being wicked.

This is basically the equivalent of adding a firewall and claiming that you've solved network security. Yeah, the firewall is pretty well placed to block malicious traffic; defining 'malicious traffic' is left as an exercise for the reader.

Support for Office 2016 and 2019 ends October 14th of this year; I assume that the feature is dropping now; rather than either 20 years ago as part of ECMA-376 and eventually in a live product for either Office 2010 or 2013, or never if they didn't want to do that, in order to draw a hard line under the utility of those?

It otherwise seems like a kind of weird time to do it. In principle what a 'cell' is has never really had an obvious mandatory scale: it has essentially always been relevant that a 'cell' existed in relation to other cells, so that something like an array could be a row; but it has also long been allowed and encouraged to do things like substring operations that acknowledge that cell contents are 'larger' objects that contain smaller ones; and are not automatically spilled out for that reason alone. Not clear that the pragmatic use case for spreadsheets would ever have supported some sort of 'any data type that implies it can be decomposed into elements shall be' rule, strings getting broken up into substrings and so on; but it's also not clear that the pragmatic use case is going to be much clarified by a single cell being n levels deep of lists and arrays of lists and arrays being a fully supported thing rather than something you hack on by shoving JSON into text cells or whatever.

It definitely seems like asking for confusion when some, but only some, "excel spreadsheets" have cells that are arrays, potentially of arrays, while others have rows of cells with contents that, at least formally, are not acknowledged as arrays.

That's the sort of curious thing about this announcement: at least in theory(I assume things are uglier in practice) the X1 parts that they shipped for windows-on-ARM/Copilot PCs already use UEFI/ACPI in line with what MS wants for booting Windows.

That obviously doesn't mean that there's a working GPU driver; or that naive power management doesn't cause the system to run at 90% of maximum power and hammer the battery flat; but the theory was that the last gen was already doing the "big kid ARM that has embraced PC standards" thing; very similar to the 'standards base' that ARM encourages ARM server part vendors to use.

I'm always a little curious what the thinking/strategy is with the Chinese outfits. I don't necessarily expect much from the OrangePi guys; they ship a surprising number of different SoCs, including multiple architectures and multiple vendors, for their size, so are likely to be mostly at the mercy of the SoC vendors; but is the situation for someone like Allwinner such that people who want linux to work on their stuff could be a resource for them and they are just not taking advantage of that very well; or are they actively annoyed by GPL-related claims and really just want to shove minimum-viable android out the door as cheaply as possible to win cheap tablet tenders and really do not want to hear from SBC hobbyists.

SOP at Qualcomm. It has been literal years of hammering on them by Google and basically every Android handset OEM to even keep parts that ship with android support in support for more than a few years(I think the current timeline, at least for 'snapdragon 8 elite' flagship parts, is a princely 8 years from release; and that is with the 'project treble' stuff that attempts to reduce the number of changes that might potentially need to be supported). Especially with the, um, raging success, of Copilot+ AI PCs they are probably ready to pretend that X1 never happened and call it good. I'm not even sure how long the windows support on X1 is expected to last.

...Modern ejector seats cause spinal injuries from which full recovery is "unusual". Smashing the spines of pilots might not be the most effective way to boost morale.

$22,000 per hour. The F35 will be nearer $42,000 per hour. These are under-estimates, as they do not include price hikes, crashes that close businesses, crashing into businesses, crashing into heavily-populated sports centres, etc.

That's a pretty shallow(thought admittedly depressingly popular) analysis of the situation.

Being in public does leave you with no particular defensible expectations of not being observed, and possibly even remembered for a time, by assorted passers by; and typically also permits more direct tailing of people for observation purposes(subject to some, often slightly vague, threshold at which having PIs or paparazzi hunting someone remains a problem even in public; as we saw here where the police took the notion seriously enough to show up but not to do anything in particular).

What it has historically never meant, for technical reasons, was pervasive coverage and longterm retention. Which is certainly increasingly feasible with only moderate levels of investment; but is absolutely a novel development for what 'public' and 'no expectation of privacy' meant.

It's like defending the installation of a massive network of sprinklers because "you have no expectation of staying dry when you go outside; haven't you heard of rain?" Sure, nobody the weather to be sunny all the time, any more than they expect everyone to avert their eyes in public; but they would correctly consider the installation of irrigation equipment on every lamppost to be an intrusion on their ability to stay dry despite the fact that the sky has never extended them a constitutionally protected right to no rain.

Pity the poor Europeans, crying out without the bot slop occupying the top half of the results. I wonder what Google is going to do to ensure that the 'degraded' results aren't universally preferred to the alternative?

I suspect that the relationship is not linear in a case like this: cancer tends to be a big issue for otherwise healthy-ish people because a lot of varieties of it take some time to develop; either chronic exposure to whatever the carcinogen of concern is or some time after the exposure when your luck with the mechanisms that suppress abnormal cell division eventually fails, or both.

There is probably a part of the graph that is mostly linear, nondrinkers to very light drinkers to light-ish drinkers; but anyone who is really hitting the sauce and succumbing to DUIs, cirrhosis, or other non-cancer alcohol mortality is making themselves ineligible for alcohol related cancer death.

How good is their game-streaming at cutting out the various 'filler' time(loading screens, startup animations telling you that Nvidia is the way it's meant to be played) and does it have some sort of 'suspend' state to handle cases where you would pause a game if it either doesn't have save on demand anywhere or takes a little while to load from save?

I know I have a bunch of games that I don't actually play all that much, in wall time terms; but Steam's 'executable run time' number is 2x-10x as high because I'm not necessarily going to save, quit, open, load if a game can be paused and alt-tabbed without crashing or continuing to eat all the GPU time to render a static image I'm not looking at; and I'm not necessarily going to do anything other than pause if I'm called away for 15 minutes by something else.

Unless the streaming service is impeccable at cutting out the various little waits it seems likely that people are going to start resenting the time limit even more than their level of seriousness and actual hand-on-controller-and-attention-locked time suggests.

Given that they already purchased Activision Blizzard King, including the "King" part of it, they clearly already have a considerable interest in casual players.

What is less obvious is how that is supposed to work for their streaming service. The stuff aimed at casuals, sensibly, is normally targeted at either potato-tier PC specs or the (pretty punchy in absolute terms) mobile devices that people worth targeting have.

It is much less clear whether there's a 'casual' market that demands current-gen console performance in very limited amounts rather than mobile or iGPU level titles. Given the extreme prevalence of various 'free to play' models that do sneaky monetization later it also looks like the 'casual' market's (significant) amount of money is largely locked up behind the sort of price sensitivity that requires clever psychological tricks to break through. I'm not sure that they'll be a good fit for something as obvious and psychologically burdensome as a ticking countdown timer hanging over every minute they play.