On Mon, Apr 2, 2012 at 12:29 AM, Jay Levitt <jay.lev...@gmail.com> wrote: > > 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.
Just as an FYI, a large percentage of the PostgreSQL developers are Mac users, including myself. They're also the company standard at EnterpriseDB - so we're not entirely unfamiliar with software development on them. >>> - 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.) If you see someone report a bug with the installers, please have them report it on the EnterpriseDB forums: http://forums.enterprisedb.com/forums/show/9.page > 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. I would disagree with that. Most users I know do not use things like homebrew (particularly those coming from Windows who have no familiarity with such package managers at all). > 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. As I said, that will happen with any distro. The installers are smart enough to detect it and avoid trying to reuse the same port. They won't ever try to touch an existing installation though (except of their own, which if detected will cause a switch to upgrade mode). > >>> - 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." That hasn't been updated because the installation steps haven't changed and I'd rather spend time writing software than updating screenshots. A couple of points of note: - The introduction says: "This document is based on the 8.4.x one-click installers but applies equally to later versions." - The doc also explains where to find the uninstaller. >>> - 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. It does. It'll detect that the port is in use and suggest a different one. I don't know of any other of those installation methods that'll do that. > > 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. Nice. You just turned me off ever wanting anything related to Ruby on my Mac either! > 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. Are you honestly trying to tell me that a developer (using any language, other than maybe vbscript in Excel) doesn't know about $PATH? > 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? There are hundreds of thousands of pieces of malware for Windows that relied on the ability to write to "system" directories like this to do their misdeeds. Anywhere they can write (or modify existing) software that may get executed at boot time or by an unsuspecting users (or potentially, root). Microsoft spent millions, probably tens or hundreds of millions enhancing the security of Windows precisely because of this type of security issue. If homebrew intentionally creates a hole like that, then for as long as I'm one of the PostgreSQL webmasters it will *never* be listed on our download pages. >>> 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! :) "Production" doesn't necessarily mean "server". All those thousands of Poker Tracker users that run with PostgreSQL on Windows on their home machines are production users for example. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
