If that'll all they intended they could have agreed on a very narrowly-tailored agreement limiting the use to the same aspects of the film as manual animation.

Maybe Cage is doing some solidarity thing with animators or maybe Amazon intended to do much more and were attempting an underhanded trick.

It's hard to tell except you'd expect Cage to say something if animators' jobs were his cause.

It sounds like his agent or manager knew what was up.

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.

> you apparently desire to use systems beyond their design points

Who doesn't include cost in design?

If my CPU/SoC is plenty fast for my task and the DRAM is faster than I need it to be and a CPU instruction to compress takes less power than a write out to the bus - it would just be wasteful to manufacture and purchase twice as much DRAM as the application needs.

Either the end user gets a better price (and all money is the result of expending energy, so we save again) or the manufacturer makes a larger profit (in a constrained market).

Now then - all you lunatics embedding Electron and costing me 400MB to send an 80 character text message - we need to talk about this.

CRAM seems like a great idea but it's not the solution to not caring about the Craft.

And those corrections require atomic clocks.

You think LLMs would write "Slashdot doesn't have table support, so it's hard to do side-by-side well, but:"? You think LLMs like writing sentences that end in conjunctions that express incomplete thoughts? Do you think LLMs write "high frequences", "naively pairs", call H.265 X.265 (I was thinking of what you refer to it as in ffmpeg), imbalanced parens after "lacks motion vectors",etc?

Don't get me wrong, I am a LLM user, I absolutely do use it sometimes for search, fact checking things I'm writing, spelling/grammar checks (clearly not that time, lol), etc. But I write my own posts.

Slashdot doesn't have table support, so it's hard to do side-by-side well, but:

JPEG XL advantages:

Licensing:

JPEG XL: Fully royalty-free (Open source / Apache 2.0)
HEIC: Proprietary patent minefield (MPEG LA, Advance, Velos; royalties apply)

Legacy JPEG Migration:

JPEG XL: Lossless, reversible bitstream transcoding (~20% smaller); fast enough for real-time web servers
HEIC: Lossy re-encode only (generational quality loss; cannot reconstruct original JPEG)

Fine Detail & Textures

JPEG XL: Retains sharp text, fine lines, subtle textures, and film grain
HEIC: Video-derived coding (HEVC / X.265). Tends to smooth out high frequences and smudge grain.

Software Encoding Speed

JPEG XL: Extremely fast; highly parallelized SIMD architecture
HEIC: Exceptionally slow and computationally expensive in software

Software Decoding Speed

JPEG XL: Fast, lightweight multi-threaded CPU decoding
HEIC: Heavy CPU overhead (without using hardware acceleration)

Progressive Rendering:

JPEG XL: True progressive decode; smart saliency algorithm to focus bandwidth on critical details first.
HEIC: None; full file must be received and decoded before display

Lossless Compression
JPEG XL: Dedicated modular mode; vastly outperforms PNG and WebP
HEIC: Ill-suited; you basically have to try to do lossless compression with an inherently-lossy format

Bit Depth & HDR

JPEG XL: Native HDR; up to 32-bit floating point per channel
HEIC: Typically capped at 10-bit or 12-bit integer

Max Dimensions & Scaling

JPEG XL: Up to 1B x 1B; efficient viewport/crop loading without full decoding
HEIC: v5.2, 4096x2160; v6.2: 8192x4320; a tiling hack allows up to 16384 x 16384

Channels & Color Spaces:

JPEG XL: Arbitrary color spaces (hyperspectral); unlimited extra channels (alpha, depth, thermal, masks, CMYK, etc)
HEIC: Rigid container; limited auxiliary channels and standard video color spaces

HEIC advantages:

Rollout / acceleration:

JPEG XL: no dedicated hardware acceleration (thankfully, it's not as important because it's so much more efficient). Software adoption still rolling out.
HEIC: Hardware silicon (ASICs). Default capture format on modern iOS/Android; native capture in Sony, Canon, and Nikon cameras

Video:

