Did you know you can activate Touch ID (or some other biometric) support to authenticate sudo commands on your command line, in a way that survives operating system updates?
All you need to do is copy & modify a single file:
cd /etc/pam.d
sudo cp sudo_local.template sudo_local
sudo nano sudo_local
And it should look like this when you are done:
# sudo_local: local config file which survives system update and is included for sudo
# uncomment following line to enable Touch ID for sudo
auth sufficient pam_tid.so
The way I see it, manually typing passwords isn’t just annoying; it’s an error-prone attack vector for key-logging and yet-another-barrier to productivity. To make software more secure, the best security stuff needs to be the most convenient option by default; this is one-of-many small steps towards that.
In general… weird things happen to Apple devices when the network services they depend on (to quickly communicate between each other on your network) are disabled, out-of-date, or in any kind of corrupt or malformed state (which it almost always is).
You want to sign in to your routers Admin GUI, and look for the following:
Something like: “Multicast”, “mDNS”, “Multicast DNS” or equivalent. Make sure this is not off or disabled. The intended purpose of mDNS is for your router to act as a “zero-configuration” resolver for the hostnames & IP addresses on your network, and its what Apple/AirPlay/AirPrint/AirDrop/HomeKit/etc… use to route their many-to-many device relationships – I.E. every iPhone to any other iPhone/HomePod/TV/etc… You may only be able to toggle in on/off, or you may have a select/radio-button option to pick some specific thing. Use your best judgement, or reply here if unsure.
Something like: “IGMP Snooping” or equivalent. Make sure this is not disabled. The intended purpose of IGMP is to have your router monitor your LAN traffic and route mDNS streams & requests directly between registered clients, rather than have those clients chatter back & forth on the entire network. Probably on/off, and should not give you multiple options. Reply if unsure.
Somehow confirm nothing is reserving or using “.local” for their own routing on your network. mDNS uses “.local” exclusively to alias the names of devices on your network that have advertised that they prefer to communicate that way. If you’ve reserved it manually, or some development environment (Valet, MAMP, etc…) has, this is a problem that needs fixing.
Make sure all wireless TVs & HomePods have excellent wifi signals. Not just good or acceptable; excellent. For every 1db lost from “full” signal strength, expect 2x data packets to be retried exponentially. Give them a clear line-of-sight – no obstructions, walls, plants, chairs, tables, etc… Everything between them will cause attenuation & signal degradation, resulting in dropped data packets & weird behaviors.
Restart everything, doing the router last. DHCP reservations (IP reassignments) rotate unless they are pinned or assigned manually. Usually, restarting a device will force it to reconcile its network assignments, including IP addresses, hostnames, and mDNS by association.
Sometimes (and this is my experience) if you have multiple “home hubs” like you do (TVs, HomePods, etc…) one of them has a tendency to work better than the others. For me, when one specific Apple TV is the “active” HomeKit hub, everything is fine, but any other hub causes all of my automations to never fully finish. I am convinced this is an Apple bug with their own on-device mDNS caches, but haven’t dug into it.
I recently noticed that animations in Safari were stuttering pretty badly on my M1 powered 2020 MacBook Air, and dove in to figure out why.
I’m a web developer, so I went to work writing a small bit of vanilla JavaScript to monitor requestAnimationFrame which is the API that the window object uses to “paint” its contents to the screen. (I did a ton of research to make sure, and it’s pretty neat.)
Both Chrome and Firefox were showing 60 frames per second as expected, but Safari was only showing as 30. 🧐
Isn’t Safari… like… supposed to be better? Something something own-the-stack? Meow meow top-down-integration, King Friday? 👑
I was pretty confused by Safari being worse here, so I tweaked my JavaScript a bunch, searched the web for clues, and walked away from the problem for a few days, but didn’t learn anything helpful or have any epiphanies.
Then one random Tuesday, Safari started running at 60fps again. Huh. Hmm.
I restarted. I opened & closed a variety of different apps. I closed a bunch of tabs everywhere. I updated all-of-the-things.
I couldn’t make Safari slow again even when I tried.
It made no sense. But hey… it’s fixed. Yay.
The next morning I started worky mcworkface and Safari was back down to 30fps.
GAH! OK. OK. OK.
“What variables changed” I thought – “What did I do differently?”
I was on battery power when it was 30. I was plugged in when it was 60.
System Preferences > Battery > Battery > Low power mode
Urkel mode
By default, macOS Monterey enables “Low power mode” on Battery power and disables it when using a Power Adapter. Safari, it seems, is programmed to interpret this setting to mean that it should reduce the number of times it paints to the screen to prolong battery life.
On my MacBook Air, that means from 60fps to 30fps. What does it mean on a 2021 MacBook Pro with ProMotion, at 120fps?
Unclear… because I don’t own one, yet… but my thinking is: folks noticing stuttering in Safari on their beefy new machines are seeing this happen how I just did, and if they disable Low power mode it will jump back up to 120fps.
The built-in display on my MacBook Air does not have a variable refresh rate. I’m not sure what it tops out at because Apple goes to great lengths to hide this information these days, but my guess is it’s running at around 60hz.
My final theories about Safari stuttering on 2021 MacBooks with 120hz ProMotion displays, is that the requestAnimationFrame API might be dropping all the way down to 10fps to match the 10hz floor of ProMotion – or it may not be perfectly synced up with the refresh rate, resulting in a sort of double-jitter problem.
If the API slows down to 10fps but the display ramps up from 10hz to 60hz, you’d certainly feel like Safari was not performing very well, especially compared to Chrome & Firefox that never slow down.
