Norbert Heger (Mastodon, Hacker News):

Since upgrading to macOS Tahoe, I’ve noticed that quite often my attempts to resize a window are failing.

This never happened to me before in almost 40 years of using computers. So why all of a sudden?

It turns out that my initial click in the window corner instinctively happens in an area where the window doesn’t respond to it. The window expects this click to happen in an area of 19 × 19 pixels, located near the window corner.

[…]

But due to the huge corner radius in Tahoe, most of it – about 75% – now lies outside the window[…]

Jason Snell:

That’s right, folks, the solution to resizing the corner of a window in Tahoe is to click outside the edge of the window. I can’t even.

Jason Anthony Guy:

The accompanying gif of him grabbing a plate captures the experience perfectly.

Rui Carmo:

The annotated images (green “expected” area, blue dot, and the “accepted target area” sitting in empty space) make the point better than any amount of hand-waving, and we need more of this to make it obvious that Apple needs to reverse course on the whole thing.

Gui Rambo:

Yes! All the time. The opposite also occurs: trying to click something behind a window and accidentally resizing the front most window instead.

Tony Arnold:

I’ve noticed that resizing windows on macOS Tahoe seems to fail 2-3 times each time I perform the action. How did Apple break so many interactions in a single release?

Garrett Murray (Mastodon):

I have struggled with this every single day since Tahoe was released. I fail on nearly every first attempt at resizing a window.

[…]

Imagine taking one of the most core, we-take-this-for-granted features of a windowing system and throwing it away. And why? Oh, because iPhones have rounded corners and therefore so should all windows on every Apple platform.

Joachim Kurz:

Things like this make me want to switch to Linux and build my own Desktop environment and window manager.

Like, gather all the macOS devs who still understand how desktop UX is supposed to work, take an Apple HIG from the 90s or and let’s build ourselves a new home.

And when we are done with that (shouldn’t take longer than a couple decades, right?), we fork the open source component from Android and do the same for mobile UX.

Mario Guzmán:

ugh this is one of the things that drives me most insane in #macOSTahoe. Basic desktop-isms are just so broken. I fear that more and more folks who don’t understand the history of the desktop are running the show at Apple. I hope I am wrong but then what explains this mess?

John Gruber (Mastodon):

One can argue with the logic behind these changes, 15 years ago. I’ll repeat that I think it was a grave error to make scrollbars invisible by default. I would argue that while the visible grippy-strip isn’t necessary, it’s nice to have. (As noted above, its presence showed you whether a window could be resized.) But there was, clearly, logic behind the decisions Apple made in 2011. They were carefully considered. The new logic was that you no longer look for a grippy-strip to click on to resize a window. You simply click inside the edge of a window. And of course Apple added a small affordance to the hit target for those edges, such that if you clicked just outside the window, that would count as “close enough” to assume you intended to click on the edge. Most users surely never noticed that. A lot of nice little touches in UI design go unnoticed because they’re nice little touches.

Until MacOS 26, most of the hit target for initiate the resizing of a window was inside the window. Because, of course, right? Even though MacOS (well, Mac OS X) stopped rendering a visible resize grippy-strip 15 years ago, the user could simply imagine that there was still a grippy area inside the lower right corner of every resizable window. It would make no sense whatsoever for the click target to resize a window to be outside the window. Why would anyone expect that? It would work against what our own eyes, and years of experience, are telling us. You pick up a thing to move it or stretch it by grabbing the thing. Not by grabbing next to the thing.

diskzero:

I worked on Finder/TimeMachine/Spotlight/iOS at Apple from 2000-2007. I worked closely with Bas Ording, Stephen Lemay, Marcel van Os, Imran Chaudry, Don Lindsey and Greg Christie. I have no experience with any of the designers who arrived in the post-Steve era. During my time, Jony Ive didn’t figure prominently in the UI design, although echoes of his industrial design appeared in various ways in the graphic design of the widgets. Kevin Tiene and Scott Forstall had more influence for better or worse, extreme skeumorphism for example.

[…]

Here is my snapshot of Stephen from the time. He presented the UI ideas for the intial tabbed window interface in Safari. He had multiple design ideas and Steve dismissed them quickly and harshly. Me recollection was that Steve said something like No, next, worse, next, even worse, next, no. Why don’t you come back next week with something better. Stephen didn’t push back, say much, just went ok and that was that. I think Greg was the team manager at the time and pushed Steve for more input and maybe got some. This was my general observation of how Stephen was over 20 years ago.

I am skeptical and doubtful about Stephen’s ability to make a change unless he is facilitated greatly by someone else or has somehow changed drastically. The fact that he has been on the team while the general opinion of Apple UX quality has degraded to the current point of the Tahoe disaster is telling. Several team members paid dearly in emotional abuse under Steve and decided to leave rather than deal with the environment post Steve’s death. Stephen is a SJ-era original and should have been able to push hard against what many of us perceive as very poor decisons. He either agreed with those decisions, or did not, and choose to go with the flow and enjoy the benefits of working at Apple.

Previously:

• Liquid Glass Disbelief
• Alan Dye Leaving Apple for Meta
• How to Turn Liquid Glass Into a Solid Interface
• Tahoe Window Corners

Update (2026-01-13): John Gruber:

If you turn on always-visible scrollbars (which you should) and scroll to the bottom, they look like this[…]

Stevie Bonifield (via Hacker News):

In a surprisingly user-friendly move, Bose has announced it will be open-sourcing the API documentation for its SoundTouch smart speakers, which were slated to lose official support on February 18th, as reported by Ars Technica. Bose has also moved that date back to May 6th, 2026.

