Dave Page wrote:
On Mon, Apr 2, 2012 at 12:29 AM, Jay Levitt<jay.lev...@gmail.com> wrote:
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.
Good to know; now I realize that even on Macs there are two worlds. I think
it's important to understand the new world, because although very little
infrastructure spans two generations, I believe that PostgreSQL is uniquely
positioned to do exactly that, just as POSIX has. It's a performant ACID
relational data store for the old guard, but it's also a web-scale
cloud-friendly polyglot-extensible preinstalled
XML/JSON/hstore/tree/graph/schemaless store for the new, and like Java
HotSpot, it gets smarter and faster every day. It is an operating system for
your data, it's free, and Oracle hasn't bought it (except yesterday).
This goes back to the "marketing challenge, not technical challenge" threads.
- 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,
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
It's not a bug with the EDB installer, except insofar as the bug is "the EDB
installer is not prominent and widely recommended enough and so they used
homebrew or macports". The EDB installer is what they used once upon a time;
today they are following a blog post that walked them through homebrew
(probably as one line of a longer process involving memcached, sphinx,
nginx, node.js, and seven other things).
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).
Yep; two worlds.
>> [docs reference 8.4]
That hasn't been updated because the installation steps haven't
changed and I'd rather spend time writing software than updating
screenshots.
Fair. I wonder if there's an easy way to automate the generation and
insertion of those screen shots. You could always write an
AppleScript/Automator/Keyboard Maestro script, but I feel like I've seen a
better way specifically for tech docs; I'll keep an eye out.
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.
Sure, and if humans read docs, instead of just glancing at them, that'd be
all you needed. In any case, I could counter myself that nobody reads the
doc period, so it doesn't matter what version is listed; that's just the
source of my own misunderstanding about maintenance.
- 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.
That's terrific, and you're right - it's the only one.
>>>> 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.
Excellent point, and one I hadn't thought of.
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!
Well, for "Rubyists", I should properly substitute "younger developers", aka
"all developers eventually".
As more toolchains work without sudo (Ruby, Python, JavaScript), using sudo
actually breaks stuff, because now you've written some files as root and
you'll later fail to overwrite them as user. Heck, I've had that happen with
ccache; if you do "sudo make install" without "make", you're compiling and
caching as root, and three years later you'll recompile as user and get a
permissions error (or a broken ccache IIRC).
Are you honestly trying to tell me that a developer (using any
language, other than maybe vbscript in Excel) doesn't know about
$PATH?
I'm not only telling you that *a* developer doesn't know; I'm telling you
that soon, *most* won't. (Or, if they do, they know it's a magic
incantation that when something breaks, a blog tells them what to type to
fix it.) I work with a smart 2005 CS graduate who, when I said "look in
/usr/lib", would try cd'ing to /Users/Library. He wrote his first shell
script last week.
I'm not saying it's good. I'm just saying it is - and you're younger than
me, so you're not going to get to retire before it happens either!
First, go read this, and understand our future userbase, the college class
of 2015:
http://www.beloit.edu/mindset/2015/
In that vein, here's my take on the average whiz kid of the next five years:
- They have never written C. (It hasn't been taught to undergrads in a
decade.) They have never used pointers, preprocessors, X11, or spinlocks.
They have never seen a hex dump or assembly, never heard of a core dump, and
never run out of disk space, let alone thought to check for it happening.
- When you say "shell", they say "You mean Terminal?" They have not heard of
autoconf, m4, or POSIX.
- "Here is the whole computer that vi was created on." (They think the
terminal is a computer:
http://ignoble-experiment.blogspot.com/2012/03/here-is-why-vim-uses-hjkl-keys-as-arrow.html)
- They will never step inside a data center.
- Caching makes things faster, but "the browser takes care of it for you".
- Compression has always been faster AND smaller. Encryption has never been
expensive.
- You have always been able to Google any error message.
And the next 10-15:
- Most software has always been open source, on github, and interpreted.
- JavaScript has always been a perfect language because you can write your
server and your client and your mobile app in it.
- They do not know why Linux "used to be called UNIX".
- Every computer and cell phone has always been continuously connected to
(and backed up to) the Internet, which has always been fast enough for
video, and has always magically auto-configured everything. They do not own
an Ethernet cable and have only heard a modem in old movies.
- Hard drives have never had rotational latency; pixels have always been too
small to see. Documents have always auto-saved and versioned, cell phones
have always been multi-core and multitouch, and computers have never needed
to boot.
- Windows is what their parents used. (Unless Win8 really saves the
company.) IBM built the first computer, didn't they? Their cell phones,
computers, and TVs (the three standard development targets) have always been
POSIX-based.
- There have never been DBAs; developers have always used ORMs or maybe
written some inline SQL.
- IPv6 has always wor-- nah, that's crazy talk.
You get the idea. Just as we grew up not having to solder our computers
(much) or boot them from the front panel, they've always had a whole layer
of infrastructure that either magically works or that they can fix by
Googling and typing without understanding the internals. (GitHub did not
need their own sysadmins until December.) Let's make PG part of that.
Jay
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
