Comment by Aurornis
10 hours ago
15.8.2 isn't released.
This is a report from the developer forums where people are supposed to report these bugs.
The second response in the thread is an Apple engineer acknowledging the bug, assigning a number, and asking the person to retest when new builds are available.
If you only read the comments here you'd come away with a completely different impression of what's happening.
That's true, but I'm sorry, telling them to test it themselves every time a new release comes out because "I can't comment on known issues or on whether or when a fix might ship" is just stupid. It's a liability-reducing strategy benefiting only Apple, not a nice way to treat customers.
Also, not having a regression test that catches OpenGL being completely broken on many common hardware configurations seems pretty bad. Yes, OpenGL on macOS is deprecated, but guess what, deprecating it was also stupid. It was a legal decision made by Apple lawyers pursuing a particular litigation strategy vs Nvidia that caused Apple's withdrawal from Khronos group. It wasn't a sound technical decision.
Both of these things make it seem like the lawyers are in charge at Apple rather than the engineers.
TBH, I'm not saying "DTS Engineer" isn't an actual Apple engineer, but it feels very LLM-written. For something like that, I wouldn't want it to guarantee that a fix can or will be done in any sort of timeframe.
I hope it does get fixed, but Apple actually has a bad track-record with another deprecated API, AppleAL (OpenAL). They broke it in a very interesting way in Tahoe where mono-channel audio on Aarch64 (not through Rosetta) did not play and it was broken through all the betas. I believe it actually may still be broken today. The workarounds were either mono-to-faux-stereo channel duplication or switch to openal-soft.
OpenGL is an even bigger deal so I don't see a world where it doesn't get fixed, but I also thought exactly the same way with the previous issue. It seems that Apple does not have any older video games in their testing apparatus.
Some references on the issue:
1. https://github.com/luanti-org/luanti/issues/16499
2. https://support.sega.com/hc/en-us/articles/39540396560145-Ma...
15.8.2 isn't released, but the 15.8.2 release candidate clearly is. I don't think think it's that crazy for people to be at least somewhat concerned that a fairly common important library got broken a bugfix release to a maintenance update that came out a month ago for a major version that came out two years ago without anyone internal testing it before publishing the RC.
> 15.8.2 isn't released, but the 15.8.2 release candidate clearly is
That’s how release candidates work.
The headline could have included RC to make it accurate. As submitted it’s pretty misleading.
They used to make these beta versions private so only ios/macos developers could test on them to report bugs to get them fixed before public release. They since opened it up to anyone who wants to install it which generates a lot of outrage from the peanut gallery when the beta has bugs.
The problem is that this is a well established pattern with this operating system:
- A bug or regression is identified in a beta or release candidate. People quickly come to defend Apple saying it will surely get fixed.
- The bug or regression is released. People quickly come to defend Apple saying it's not a big deal, there are workarounds, and it will probably get fixed.
- The bug or regression is now the status quo. Why are you rehashing old news? Nobody cares, this impacts only 1% of people, you're imagining things, thread locked, user banned, et cetera.
The time to complain loudly and broadly is _before_ the bug or regression becomes the new status quo for the platform.
This sounds more like a story than a real issue. Do you have specific examples you can point to?
MST? https://en.wikipedia.org/wiki/DisplayPort#Multi-Stream_Trans...
1 reply →
Thanks for the context, the state of HN has been quite sad in recent years, now people (hopefully, and not bots) read the title and then go on random anecdotes, dumb generalisations and awkward tangents.
>and awkward tangents
Especially on special internet forums, HN included, bots are generally paid for by professional influence campaigns so..
Yeah..
Whatever those AI's have to do to shape the conversation to get their message in, that's what they'll do. And that's going to sound pretty awkward to human ears.
An Apple engineer acknowledged the bug? That comment reeks strongly of Claude. I have a feeling that somebody did not use their brain and the response is an auto-response by Claude. Also things like attaching a sysdiagnose is useless and is well known to be hoops Apple requires bug reporters to jump through with no benefit to either party.
You also make it sound like the Apple engineer assigned the number but the number was auto-assigned when the bug report was filed. The same number was present in the first post so it could not have been assigned by the Apple engineer.
As far as I can see the Apple engineer did nothing at all. The attitude of that Apple engineer is worse than staying silent on this bug.
> The attitude of that Apple engineer is worse than staying silent on this bug.
The Apple engineer opened the ticket which is how these bugs get prioritized and fixed.
Staying silent or not responding would mean it doesn’t get fixed.
The Apple engineer didn’t open the ticket. The original reporter did. Perhaps actually look at the assigned number before jumping to defend Apple.
2 replies →
> Also things like attaching a sysdiagnose is useless and is well known to be hoops Apple requires bug reporters to jump through with no benefit to either party.
As a former Apple SWE that has read innumerable sysdiagnose reports, this statement is bullshit.
External bug reports very commonly have a variation of "THIS IS BROKEN YOU SUCK FIX THIS" as the main note. Even with a crash log attached that's not at all helpful. A sysdiagnose gives a state of the system the reporter has in front of them. You can't triage a bug with "FIX NOW" as the description.
I know I know, Apple has infinity dollars and every SWE should just magically fix bugs without needing to triage them first. Every external bug reports very is also a special snowflake that deserves concierge VIP serve and a dedicated SWE team to fix.
“Most bug reports are bad” and “most good bug reports aren’t handled well” can both be true.
As a macOS user, my most recent datapoint is a crash in Apple Music that I’ve submitted probably a few dozen crash reports for, along with steps that trivially and consistently reproduce the crash - from my perspective, the crash was introduced in macOS 26 last year, and has received zero attention since then.
Did you read the bug report? This is not your garden variety THIS IS BROKEN YOU SUCK FIX THIS bug. It is respectful, it has a minimal reproducer, and it is communicated clearly. There’s no reason to stall it using the sysdiagnose requirement.
And yes, this is not the first time I’ve seen Apple requiring sysdiagnose for an excellently written report. Even John Siracusa would get these sysdiagnose requests; it’s a stalling tactic being applied indiscriminately.
If Apple cannot distinguish between an angry nontechnical user that SHOUTS IN UPPERCASE and a developer that communicates professionally with an equal, that’s Apple’s problem.
5 replies →