Re: Switching to Homebrew as recommended Mac install?

Dave Page wrote:
> It seems to me that most of your arguments against the installers are
> based on incorrect understanding or information, and most of your
> arguments for Homebrew actually come across as arguments against!

You're right about the former - and as to the latter, they *were* arguments
against ("potential objections"). I try to pre-argue against my own
proposals to save everyone time; if I can still prevail, I must have a damn
good idea :)

At this point I agree with you, but I'm still going to go into detail,
because I think there are two markets for Postgres, and the database
community has been so focused around enterprise for so long that you're
missing opportunities with web startups. I'd love to help bridge the gap,
having jumped straight from big-iron PL/I to ooh-Ruby-is-shiny. And web
startups develop on Mac laptops. They just do. So if it helps you to imagine
me as a 20something "I'm a Mac" hipster, working on some hot Facebook/mobile
app with funding from Spark Capital, do that. Lord knows it helps me.

>> - We have few Mac experts hanging out in #postgresql.
> Not sure how this is relevant to the proposal.

The impetus for the idea was that there seems to be a steady stream of
novice PG users on Mac who come into #postgresql with installation problems,
which is bad enough as an out-of-box experience - but worse is that there
are rarely folks around who can help. (Of course, I'm extrapolating; every
time *I'm* in IRC and see this, there's someone who can help. But you know
what I mean.)

And (although my proposal started with documentation) I'm of the firm
opinion that "there's no such thing as a documentation error"; a user
problem is a software problem. Humans will click buttons before they'll
read, developers are humans, and no amount of RTFM will ever fix that. If we
can make installers smarter, that's way better than troubleshooting guides,
IRC, mailing lists, etc. So that's where I was coming from.

I didn't realize that you were actively maintaining the EDB installer (see
below for the 8.4 doc explanation); obviously, if you can improve that, it's
the best solution and we should, if anything, recommend it MORE vigorously.
Still, there's a growing community of developers who expect "brew install"
to work, and I do want to fix it for them. The EDB installer will always be
a one-off experience; most of the other servers you install will be through
a package manager, and homebrew's popularity (despite its youth) is
impressive. Both of my n=2 data points had run across PG a while back,
installed it with the one-click to try it out, forgotten about it, done
"brew install postgresql" today, and naturally ran into problems.

>> - By default, it installs to /Library/PostgreSQL, which is also (I think)
>> where the Apple-supplied Lion install is
> No, Apple's version is installed in /usr on mine.

Ah hah. I suppose only the Apple .plist is stored under /Library, then. Let
me amend that to "this made everyone in IRC, and probably many other
non-Mac-expert troubleshooters, assume that this is an Apple-installed
package." It'd be great for this to go somewhere that feels like "Oh, this
was installed by you"; /Library feels kinda weird for a server, though I can
understand your reasoning. Maybe even /Library/EnterpriseDB/PostgreSQL to
make it obvious?

>> - The uninstaller is hidden in /Library/PostgreSQL, which (since Finder
>> hides /Library by default) you're likely to go to via Terminal. But the
>> uninstaller is a Mac app, so even if you find it you have to know to use
>> "open" to run it, because Mac apps are really directories that the Finder
>> abstracts away from you.
> Yes.

How about a one-liner bash script "uninstall-postgresql" that does nothing
but "open uninstall-postgresql.app"?

>> - The EDB docs are written against 8.4.
> Only if you install 8.4. If you install 8.3 you get the 8.3 docs, 9.0
> the 9.0 docs and so on.

No, I meant on the web:

http://www.enterprisedb.com/resources-community/pginst-guide

That's what made me assume that the installer wasn't maintained (except as
to repackaging new PG versions, obviously). It's obviously not hard to
replace "8.3" with "9.1" when you read it, but it still leaves an impression
akin to "This web site works best with IE7 and above." Allow me to now
replace most of this thread with "hey, you might wanna update that page."

>> - There are eight ways to install Postgres on a Mac
> That isn't any more of a reason to discount the EDB installer than any other.

Nope, just an argument that the recommended installer should handle that nicely.

>> - We just had two folks within an hour, BOTH with conflicting installs of
>> Postgres.
> Not sure how that is relevant either. You can have conflicting
> installation using any of the installation methods, including a
> home-built source tree.

Right, but I suspect this is a common problem - not only have I seen it in
IRC but 3 or 4 times in my 12-person startup, which is kinda amazing given
that we've been recommending homebrew since day 2 last year (but day 1 was
macports, and then there was Lion, which is already 30-40% of the Mac
installed base).

