Looks pretty much abandoned. First thing I looked for was jq (added in Sequoia) but it isn’t there. Then I looked at the repo. All commit activity was during the same week, three years ago. A couple issues opened, with no progress.
One thing that always grinds my gears is how the macOS filesystem is a hodgepodge of stuff thrown around without any apparent logic (similarly to Windows), which is in stark contrast to the also apparently illogical but standardised hierarchy of Linux and the BSDs. I do understand their need to keep the /System directory around for the Classic days, but /usr? /sbin? The only "fixed" file should be /usr/bin/env, all the rest should be in /System. The mix of classic UNIX directories and Classic is annoying
On the other hand, their /Applications directory is genius. No need for databases to track which files belong to which application. Everything belonging to an application resides in its subdirectory of /Applications. Installing and removing software becomes incredibly simple.
Except stuff in /Library/Application Support. Oh, and /Library/Extensions. Oh, and /Library/DriverExtensions. Oh, and /Library/LaunchAgents. And /Library/LaunchDaemons. Also /Library/Perl (this is Apple-provided) and /Library/TeX (this is not, this is MacTeX). And /Library/Developer.
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".
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?
> the system Ruby (which is almost always very outdated), really gets in the way
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
The advice applies to Linux, too. The interpreter that "comes with the system" is usually there to accommodate other software within the distribution that is powered by that interpreter, and it's not guaranteed to stay where it is as you like it, or update when you want it updated, because there might be an application keeping it from getting updated.
Back then macOS as a platform was quite polyglot with multiple scripting languages and bindings/bridges to ObjC. Being an OOTB dev box was a feature, notably with Web 2.0, and there was Rails right there as well as Apache too, and a thing called Mac OS X Server. IIRC they even had Java in there, with WebObjects, until the Oracle debacle.
Today on Tahoe, this is what remains:
$ uname -sr
Darwin 25.0.0
$ /usr/bin/ruby --version
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin25]
$ /usr/bin/bundle --version
Bundler version 1.17.2
$ /usr/bin/gem --version
3.0.3.1
$ /usr/bin/rails
Rails is not currently installed on this system. To get the latest version, simply type:
$ sudo gem install rails
You can then rerun your "rails" command.
$ perl -v
This is perl 5, version 34, subversion 1 (v5.34.1) built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
$ python3 --version
Python 3.9.6
One can note the irony of the most up to date of those being Perl, probably a testament to its insane backwards compatibility.
Looks pretty much abandoned. First thing I looked for was jq (added in Sequoia) but it isn’t there. Then I looked at the repo. All commit activity was during the same week, three years ago. A couple issues opened, with no progress.
One thing that always grinds my gears is how the macOS filesystem is a hodgepodge of stuff thrown around without any apparent logic (similarly to Windows), which is in stark contrast to the also apparently illogical but standardised hierarchy of Linux and the BSDs. I do understand their need to keep the /System directory around for the Classic days, but /usr? /sbin? The only "fixed" file should be /usr/bin/env, all the rest should be in /System. The mix of classic UNIX directories and Classic is annoying
On the other hand, their /Applications directory is genius. No need for databases to track which files belong to which application. Everything belonging to an application resides in its subdirectory of /Applications. Installing and removing software becomes incredibly simple.
Except stuff in /Library/Application Support. Oh, and /Library/Extensions. Oh, and /Library/DriverExtensions. Oh, and /Library/LaunchAgents. And /Library/LaunchDaemons. Also /Library/Perl (this is Apple-provided) and /Library/TeX (this is not, this is MacTeX). And /Library/Developer.
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".
I'd love to see some deeper automated analysis.
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.
Basically, links to virustotal and results of running in their sandboxes.
Would it be possible to list all binaries alphabetically on one page?
It seems to work for most stuff in /usr/{,s}bin /{,s}bin /usr/libexec but not all of /System/Library just yet.
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"
Pretty cool tool, I used it to lookup system ruby.
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?
> the system Ruby (which is almost always very outdated), really gets in the way
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
The advice applies to Linux, too. The interpreter that "comes with the system" is usually there to accommodate other software within the distribution that is powered by that interpreter, and it's not guaranteed to stay where it is as you like it, or update when you want it updated, because there might be an application keeping it from getting updated.
Back then macOS as a platform was quite polyglot with multiple scripting languages and bindings/bridges to ObjC. Being an OOTB dev box was a feature, notably with Web 2.0, and there was Rails right there as well as Apache too, and a thing called Mac OS X Server. IIRC they even had Java in there, with WebObjects, until the Oracle debacle.
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.The most insane thing of them all insane things is that that Perl ships with DBIx::Class — in /System/Library/Perl/5.34, no less!
I'm wondering what in the world is the system using DBIx::Class for.