See also yesterday's "Apple’s built-in macOS firewall breaks third-party firewalls" https://obdev.at/blog/apples-built-in-macos-firewall-breaks-...
replies(4):
Process 310: 314990 leaks for 967643488 total leaked bytes.
Ouch!
I remember back in the day when installing two firewalls or two antivirus programs on Windows would break it, so it will have to be reinstalled. That was 20 years ago, though, one would think we're better at making an OS by now.
Instead, human systems require eternal vigilance from the humans inside it. Even governmental systems which can encode knowledge into laws rely on the eternal vigilance of judges, prosecutors, and defenders to utilize that knowledge.
So GGz if you're writing a new subsystem in an OS and you're expected to learn from mistakes a team of two people made in some subsystem 20 years ago that someone quietly patched.
The suite would run the most-used apps and utilities against updates and report regressions.
So for example, the vast majority of apps on my Mac can't run, because they were written for early versions of OS X and OS 9, even all the way back to System 7 when apps were expected to still run on 4/5/6. The suite would reveal that Apple has a track record of de-prioritizing backwards compatibility or backporting bug fixes to previous OS versions.
Edit: integration test suite
Process 43619: 2194911 leaks for 6742615664 total leaked bytes.
jesus.
The trouble is, Apple’s feedback process is so opaque that we can never know the details. All we have is the feeling of “a simple test of macOS with a third party firewall before unleashing it to the world would have shown the problem”.
For a piece of software on which countless people rely upon (which macOS and iOS are), the “beta” begins after exhausting all internal means of detecting regressions and unwanted behaviour. It’s not cheap but they can’t just dump something and expect unpaid, third party developers to report all the bugs (while never getting a reply on that feedback app).
However, these days it seems that even point releases only introduce new bugs in the rush to deliver late features, and rarely address any issues
Just as well, although I loathe some of the choices Apple's made over the years, such as it's own Settings app, the overall UI would be pretty recognizable if me from 20 years ago found a time machine (pun intended). I recently bought a new mac, and it occurred to me that it feels basically like the E-Mac I used in middle school all those years ago, albeit with the occasional annoyance I wouldn't have been aware of then.
"See? This is why extensions are bad!"
It's 100% in Apple's culture to do so. They don't even need to do it deliberately --- just ignore the inevitable bugs that appear.
sudo leaks com.objective-see.lulu.extension | grep "total leaked bytes" Password: Process 851 is not debuggable. Due to security restrictions, leaks can only show or save contents of readonly memory of restricted processes.
Process 851: 1086 leaks for 108576 total leaked bytes.
[1] https://devblogs.microsoft.com/oldnewthing/20050824-11/?p=34...
Apple dropping support for old things over time is a reasonable philosophy, but Apple breaking current things unintentionally and then neither fixing nor communicating about it, primarily because they don't actively engage with their ecosystem in general, is a problematic choice on their part.
The cynic in me assumes it's just teams from different silos trampling over each other in a shared code base. Given Apple's obsession with leak prevention they're probably prohibited by NDA from talking to each other.
"Apple also broke many aspects of networking in macOS 15 (Sequoia). Until Apple releases a fix, the solution for now appears to be to disable the macOS firewall."
Presumably doing that would likely also work around the problem for littlesnitch?
The .app icon shows the "circle slash" overlay, however, and attempting to launch it from the Finder (Sequoia 15.1 running on an Intel Mac) yields the OS-level "needs to be updated" alert without actually exec'ing the binary.
The Mach-O executable in "Contents/MacOS" loads and runs successfully when called directly from a shell prompt, however, and displays an application-generated "Some of the application components are missing…Please reinstall…" alert.
Which is actually encouraging, given that I'm attempting to run it directly from the Master Collection .dmg image without actually installing anything, which, given all the prerequisite detritus Adobe apps habitually scatter around the system when installed, I wouldn't expect to work even on a supported OS.
Less encouraging is the fact that the app-generated alert box text is blurry, suggesting the application wouldn't properly support Retina displays even if it could be cajoled into running.
> Less encouraging is the fact that the app-generated alert box text is blurry, suggesting the application wouldn't properly support Retina displays even if it could be cajoled into running.
This was actually the main reason I simply stopped using it (aside from not needing it professionally anymore and Adobe switching to subscription after CS6). CS6 was the last version before laptops started shipping with high dpi screens, and Carbon (from what I understood at the time) was simply the older cocoa UI framework that was replaced as Apple switched to a more versatile SDK. Sibling commentor suggested it was because Carbon was 32-bit only and that seems plausible, I hadn't experimented heavily with Obj-C or Apple dev, but I'm sure the switch was a massive undertaking.
[1] https://www.macrumors.com/2007/06/13/leopard-drops-carbon-64...