Thread: The case for the One-Click Installer
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
----- "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.
> 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
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)
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
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
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
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
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
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