When cloud support ends, an update to the SoundTouch app will add local controls to retain as much functionality as possible without cloud services.

[…]

Usually when products lose support for cloud services, they end up bricked, and occasionally users step in themselves to fix things. For instance, when Pebble originally shut down in 2016, users kept their watches functional by creating the Rebble Alliance, a community-run replacement for the watches’ cloud services, firmware, and app store.

Previously:

• Google Ends Support for Early Nest Thermostats
• Humane Acquired, Ai Pin Discontinued
• Sonos Will Stop Providing Software Updates for Its Oldest Products in May
• Awair Removing Features and Support for Older Devices
• Drobo Files for Bankruptcy
• Older Kindles Will Lose Cellular Access
• Logitech Harmony Remote Discontinued
• Slingbox Discontinued
• Eye-Fi Demonstrates the Danger of Cloud-Dependent Hardware
• Nest to Shut Down Revolv Home Automation Hubs

Jonas Bonér (based on work by Peter Norvig and Jeff Dean from 2012):

L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms

Colin Scott has a page that helps visualize how these types of numbers have changed over time (Hacker News).

Jon Snader:

Mohammad Zeya Ahmad has an informative post [archive] that answers that question. He has a list of how much time various common operations take. That’s interesting but what make his list stand out is that he draws conclusions from his results.

For example, SSDs are about 30 times faster than HDDs so if you have a high performance disk-based task, it makes sense to use SSDs. Of course, there are reasons to prefer HDDs but if performance is your controlling metric, SSDs are probably your best choice.

For each group of comparable metrics, Ahmad offers an actionable suggestion. Those groups range from CPU versus Cache and Memory speeds to network transfer times.

Previously:

• Python Numbers Every Programmer Should Know
• C Is Not a Low-level Language
• Squeezing the Most Out of Bluetooth
• Performance Comparisons of Common Operations, 2016 Edition
• Transatlantic Ping Faster Than Sending a Pixel to the Screen

The Midwest is expected to have very cold temperatures this weekend, which got me thinking about burst water pipes. Water expands about 9% as it freezes, and a lot of people think it’s pressure from the outward expansion of ice that ruptures pipes, but it’s more complicated than that.

My favorite reference for this phenomenon is this 1996 paper by Jeffrey R. Gordon of the Building Research Council at the University of Illinois. It’s entitled “An Investigation into Freezing and Bursting Water Pipes in Residential Construction,” and it goes through the testing that the BRC did on behalf of the Insurance Institute for Property Loss Reduction.

Why do I have a favorite reference for burst pipes? I used to get hired by insurance companies to investigate burst pipes and the subsequent damage in high-end residences. When the pipe failed in a heated area, it was nice to have this paper to back up my explanation of how freezing in one part of a pipe can lead to failure in another. Also, the report is quite easy to read. There’s not a lot of jargon, and you don’t need much scientific or engineering background to understand it.

Here’s Figure 15 from the report, which graphs the data collected during the testing of a 3/4″ copper pipe running through an unheated attic. The pipe was instrumented with thermocouples to capture its temperature at three locations and a pressure gauge to capture the water pressure inside it. The red annotations are mine. As you can see, the pressure rose to about 4,000 psi, at which point the pipe bulged—that’s the drop in pressure as the pipe increased in diameter and decreased in wall thickness—and then burst.

The best explanation of what happened in the test—and what commonly happens in real-world pipe bursts—comes from the report itself:

This shows the central, and often least understood, fact about burst water pipes: freezing water pipes do not burst directly from physical pressure applied by growing ice, but from excessive water pressure. Before a complete ice blockage, the fact that water is freezing within a pipe does not, by itself, endanger the pipe. When a pipe is still open to the water system upstream, ice growth exerts no pressure on the pipe because the volumetric expansion caused by freezing is absorbed by the larger water system. A pipe that is open on one end cannot be pressurized, and thus will not burst.

Once ice growth forms a complete blockage in a water pipe the situation changes dramatically. The downstream portion of the pipe, between the ice blockage and a closed outlet (faucet, shower, etc.) is now a confined pipe section. A pipe section that is closed on both ends can be dramatically pressurized, water being an essentially incompressible fluid. If ice continues to form in the confined pipe section, the volumetric expansion from freezing results in rapidly increasing water pressure between the blockage and the closed outlet. As figure 15 shows, the water pressure in a confined pipe section can build to thousands of pounds per square inch.

Read that second paragraph again. It’s really a perfect explanation of how, for example, a pipe or joint under a bathroom sink can fail even though that part of the pipe was never exposed to freezing temperatures. It’s the ice buildup in the pipe elsewhere—typically in an unheated area on the other side of the drywall—and the continued growth of ice in the isolated zone between that blockage and the faucet at the sink that leads to a huge increase in pressure. The pipe will fail at whatever point is weakest within that zone.

Which leads to some common advice given when temperatures are going to drop.

• For sinks up against an outside wall, leave the cabinet doors open so the warm air of the house gets a chance to circulate around the pipes. You want them to get as much exposure to warm air as possible so they can conduct that heat to the colder parts on the other side of the drywall.
• Open faucets that are against an outside wall and let them drip. I’ve never done this because I added extra insulation around and on the cold side of my pipes many years ago, but it can help. Not, as some people say, because moving water doesn’t freeze (have they never seen a river frozen over?) but because a slightly open valve prevents the buildup of pressure shown in Figure 15. As the report says, “A pipe that is open on one end cannot be pressurized, and thus will not burst.”