Hacker News Reader

Comment by mistersquid | Hacker News Reader

As a longtime Mac user (as early as System 7) and aficionado of UNIX, I love OS X's CLI and its affordances. The linked article provides several well-packaged tidbits that might encourage users of other CLI-replete OS's to check out OS X.

More power.

However, I'm not a fan of the soft recommendation for Homebrew. I understand Homebrew places everything in `/usr/local` but software installs on Mac should generally conform to dragging and dropping bundles inside `/Applications`.

In my experience, requirements to install packages using Homebrew could be circumvented by searching for .dmg or .pkg equivalents. The benefit is that software so installed is much easier for intermediate users to track and maintain.

View on HN

The /applications folder is for .app bundles; Homebrew mostly installs Unix binaries which are appropriately placed in /usr/local , just like many Apple-supplied binaries are in /usr. The two conventions work well side-by-side.

The vast majority of Homebrew packages are not available as .dmg or .pkg ; installing that way also is a huge PITA when dealing with a myriad of small developer tools that require dependencies, whereas brew manages all of that for you, including upgrades.

Though, wouldn't it be better if all software on Mac used the native package manner? Obviously in an ideal world...

If only the native package manager wasn't write-only for pkg installers. I use Homebrew for its `uninstall` command.

Wow, I had no idea... clearly I don't deploy software to my Mac often enough. NeXT had an uninstall, I assumed that carried over.

The pkg manager does track all the files it installs, so it's a trivial script to go "uninstall" them. Anyway, good reason to stick with Homebrew.

For the few formulas that create an app bundle (Homebrew deliberately avoids GUIs in general), "brew linkapps" symbolically links the bundle to /Applications; similar to the way it links things from /usr/local/Cellar/$formula/$version/bin to /usr/local/bin.

I think MacPorts is a much better tool than Homebrew with way more useful packages. It also installs itself into /opt/local by default so it doesn't conflict with other stuff in /usr/local and for actual OS X or X-Windows apps, it installs them in /Applications. Luckily, they can both live on one system if you're careful, as some people insist on providing only Homebrew copies of their software, which is a bit unfortunate considering that MacPorts is clearly the better system.

I found home-brew much more problematic and more significantly much slower when i last used it (a few years back now).

At this point I've given up on any of these "package managers" for OS X.

I've thought about starting a project (possibly with some support from my company, which focuses on Linux packaging) to provide a) a tool to download and install .pkg files, and b) a toolchain for more easily building .pkg files for the things that aren't available.

And I found Homebrew to be a "much better tool than MacPorts with way more useful packages" which to me is "clearly the better system" :) Been using it for the last 5 years and had many chances to compare both. See, it's all opinionated.

I thought that /usr/local was a widely accepted place on UNIX systems like OS X for user installation of UNIX applications and tools (which are usually command line utilities). /Applications on the other hand is where Mac-specific GUI apps are installed, right? You wouldn't clutter up /Applications with command line utilities like ffmpeg, ImageMagick, wget, youtube-dl, or sox, would you? Isn't this separation done by design?

Without something like Homebrew you don't get any current Unix tools (OSX shell is way out of date) or anyway to systematically update them. This is a big benefit that far outweighs any perceived benefit dropping bundles into /Applications. And you get some attempt at installation of dependencies.

What are current UNIX tools? OS X supports what is expected from a POSIX compliant OS.

I guess you mean BSD and GNU extensions to POSIX.

OS X ships outdated versions of Bash and Git for example. The 10.10.5 version ships Bash 3.2 and Git 2.3, while Homebrew gives you Bash 4.3+ and git 2.5+.

This is the usual mistake young generations do in regard to UNIX, neither bash nor Git are part of UNIX standard.

POSIX IEEE Std 1003.1, 2013 Edition defines sh as the shell.

There is no git in POSIX IEEE Std 1003.1, 2013 Edition.

Virtually every person who uses any modern Linux or OS X system expects bash to be installed and in the modern vernacular it can be completely and safely considered, in informal discussion, to be part of relevant Unixes. You knew exactly what he meant, but for some reason (and I won't speculate but it isn't a good look on you) you decided to be pedantic for the sake of being pedantic. You're not being helpful to anyone or anything and should stop, and you know it.

The majority of people who use Bash on OS X will not be using advanced features.

The people that are likely to use advanced features would also hopefully be aware of Bash's fragility/compatibility issues between minor versions, and thus wouldn't rely on it for anything like shell scripts.

So we're left with people who want to use advanced features and are doing so purely on machines they control.. So what stops them from either compiling their own bash, or using one of the third party package managers to install it?

It shouldn't be the job of a third-party package manager to do this. I want my vendors to stay up to date not just for feature purposes, but for security ones, too. (Remember how long it took Apple to get a Shellshock patch out there?)

But I have less of an interest in that than in discouraging jerkish pedantry.

A Unix derived operating system with a package manager (BSD Ports, Linux debian/apt or rpm) is way more powerful than one without. Half the time I am installing stuff I don't particularly like or want- but that is necessary to complete a project.

hahahaha I see you've never tried to use rsync on a Mac. Some (documented) command line options just DON'T work. They're in the manpage, but they don't do anything. There's lots of other little gotchas in other utils as well, especially when coming from Linux.

I don't like putting homebrew into /usr/local, because many other installers put stuff in there, often incorrectly, and it sort of acts as a bit of a dumping ground. I install to /homebrew and it works fine. homebrew bitches and moans about not being installed to /usr/local, but it's never been an issue for me -- probably because I use application level package managers (emacs cask, python, opam, &c.) rather than homebrew for those sorts of things.

I still hate homebrew, of course, because it doesn't handle dependencies well at all, but I'm not 100% ready to switch to nix. Maybe that can be my project for the week, actually.

I would expect that a significant percentage of unix packages would throw a fit if they had to live in their own subtree.

Reply on news.ycombinator.com