Hacker News Reader

Comment by po | Hacker News Reader

Not really a command line utility, but rather a programming utility used through the command line:

I've replaced my MacPorts install with Homebrew and have been pretty happy with it. It's relatively new so not everything is in there yet.

View on HN

There is something written on the linked page that has always bothered me: "Using sudo all the time is annoying, but far worse — it conditions you to type in your root password without thinking about it." That quote implies a misunderstanding of sudo, and has made me less confident about installing Homebrew. Unix permissions and installation procedures should be well understood by a developer of package management software.

It's probably good software, for all that. He probably understands Unix better than I do, but it still bothers me.

The author (of Homebrew) is well intentioned but I've gotten a few hints that he doesn't really come from a *nix background (the /usr/local thing, the aggressive Gentoo-esque "optimization", etc).

[edit: http://news.ycombinator.com/item?id=872072 for some clarification on a few Homebrew vs MacPorts misconceptions.]

I used Homebrew for a bit, even submitted some recipes, but I've since switched back to MacPorts, in short because:

* MacPorts was once as simple as Homebrew, it's not now for good reasons. Eg, the reason MacPorts uses it's own python is beucase Apple is slow to update their own python, and when they do it happens outside of your own setup so you won't necessarily know you need to rebuild X, Y and Z.

* Homebrew did some silly things like aggressive stripping (which seemed to just be commands pulled from the Gentoo wiki without any real justification) which caused problems a few times when I tried to install things outside of Homebrew (eg, easy_install of MySQLdb didn't work out-of-the-box with the Homebrew mysql libs).

If they didn't have those insane installation instructions that said:

  sudo chown -R `whoami` /usr/local

I'd check this out. But I just can't bring myself to do it when they still have that as their default install instructions.

A lot of developers have no idea how UNIX permissions and mode bits work. I've witnessed this countless times, when a developer can't figure out why his code won't run, and just tells me to "chmod -R 777 /programdir/*"

I've had to sit a few developers down and teach them how to use commands like strace and truss to show them exactly which file they are trying to f_open and why it fails (usually trying to open a file in read/write mode that is not owned by them and 644 permissions).

Shouldn't this stuff be taught in basic CS101 courses?

Why would stuff about a particular OS's filesytem be taught in a beginning computer science class?

It's akin to "here's where the computer lab is" rather than in the "this is what a stack is"

Because CS101 should teach you about basic programming techniques, like how to open a file for reading or writing. In order to understand how to open a file, you need to have a basic understanding of how permissions work. In order to understand how permissions work, you need to understand how mode bits work.

This is really basic stuff, but I'm not surprised that most developers think it is beneath them. "That's sysadmin stuff; I don't need to learn that." These are usually the same developers that think chmod 777 is a fix.

Uh, so don't do that. On my macbook, I stuck homebrew in ~/homebrew and everything is great.

I think the point is more that the general instructions tell you to do it without any justification (which a lot of experienced *nix users seem to think it needs, myself included), it makes you wonder what kind of code is sitting in there without real justification.

I don't get why this is bad. The stuff in /usr/local is supposed to belong all to me unless I have to share my computer with other users and then I guess I'd use a group. I also like the point the brew README makes about how using sudo a lot conditions you to use it without thinking.

I'm just waiting to get a new MBP to setup everything via homebrew. Building myself vs choosing MacPorts has never been an easy choice. Inevitably over the years the choice one way or another has caused me a lot of pain. Homebrew seems to be the best of both worlds, and allows you to confine everything to your home directory which is a nice bonus in my case.

My only fear with homebrew is the lack of robust dependency resolution, but in practice I tend to be installing a limited set of devtools, so it doesn't rise to the same dependency hell that gave rise to the modern crop of unix package managers.

I feel like this is a common argument against homebrew, but have yet to encounter a situation where this was actually an issue.

I've found that the dependancy resolution is pretty decent. Heck, it can install ImageMagick just fine.

Why isn't there a binary package system, like apt, for OSX?

[fink](http://www.finkproject.org/) [macports](http://www.macports.org/)

MacPorts isn't binary. I didn't know Fink was, but that's cool, and I'm switching right away.

There is also [the possibly out of date?] Rudix (http://rudix.org/), which is basically standard OSX packages (.pkg) of typical unix tools. Their summary:

> Rudix features a world class collection of pre-compiled and ready to use Unix compatible software which are not available from a fresh installation of Mac OS X but are popular among other Unix environments. Here you can find utilities, programming languages, libraries and tools delivered as standard Mac OS X packages.

I haven't used this, though it may appeal to some.

"Dependency resolution and updates are basic or not working yet."

Reply on news.ycombinator.com