A less complicated complication
March 29, 2026 at 10:42 AM by Dr. Drang
Back in January, I complained about the Apple Watch’s Timer complication being too complicated. A couple of days ago, Dan Moren told me on Mastodon that my complaint had been addressed in watchOS 26.4, which was released earlier this week. After a surprisingly quick update of my watch (I had already updated every other device to 26.4 but somehow forgot to do the watch), I added a 3-minute timer as the bottom center complication and, miracle of miracles, it worked exactly as it should.
To recap, my January complaint was that although I could create a complication that looked like it would start a 30-second timer when tapped, that complication actually required a second tap on a smaller button to start it—a stupid way to implement the feature. As of 26.4, the stupidity has been removed. Now the timer starts immediately when you tap the complication.
If you’d like a quick way to set a specific timer on your watch, press and hold on your watch’s home screen, tap the Edit button, and then swipe (if necessary) to get to the complications screen. Tap the complication you want to change to a Timer, scroll through the list, and choose Timers. At this point, you will be given the option to choose either a generic timer complication—one that just opens the Timers app—or one set to one of the specific times you’ve created in the Timers app.
Choose the one you want and go back to your home screen. Now you have a specific timer complication that works the way it should.
(Aside: I wanted a 30-second timer in January because I was doing physical therapy stretching exercises then that were supposed to be held for 30 seconds. I’m not doing those exercises anymore, so I made a 3-minute timer for tea.)
Thanks to Dan for telling me about this. I had given up on this type of complication and wouldn’t have thought to look for the improvement.
Another improvement in 26.4—one that’s sort of mentioned in the release notes—is that you no longer have to tap the small arrow button to start a workout. You can also tap anywhere in the big area around the exercise icon above the three bottom buttons on the Workouts screen. And you don’t have to wait for the arrow button to slowly animate into view.
I bitched about the previous behavior—prompted by a Greg Pierce complaint—in December. It’s almost as if Apple is listening now.
Are you a mod or a rocker?
March 27, 2026 at 6:07 PM by Dr. Drang
I’ve been working my way slowly through Reingold and Dershowitz’s Calendrical Calculations. This week I hit Chapter 11 on the Mayan and Aztec calendars and came across a notation for modulo arithmetic that wasn’t familiar to me.1 I figured I’d write about it here on the off-chance that any of you would find it interesting. Also, to make it stick in my head a little better.
The notation came up in the section on the Haab calendar, a sort of solar calendar that the Mayans used along with the Tzolk’in and Long Count calendars. The Haab calendar has 18 months of 20 days each and then a 19th sort-of-month with just 5 days. There’s no year number in the Haab calendar, so there’s no way to convert directly from the Haab calendar to other calendars. But there is a way to get a date in another calendar that’s on or nearest before a given Haab date.
Reingold and Dershowitz use a “fixed” or “RD” calendar as their way station between all the calendars. It’s a single day number that counts up from what would have been January 1 of the Year 1 in the Gregorian calendar if the Gregorian calendar had existed back then. In this system, 0001-01-01 is Day 1 and today, 2026-03-27, is Day 739,702.
The function that finds the closest given Haab date on or before a given fixed date is called mayan-haab-on-or-before, and it’s defined this way in the text:
What’s odd about the modulo notation in this definition is that the thing after “mod” isn’t a divisor, it’s an interval: the half-open interval between date (inclusive) and date – 365 (exclusive).
Here’s how R&D define this interval modulus, both in Chapter 1 of Calendrical Calculations and in this ACM paper:
As long as the two ends of the interval aren’t identical, the answer will lie in the range . This notation is helpful in shifted modulo operations like the one in mayan-haab-on-or-before because it explicitly tells you the range of answers you’ll get. The idea is that the resulting fixed date will be anywhere from 0 (inclusive) to 365 (exclusive) days before the given date.
(The normal modulo notation, , could be written as , although this doesn’t seem particularly helpful.)
Note that in mayan-haab-on-or-before, the interval goes backward, which means the divisor in the standard mod function is a negative number: –365. If you’re implementing this function in a programming language, you have to make sure that using a negative divisor in your language’s mod will give you a negative answer. This means that mod must have a floored definition. The mod function in Lisp, which R&D are using, and the % operator in Python, which I’m using as I reimplement R&D, both use the floored definition.
I mentioned earlier that the 19th month of the Haab calendar is an oddball because it has only 5 days. As it happens, today is smack in the middle of that 19th month, which is called Wayeb or Uayeb, depending on whose transliteration you use.
Another odd thing about the Haab calendar—something that computer programmers must love—is that the day numbers within a month start at 0, not 1. So Monday, which is the start of the next Haab cycle, will be 0 Pop, Pop being the name of the first Haab month.
-
It would have been familiar if I’d read Chapter 1 carefully instead of skimming, but I was eager to get past the preliminaries quickly and figured I could always go back to Chapter 1 if necessary. Which it was. ↩
Saving us from ourselves?
March 26, 2026 at 4:06 PM by Dr. Drang
You may have seen this article by Joe Rossignol in MacRumors yesterday. It’s about a new feature in macOS 26.4 that’s designed to keep us from pasting dangerous commands in Terminal. If a user pastes such a command, this warning pops up:
Near the end of the article, Rossignol says
We have yet to determine exactly which commands trigger the warning, which does not always appear.
I updated to 26.4 today and tried to trigger the warning. Since rm -rf is generally considered dangerous, I created some files I could try it out on.
Here are the commands I used in Terminal to create five new files, named test1.txt through test5.txt, in a folder named test and fill them with some nonsense text:
$ mkdir test
$ touch test/test{1..5}.txt
$ pbcopy <<END
> Same continent also, pre-occupation has probably played a more marked
influence; thus I can understand how it may be said, to be striving to the
feral animals of South America) the black bear was seen by Hearne swimming
for hours with widely open through an internal force beyond the other
completed cells. It must suffice for our profound ignorance on the variations
which have been.
> END
$ for f in test/*; do pbpaste >> $f; done
The nonsense text in the here-document was generated on the fly using my Dissociated Darwin script. I used to call it via TextExpander; now it’s called via Typinator, but the process is the same.
I then created a simple HTML file with the command rm -rf test in its body and uploaded it to my server. Since websites were mentioned in the warning as a source of dangerous commands, I figured copying the command from an external site would be the most likely way to trigger the warning.
I aimed Safari at the file’s URL, copied the command, switched back to Terminal, and pasted. No warning popped up, and I was able to execute the pasted command and delete the folder and files with no trouble.
OK, let’s try something a little more convoluted. After recreating the test folder and files, I made a file named dangerous.txt and put it on my server. Its contents were simply rm -rf test. I then added this command to the HTML file described above:
curl https://leancrew.com/dangerous/dangerous.txt | bash
Surely, I thought, a command that pipes the contents of some random file on the internet into bash for execution would be worth warning about. Nope. I copied the curl command from Safari, pasted it into Terminal, and hit Return. No warning from macOS and my test folder and files disappeared again.
My feelings about this have gone from “I hope Apple doesn’t make it impossible for me to work the way I normally do” to “Looks like Apple isn’t going overboard on the protection” to “Is there any protection here at all?”
Maybe there’s some setting on my system I changed long ago that’s now bypassing the warning. If so, I’d like to know what it is. Or maybe I just haven’t hit a high enough danger level yet. Which seems wrong.
Hardware vs. software
March 19, 2026 at 1:28 PM by Dr. Drang
I’ve been thinking about the new Apple Studio Display lately, mainly in the context of Jason Snell’s review of it on Six Colors and his further discussion with Myke Hurley on Upgrade.
Jason’s primary complaint about the Studio Display isn’t its high price or how little it’s improved over the 2022 version. It’s that the base stand—the one you get for $1600—has no height adjustment. To get the ergonomic benefit of height adjustment, you need to buy either the VESA mount adapter (and an arm if you don’t already have one) or the exquisite height-adjustable stand, which is a $400 addition.
It’s hard to argue with Jason when he says this:
Apple claims it’s a champion of accessibility. But in my opinion, part of accessibility is ergonomics. Different people need displays at different heights, and we are all shaped differently. Apple’s continued insistence on shipping displays and iMacs that aren’t height-adjustable by default is frustrating. You spend all this money on a pricey Apple display and then, what, put it on an old dictionary? Meanwhile, even the cut-rate competition offers height adjustments.
The “old dictionary” comment reminded me that in the days of CRT monitors, I—and many of the people I worked with—used the CRC Handbook of Chemistry and Physics to bring our monitors up to the proper height. We all agreed it was the best use we’d ever gotten out of that book.
And that experience my friends and I had with the CRC Handbook points to an important fact about monitor height adjustment: for most people, it’s a set-it-and-forget-it feature. You get your monitor to a height that works well with your desk setup, and you don’t change it for ages. The smooth fingertip control Apple provides with its upgraded stand—while undoubtedly useful for some—isn’t the kind of ergonomic help that most customers need.
What Apple’s doing here is the opposite of what it does on the software side. Most Apple apps are built to be good enough for the great bulk of its users. People who need more—in a calendar, a mail client, a to-do manager, a spreadsheet, a word processor, and so on—go to third-party apps to get those extra features.
This has served both Apple and its customers well. Even those of us who consider ourselves power users aren’t power users across the whole gamut of computing. We use a mix of basic and advanced apps to match our needs. Apple doesn’t have to stay on the cutting edge of all its many software products, and we get free apps that handle a lot of what we do.
Maybe Apple thinks its basic stand has been designed to hit that sweet spot for the vast majority of its users. Maybe they’ve spent considerable time and money on studies of desks and chairs and torsos and have come up with a single monitor height that’s “just fine.” I hope not, because that money would’ve been better spent on a simpler and less beautiful height-adjustable stand.