This happens all the time for positions that don't have H1Bs. It's not unique to hiring and retaining H1Bs. Any business, institution or government agency that wants to fill a position and is required to publicly post a position has probably done this if they already have a specific candidate in mind.

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.

True to a large part, but it also depends on which population you're referring to, and I don't tend to be very America-centric. For example, Britons made over 91 million overseas trips in 2024, of which 71 million journeys were to Europe:
https://www.ons.gov.uk/peoplep...

That's for a population of 69 million. Of course, there are people like me who went abroad eight times that year, and plenty who don't. Except for Portugal or Iceland or Western Africa, all of those trips involved a time zone change. Of course, you said "most", which could be 51%. The point is: a large number of people do regularly travel across time zones.

Can't you just run the following instead of installing something, or did these change with Arm Macs?

pmset -g therm

sudo powermetrics --samplers thermal,cpu_power -n 1

The other clue is the kernel_task process unexpectedly running at high CPU load.

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!"

Yeah, what has a better understanding of particle physics ever done for US, huh??? ... ...

_ ...........