It's worse in the Mac world because it is, very much unlike the enterprise
database world, a whiplashing, trend-driven ecosystem. Once there was Fink,
and there was great rejoicing because now we had a package system at all.
And then there was MacPorts, and everyone said "that's so much better! Let's
all switch!" and there was rejoicing and some conflicts. And now the Rails
community is both (a) collectively realizing that MySQL is not, in fact,
better than Postgres for any of their use cases, and thus embracing PG as
their go-to database, and (b) loving homebrew, no doubt because it's written
in Ruby. And the Rails community is a Mac community.

So you have a growing user base who may have tried two or three package
managers over the years and either ignored the warnings to not run both, or
couldn't find all their packages in one manager, plus people who are using
Lion and didn't realize it now comes with PG, so they're trying to install
it, plus the I-forgot-I-tried-this crowd... it'd be nice to handle this case.

>> 1. homebrew installs everything under /usr/local and makes that
>> user-writeable. Sorry. It does because most Mac users don't know how to
>> edit PATH for GUI apps (it's in a .plist in a hidden directory in your home
>> dir), and /usr/local is already in PATH by default.
>
> Your reasoning doesn't make sense. Why does putting something in the
> path require a directory to be world writeable.

Sorry - two separate things plus one misdirected argument:

1. Rubyists in general are sick of sudo'ing on their laptops, because It
Doesn't Matter (as I'll fail to argue later). Homebrew puts itself into a
directory that is user-writable so it does not require sudo for basic
installation.

2. Because shell's $PATH is hard to change programmatically due to
shell-config individualism (MacPorts was notorious for failing at this), and
yet many Mac programmers know nothing of shells at all (so they don't know
how to edit it manually), Homebrew puts itself into a directory that is
already in $PATH by default, but which is conveniently nonexistent by default.

Thus, Homebrew chowns /usr/local to (desktop user):admin.

> In any case, the fact that Homebrew does that to /usr/local should be
> enough to make any user run away screaming in terror. If it opens up a
> security hole like that, what else does it do to break your system?

So this is pointless to the discussion now, but if you want to engage
off-list, I'd frankly love to be reconvinced: Assume that I am on a laptop,
not a server. There is one physical user, and that user is me. I am always
logged in as that user. I am also conditioned to enter my password every
time an installer says it needs me to. I am a developer, and I am writing
software that will require me to keep my database credentials in cleartext
in a directory readable by me, and in the non-PCI, non-SOX, non-HIPPA world
of startups, those are certainly going to be superuser credentials for
convenience. What, exactly, is the attack vector opened by installing
postgres or other developer tools under my username? And what is the
relative risk of being targeted along that vector, and not "You're at
Starbucks and you're browsing Facebook without SSL", other than spear
phishing attacks?

>> 2. The current formula installs Postgres as the desktop user, not as the
>> _postgres role account.
>
> That's not very helpful on shared machines - and whilst it may be fine
> for developers etc, it's not the recommended way to setup PostgreSQL
> for any kind of production use.

Oh, of course. Homebrew does not target the three remaining people who run
production XServes. It's purely for Mac developer workstations. At
startups. Which are MacBooks! :)

>> Meanwhile, the EDB installer by default installs both app and data to a
>> directory that requires root - so I assume it runs as root too - and
>> nobody's complained.
>
> No it doesn't. It installs the app to a root owned directory for
> security, and the data goes in a postgres owned directory so it can
> only be modified by the account the service runs under.

My bad - false assumption.

> They seem like a number of reasons not to use Homebrew too (at least
> as it is now).

Right, but it's about 20 lines of code to fix all that; embrace the wonder
of Ruby.

>> In IRC, both users had actually installed the EDB version months ago and
>> forgotten about it, but over time, Lion users will grow, since new Macs
>> come with Lion. There are several ways to address this; my preference
>> is to warn about existing installs but take care of any magic
>> to make them go away, a la
>> http://nextmarvel.net/blog/2011/09/brew-install-postgresql-on-os-x-lion/.
> So you propose to make it silently disable existing servers?

Oh, God no. I meant "You have an existing Postgres install. Do you really
want to replace the binaries? We'll stick them in this directory for
safekeeping." I do not think the homebrew use case and the multiple
side-by-side versions use case overlap at all. (Except me, and I'd cope.)

>> 8. There might be other popular things that EDB's StackBuilder does.
> PostGIS, Slony, psqlODBC, pgJDBC, Npgsql, phpPgAdmin...

OK, I'm convinced! (Though for the record, homebrew has formulas for
postgis, pg_top, pgbouncer, pgpool-ii, and pgtap, so nyah. Formulas are
simple if building is simple; pgtop.rb attached if you're curious.)

Jay