Apple Newsroom:

Apple today announced M5 Pro and M5 Max, the world’s most advanced chips for pro laptops, powering the new MacBook Pro. The chips are built using a new Apple-designed Fusion Architecture. This innovative design combines two dies into a single system on a chip (SoC), which includes a powerful CPU, scalable GPU, Media Engine, unified memory controller, Neural Engine, and Thunderbolt 5 capabilities. M5 Pro and M5 Max feature a new 18-core CPU architecture. It includes six of the highest-performing core design, now called super cores, that are the world’s fastest CPU core. Alongside these cores are 12 all-new performance cores, optimized for power-efficient, multithreaded workloads. [...]

The industry-leading super core was first introduced as performance cores in M5, which also adopts the super core name for all M5-based products — MacBook Air, the 14-inch MacBook Pro, iPad Pro, and Apple Vision Pro. This core is the highest-performance core design with the world’s fastest single-threaded performance, driven in part by increased front-end bandwidth, a new cache hierarchy, and enhanced branch prediction.

M5 Pro and M5 Max also introduce an all-new performance core that is optimized to deliver greater power-efficient, multithreaded performance for pro workloads. Together with the super cores, the chips deliver up to 2.5× higher multithreaded performance than M1 Pro and M1 Max. The super cores and performance cores give MacBook Pro a huge performance boost to handle the most CPU-intensive pro workloads, like analyzing complex data or running demanding simulations with unparalleled ease.

This is a bit confusing, but I think — after a media briefing with Apple reps this morning — I’ve got it straight. From the M1 through M4, there were two CPU core types: efficiency and performance. When the regular M5 chip debuted in October, Apple continued using those same names, efficiency and performance, for its two core types. But as of today, they’re renaming them, and introducing a third core type that they’re calling “performance”. They’re reusing the old performance name for an altogether new CPU core type. So you can see what I mean about it being confusing.

There are now three core types in M5-series CPUs. Efficiency cores are still “efficiency”, but they’re only in the base M5. What used to be called “performance” cores are now called “super” cores, and they’re present in all M5 chips. The new core type — more power-efficient than super cores, more performant than efficiency cores — are taking the old name “performance”. Here are the core counts in table form, with separate rows for the 15- and 18-core M5 Pro variants:

Another way to think about it is that there are regular efficiency cores in the plain M5, and new higher-performing efficiency cores called “performance” in the M5 Pro and M5 Max. The problem is that the old M1–M4 names were clear — one CPU core type was fast but optimized for efficiency so they called it “efficiency”, and the other core type was efficient but optimized for performance so they called it “performance”. Now, the new “performance” core types are the optimized-for-efficiency CPU cores in the Pro and Max chips, and despite their name, they’re not the most performant cores.

npx workos launches an AI agent, powered by Claude, that reads your project, detects your framework, and writes a complete auth integration directly into your existing codebase. It’s not a template generator. It reads your code, understands your stack, and writes an integration that fits.

The WorkOS agent then typechecks and builds, feeding any errors back to itself to fix.

See how it works →

What HazeOver does is highlight the active window by dimming all background windows. That’s it. But it does this simple task with aplomb, and it makes a significant difference in the day-to-day usability of MacOS.

Marcin Wichary, writing at Unsung (which is just an incredibly good and fun weblog):

Half of my education in URLs as user interface came from Flickr in the late 2000s. Its URLs looked like this:

flickr.com/photos/mwichary/favorites
flickr.com/photos/mwichary/sets
flickr.com/photos/mwichary/sets/72177720330077904
flickr.com/photos/mwichary/54896695834
flickr.com/photos/mwichary/54896695834/in/set-72177720330077904

This was incredible and a breath of fresh air. No redundant www. in front or awkward .php at the end. No parameters with their unpleasant ?&= syntax. No % signs partying with hex codes. When you shared these URLs with others, you didn’t have to retouch or delete anything. When Chrome’s address bar started autocompleting them, you knew exactly where you were going.

This might seem silly. The user interface of URLs? Who types in or edits URLs by hand? But keyboards are still the most efficient entry device. If a place you’re going is where you’ve already been, typing a few letters might get you there much faster than waiting for pages to load, clicking, and so on.

In general, URLs at Daring Fireball try to work like this.

• This post: /linked/2026/03/02/wichary-flickr-urls
• In Markdown: /linked/2026/03/02/wichary-flickr-urls.text
• This day’s posts: /linked/2026/03/02/
• This month’s posts: /linked/2026/03/

I say “in general” because the DF URLs could be better. There should be one unified URLs space for all posts on DF, not separate ones for feature articles and Linked List posts. Someday.

Wichary subsequently posted this fine follow-up, chock full of links regarding URL design.

During the most recent episode of The Talk Show, Jason Snell brought up a weird issue that I started running into last year. On my Mac, sometimes I’d drag an image out of a web page in Safari, and I’d get an image in WebP format. Sometimes I wouldn’t care. But usually when I download an image like that, it’s because I want to publish (or merely host my own copy of) that image on Daring Fireball. And I don’t publish WebP images — I prefer PNG and JPEG for compatibility.

What made it weird is when I’d view source on the original webpage, the original image was usually in PNG or JPEG format. If I opened the image in a new tab — just the image — I’d get it in PNG or JPEG format. But when I’d download it by dragging out of the original webpage, I’d get a WebP. This was a total WTF for me.

I turned to my friend Jeff Johnson, author of, among other things, the excellent Safari extension StopTheMadness. Not only was Johnson able to explain what was going on, he actually made a new Safari extension called ChangeTheHeaders that fixed the problem for me. Johnson, announcing ChangeTheHeaders last year:

After some investigation, I discovered that the difference was the Accept HTTP request header, which specifies what types of response the web browser will accept. Safari’s default Accept header for images is this:

Accept: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5

Although image/webp appears first in the list, the order actually doesn’t matter. The quality value, specified by the ;q= suffix, determines the ranking of types. The range of values is 0 to 1, with 1 as the default value if none is specified. Thus, image/webp and image/png have equal precedence, equal quality value 1, leaving it up to the web site to decide which image type to serve. In this case, the web site decided to serve a WebP image, despite the fact that the image URL has a .png suffix. In a URL, unlike in a file path, the “file extension”, if one exists, is largely meaningless. A very simple web server will directly match a URL with a local file path, but a more complex web server can do almost anything it wants with a URL.

This was driving me nuts. Thanks to Johnson, I now understand why it was happening, and I had a simple set-it-and-forget-it tool to fix it. Johnson writes:

What can you do with ChangeTheHeaders? I suspect the biggest selling point will be to spoof the User-Agent. The extension allows you to customize your User-Agent by URL domain. For example, you can make Safari pretend that it’s Chrome on Google web apps that give special treatment to Chrome. You can also customize the Accept-Language header if you don’t like the default language handling of some website, such as YouTube.

Here’s the custom rule I applied a year ago, when I first installed ChangeTheHeaders (screenshot):

Header: Accept
Value: image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
URL Domains: «leave blank for all domains»
URL Filter: «leave blank for all URLs»
Resource Types: image

I haven’t seen a single WebP since.

ChangeTheHeaders works everywhere Safari does — Mac, iPhone, iPad, Vision Pro — and you can get it for just $7 on the App Store.