The “ninjas stole my dog/wife/kids, need money for karate lessons” joke itself predates smartphones. I used to see this sign from panhandlers all throughout the 2000’s.

What if Claude was one of us?

Focal length equivalent assumes a 35mm sensor or film format. 50mm on 35mm is basically the human range of view (although human eyes are interesting in that our resolution is so much sharper in the middle of the sensor than on the edges, and there’s significant variation between individuals.

But the important part is that it isn’t actually focal length that makes the effect. It’s distance from the camera. If you do a dolly zoom with a fixed focal length lens, where you still push or pull the camera towards or away from a subject, you can still see this effect on the nose and the ears.

A flat, two dimensional representation of a three dimensional object will always have distortion. The effect we see here is about distortion that changes with camera distance, and the change itself is what makes things feel strange.

The day is the number I want to know most of the time. Day, month, year, in order of which number you most likely need to know first.

No, getting the year wrong by 1 is much more significant than getting the day wrong by 1. If you’re arguing that it won’t happen because people will infer from context the correct year, then you’re actually assuming that the person already does know the year first. The only reason why people don’t state the year is because it is already known by the listener. But just because it’s unstated doesn’t mean that it isn’t critically important.

If you’re measuring duration, for example, you will put the largest unit first. The longest serving prime minister of the UK served for 20 years and 315 days. Magellan’s expedition around the lasted 2 years, 11 months, and 16 days, if you count from Sanlúcar de Barrameda. The course record for the Iditarod race is 7 days, 14 hours, 8 minutes, and 57 seconds.

And some languages are more irregular than others about numbers. In English, we say “sixteen” where the ones digit is said before the tens digit. French has some base 20 naming conventions that screw up the order, too.

But when we write numbers, we go left to right, largest to smallest. That’s why describing time should follow the same convention, and why ISO 8601 exists.

You’re using the word “significant” in a colloquial/informal way, but in terms of the strict mathematical definition, most significant digits to least significant is about the size of the unit. If you were to create a dial system, the most significant digits move the slowest and the least significant digits move the fastest.

Or, if you are rounding a measurement to the N most significant figures, you are by definition keeping the largest units and rounding off the rest.

So ISO 8601 properly orders it left to right, largest to smallest, without exceptions. It can be truncated for lower precision, like how 2026-09-14T20:15:35 takes place in a particular year (2026), or a particular calendar month (2026-09) or a particular day (2026-09-14).

It’s the best format and everyone should use it.

It’s kinda shocking that people can’t seem to detect pretty obvious satire.

HTML / JS is still a buggy pile of slop.

In what world is JavaScript considered buggier than Flash, either in the actual content in the wild or the client-side software rendering/running that content? It wasn’t true when Flash died and certainly isn’t true today.

Flash was a security nightmare, with all sorts of kludges patched on to try to deal with fundamental flaws in how it handled privileges. If you want to go back to the days where zero click exploits can take over your machine just from a browser visiting the wrong URL, leave the rest of us out of that vision.

The current web experience is complete garbage in comparison.

Mm, and what makes you think that handing Adobe the keys to control everyone’s web experience would make it better?

As a browser-supported web image format, the only real runaway advantage of JXL is the ability to losslessly reencode existing JPEG files, when the vast majority of image files that people already have are stored as JPEG “originals.”

But as an overall image format, JXL has a much more ambitious scope: much higher limits in the spec to resolution, bit depth, layers, etc., showing an intent to be used as a raw image capture format and printing format, not limited to screen resolutions and bit depth like AVIF is.

So if the original file gets stored as JXL, the workflow and pipeline of a JXL native process the whole way may have an advantage over exporting to a screen-friendly AVIF at the end of the process, while the original still gets stored as another format.

Re-encoding from JPEG to AVIF will always drop quality. Lossless re-encoding from JPEG to JPEG XL makes a pixel perfect reproduction, while shrinking file size.

Apple’s Safari supports still images in JXL.

Perhaps more notably, Apple’s iPhone ProRaw supports JXL encoding for its raw sensor data. They’re laying the groundwork for JXL to be a supported format from the point of capture at the camera, through all the processing to make an image for web publishing or whatever.

The killer feature is that JXL is better in that it can losslessly encode JPEG further, and the overwhelming majority of the legacy image files that people have are JPEG. That alone should justify its support, because there are a lot of files out in the world where the highest quality, closest to “original” quality file is stored in JPEG format. A format that allows for the further compression with zero loss of quality from those originals is really important.

And the other thing this article (and a lot of the discussion around JXL) chooses not to cover is how JXL is a good format outside of just web images. It’s not just looking to replace JPG/PNG/webp. It’s also looking to replace raw photography formats like DNG, TIFF, and other formats that are used for full workflows from image capture from the imaging sensor itself, from cameras to scanners to medical imaging.

If JXL succeeds at becoming the dominant raw capture format, the entire workflow of processing those raw images into exported web-friendly images will favor JXL for photography.

No, you’ve got it all wrong. Flash was buggy and insecure proprietary software written for proprietary OSes. I’m glad it died, after several years of trying to fight its normalization on the web, where you’d need to install shitty plugins like gnash on Linux to try to see the same web that people were seeing on Mac or Windows.

The web should always be built on open standards, and Flash was the biggest barrier to that ideal at the time that iPhones came out. Flash deserved to die, and I celebrated when it did.

Steps that either would not work between architectures or that Rosetta would handle (thereby answering your own question)

What? They would compile the code that they control for the M-series architectures. The target architecture is M-series ARM chips running on MacOS.

Rosetta is for translating x86 to ARM. Which wouldn’t be necessary because there are no x86 binaries involved at all.

I don’t understand why Rosetta has to be involved in any way at all.

Apple provides APIs for programming low level GPU instructions, including AI workloads, on their chips, using the Metal API. Anyone interested in using Apple hardware to its full potential can just write Mac-native software, same as any other MacOS native software directly compiled as binaries to run on Mac M series chips. No Rosetta required for translating x86 instructions to ARM, when the whole thing compiles for Apple’s native instructions in the first place.

Yup. My main living data is on a NAS, my on-site backup is an external USB enclosure with a SATA hard drive hooked up to a Mac Mini, all so that I can leverage a Backblaze account to back up the external hard drive with unlimited data.