I will say, I don't love the use of LLMs to write these bug reports. It's probably fine if reviewed, but at least review for things like "worked on macOS 25", which obviously didn't exist. If that wasn't caught, how sure are you that the rest of the report is accurate? We all want the bugs fixed, but people are going to start throwing out the obviously LLM written reports rather than have to validate each claim, since the author probably didn't.
- Reference Presets no longer allow setting arbitrary SDR nits, making it impossible to natively unlock 1600nits of brightness on MacBook Pros or 2000nits on Studio Display XDR which breaks my Lunar app [0] (this seems to be intended, no idea what hurt Apple that they had to block this under SIP)
- The orange microphone dot indicator and its very colored friends can no longer have their brightness changed for dimming them, which made my YellowDot app useless [1] (I guess this is for privacy, I still think this could have a setting guarded under TouchID like Accessibility Permissions works)
- Floating non-titled windows don't accept mouse events (thankfully this got fixed) [2]
- Gamma table changes don't work on MacBook Neo and M5 Pro/Max which breaks Sub-zero Dimming and dimming external monitors that don't support DDC (thankfully, Apple is looking into it) [3]
- The resizing area thing on very rounded windows which drives everyone nuts, I had to add custom resize handlers to some of my windows
- The `com.apple.SwiftUI.Drag-` temporary file paths that get generated for any file that gets dragged from a drag&drop handler which makes it impossible to get to the original file when dragging images from Clop [4] or file shelf apps like Yoink, Dropover etc.
- NSImage returning different pixel count for .size than what the image actually has, breaking workflows that depended on that to determine the image DPI
[1] https://github.com/FuzzyIdeas/YellowDot/issues/18
[2] https://developer.apple.com/forums//thread/814798
But that only really helps you when you're dealing with websites in a browser, and when you want the address to resolve back to your local machine. So it wont help you with other programs like python/wget/etc or any calls you make to getaddrinfo()
I set that up in like 2014? Even back then it was known already that the quick /etc/resolver way was the deprecated way to do things. So I guess they finally killed that feature off?
The proper (more awkward) way is to use scutil directly (which then stores the settings in some binary plist somewhere, I assume).
Maybe try this and see if it still works afterwards?
Ignoring the current Tahoe mess, MacOS felt relatively polished. I'm purely talking about UX here, as the OS is evidently buggy. The most popular Gnome themes are a re-impl of MacOS, so I can't be the only one.
It makes you wonder why they were messing around in these areas at all at this point.
I suppose I'm lazy - I've always used /etc/hosts, but then again, I've never had use cases like those mentioned in the linked gist.
Programs like LittleSnitch never really seem like "enough" for me, because the computer has to boot before DNS filtering comes online. It also has the design error (IMHO) of pre-resolving IP addresses before clicking Accept/Deny(all).
A great blockrule for your personal firewalls would be to ban (at top level) icloud.com, apple.com, &c; system updates can then be performed manually using guides like <http://www.mrmacintosh.com>. Of course: this breaks everything (in exactly the way I prefer to compute).
https://github.com/apple/container/issues?q=is%3Aissue%20sta...
Thank you for the heads up.
Next question: what reason would Apple have to make a change that would interfere with developers using their operating system?
There's a game I play (Old School Runescape) that does network ticks every .6s. Mac does some sort of aggressive optimization on the network hardware/software, so network this infrequent doesn't keep the layers "hot", and you end up getting delayed ticks regularly, meaning you learn what should be happening in the game .2-.5s late. This optimization for (I assume) battery life makes the software not work as intended.
Playing anything that streams, like video, or triggering TCP connections (e.g. curl) at a more frequent clip while the game is running fixes the problem.
No way other than hacks that I've found to fix it, and I have no idea how you could report this to the right team at Apple to get it actually fixed.
All Feedbacks that you file are private to your own Apple Account.
New-UnboundInterface.sh - linux/rhel-like specific
# create a bridge interface for Unbound
# because Docker...
IFTYPE=bridge
IFNAME=unbound0
IPADDR=10.53.0.1
IPADDR6=fd53:fd53:fd53::1
nmcli connection add type $IFTYPE ifname $IFNAME
nmcli connection modify $IFTYPE-$IFNAME ip4 $IPADDR/32
nmcli connection modify $IFTYPE-$IFNAME ipv4.dns $IPADDR
nmcli connection modify $IFTYPE-$IFNAME ip6 $IPADDR6/64
nmcli connection modify $IFTYPE-$IFNAME ipv6.dns $IPADDR6
nmcli connection up $IFTYPE-$IFNAME
firewall-cmd --new-zone=unbound --permanent
firewall-cmd --zone=unbound --permanent --change-interface=$IFNAME
firewall-cmd --zone=unbound --permanent --add-service=dns
firewall-cmd --reload
00-localinterface.conf # should be placed in /etc/unbound/conf.d
# bind to a specified IP address, allow access
server:
interface: 10.53.0.1
interface: fd53:fd53:fd53::1
access-control: 10.53.0.1/32 allow
access-control: fd53:fd53:fd53::1/128 allow
91-allow-docker-containers.conf # allow queries from the Docker "bridge"
server:
access-control: 172.18.0.1/16 allowWait, it does that (from 15 to 26) without user interaction?
Here’s a GitHub comment showing someone on MacOS 26 with a `.test` domain, which you claim is broken: https://github.com/apple/container/issues/856#issuecomment-3... —- maybe you are configuring it incorrectly.
The whole macOS thing is amateur