Обсуждение: The case for the One-Click Installer

Поиск
Список
Период
Сортировка

The case for the One-Click Installer

От
Josh Berkus
Дата:
All,

Selena pointed out that the current argument about procedure is
pointless.  She's right.  Therefore, let me explain *from an advocacy
perspective* the reason why the one-click installer is important.

Not that this means that we need to have EnterpriseDB do our installers,
but it explains what would have to be replaced in a non-EDB community
installer.  And, for that matter, why I encouraged EnterpriseDB to build
a one-click installer for community PostgreSQL last year.

When I was working in the MySQL department at Sun last year, I got an
earful on the things the PostgreSQL project had done wrong which MySQL
AB had been able to take advantage of.  There were some interesting
surveys on why people chose to adopt MySQL over PostgreSQL (and I'll
tell you that most of the reasons discussed here or on planetpostgresql
are missing the point).

One of the biggest reasons for people choosing MySQL was the "some
assembly required" nature of PostgreSQL: the requirement to find and
download 5 to 20 separate components, often from separate web sites, and
compile and integrate them yourself.  Further, even where operating
system packages provided a lot of these extra components, the set of
components available and what they're called varied widely between
packages.  And many components were simply not available on Windows.

For a developer who "just wants a database" that approach is
intolerable, and they'll use anything else which provides them a
"complete package".  As of 8.2, this issue was possibly the largest
single blocker to increased PostgreSQL adoption, probably greater than
built-in replication or any of the other technical features we like to
talk about.  Discussions about installers and packages on -hackers and
other lists largely petered out without anyone offering to help.

Therefore, we needed a "just install it" package.  If I had been able to
build this using the Sun team, I would have.  However, only EnterpriseDB
was in a position to supply the staff and technology.

Since 8.3, the One-Click installer has been wildly successful in
bringing in new users.  On IRC, I'd estimate that 50% of new users
showing up used it to install (higher on Mac or Windows).

Therefore, any replacement of EnterpriseDB's "one click installer" needs
to be able to replace the "just install it" functionality.  And it needs
to work as well as the One-Click does.

Because EDB is a VC-funded company and may someday be sold, I agree that
it's not healthy to be dependant on them for installers.  One way to
resolve this is for more people to help and get Dimitri's extension
packaging system finished; if we had that, the issue of packaging all
drivers and components would be come vastly decreased, and supporting
multi-operating-system installers much easier.  However, I've yet to see
anyone arguing for an change of installers on this list volunteer to
help Dimitri, and his project is liable to not complete this year due to
lack of help.

Further, let me point out again that the MSI installers were dropped
because *absolutely nobody* wanted to put any work into them other than
the EDB staff.  So it's not like we're drowning in installation
contributors.

In other words, if you care about the installer situation and want to
change it, the way to do so is to put in some work building installers,
module packagers, or other tools to improve the community installation
situation.  *Not* shouting arguments about what EDB ought to do.

I'll admit that I'm fundamentally lazy and would prefer to work on parts
of PostgreSQL which EnterpriseDB isn't taking care of, like autotuning
and tutorials.  We have a TODO list long enough for 100 times the
contributors we have now.  But how any contributor spends their time is
up to them.

(and can I just say how much the arguments on this list sound like the
"Red Hat is taking over Linux" of 2001?)

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Re: The case for the One-Click Installer

От
Adrian Klaver
Дата:
----- "Josh Berkus" <josh@agliodbs.com> wrote:

