For example the XPC endpoints the binary offers and a list of other binaries which reference those.
Maybe the launch modalities, system vs. User session, which paths it reads/writes.
Not sure if all of those things can be staically determined by some tooling, but it would be really helpful.
Automator Installer -> /System/Library/CoreServices/Automator Installer.app/Contents/MacOS/Automator Installer
"There is no exact information for this binary file."
webdavfs_agent -> /System/Library/Extensions/webdav_fs.kext/Contents/Resources/webdavfs_agent
"The webdavfs_agent binary is unknown"
Also, the dread of "removal instructions" that include stuff like "go through these directories and delete things that look like they belong to this software".
evolve2k•8h ago
https://macosbin.com/bin/ruby
Younger me loved that Apple used Ruby and that Ruby was “pre installed” on the Mac.
This of course was because macOS relies on Ruby for certain things. However as a more experienced dev, the system Ruby (which is almost always very outdated), really gets in the way especially for beginners.
Anyone have more background on system Ruby and why it’s in macOS?
lloeki•4h ago
Today on Tahoe, this is what remains:
One can note the irony of the most up to date of those being Perl, probably a testament to its insane backwards compatibility.WesolyKubeczek•3m ago
I'm wondering what in the world is the system using DBIx::Class for.
qalmakka•3h ago
This also applies to Perl and especially Python. While relying on system Perl is bad but not terrible (Perl is very backward compatible, has good versioning of features, ...), I always have to fight against Mac users that keep using the outdated system Python instead of pulling a new one from Brew. Don't use the system interpreters folks! This is not Linux
WesolyKubeczek•6m ago