JPEG XL: Supports animations (GIF/APNG replacement), with some optimizations** (it's not just a series of stills), but lacks the full set of optimizations that a proper video codec has.
HEIC: Container naively pairs full HEVC video tracks and audio with video.

** - JPEG XL can store up to 4 reference frames in a buffer, with multiple blending modes from the references (add, replace, multiply, etc); has subframe bounding boxes ("dirty rectangles") for when only part of a frame changes; invisible frames; modular deltas (differences between frames); etc. However, it lacks motion vectors (e.g. detecting a feature drifting across a scene and simply having to encode "move it" (followed by any needed deltas). So it's great for "GIFs", but if you wanted to encode a full movie, it'd be significantly larger than e.g. HEVC.

Look, I use HEIC, but JPEG-XL is just better.

* Royalty-free
* Lossless transcoding of legacy JPEGs to immediately reduce their sizes by ~20% (fast enough that you can have webservers do it in realtime)
* Better fine detail / high frequency data representation for the same bitrate. HEIC was designed for video and simply is not as good at stills.
* Faster decoding
* MUCH faster compression
* True progressive decoding - and not old-school blocky progressive decoding, but using a smart algorithm that restores coarse detail (particularly focusing on parts of the image that the eyes immediately focus on) first, then progressively adding in finer detail that the eyes take more time to notice later.
* Vastly better lossless compression
* Better colour depth and native HDR (up to 32 bit per channel)
* Up to 1B x 1B pixel images (again, useful for scientific and engineering applications), with efficient loading (don't have to load and decode the whole 1B x 1B image at full resolution to view it)
* Arbitrary colour spaces - you can even use it for scientific hyperspectral imaging. You can include e.g. alpha, depth maps, thermal data, selection masks, etc etc.

It's just a better format for stills. It's annoying that it's taken this long to get support to take off (because it takes ages for most people to update their browsers), but I'm really glad that it's starting to.

Can't tell if we should moderate the article as Troll or Flamebait.

Commenters have already pointed out the dishonesty of the prose based on their own published stats.

"You are a poor scientist Dr. Venkman."
-Dean Yeager

Yes, I'm enabling the clickbait by commenting.

JPEG-XL is a good format but I just realized yesterday that Google Docs on Android doesn't support inserting a webp image a decade after Google was pushing it. I had one from a website and needed to run it through imagemagick first.

Android supports it, all the apps using android image primitives supoort it, but one of Google's flagship apps still doesn't.

We used move much faster thirty years ago. If an app supported say GIF, PNM, and TGA when JPEG came out it was supported in the next release.

Hopefully this round will be better. It's probably a management problem ... maybe they will listen to their chatbot since they don't listen to their engineers.

The need for them came from relativity, but the atomic clocks needed to be able to handle such fine corrections are based on the hyperfine transition of 133Cs. You're not getting very far on atomic clocks without particle physics

Okay Felicia.

Sounds like Newton. Long tradition, I guess

"Okay, nuclear power. Yeah. Yeah, they did give us that. That's true. "

"And industrial-scale superconducting magnets!"

"Don't forget GPS satellite relativistic corrections!"

"And radioisotope therapy!"

"Electron beam therapy?"

"World Wide Web, wasn't that created by particle physicists?"

"Yeah, they did do that."

"Capacitative touchscreens too, you know."

"All right, all right, FAIR ENOUGH! But APART from computers, telecommunications, nuclear power, PET scans, MRIs, satellite communications, superconductors, radioisotope therapy, electron beam therapy, heat-shrink tubing, cargo and baggage screening, smoke detectors, muon tomography, capacitative touchscreens, and the World Wide Web, WHAT HAS PARTICLE PHYSICS EVER DONE FOR US?!"

"Synchrotron light sources for drug discovery?"

"Oh, drug discovery?! GROW UP!"

I don't know the protocol but old phone headsets had a 2.5 or 3.5mm jack with an extra ring that got you play/pause/hook/next/last.

Hypothetically that could have been implemented. I had a collection of Alexas that got binned as soon as they got caught spying for police so I never got that far. ESP32 is better for nerds anyway.

One thing Australia does right is a statute naming removal of features as a violation of contract requiring full refunds in these circumstances.