> All,
>
> Selena pointed out that the current argument about procedure is
> pointless.  She's right.  Therefore, let me explain *from an advocacy
>
> perspective* the reason why the one-click installer is important.
>
> Not that this means that we need to have EnterpriseDB do our
> installers,
> but it explains what would have to be replaced in a non-EDB community
>
> installer.  And, for that matter, why I encouraged EnterpriseDB to
> build
> a one-click installer for community PostgreSQL last year.
>
> When I was working in the MySQL department at Sun last year, I got an
>
> earful on the things the PostgreSQL project had done wrong which MySQL
>
> AB had been able to take advantage of.  There were some interesting
> surveys on why people chose to adopt MySQL over PostgreSQL (and I'll
> tell you that most of the reasons discussed here or on
> planetpostgresql
> are missing the point).
>
> One of the biggest reasons for people choosing MySQL was the "some
> assembly required" nature of PostgreSQL: the requirement to find and
> download 5 to 20 separate components, often from separate web sites,
> and
> compile and integrate them yourself.  Further, even where operating
> system packages provided a lot of these extra components, the set of
> components available and what they're called varied widely between
> packages.  And many components were simply not available on Windows.
>
> For a developer who "just wants a database" that approach is
> intolerable, and they'll use anything else which provides them a
> "complete package".  As of 8.2, this issue was possibly the largest
> single blocker to increased PostgreSQL adoption, probably greater than
>
> built-in replication or any of the other technical features we like to
>
> talk about.  Discussions about installers and packages on -hackers and
>
> other lists largely petered out without anyone offering to help.
>
> Therefore, we needed a "just install it" package.  If I had been able
> to
> build this using the Sun team, I would have.  However, only
> EnterpriseDB
> was in a position to supply the staff and technology.
>
> Since 8.3, the One-Click installer has been wildly successful in
> bringing in new users.  On IRC, I'd estimate that 50% of new users
> showing up used it to install (higher on Mac or Windows).
>
> Therefore, any replacement of EnterpriseDB's "one click installer"
> needs
> to be able to replace the "just install it" functionality.  And it
> needs
> to work as well as the One-Click does.
>
> Because EDB is a VC-funded company and may someday be sold, I agree
> that
> it's not healthy to be dependant on them for installers.  One way to
> resolve this is for more people to help and get Dimitri's extension
> packaging system finished; if we had that, the issue of packaging all
>
> drivers and components would be come vastly decreased, and supporting
>
> multi-operating-system installers much easier.  However, I've yet to
> see
> anyone arguing for an change of installers on this list volunteer to
> help Dimitri, and his project is liable to not complete this year due
> to
> lack of help.
>
> Further, let me point out again that the MSI installers were dropped
> because *absolutely nobody* wanted to put any work into them other
> than
> the EDB staff.  So it's not like we're drowning in installation
> contributors.
>
> In other words, if you care about the installer situation and want to
>
> change it, the way to do so is to put in some work building
> installers,
> module packagers, or other tools to improve the community installation
>
> situation.  *Not* shouting arguments about what EDB ought to do.
>
> I'll admit that I'm fundamentally lazy and would prefer to work on
> parts
> of PostgreSQL which EnterpriseDB isn't taking care of, like autotuning
>
> and tutorials.  We have a TODO list long enough for 100 times the
> contributors we have now.  But how any contributor spends their time
> is
> up to them.
>
> (and can I just say how much the arguments on this list sound like the
>
> "Red Hat is taking over Linux" of 2001?)
>
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> www.pgexperts.com


+1 and thank you.

Re: The case for the One-Click Installer

От
Korry Douglas
Дата:
> Because EDB is a VC-funded company and may someday be sold, I agree
> that it's not healthy to be dependant on them for installers.  One
> way to resolve this is for more people to help and get Dimitri's
> extension packaging system finished; if we had that, the issue of
> packaging all drivers and components would be come vastly decreased,
> and supporting multi-operating-system installers much easier.
> However, I've yet to see anyone arguing for an change of installers
> on this list volunteer to help Dimitri, and his project is liable to
> not complete this year due to lack of help.


Another way to resolve this would be for EnterpriseDB to open-source
the code used to build the one-click installers, which, is exactly
what we have done.

Since we have already open-sourced the code, the community only
depends on EnterpriseDB for manpower.


            -- Korry

Re: The case for the One-Click Installer

От
Joshua Kramer
Дата:
Josh,

> Therefore, any replacement of EnterpriseDB's "one click installer" needs to
> be able to replace the "just install it" functionality.  And it needs to work
> as well as the One-Click does.

+1 - very good analysis.

A question.  Does having all the Contrib packages installed in the
template databases by the installer contribute meaningfully to the value?

Would having a bare-bones installer, that installed the contrib packages
(but did not insert them into template1) be a benefit?

Check out the installers for xTuple, for versions 3.2.1 and prior.  If I
heard correctly, Selena created the one for Mac and I created the one for
Windows.  As part of the process, these installers install PG, PGAdminII,
and create a Windows Service Account and Windows Service.

Aside from testing, it would take 1-3 hours to create a new Windows PG
installer with the scripts I have, and I'm perfectly happy to give those
scripts to anyone who's interested.  I don't know if I can commit the time
to make the installers myself.

