Thread: Installation simplicity
I have just downloaded the Solid Embedded Engine database from www.solidtech.com. Installing Solid was a breeze - a single file to untar, two commands to run (create initial database, start database server), and I was running! Compare this to the nightmare (for some people, at least) of installing PostgreSQL. Yes, that includes compiling, which is complex in itself, but I think that PgSQL installation could be much simpler. Does anybody have ideas as to how this could be accomplished? -- Windows is okay, because even though it crashes all the time, it pops up a nice window and asks if its okay first.
Guan Yang wrote:
>I have just downloaded the Solid Embedded Engine database from
>www.solidtech.com. Installing Solid was a breeze - a single file to
>untar, two commands to run (create initial database, start database
>server), and I was running!
>
>Compare this to the nightmare (for some people, at least) of installing
>PostgreSQL. Yes, that includes compiling, which is complex in itself,
>but I think that PgSQL installation could be much simpler.
>
>Does anybody have ideas as to how this could be accomplished?
Use a pre-built package, such as the Linux packages from Debian or Red Hat.
What you really seem to be asking for is that such packages be available
at ftp.postgresql.org for all possible platforms. A commercial organisation
has to do this, because they don't release source code. The downside is
that only a limited set of platforms are supported.
--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"Delight thyself also in the LORD; and he shall give
thee the desires of thine heart." Psalms 37:4
On seg, 18 out 1999, Oliver Elphick wrote: > Guan Yang wrote: > >I have just downloaded the Solid Embedded Engine database from > >www.solidtech.com. Installing Solid was a breeze - a single file to > >untar, two commands to run (create initial database, start database > >server), and I was running! > > > >Compare this to the nightmare (for some people, at least) of installing > >PostgreSQL. Yes, that includes compiling, which is complex in itself, > >but I think that PgSQL installation could be much simpler. > > > >Does anybody have ideas as to how this could be accomplished? > > Use a pre-built package, such as the Linux packages from Debian or Red Hat. > > What you really seem to be asking for is that such packages be available > at ftp.postgresql.org for all possible platforms. A commercial organisation > has to do this, because they don't release source code. The downside is > that only a limited set of platforms are supported. > I've installed and compiled many "source" applications in my life and I must confess that PostgreSQL installation procedure was one of the most confusing ones. Qmail was also confusing. Apache or even MySQL are very simple and should be taken as an example. But once you get it installed, PostgreSQL is great! ;-) -- Henrique Pantarotto CEPAnet Internet Provider webmaster / analista de sistemas Email: scanner@cepa.com.br Tel: (011) 5506-8477 Cel: (011) 9706-3444 LINUX FRIEND
Hi! UdmSearch-2.1.5 - full featured PostgreSQL based web search engine is available now. Download it from http://mysearch.udm.net/ From ChangeLog: * robots.txt support did not work with "FollowOutside yes", fixed *Added file: URL. One could index local files now. *Added "Alias" indexer.conf command to organize search through master site indexing local mirror while indexing *Added perl frontend by Rohan Baxter search.pl. It matches functionality of search.php3 for version udmsearch-2.1.3 except for use of Rand variables *Added sorting by rate/modification date in search.cgi *Added HTTPHeader indexer.conf command to add user defined headers in HTTP requests *Fixed bug in reaping zombies of external parser processes *Fixed some bugs in new database interface (bugs since 2.1.4.b1) *Added italian stoplist *Added page navigator template *Fixed a bug in html template when title, description or text contain a special html characters like &<> *Fixed a bug in cp1250 -> iso-8859-2 conversion -- Alexander Barkov IZHCOM, Izhevsk email: bar@izhcom.ru | http://www.izhcom.ru Phone: +7 (3412) 51-55-45 | Fax: +7 (3412) 78-70-10 ICQ: 7748759
hi... > > I've installed and compiled many "source" applications in my life and I must > confess that PostgreSQL installation procedure was one of the most confusing > ones. Qmail was also confusing. Apache or even MySQL are very simple and > should be taken as an example. what _exactly_ is the problem everyone is having? i know on Solaris, there is the share memory problem. under windows, you have to get Cygwin going. these seem to be the prices of running these platforms, period. that being said, i've installed Postgres several times, always from source. i find that the magic commands: ./configure make make install have always worked just fine. i've rarely had any need/desire to deviate from the defaults (when i have, its been very easy to accomplish as well). and this way you get a rdbms that is optimized for your system! after that, a simple initdb, createdb, add some users, and away you go. i do agree that postgres administration needs work. the tools given are too simple, the framework not comprehensive enough. they are workable, but not Good. (imo) i submitted some thoughts on it last week to the mailing list, no reponse yet *shrug* perhaps i'm the only one who feels this way... in any case, i don't think that installing it is hard. if YOU feel it is, how 'bout this: why don't you compile it on your box running your OS and then package it up so the others who follow in your footsteps don't have to "endure the horrors" that you have =) this is open source, after all. -- Aaron J. Seigo Sys Admin
To be fair installing Postgres isn't as complicated as Oracle. See my previous comments on installing Oracle[1]... I did find the postmaster vs backend thing a bit confusing at first- plus the fact that you need a Postgres user. I can remember thinking, what's this postmaster thingy, and do I run it by myself and who do I run it as (from the security and functional viewpoint). There's also the "what do I do next?". >./configure >make >make install > >have always worked just fine. i've rarely had any need/desire to deviate >from the defaults (when i have, its been very easy to accomplish as well). and >this way you get a rdbms that is optimized for your system! > >after that, a simple initdb, createdb, add some users, and away you go. It is actually quite simple once you know it. But when you start out not knowing it it's not as simple. Things people would probably like to know: 0) You need to know what to do next. 1) You have to know that you have to do initdb first, and who does it, and what happens after that. Same for createdb. 2) Know how to set it to run everytime the system boots up... 3) How do you stop/restart it? When do you need to do that? 4) How to get to that SQL stuff? Ah Psql, not postsql :). 5) What's with the createdb as compared to CREATE DATABASE via psql. You don't know that createdb is just a script which calls psql- it could be some magical thing that you MUST run if not bad things happen later :). 6) What can you change? And what do you do if you change it? (relinking? recompiling? restart?). And if you suddenly want to turn on access controls - passwords for users and stuff, the admin approach changes completely! You CANNOT use the scripts (remember, you didn't know they were just scripts) you must shift to psql, and the webdocs aren't as clear on that. Createdb? Now different. Add user? Also different. You need to know similar things for other systems. But for some reason many users don't find these things as obvious when installing postgres for the first time. However all in all Postgres ain't that bad (a few other commercial database engines spring to mind). Still I hope we aren't aiming that way ;). For rule 0, sticking a basic HowTo with the source may help. All this is not unexpected though: practically ALL databases engines are different. What to run as backend/daemon, how to run, how to stop it from running, what to run to admin it. Dates, times (how to set a field's date and time to "now"), currency, numbers, indexes, counter vs serial vs auto increment vs sequences+insert triggers. They're all different. And the thing is all these details are rather important for practically any decent database app! Many times after we figure stuff out, we no longer understand why it was so hard in the first place. This is a problem when writing docs for newbies.. Cheerio, Link. [1] Is it just me, or is installing Oracle based on the Oracle installation manual like doing surgery following an academic textbook? e.g. chapter 1 has 100 ways to do an incision. Chapter 2 has 20 ways on sewing up. Chapter 3 discusses anaesthesia. Chapter 4- tying blood vessels, (by the way please refer to chapter 2 for more sewing hints).. Also see Appendix A: Ways to hold scalpels. Appendix B: Washing. And so on. In the end one has to go to the web and look for a HOWTO :).
RTFM :) Most of the installation issues you bring up below are in the install.txt file. It's a pretty foolproof document (type this, if you see this, do that, else do this...) The only problem is that it is long, which may seem a bit daunting to newbies. Maybe a INSTALL-QUICK.TXT file that just has the important 13 steps, and a note at the top that you can get precompiled packages for the different distributions at a given URL? At 11:56 PM 10/18/99, Lincoln Yeoh wrote: [snip] >Things people would probably like to know: >0) You need to know what to do next. >1) You have to know that you have to do initdb first, and who does it, and >what happens after that. Same for createdb. >2) Know how to set it to run everytime the system boots up... >3) How do you stop/restart it? When do you need to do that? >4) How to get to that SQL stuff? Ah Psql, not postsql :). >5) What's with the createdb as compared to CREATE DATABASE via psql. You >don't know that createdb is just a script which calls psql- it could be >some magical thing that you MUST run if not bad things happen later :). >6) What can you change? And what do you do if you change it? (relinking? >recompiling? restart?). > >And if you suddenly want to turn on access controls - passwords for users >and stuff, the admin approach changes completely! You CANNOT use the >scripts (remember, you didn't know they were just scripts) you must shift >to psql, and the webdocs aren't as clear on that. Createdb? Now different. >Add user? Also different. > >You need to know similar things for other systems. But for some reason many >users don't find these things as obvious when installing postgres for the >first time. > >However all in all Postgres ain't that bad (a few other commercial database >engines spring to mind). Still I hope we aren't aiming that way ;). > >For rule 0, sticking a basic HowTo with the source may help. > >All this is not unexpected though: practically ALL databases engines are >different. What to run as backend/daemon, how to run, how to stop it from >running, what to run to admin it. Dates, times (how to set a field's date >and time to "now"), currency, numbers, indexes, counter vs serial vs auto >increment vs sequences+insert triggers. They're all different. And the >thing is all these details are rather important for practically any decent >database app! > >Many times after we figure stuff out, we no longer understand why it was so >hard in the first place. This is a problem when writing docs for newbies.. > >Cheerio, > >Link. > >[1] >Is it just me, or is installing Oracle based on the Oracle installation >manual like doing surgery following an academic textbook? e.g. chapter 1 >has 100 ways to do an incision. Chapter 2 has 20 ways on sewing up. Chapter >3 discusses anaesthesia. Chapter 4- tying blood vessels, (by the way please >refer to chapter 2 for more sewing hints).. >Also see Appendix A: Ways to hold scalpels. Appendix B: Washing. >And so on. In the end one has to go to the web and look for a HOWTO :). > > > > >************ >
There appears to be some difference between the RPM Postgres distribution and what you would expect from compiling the binaries. I don't know what the problem was, but rather than try to figure the thing out, I finally removed the RPM's downloaded and compiled according to the documentation. That was not necessarily easy and - coming from a Windows background - not all of the directions made sense. But it seems to have worked so far. However, there is absolutely no reason - none why the RPMs should not precisely - precisely - match the suggested configuration set forth in the documentation. It should start and work first time, every time. No problem, no hassle. 'rpm -Uvh 'whatever'' - and that's it. Just like apache. I no longer even attempt to install the RedHat postgres. I just download and install. I do not know what the problem with the rpm's is, but it is too annoying for me to bother figuring it out. RPMs are for people who do not know how or are not comfortable with compiling and installing Linux distributions. It defeats their purpose to expect these people to jump through hoops while installing rpms. The rpm should do all - repeat all - the work for them. And it is not responsive to state "Oh, you forgot to squiggle the doohickey." Regards, Duncan C. Kinder dckinder@mountain.net ----- Original Message ----- From: Charles Tassell <ctassell@isn.net> To: <pgsql-general@postgreSQL.org> Sent: Monday, October 18, 1999 9:47 PM Subject: Re: [GENERAL] Installation simplicity > RTFM :) Most of the installation issues you bring up below are in the > install.txt file. It's a pretty foolproof document (type this, if you see > this, do that, else do this...) The only problem is that it is long, which > may seem a bit daunting to newbies. Maybe a INSTALL-QUICK.TXT file that > just has the important 13 steps, and a note at the top that you can get > precompiled packages for the different distributions at a given URL? > > At 11:56 PM 10/18/99, Lincoln Yeoh wrote: > [snip] > >Things people would probably like to know: > >0) You need to know what to do next. > >1) You have to know that you have to do initdb first, and who does it, and > >what happens after that. Same for createdb. > >2) Know how to set it to run everytime the system boots up... > >3) How do you stop/restart it? When do you need to do that? > >4) How to get to that SQL stuff? Ah Psql, not postsql :). > >5) What's with the createdb as compared to CREATE DATABASE via psql. You > >don't know that createdb is just a script which calls psql- it could be > >some magical thing that you MUST run if not bad things happen later :). > >6) What can you change? And what do you do if you change it? (relinking? > >recompiling? restart?). > > > >And if you suddenly want to turn on access controls - passwords for users > >and stuff, the admin approach changes completely! You CANNOT use the > >scripts (remember, you didn't know they were just scripts) you must shift > >to psql, and the webdocs aren't as clear on that. Createdb? Now different. > >Add user? Also different. > > > >You need to know similar things for other systems. But for some reason many > >users don't find these things as obvious when installing postgres for the > >first time. > > > >However all in all Postgres ain't that bad (a few other commercial database > >engines spring to mind). Still I hope we aren't aiming that way ;). > > > >For rule 0, sticking a basic HowTo with the source may help. > > > >All this is not unexpected though: practically ALL databases engines are > >different. What to run as backend/daemon, how to run, how to stop it from > >running, what to run to admin it. Dates, times (how to set a field's date > >and time to "now"), currency, numbers, indexes, counter vs serial vs auto > >increment vs sequences+insert triggers. They're all different. And the > >thing is all these details are rather important for practically any decent > >database app! > > > >Many times after we figure stuff out, we no longer understand why it was so > >hard in the first place. This is a problem when writing docs for newbies.. > > > >Cheerio, > > > >Link. > > > >[1] > >Is it just me, or is installing Oracle based on the Oracle installation > >manual like doing surgery following an academic textbook? e.g. chapter 1 > >has 100 ways to do an incision. Chapter 2 has 20 ways on sewing up. Chapter > >3 discusses anaesthesia. Chapter 4- tying blood vessels, (by the way please > >refer to chapter 2 for more sewing hints).. > >Also see Appendix A: Ways to hold scalpels. Appendix B: Washing. > >And so on. In the end one has to go to the web and look for a HOWTO :). > > > > > > > > > >************ > > > > > ************ > >
On Tue, Oct 19, 1999 at 11:03:37AM -0700, Duncan Kinder wrote:
> RPMs are for people who do not know how or are not comfortable with
> compiling and installing Linux distributions. It defeats their purpose to
> expect these people to jump through hoops while installing rpms. The rpm
> should do all - repeat all - the work for them.
Perhaps you should take that up with whomever maintains the .rpm
files. I never touch them. I don't even use the debian packages, because
I prefer to compile and install my own tools for production use. Since I
don't see them on ftp.postgresql.org, I assume that they don't belong
directoy to the Postgres team...
Postgres, to me, is just as easy to "make install" as any other
common application: Apache, PHP, or various mailers. Configuration
tends to be easier--there is only one hba.conf file and then you
need to create a user. After that, you are in a SQL environment.
--
Adam Haberlach | "Faster isn't always better,
adam@newsnipple.com | but slower never is."
http://www.newsnipple.com | --Brian Swetland
On Tue, 19 Oct 1999, Duncan Kinder wrote:
> RPMs are for people who do not know how or are not comfortable with
> compiling and installing Linux distributions. It defeats their purpose to
> expect these people to jump through hoops while installing rpms. The rpm
> should do all - repeat all - the work for them.
RPMs (and other distribution formats; I personally attached to Debian
GNU/Linux) are also for busy system administrators who cannot spent hours
compiling, installing and configuring soft. Open software is free like free
speech, but not like free beer :) Either I have to pay money or spent time.
RPMs and the like help installing/upgrading. Recently I've upgraded a
dozen of computers that ran Debian 2.0 to 2.1. I spent about 10 minutes per
computer - login, run dselect, update a list of packages, verify, and
upgrade. Without such system I'd have to spent hours on every system.
Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.
Doesn't the apache 1.3.6 that comes with RH 6.0 require that postgres be installed, incorrectly per those pesky rpms, in order to work? I swear that I've tried to avoid installing postgres due to this and every time RH requires me to install some of postgres... We're about to clear our current machine and do a fresh install of 6.1 when it gets here and I would prefer to avoid this problem if possible. TIA, Shawn Pursley(shawn.pursley@service-transport.com) Network Administrator Service Transport ----- Original Message ----- From: Duncan Kinder <dckinder@mountain.net> To: <pgsql-general@postgreSQL.org>; Charles Tassell <ctassell@isn.net> Sent: Tuesday, October 19, 1999 1:03 PM Subject: Re: [GENERAL] Installation simplicity > There appears to be some difference between the RPM Postgres distribution > and what you would expect from compiling the binaries. > > I don't know what the problem was, but rather than try to figure the thing > out, I finally removed the RPM's downloaded and compiled according to the > documentation. > > That was not necessarily easy and - coming from a Windows background - not > all of the directions made sense. But it seems to have worked so far. > > > However, there is absolutely no reason - none why the RPMs should not > precisely - precisely - match the suggested configuration set forth in the > documentation. It should start and work first time, every time. No > problem, no hassle. 'rpm -Uvh 'whatever'' - and that's it. Just like > apache. I no longer even attempt to install the RedHat postgres. I just > download and install. I do not know what the problem with the rpm's is, > but it is too annoying for me to bother figuring it out. > > RPMs are for people who do not know how or are not comfortable with > compiling and installing Linux distributions. It defeats their purpose to > expect these people to jump through hoops while installing rpms. The rpm > should do all - repeat all - the work for them. > > And it is not responsive to state "Oh, you forgot to squiggle the > doohickey." > > > > Regards, > > Duncan C. Kinder > dckinder@mountain.net > > > > ----- Original Message ----- > From: Charles Tassell <ctassell@isn.net> > To: <pgsql-general@postgreSQL.org> > Sent: Monday, October 18, 1999 9:47 PM > Subject: Re: [GENERAL] Installation simplicity > > > > RTFM :) Most of the installation issues you bring up below are in the > > install.txt file. It's a pretty foolproof document (type this, if you see > > this, do that, else do this...) The only problem is that it is long, > which > > may seem a bit daunting to newbies. Maybe a INSTALL-QUICK.TXT file that > > just has the important 13 steps, and a note at the top that you can get > > precompiled packages for the different distributions at a given URL? > > > > At 11:56 PM 10/18/99, Lincoln Yeoh wrote: > > [snip] > > >Things people would probably like to know: > > >0) You need to know what to do next. > > >1) You have to know that you have to do initdb first, and who does it, > and > > >what happens after that. Same for createdb. > > >2) Know how to set it to run everytime the system boots up... > > >3) How do you stop/restart it? When do you need to do that? > > >4) How to get to that SQL stuff? Ah Psql, not postsql :). > > >5) What's with the createdb as compared to CREATE DATABASE via psql. You > > >don't know that createdb is just a script which calls psql- it could be > > >some magical thing that you MUST run if not bad things happen later :). > > >6) What can you change? And what do you do if you change it? (relinking? > > >recompiling? restart?). > > > > > >And if you suddenly want to turn on access controls - passwords for users > > >and stuff, the admin approach changes completely! You CANNOT use the > > >scripts (remember, you didn't know they were just scripts) you must shift > > >to psql, and the webdocs aren't as clear on that. Createdb? Now > different. > > >Add user? Also different. > > > > > >You need to know similar things for other systems. But for some reason > many > > >users don't find these things as obvious when installing postgres for the > > >first time. > > > > > >However all in all Postgres ain't that bad (a few other commercial > database > > >engines spring to mind). Still I hope we aren't aiming that way ;). > > > > > >For rule 0, sticking a basic HowTo with the source may help. > > > > > >All this is not unexpected though: practically ALL databases engines are > > >different. What to run as backend/daemon, how to run, how to stop it from > > >running, what to run to admin it. Dates, times (how to set a field's date > > >and time to "now"), currency, numbers, indexes, counter vs serial vs auto > > >increment vs sequences+insert triggers. They're all different. And the > > >thing is all these details are rather important for practically any > decent > > >database app! > > > > > >Many times after we figure stuff out, we no longer understand why it was > so > > >hard in the first place. This is a problem when writing docs for > newbies.. > > > > > >Cheerio, > > > > > >Link. > > > > > >[1] > > >Is it just me, or is installing Oracle based on the Oracle installation > > >manual like doing surgery following an academic textbook? e.g. chapter 1 > > >has 100 ways to do an incision. Chapter 2 has 20 ways on sewing up. > Chapter > > >3 discusses anaesthesia. Chapter 4- tying blood vessels, (by the way > please > > >refer to chapter 2 for more sewing hints).. > > >Also see Appendix A: Ways to hold scalpels. Appendix B: Washing. > > >And so on. In the end one has to go to the web and look for a HOWTO :). > > > > > > > > > > > > > > >************ > > > > > > > > > ************ > > > > > > > ************ > >
hi all... > I don't know what the problem was, but rather than try to figure the thing > out, I finally removed the RPM's downloaded and compiled according to the > documentation. hm. for a RDBMs though, performance is an issue. this isn't a an end-user GUI we're talking about, its a grid-iron piece of back end software. pre-compiled will almost NEVER give you good performance, even if it goes in smoothly... > That was not necessarily easy and - coming from a Windows background - not > all of the directions made sense. But it seems to have worked so far. this i agree with. completely. which is why i suggested last week a complete reworking of the administration functions... to make these functions a seperate program (that also did compiling and installation, btw) that could have a GUI front end put on it... it also looked seriously at restructuring the security policies... unfortunately, i'm not a pgsql developer (yet), too busy at work right now.. arg. but maybe one day i'll get in there... and then fix some of this stuff along with the other great developers already up to their elbows in byte-grease. > RPMs are for people who do not know how or are not comfortable with > compiling and installing Linux distributions. It defeats their purpose to > expect these people to jump through hoops while installing rpms. The rpm > should do all - repeat all - the work for them. while i agree with this concept in theory, an RDBMS of commercial quality should really not be managed by someone not comfortable with systems administration. there are other products out there for them that probalby do what they are looking for better. > And it is not responsive to state "Oh, you forgot to squiggle the > doohickey." ROFL... yes. and don't forget to twist the little green fangle three times to the right, but only after flanging the morgoon. -- Aaron J. Seigo Sys Admin