If it is objectively true provide your evidence. Given such an extraordinary claim it shouldn't be that difficult.

Your assertion _is_ absurd on its face.

You sound like the goonies in our marketing department.

Throughput Vs latency. Hardware RAID tends to be fast for processing large volumes of data, but the overhead increases the latency.

It's a bit different with DRAM though because the controller is complex and built into the CPU. AMD, for example, already transparently encrypts data in RAM with no performance loss, all in hardware.

Please just put a sock in it. You keep spewing inane rhetoric about AI even in places where TFA has nothing to do with AI. You can't support your statements objectively and so all you have left are lame ass appeals to authority and generalized claims lacking any useful specificity.

There are a lot of people here who spent decades working various domains you've never even heard of it doesn't fucking matter that one person is more popular than another or their code is used by more people than someone else's... or fucking patents...Jesus Christ.

I wish everyone saying LLMs are not even AI and everyone saying LLMs are as good as "software engineers" with 150 IQ would lock themselves in a room and beat each other senseless until they both started making sense.

Thanks, I'll have a watch of that later.

Heinz's prediction was made 24,080 days ago and there are only 35 days left on the clock. If in the immortal words of airman Dougherty Jesus H Christ we're still here after Friday 13th then fine go shit on his grave... until then I fully intend to give him the benefit of the doubt.

I was interesting by the article's comment that it could lead to smaller clocks, but that doesn't seem likely from what you are saying. At the moment a "chip scale" atomic clock is a metal can maybe the size of a consumer CPU, and pulling quite a bit of power.

I think the original article was somewhat tongue in cheek.

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.

Maybe the real end of the world, if Trump reacts badly enough.

Population growth is levelling off and we will end up somewhere between 10 and 12 billion by the end of the century. It's sustainable as long as we are careful... Which we tend not to be. Most of the growth is in Africa, which has a lot of scope for it.

In fact the main reason population is still growing is people are living longer. The global fertility rate has dipped below 2.1, the steady state level due to childhood deaths.

Not only did she develop software without the aid of modern debugging tools, on a new architecture that was limited in ways that most modern embedded developers can't even imagine, she pioneered a lot of the software safety techniques we still use.

When you get around to answering my question let me know.

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.