http://sourceforge.net/projects/postbooks/

Cheers,
-J

--

-----
http://www.globalherald.net/jb01
GlobalHerald.NET, the Smarter Social Network! (tm)

Re: The case for the One-Click Installer

От
Josh Berkus
Дата:
Josh,

> Aside from testing, it would take 1-3 hours to create a new Windows PG
> installer with the scripts I have, and I'm perfectly happy to give those
> scripts to anyone who's interested. I don't know if I can commit the
> time to make the installers myself.

If these installers aren't readily available out of the postbooks
project, I'd love to have them on pgFoundry.

Note though that when I say "componenents" I mean drivers, replication
tools, monitioring tools, GUI, etc., as well as contrib modules.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Re: The case for the One-Click Installer

От
Greg Smith
Дата:
On Thu, 9 Jul 2009, Joshua Kramer wrote:

> Would having a bare-bones installer, that installed the contrib packages (but
> did not insert them into template1) be a benefit?

Somebody might be able to do something with them.  But as Joshua was
pointing out, the root problem here is not a source code one, it's a
manpower one.  The MSI installer was itself a viable codebase to work
from if there were people who wanted to do it.

EDB's one-click installer stack is completely open-source and anybody else
could replicate what they do given enough people and resources to work on
it.  If that weren't the case, I'd be among those shouting from the
rooftops that there's a serious problem here.  The only problem that's
worth solving here is finding those resources.

I don't know exactly how EDB's work has gotten carved up there, but I know
my own multi-platform forays suggest that the Windows builds take a
disproportionate amount of resources to maintain compared to ones based on
RPM and deb formats.  On a gross level there's three chunks of work here:

1) Getting the installer working on any platform
2) Building and testing on Windows platforms
3) Building and testing on UNIX platforms

Dave suggested there was 3 man-months worth of work just to get 8.4 out
the door here.  If you cut the work down to "one-click installers only for
Windows", basically eliminating just (3) out of the above, I doubt you'll
discover that reduces the amount of time required to support things in a
linear way--where the job scales based on the total number of platforms
supported.  There's both the overhead of packaging anything and the heavy
Windows overhead relative to other platforms to consider.

As someone who has a good feel for how much work is involved, I really
appreciate the work Dave and the rest of the EDB team involved does to
make a good PostgreSQL product for Windows.  I don't think many people
here have a full feel for how hard it is to run a software QA effort
against a complicated product.  And while I don't directly use the
one-click installer myself on the Linux platforms I mainly use, having it
as an option does seem to provide some value to new users in particular.

I'm really disappointed at how little respect for that work and its value
to the community is being shown the last few days here.  Obviously it
would be better if that were done by volunteers or with a no-strings
attached sponsorship, but just recognizing that fact doesn't make those
resources appear.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

Re: The case for the One-Click Installer

От
Dave Page
Дата:
On Thu, Jul 9, 2009 at 9:16 PM, Greg Smith<gsmith@gregsmith.com> wrote:
> 1) Getting the installer working on any platform
> 2) Building and testing on Windows platforms
> 3) Building and testing on UNIX platforms
>
> Dave suggested there was 3 man-months worth of work just to get 8.4 out the
> door here.  If you cut the work down to "one-click installers only for
> Windows", basically eliminating just (3) out of the above, I doubt you'll
> discover that reduces the amount of time required to support things in a
> linear way--where the job scales based on the total number of platforms
> supported.  There's both the overhead of packaging anything and the heavy
> Windows overhead relative to other platforms to consider.

From a QA perspective, probably 10% of the effort is OS X, 40% for
Linux (mainly due to the sheer number of Linux distros), and 50% for
the various versions of Windows and different configurations.

From a development and support perspective, Linux & Mac probably
equate to 10% of the effort each. The rest is Windows. The reason it
tends to be so high, is the sheer number of different (and
unpredictable) possible configurations of things like local and domain
security policies, filesystem ACLs, effects of folder redirection,
UAC, changes to utilities between different releases (eg. cacls vs.
icacls), encoding and locale issues and oddities seen when running
over terminal services sessions.

> As someone who has a good feel for how much work is involved, I really
> appreciate the work Dave and the rest of the EDB team involved does to make
> a good PostgreSQL product for Windows.

