Live data from Hacker News

Look up macOS system binaries

macosbin.com

11–20 of 25 posts

Re: Look up macOS system binaries

#11
post #9

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 t…

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.

Re: Look up macOS system binaries

#13
post #11
post #9

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 t…

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".

Re: Look up macOS system binaries

#14
post #2

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…

> 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…

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.

Re: Look up macOS system binaries

#15
post #7
post #2

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…

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…

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.

Re: Look up macOS system binaries

#16
post #11

Earlier quoted context omitted.

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 b…

When available I prefer installing applications via brew as casks, since at least this way if I decide to uninstall it later brew will take care of deleting all of these associated directories. I remember using an app called AppZapper several years ago which did this but for arbitrary applications. No idea if it’s still around/maintained.

Re: Look up macOS system binaries

#17

Earlier quoted context omitted.

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 b…

When available I prefer installing applications via brew as casks, since at least this way if I decide to uninstall it later brew will take care of deleting all of these associated directories. I remember using an app called AppZapper several years ago which did this but for arbitrary applications. No idea if it’s still around/maintained.

There's `brew uninstall --zap $application`[1], and there's pretty decent coverage, but it's by no means comprehensive. If you feel inclined to contribute, the process is quite streamlined, and there's a helper script[2].

I used Appcleaner[3] for many years, and it's still perfectly serviceable

I'm keeping my eye on Pearcleaner[4], which is additionally open-source and written in Swift.

[1] https://docs.brew.sh/Cask-Cookbook#stanza-zap

[2] https://github.com/nrlquaker/homebrew-createzap

[3] https://freemacsoft.net/appcleaner/

[4] https://itsalin.com/appInfo/?id=pearcleaner

Re: Look up macOS system binaries

#18

Earlier quoted context omitted.

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 b…

When available I prefer installing applications via brew as casks, since at least this way if I decide to uninstall it later brew will take care of deleting all of these associated directories. I remember using an app called AppZapper several years ago which did this but for arbitrary applications. No idea if it’s still around/maintained.

Appcleaner does this. One of first installs on a fresh macos.

Re: Look up macOS system binaries

#19
post #9

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 t…

It isn't as if UNIX is any piece of fine art in filesystems design, especially clear to everyone that has used multiple commercial UNIXes.

People should stop worshiping UNIX System V, while ignoring the chaos that came later with the explosion of UNIX clones.

There is a reason why the UNIX authors then went on designing Plan 9, followed by Inferno, while trying to fix what they percevied as design flaws in UNIX, from filesytem, security model, process execution model, and userspace languages.

Re: Look up macOS system binaries

#20
post #9

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 t…

> The only "fixed" file should be /usr/bin/env, all the rest should be in /System

Modern macOS separates things that are protected by System Integrity Protection and are unalterable (checksummed) in /System. Everything else, including user-customizable system components go in /Library.

Modern macOS file structure is highly organized and easy to reason about if you have even a beginner’s understanding of its security implementation.

Post reply on HN