Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Look up macOS system binaries

macosbin.com

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Look up macOS system binaries

#21

Post by qalmakka »

WesolyKubeczek wrote: post #14
qalmakka wrote: post #10

Earlier quoted context omitted.

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

It really depends, though. On rolling releases such as Arch Linux it's basically the latest version most of the time, so you can often just roll with it and get stuff done. On Debian and the like, absolutely, you shouldn't be using the system wide interpreters

Re: Look up macOS system binaries

#22

Post by delta_p_delta_x »

qalmakka wrote: 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…

> also apparently illogical but standardised hierarchy of Linux and the BSDs

Hmm.

  /usr/bin
  /usr/sbin
  /bin
  /opt/bin
  ~/bin
  ~/.local/share/bin
  ~/opt/bin

  /include 
  /lib/include
  /usr/include
  /usr/lib/include
  /usr/lib/clang/include
And many more. Some directories are symlinks to another. Some of these directories do not exist on some distributions.

Why are Linux people always so misguided and haughty?

Re: Look up macOS system binaries

#23

Post by qalmakka »

delta_p_delta_x wrote: post #22
qalmakka wrote: 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…

> also apparently illogical but standardised hierarchy of Linux and the BSDs Hmm. /usr/bin /usr/sbin /bin /opt/bin ~/bin ~/.local/share/bin ~/opt/bin /include /lib/include /usr/include /usr/lib/include /usr/lib/clang/include And many more. Some directories are symlinks to another. Some of these directories do not exist on some distributions. Why are Linux people always so misguided and haughty?

What's so hard to understand about "apparently illogical but standardised"? I never said it was beautiful, I said that despite being dumb [^1] at least there is a standard for it (https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html). So yeah here are nonsensical directories like /opt, but at least they have a clear purpose, compared to the "well who cares, chuck it in there" approach NeXT/Apple had when tossing stuff around (sure, they've now "improved" that with SIP nowadays, but it's still a mess IMHO)

[1]: for instance, "usr" contains libraries only due to the first PDP7 at bell labs having two disks, the first mounted as /, the second as /usr (user). When they ran out of space under /, they replicated the filesystem structure in their user disk, thus the birth of /usr/bin and the like. When /usr got too cluttered they created /home (or /usr/home, don't recall which)

Re: Look up macOS system binaries

#24

Post by qalmakka »

pjmlp wrote: post #19
qalmakka wrote: 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…

But at least there's a standard that specifies what the directories are supposed to mean: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

I won't argue with your point because you are right, I was arguing that at least Linux and the BSDs, despite their stupid hierarchy, at least have standards that assign those directories specific functions. This is in stark opposition with Windows and macOS, where across the years stuff has been chucked basically everywhere (especially on Windows, which is the worst offender in this regard) without a lot of care about what was being put where. On macOS you can find binaries inside frameworks, stuff in /usr/bin, stuff in /sbin, stuff under System, ... and for quite a long time there really wasn't any apparent logic behind it except that it was the most convenient place to put it, similarly on Windows where some 64-bit programs chuck stuff in the 32-bit program application directory just because

Re: Look up macOS system binaries

#25

Post by pjmlp »

qalmakka wrote: post #24
pjmlp wrote: post #19

Earlier quoted context omitted.

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…

But at least there's a standard that specifies what the directories are supposed to mean: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html I won't argue with your point because you are right, I was arguing that at least Linux and the BSDs, despite their stupid hierarchy, at least have standards that assign those directories specific functions. This is in stark opposition with Windows and macOS, where acros…

Those "standards" are followed upon various Linux distributions with some degree of flexibility in what they actually mean.
Post reply on HN