Thanks Greg.


--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: The case for the One-Click Installer

От
Andreas Pflug
Дата:
Dave Page wrote:
>
> From a QA perspective, probably 10% of the effort is OS X, 40% for
> Linux (mainly due to the sheer number of Linux distros), and 50% for
> the various versions of Windows and different configurations.
>
> From a development and support perspective, Linux & Mac probably
> equate to 10% of the effort each. The rest is Windows. The reason it
> tends to be so high, is the sheer number of different (and
> unpredictable) possible configurations of things like local and domain
> security policies, filesystem ACLs, effects of folder redirection,
> UAC, changes to utilities between different releases (eg. cacls vs.
> icacls), encoding and locale issues and oddities seen when running
> over terminal services sessions.
>
Dave, while you're showing some numbers about the installer hell (I know
why I always tried to keep away from installers and build systems...),
can you shed a little light on the "3 men working fulltime for some
months on the installer": how much of that work was purely postgres
related, and not reusable/sharable with EDB servers?

AFAIR EDB had the installer for their own products first, and in a
second step made it vanilla-postgres-aware. Of course there's absolutely
nothing wrong with that, that's how OSS works. But all that uncountable
windows issues apply to the EDB products as well, so a good bunch of
code as well as experience gained from tests is shared.
In this case, I guess pgsql8.4 is the first product tested, and edb8.4
will follow, gaining benefit from everything learned with pgsql. Again,
there's absolutely nothing wrong about that, unless you try to induce
the impression that EDB contributed manpower solely usable on
vanilla-pgsql with no direct benefit for edb products, in order to
justify why EDB should gain a premium marketing platform on the pgsql
distribution as kickback. Actually, I did get that impression.


Regards,
Andreas

Re: The case for the One-Click Installer

От
Dave Page
Дата:
On Thu, Jul 9, 2009 at 11:24 PM, Andreas Pflug<pgadmin@pse-consulting.de> wrote:

> Dave, while you're showing some numbers about the installer hell (I know why
> I always tried to keep away from installers and build systems...), can you
> shed a little light on the "3 men working fulltime for some months on the
> installer": how much of that work was purely postgres related, and not
> reusable/sharable with EDB servers?
>
> AFAIR EDB had the installer for their own products first, and in a second
> step made it vanilla-postgres-aware. Of course there's absolutely nothing
> wrong with that, that's how OSS works. But all that uncountable windows
> issues apply to the EDB products as well, so a good bunch of code as well as
> experience gained from tests is shared.
> In this case, I guess pgsql8.4 is the first product tested, and edb8.4 will
> follow, gaining benefit from everything learned with pgsql. Again, there's
> absolutely nothing wrong about that, unless you try to induce the impression
> that EDB contributed manpower solely usable on vanilla-pgsql with no direct
> benefit for edb products, in order to justify why EDB should gain a premium
> marketing platform on the pgsql distribution as kickback. Actually, I did
> get that impression.

The PostgreSQL 8.3 one-click installers, and the 60 or so add-on
installers that are available through StackBuilder are the first of
our 'next generation' installers. The current version of Postgres Plus
Standard server (8.3) uses Apple's installer on Mac, Wix on Windows
and some Java thing on Linux. The current version Postgres Plus
Advanced Server (8.3R2) uses a java based Installshield installer.

The next version of Postgres Plus Standard Server (which will probably
be out in late Q3/Q4) will use the same technology as we're using for
PostgreSQL on all platforms. It will reuse a fair chunk of the
existing installers code, and was intentionally designed that way to
optimise the use of resources.

The next version of Advanced Server (no idea on the ETA of that) will
almost certainly use the same technology, but with significantly less
shared code, mainly because the products are quite different.

So currently, all of those resources have been dedicated purely to
PostgreSQL, but it is true that we will benefit from reduced/combined
testing requirements on Postgres Plus in the future.

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Re: The case for the One-Click Installer

От
decibel
Дата:
On Jul 9, 2009, at 12:41 PM, Josh Berkus wrote:
> One of the biggest reasons for people choosing MySQL was the "some
> assembly required" nature of PostgreSQL: the requirement to find
> and download 5 to 20 separate components, often from separate web
> sites, and compile and integrate them yourself.


+1, and FWIW, this is something that Pervasive would have done if we
could have mustered the manpower.
--
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828