Thread: Humor me: Postgresql vs. MySql (esp. licensing)
Yes, I know you've seen the above subject before, so please be gentle with the flamethrowers. I'm preparing to enter a discussion with management at my company regarding going forward as either a MySql shop or a Postgresql shop. It's my opinion that we should be using PG, because of the full ACID support, and the license involved. A consultant my company hired before bringing me in is pushing hard for MySql, citing speed and community support, as well as ACID support. My biggest concern with MySQL is licensing. We need to keep costs low, and last I remember the parent company was being pretty strict on "fair use" under the GPL. If I recall, they even said a company would have to license the commercial version if it were simply used operationally within the company. Also, I was under the impression that Postgresql had pretty much caught up with MySql in the speed category...is this not the case? Finally, ACID support in mysql always seemed kind of a hack....perhaps this has changed? Thanks for any input (armament ;) ) you can provide. John
Sorry for the repost again. I emailed the Admin asking to cancel it (I originally posted from a non-subscribed address), but perhaps he missed it. John John Wells said: > Yes, I know you've seen the above subject before, so please be gentle with > the flamethrowers. > > I'm preparing to enter a discussion with management at my company > regarding going forward as either a MySql shop or a Postgresql shop. > > It's my opinion that we should be using PG, because of the full ACID > support, and the license involved. A consultant my company hired before > bringing me in is pushing hard for MySql, citing speed and community > support, as well as ACID support. > > My biggest concern with MySQL is licensing. We need to keep costs low, > and last I remember the parent company was being pretty strict on "fair > use" under the GPL. If I recall, they even said a company would have to > license the commercial version if it were simply used operationally within > the company. > > Also, I was under the impression that Postgresql had pretty much caught up > with MySql in the speed category...is this not the case? > > Finally, ACID support in mysql always seemed kind of a hack....perhaps > this has changed? > > Thanks for any input (armament ;) ) you can provide. > > John > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match >
> I'm preparing to enter a discussion with management at my company > regarding going forward as either a MySql shop or a Postgresql shop. - PostgreSQL supports constraints. MySQL doesn't; programmers need to take care of that from the client side - Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common sense tells you the value would be rejected. Yet MySQL happily folds it in and carries on its merry way. - Triggers: PostgreSQL yes, MySQL no. Translates into more work for your MySQL developers in both creating your app and moving it forward with each rev. - Transactions: We've been here before. Suffice to say, MySQL+InnoDB is almost there. Plain ol' MySQL doesn't have it, which tells you something about their philosophy towards database design. - Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches. Once you start getting complex, PostgreSQL is competitive. I think this speed issue is overrated: over time, PostgreSQL has sped up and MySQL has slowed down which is pretty impressive, considering both have added features from their early versions. - Scalability: MySQL dies before PostgreSQL does. PostgreSQL under extreme load may slow down, but it'll finish. MySQL simply gives up. If the project is for slapping dynamic html on a page with data not crucial for business, MySQL is probably fine. But if we're talking business processes, data you care dearly about, MySQL is out. Lack of constraints is the deal-breaker for me. PostgreSQL is more comparable to Oracle. MySQL is more like Access -- quick and dirty. But boy, they sure are good at marketing. Probably because MySQL is developed by a single company with venture cap and a public relations company whereas PostgreSQL is developed out in the open by a close-knit community. -- Best, Al Hulaton | Sr. Account Engineer | Command Prompt, Inc. 503.222.2783 | ahulaton@commandprompt.com Home of Mammoth PostgreSQL and 'Practical PostgreSQL' Managed PostgreSQL, Linux services and consulting Read and Search O'Reilly's 'Practical PostgreSQL' at http://www.commandprompt.com
John Wells wrote: >Yes, I know you've seen the above subject before, so please be gentle with >the flamethrowers. > >I'm preparing to enter a discussion with management at my company >regarding going forward as either a MySql shop or a Postgresql shop. > >It's my opinion that we should be using PG, because of the full ACID >support, and the license involved. A consultant my company hired before >bringing me in is pushing hard for MySql, citing speed and community >support, as well as ACID support. > >My biggest concern with MySQL is licensing. We need to keep costs low, >and last I remember the parent company was being pretty strict on "fair >use" under the GPL. If I recall, they even said a company would have to >license the commercial version if it were simply used operationally within >the company. > >Also, I was under the impression that Postgresql had pretty much caught up >with MySql in the speed category...is this not the case? > >Finally, ACID support in mysql always seemed kind of a hack....perhaps >this has changed? > >Thanks for any input (armament ;) ) you can provide. > > Take a look at this document: http://sql-info.de/mysql/gotchas.html You will find that there are some "features" that are realy undesirable in a serious SGBD. -- Diogo Biazus diogo@ikono.com.br http://www.ikono.com.br
> -----Original Message----- > From: Oliver Elphick [mailto:olly@lfix.co.uk] > Sent: Wednesday, October 08, 2003 3:10 PM > To: Vivek Khera > Cc: PostgreSQL general list > Subject: Re: [GENERAL] Humor me: Postgresql vs. MySql (esp. licensing) > > > On Wed, 2003-10-08 at 20:28, Vivek Khera wrote: > > >>>>> "OE" == Oliver Elphick <olly@lfix.co.uk> writes: > > > > OE> But as far as Debian is concerned, paragraph 1 applies: > > > > OE> 1. Free use for those who are 100% GPL > > > > [[ ... ]] > > > > OE> That makes it free under the Debian Free Software > Guidelines, so I > > OE> have no grounds for requesting its removal. :-( > > > > So if I build and sell an appliance (hardware+software) based on > > debian and using the 'free' collection of software, > suddenly I'm not > > in compliance with their license. Sounds like a time-bomb > waiting to > > explode. > > It's licensed under the GPL, which means that you can indeed > sell it, SO LONG AS you make your own source code available > to your customer under the GPL or a compatible licence. > Nothing in the GPL stops you demanding money for the > software; what it requires is that you make your source code > available. Then who's going to pay for it? > It's whole purpose is to force the freeing of > source code; it is not much concerned with money. For > example, I remember years ago installing a DG Aviion > operating system upgrade, where I found that the compiler was > gcc, with the GPL prominently attached. And every > embedded-Linux device is in the same situation. > > MySQL's licence does not require you to buy a licence for > _any_ commercial use, but only for commercial use where you > do not release your source code under a GPL-compatible licence. > > There seems to be an awful lot of confusion about the GPL. > Maybe Microsoft's campaign has been bearing fruit in unlikely > quarters... The reason that there is a lot of confusion is that the license conditions are extremely confusing. > -- > Oliver Elphick > Oliver.Elphick@lfix.co.uk > Isle of Wight, UK > http://www.lfix.co.uk/oliver > GPG: 1024D/3E1D0C1C: CA12 09E0 > E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C > ======================================== > "Let no man say when he is tempted, I am tempted of > God; for God cannot be tempted with evil, neither > tempteth he any man; But every man is tempted, when he > is drawn away of his own lust, and enticed." > James 1:13,14 > > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index > scan if your > joining column's datatypes do not match >
> It's my opinion that we should be using PG, because of the full ACID > support, and the license involved. A consultant my company hired before > bringing me in is pushing hard for MySql, citing speed and community > support, as well as ACID support. Does the consultant push "speed AND ACID" or "speed OR ACID"? My point is that PostgreSQL is said to be harder to install/maintain/tune than MySQL. I have been reading some MySQL mailing list and for what I see there, using InnoDB tables (the only way to have foreign keys, transactions, and row level locking for MySQL) makes MySQL slower and adds complexity to tuning the database. See this thread for example http://lists.mysql.com/mysql/148832 . So when someone says that PostgreSQL without tuning is 5 times slower than MySQL retrieving the same query, it is quite right to also say that MySQL InnoDB without tuning is 5 times slower than MySQL MyISAM. In my opinion you might consider MySQL only when you don't need the features provided by PostgreSQL (and even then data consistency and durability issues favor PostgreSQL) because if you need them, your developers need to implement them and do extra work, spending more time and money. It was already mentioned but I'll post this link again http://sql-info.de/mysql/ . IMHO if you are not aware of these gotchas they can also increase development time because some things are too different from regular/logical behavior (or common sense if you will) of any other database. Kaarel
> Does the consultant push "speed AND ACID" or "speed OR ACID"? My point > is that PostgreSQL is said to be harder to install/maintain/tune than > MySQL. Erhm, I kind of missed half of my sentence or smth. Anyway the point is that with MySQL you get *either* (speed) or (foreign keys and transactions) not both as what seems the consultant is pushing. Kaarel
> Then who's going to pay for it? Just because you ship it to them GPL does not mean that it is publicly accessible. For exsample, if I have a product that I built for a customer, I would have to give it to them under the GPL. But I also have the choice to not give it to them AT ALL. So, they pay me to get it, and the license is the GPL. Their other choice, if they didn't pay me, would be to not have it at all. It's likely that I could sell this same software to multiple entities, because the likelihood of the first company having the time, personel, and motivation to just giving it away on the Internet are very small. In addition, if you make it available at stores, people will buy it for convenience, like they do with Red Hat and Star Office. > The reason that there is a lot of confusion is that the license > conditions are extremely confusing. I haven't found this to be true. Most people just don't read the license and assume they know what it says. For a license, it's pretty straightforward. Not as straightforward as MIT/X, but pretty straightforward nonetheless. In fact, most of the complications come from copyright law itself(i.e. - the definition of a derivative work), and not the GPL. Jon
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
Thanks for this information, it's very helpful. I've included some
additional comments to further demonstrate how a qualified business planner
may look at this...
>> I'm preparing to enter a discussion with management at my company
>> regarding going forward as either a MySql shop or a Postgresql shop.
>
> - PostgreSQL supports constraints. MySQL doesn't; programmers need to
> take care of that from the client side
Wow. That's so rediculous that I don't want to believe it because
this feature is just so basic.
> - Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common
> sense tells you the value would be rejected. Yet MySQL happily folds it
> in and carries on its merry way.
That's unacceptable. To me, this is a complete show-stopper because I
simply won't tolerate data loss due to an idiotic design flaw.
> - Triggers: PostgreSQL yes, MySQL no. Translates into more work for your
> MySQL developers in both creating your app and moving it forward with
> each rev.
There are also circumstances where PostgreSQL will create implicit
triggers, which means to me that MySQL must be lacking in some other
features as a result of not supporting this.
> - Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
> almost there. Plain ol' MySQL doesn't have it, which tells you something
> about their philosophy towards database design.
It also indicates that Transactions are new to this product, and so
one may be better off with a more experienced group of developers who've
already earned their "battle scars" as is obviously the case with
PostgreSQL.
> - Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches.
> Once you start getting complex, PostgreSQL is competitive. I think this
> speed issue is overrated: over time, PostgreSQL has sped up and MySQL
> has slowed down which is pretty impressive, considering both have added
> features from their early versions.
Do you know of any published benchmarks for this? I need to convince
some people who are hell-bent on MySQL being fast for everything that
they're mis-informed, and they refuse to take anyone's word for it.
> - Scalability: MySQL dies before PostgreSQL does. PostgreSQL under
> extreme load may slow down, but it'll finish. MySQL simply gives up.
[sNip]
I've experienced this very problem with MySQL actually. It seems that
Apache James (an open source Java-based SMTP/POP3 mail server) running on
FreeBSD will trigger this problem very quickly as soon as multiple users
attempt to send large (greater than 10 MBs) file attachments -- perhaps
JDBC is part of the problem, but in the Apache James error logs there is
indication of MySQL connectivity problems (also during busy times on
systems sending approximately 500,000 eMails per day).
--
Randolf Richardson - rr@8x.ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
Randolf Richardson, DevNet SysOp 29 wrote: >>- Define a 32-bit field in MySQL. Insert a 64-bit number instead. Common >>sense tells you the value would be rejected. Yet MySQL happily folds it >>in and carries on its merry way. > That's unacceptable. To me, this is a complete show-stopper because I > simply won't tolerate data loss due to an idiotic design flaw. Worse. It is no data loss. It is loss of data integrity. If I know I have lost two hours of work, I will crib but redo it. If I know around 5% of records are messed up by database in last 5 years but don't know which, just think where do I stand. >>- Speed: mHz for mHz, MySQL has PostgreSQL beat for simple searches. >>Once you start getting complex, PostgreSQL is competitive. I think this >>speed issue is overrated: over time, PostgreSQL has sped up and MySQL >>has slowed down which is pretty impressive, considering both have added >>features from their early versions. > Do you know of any published benchmarks for this? I need to convince > some people who are hell-bent on MySQL being fast for everything that > they're mis-informed, and they refuse to take anyone's word for it. Good benchmarks are hard to come by for two reasons 1. It is very difficult not to be blamed biased. 2. Featuer compensation. What if you run a postgresql benchmark with triggers and views, how do you test it with mysql anyways? I would suggest you to try OSDB becnhmarks http://osdb.sourceforge.net/ Your results will be great contribution to the community. Or try porting pgbench to mysql innodb. Actually I would like to see what the this benchmark does. Any prior knowledge of the results? >>- Scalability: MySQL dies before PostgreSQL does. PostgreSQL under >>extreme load may slow down, but it'll finish. MySQL simply gives up. > > [sNip] > > I've experienced this very problem with MySQL actually. It seems that > Apache James (an open source Java-based SMTP/POP3 mail server) running on > FreeBSD will trigger this problem very quickly as soon as multiple users > attempt to send large (greater than 10 MBs) file attachments -- perhaps > JDBC is part of the problem, but in the Apache James error logs there is > indication of MySQL connectivity problems (also during busy times on > systems sending approximately 500,000 eMails per day). Try dbmail. I am no mail admin but that is a mail server which works off postgresql/mysql. http://www.dbmail.org Shridhar >
It would be helpful to both communities if there was a factual feature-by-feature grid comparing the relative capabilities of Postgresql 7.4 and MySQL 4.x. It would probably be best to limit it to objective measures such as "Supports sub-selects in UPDATE queries". Even features that are supported by both should be listed, just so the evaluator can make it as a known issue. A separate supplemental section offering subjective items such as scalability anecdotes would be useful, too. An associate starting a project expecting to use MySQL asked me about it. I had formed my own unscientific impressions that PostgreSQL was more appropriate for his app, but I googled in vain for an updated PostgreSQL vs. MySQL table as described above. I only found one from 2001, and many of the distinctions no longer applied to current versions.
If you'd like to head up this list, I'm sure people will answer any
questions you might have. Getting the two communities to agree will be
tricky, for example, you would have to break down the features into
minute detail: support subselects in SELECT clause, supports subselects
in FROM clause, supports subselects in WHERE clause.
then theres also the areas where the two project simply disagree... one
area is (something like) supporting 1 -- 1 = 0 i think, which mysql
supports but we dont. (course neither does the spec...)
and finally you need to work out how your going to define supporting
something. In postgresql we have basically two levels of supported
functionality... coded but not released, and released code. in mysql
they have alpha, beta, gamma... maybe more? and they have "plugins" that
might be needed in some functionality (think innodb for transactions,
and let's gloss over whether their implementation is acid compliant)
so just be prepared if your going to do it. also, if you do do it, i'd
like to see a feature comparison against some more interesting
candidates, like oracle or informix
Robert Treat
On Thu, 2003-11-20 at 11:12, Jeff Kowalczyk wrote:
> It would be helpful to both communities if there was a factual
> feature-by-feature grid comparing the relative capabilities of Postgresql
> 7.4 and MySQL 4.x. It would probably be best to limit it to objective
> measures such as "Supports sub-selects in UPDATE queries". Even features
> that are supported by both should be listed, just so the evaluator can
> make it as a known issue. A separate supplemental section offering
> subjective items such as scalability anecdotes would be useful, too.
>
> An associate starting a project expecting to use MySQL asked me about it.
> I had formed my own unscientific impressions that PostgreSQL was more
> appropriate for his app, but I googled in vain for an updated PostgreSQL
> vs. MySQL table as described above. I only found one from 2001, and many
> of the distinctions no longer applied to current versions.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Shridhar Daithankar wrote: > Good benchmarks are hard to come by for two reasons > > 1. It is very difficult not to be blamed biased. > 2. Featuer compensation. What if you run a postgresql benchmark with triggers > and views, how do you test it with mysql anyways? Good benchmark implementations you mean. If you look for example at the TPC-W definitions, they define an artificial bookstore web interface, from what communications have to be encrypted down to what consitency constraints have to be guaranteed. They do not force you to implement these constraints in any particular way or tell you what part of the application logic has to run where. If you're using PostgreSQL, you are absolutely fine implementing whatever makes sense as a view, a stored procedure, whatever comes handy. Of course, for the comparision to that other databaze, you have to implement all these requirements in your middleware ... and then you get into this biased blaming and so on and so forth. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
[sNip]
> For exsample, if I have a product that I built for a customer, I would
> have to give it to them under the GPL. But I also have the choice to not
> give it to them AT ALL. So, they pay me to get it, and the license is
> the GPL. Their other choice, if they didn't pay me, would be to not have
> it at all. It's likely that I could sell this same software to multiple
> entities, because the likelihood of the first company having the time,
> personel, and motivation to just giving it away on the Internet are very
> small.
[sNip]
In summary, you could be charging them for some very expensive courier
services, if for which they don't pay then you won't deliver. =)
--
Randolf Richardson - rr@8x.ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
>>>- Define a 32-bit field in MySQL. Insert a 64-bit number instead.
>>>Common sense tells you the value would be rejected. Yet MySQL happily
>>>folds it in and carries on its merry way.
>>
>> That's unacceptable. To me, this is a complete show-stopper because I
>> simply won't tolerate data loss due to an idiotic design flaw.
>
> Worse. It is no data loss. It is loss of data integrity. If I know I
> have lost two hours of work, I will crib but redo it. If I know around
> 5% of records are messed up by database in last 5 years but don't know
> which, just think where do I stand.
That is worse, thanks for your clarity. I stopped before thinking it
through this far because any kind of screw-up like this just isn't worth
the risk in my opinion -- they really need to fix that and I think they
should make it a high priority.
[sNip]
>> Do you know of any published benchmarks for this? I need to convince
>> some people who are hell-bent on MySQL being fast for everything that
>> they're mis-informed, and they refuse to take anyone's word for it.
>
> Good benchmarks are hard to come by for two reasons
>
> 1. It is very difficult not to be blamed biased.
> 2. Featuer compensation. What if you run a postgresql benchmark with
> triggers and views, how do you test it with mysql anyways?
>
> I would suggest you to try OSDB becnhmarks
>
> http://osdb.sourceforge.net/
Thanks, I'll take a look at that.
> Your results will be great contribution to the community.
If I get enough spare time, I'll consider doing this.
> Or try porting pgbench to mysql innodb.
>
> Actually I would like to see what the this benchmark does. Any prior
> knowledge of the results?
I have no idea.
[sNip]
>> I've experienced this very problem with MySQL actually. It seems that
>> Apache James (an open source Java-based SMTP/POP3 mail server) running
>> on FreeBSD will trigger this problem very quickly as soon as multiple
>> users attempt to send large (greater than 10 MBs) file attachments --
>> perhaps JDBC is part of the problem, but in the Apache James error logs
>> there is indication of MySQL connectivity problems (also during busy
>> times on systems sending approximately 500,000 eMails per day).
>
> Try dbmail. I am no mail admin but that is a mail server which works off
> postgresql/mysql. http://www.dbmail.org
I see that it doesn't support file-based mail directories for storing
messages. That's too bad, because it just won't be able to meet the
performance of well-programmed mail servers such as Mercury (uses Novell
Directory Services for the user database) or qmail (can use PostgreSQL, and
other database engines, for the user database).
--
Randolf Richardson - rr@8x.ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
"Randolf Richardson, DevNet SysOp 29" <rr@8x.ca> writes:
>> - Speed: mHz for mHz, MySQL has PostgreSQL beat for simple
>> searches. Once you start getting complex, PostgreSQL is
>> competitive. I think this speed issue is overrated: over time,
>> PostgreSQL has sped up and MySQL has slowed down which is pretty
>> impressive, considering both have added features from their early
>> versions.
>
> Do you know of any published benchmarks for this? I need to
> convince some people who are hell-bent on MySQL being fast for
> everything that they're mis-informed, and they refuse to take
> anyone's word for it.
Publishing benchmarks is more than a little troublesome.
The sorts of ways to make PostgreSQL _really shine_, performance-wise,
involves making use of features that MySQL simply doesn't have. Fancy
footwork with stored procedures, for instance.
And "they" would (somewhat rightly) object that this would represent a
test that is "intended to make MySQL fail."
And if you start publishing results, MySQL AB might be able to send
"attack lawyers" at you, irrespective of whether there's a case with
merit. Virtually all of the commercial databases have a licensing
clause that forbids publishing benchmarks without the express consent
of the vendor, and a decent case can be made that this is a legitimate
'right' for the vendor to have.
In any case, I would think it doubtful that there is anything
reasonable to present to people that are so religiously "hell-bent,"
in any case. If they don't want to believe you, they will find
excuses to disbelieve whatever results you may give them.
--
output = reverse("ofni.smrytrebil" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)
Re: Postgresql vs. MySql - need feature matrix for current versions
From
"Randolf Richardson, DevNet SysOp 29"
Date:
> It would be helpful to both communities if there was a factual
> feature-by-feature grid comparing the relative capabilities of Postgresql
> 7.4 and MySQL 4.x. It would probably be best to limit it to objective
> measures such as "Supports sub-selects in UPDATE queries". Even features
> that are supported by both should be listed, just so the evaluator can
> make it as a known issue. A separate supplemental section offering
> subjective items such as scalability anecdotes would be useful, too.
>
> An associate starting a project expecting to use MySQL asked me about it.
> I had formed my own unscientific impressions that PostgreSQL was more
> appropriate for his app, but I googled in vain for an updated PostgreSQL
> vs. MySQL table as described above. I only found one from 2001, and many
> of the distinctions no longer applied to current versions.
How does this one look?
Database Server Feature Comparisons
http://www.mysql.com/information/crash-me.php
--
Randolf Richardson - rr@8x.ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
"Randolf Richardson, DevNet SysOp 29"
Date:
[sNip] >> I would suggest you to try OSDB becnhmarks >> >> http://osdb.sourceforge.net/ > > Thanks, I'll take a look at that. > >> Your results will be great contribution to the community. > > If I get enough spare time, I'll consider doing this. [sNip] According to their home page, tests are "underway" for both PostgreSQL and MySQL. I guess I won't have to worry about this since someone else is already working on it. -- Randolf Richardson - rr@8x.ca Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.8x.ca/ This message originated from within a secure, reliable, high-performance network ... a Novell NetWare network.
Randolf Richardson, DevNet SysOp 29 wrote: > [sNip] > > For exsample, if I have a product that I built for a customer, I would > > have to give it to them under the GPL. But I also have the choice to not > > give it to them AT ALL. So, they pay me to get it, and the license is > > the GPL. Their other choice, if they didn't pay me, would be to not have > > it at all. It's likely that I could sell this same software to multiple > > entities, because the likelihood of the first company having the time, > > personel, and motivation to just giving it away on the Internet are very > > small. > [sNip] > > In summary, you could be charging them for some very expensive courier > services, if for which they don't pay then you won't deliver. =) Of course a competitor could purchase a copy or get it from a customer and set up shop right away selling it too. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
[sNip]
>> Do you know of any published benchmarks for this? I need to
>> convince some people who are hell-bent on MySQL being fast for
>> everything that they're mis-informed, and they refuse to take
>> anyone's word for it.
>
> Publishing benchmarks is more than a little troublesome.
>
> The sorts of ways to make PostgreSQL _really shine_, performance-wise,
> involves making use of features that MySQL simply doesn't have. Fancy
> footwork with stored procedures, for instance.
Then a different approach is needed. One idea I can think of is to
come up with a set of both simple and complex objectives, and then see
which databases yield the best results. I believe this type of testing
would reveal more useful results for someone who's faced with the task of
choosing the right database engine for the job.
> And "they" would (somewhat rightly) object that this would represent a
> test that is "intended to make MySQL fail."
Unfortunately this is what happens whenever we compare Apples to
Oranges. Let's refrain from bringing Bananas into this. ;-D
> And if you start publishing results, MySQL AB might be able to send
> "attack lawyers" at you, irrespective of whether there's a case with
They can do this regardless of what statements are made. In fact,
they could even take issue with something completely irrelevant and,
although the courts may laugh it out of the courtroom, it could be very
much like a DoS attack, but I doubt MySQL would be so bold since it would
likely be portrayed as bad publicity from the anti-corporation types who
seem to be quite easy to find in just about every open source community.
> merit. Virtually all of the commercial databases have a licensing
> clause that forbids publishing benchmarks without the express consent
> of the vendor, and a decent case can be made that this is a legitimate
> 'right' for the vendor to have.
In that case MySQL could be in a lot of legal trouble in the future
given this web page where they include comparisons with database engine
products from various vendors (e.g., Microsoft, Oracle, SyBase, etc.):
MySQL Benchmarks
http://www.mysql.com/information/benchmarks-old.html
> In any case, I would think it doubtful that there is anything
> reasonable to present to people that are so religiously "hell-bent,"
> in any case. If they don't want to believe you, they will find
> excuses to disbelieve whatever results you may give them.
Not everyone is hell-bent on brand names when it comes to determining
which products best fit the job at hand.
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
[sNip]
>> In summary, you could be charging them for some very expensive courier
>> services, if for which they don't pay then you won't deliver. =)
>
> Of course a competitor could purchase a copy or get it from a customer
> and set up shop right away selling it too.
Ah, so even the GPL has a few loop holes! =D
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
Randolf Richardson wrote: >> And if you start publishing results, MySQL AB might be able to send >> "attack lawyers" at you, irrespective of whether there's a case with > > They can do this regardless of what statements are made. In fact, > they could even take issue with something completely irrelevant and, > although the courts may laugh it out of the courtroom, it could be very > much like a DoS attack, but I doubt MySQL would be so bold since it would > likely be portrayed as bad publicity from the anti-corporation types who > seem to be quite easy to find in just about every open source community. You didn't follow the MySQL vs. NuSphere (aka PeerDirect) clash? It's been even on our mailing lists, search the archives. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Tue, 2003-11-25 at 16:58, Randolf Richardson wrote:
> [sNip]
> >> In summary, you could be charging them for some very expensive courier
> >> services, if for which they don't pay then you won't deliver. =)
> >
> > Of course a competitor could purchase a copy or get it from a customer
> > and set up shop right away selling it too.
>
> Ah, so even the GPL has a few loop holes! =D
Not really. Well, actually no. One of the goals of the GPL is to make it
possible for this very thing to happen.
I can get GPLed software (however, by paying or for free), and the
source for it and do whatever I want with it, including on-selling
copies or derived works.
The only catch is that my copies and derived works must also be licenced
under the GPL.
Stephen
Attachment
Randolf Richardson <rr@8x.ca> writes: >> I _don't_ think what MySQL AB is doing with it is quite what was >> intended, but the various side-effects that you see are, by and >> large, quite intentional, even the ones that don't play into >> scenarios of Richard Stallman as "Evil Overlord." > > The big question is this: Has the GPL been violated by MySQL? The MySQL AB interpretation that any use of their software under the GPL inherits to mandating that your software be licensed under the GPL certainly seems controversial. <http://slashdot.org/interviews/00/05/01/1052216.shtml> In that interview, the indication is that by separating components into "client" and "server" bits, using CORBA, the GPL can be circumvented because the client and server aren't "linked." Which is the opposite of what MySQL AB is telling people. The MySQL AB strategy doesn't seem to involve the "client-vs-server" issue. Arguing that your client must be GPL-licensed because the server is wouldn't fly terribly far. Instead, they only provide _client_ software in GPL-licensed form, as _that_ would "taint" the software you might link to it such that it would have to be GPL-licensed. <http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2> What is very interesting is that they oppose attempts to circumvent this by someone prepared to write their own client. (The discussion came up when SAP-DB users were distressed that they would no longer be able to get a LGPL-licensed client library, and were discussing the possibility of writing their own...) "In this case, I would suspect that the intent of your middleware is what would matter most in a court case. If the middleware appears to mostly be in place to circumvent licensing restrictions, then it (I believe) would not circumvent the license. If the middleware is an abstraction layer that simply allows for convenient access to a variety of different data sources, then the license might be circumvented." -- Zak Greant <zak@mysql.com> What is also very interesting is that many/most of the uses of "client libraries" get embedded into PHP/Perl/Python modules, which leads to a mishmash of licenses that may (as with PHP) make redistribution of the client libraries nonpermissible. Long and short... No, I don't see that the GPL has been "violated." But if the GPL is intended as a 'protector/encourager of free software,' their use of it seems to me to be about as distant from that _intent_ as possible. -- let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;; http://www3.sympatico.ca/cbbrowne/postgresql.html If the FreeBSD team could get away with it, they would probably use warnings like "Contains live plague bacteria. Beware the Rabid Hippopotami. May cause nausea and vomiting." -- Michael Lucas, re: FreeBSD-CURRENT
Randolf Richardson <rr@8x.ca> writes:
> [sNip]
>>> In summary, you could be charging them for some very expensive courier
>>> services, if for which they don't pay then you won't deliver. =)
>>
>> Of course a competitor could purchase a copy or get it from a customer
>> and set up shop right away selling it too.
>
> Ah, so even the GPL has a few loop holes! =D
If you read the GPL very carefully, you may find that it was crafted
with considerable care and intent.
I _don't_ think what MySQL AB is doing with it is quite what was
intended, but the various side-effects that you see are, by and large,
quite intentional, even the ones that don't play into scenarios of
Richard Stallman as "Evil Overlord."
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','ntlug.org').
http://www.ntlug.org/~cbbrowne/spreadsheets.html
"World domination. Fast." -- Linus Torvalds
[sNip]
> If you read the GPL very carefully, you may find that it was crafted
> with considerable care and intent.
Oh, please don't misunderstand me, I wasn't implying that there was
anything wrong with such a loophole; after all, some loopholes are
intentional. =)
Although I view the GPL as well-intended to ensure that free software
remains that way, I still find that the BSD License seems to be better suited
to the needs of businesses at this point in time.
> I _don't_ think what MySQL AB is doing with it is quite what was
> intended, but the various side-effects that you see are, by and large,
> quite intentional, even the ones that don't play into scenarios of
> Richard Stallman as "Evil Overlord."
The big question is this: Has the GPL been violated by MySQL?
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
Randolf Richardson Wrote: > Although I view the GPL as well-intended to ensure that free software > remains that way, I still find that the BSD License seems to be better suited > to the needs of businesses at this point in time. > As long as we are on the subject of licenses, here is my point of view: Different licenses for different businesses. I am also trying to show why PostgreSQL's licensing puts it in a good position to take advantage of MySQL's mistakes. Open source licenses really break down into three main groups each of which do a good job of serving the needs of certain types of businesses, and each group has its major success stories... 1) GPL-- includes a few derivative licenses as well from the FSF and others. Best success stories are Linux and the GCC. I personally doubt that IBM would be hiring so many developers to work on the Linux kernel of Sun could take the code and incorporate it into Solaris. Major business benefit for the GPL. 2) BSD/MIT class of licenses. Success stories include BIND and Apache. Helps build a wider community of proprietary and open source developers. 3) Alladin Public License and spinn-offs. The APL is designed to allow the software to be used in other open source projects, and be distributed free of charge. However, if MAY NOT be distributed for a fee or tied to services without additional permission from the vendor. This has the business benefit of ensuring greater royalites. There have been several success stories here (iirc. Ghostscript was once and may still be released under this license, as is PDFLib). The big issue with licensing here, however, is the fact that MySQL, by releasing the client libraries uder the GPL has essentially said that any developers building proprietary apps must buy expensive licenses from them. This is similar to what Trolltech has done with QT. The result is that, although these products (MySQL and QT) have large open source followings, the are not making large inroads into corporate space, and will likely never do so when there are more free alternatives to be had (PostgreSQL, GTK+, etc). Now, the MySQL issues can be easily circumvented. One could relatively easily write (in PHP), a GPL'd middle component which would provide a simple SOAP interface for MySQL, and then use proprietary apps to connect to it-- one could even distribute the MySQL client libs without infracting on the license in that way, but it is too much overhead and quite frankly work when there are better alternatives. The GPL was designed with the idea that programs would be relatively self-contained, and that non-GPL'd programs could easily interact with them. The other licenses make no such assumption. And in order to be competitive in the corporate workspace, GPL'd programs need to be self-contained. A good example of this problem was a program I have been developign for a couple years called HERMES. It is a CRM/ERP platform that (still) supports both MySQL and PostgreSQL. The homepage is at http://hermesweb.sourceforge.net. The program is licensed under the GPL, and I do not have the right to change that since others have contributed code. The problem is that at the moment, the program is NOT self-contained, so any extensions, new interfaces, etc. must also be GPL'd. This severely limits the community that can find the program useful. The solution is to add a set of basic interfaces which will allow non-GPL'd programs to talk to the server. The current approach is to create a set of Database Level API's (Stored Proceedures), LDAP bindings, and web services. In this way, we hope to allow the program to become the center of a larger community. Also, even with BSD licenses, there is a strong incentive to share code, since it ensures that the burden of maintenance is minimized. Therefore the BSD license is not so weak as many GPL zealots would like to think. The resulting situation is that MySQL has some licensing and technical issues that make it a very bad fit for enterprise use. PostgreSQL is both more free (in that closed source programs can CONNECT to it) and technically ahead of MySQL. It is also more rugged and performs better under real circumstances. For this reason, I cannot think of a company (aside from web hosting services) choosing MySQL over PostgreSQL. Web hosting services are a special exception, and I think that we could provide better tools for managing hosted accounts. Best WIshes, Chris Travers
Re: Humor me: Postgresql vs. MySql (esp. licensing)
From
merlyn@stonehenge.com (Randal L. Schwartz)
Date:
>>>>> "Chris" == Chris Travers <chris@travelamericas.com> writes: Chris> The resulting situation is that MySQL has some licensing and Chris> technical issues that make it a very bad fit for enterprise Chris> use. PostgreSQL is both more free (in that closed source Chris> programs can CONNECT to it) and technically ahead of MySQL. It Chris> is also more rugged and performs better under real Chris> circumstances. For this reason, I cannot think of a company Chris> (aside from web hosting services) choosing MySQL over Chris> PostgreSQL. The biggest advantage MySQL still has over PostgreSQL is the same advantage Microsoft has over Unix - entrenchment, both in software and mindshare. The marketplace often does the right thing, but when one "was right" thing dominates the market, the "new right" thing rarely has an easy time. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
[sNip]
>> The big question is this: Has the GPL been violated by MySQL?
>
> The MySQL AB interpretation that any use of their software under the
> GPL inherits to mandating that your software be licensed under the GPL
> certainly seems controversial.
Whether or not their interpretation is correct is less of a concern to
me than the fact that they've interpreted it in this way. The reason is
that if I develop a product that isn't licensed under the GPL, and it
becomes very popular, then I would be worried about having to defend myself
in front of some court or arbitrator.
Considering that this is more than a mere annoyance which can prove to
be very expensive and time consuming, I'd rather just avoid the whole mess
altogether by just avoiding using such a vendor's product altogether.
Of course I'll attempt to get an official response from the legal
department of such a company before jumping to any conclusions. In the
case of MySQL, if I wanted to develop a project that was not open source
and didn't comply with the GPL, I'd send a letter (or eMail) to MySQL and
ask for clarity on what my obligations would be with regards to their
licensing and my product (and would also include a general outline of how
my product will use MySQL). If I don't like the obligations, then I'll
just not use their product (unless they're willing to make an exception for
me), but in the end I will require a written answer be sent through the
mail, complete with signatures since it's extremely easy to create doubt in
the courts around the authenticity of an eMail when you have the right
experts on your side (such as people like me).
> <http://slashdot.org/interviews/00/05/01/1052216.shtml>
>
> In that interview, the indication is that by separating components
> into "client" and "server" bits, using CORBA, the GPL can be
> circumvented because the client and server aren't "linked." Which is
> the opposite of what MySQL AB is telling people.
>
> The MySQL AB strategy doesn't seem to involve the "client-vs-server"
> issue. Arguing that your client must be GPL-licensed because the
> server is wouldn't fly terribly far. Instead, they only provide
> _client_ software in GPL-licensed form, as _that_ would "taint" the
> software you might link to it such that it would have to be
> GPL-licensed.
It's all very complicated.
> <http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2>
>
> What is very interesting is that they oppose attempts to circumvent
> this by someone prepared to write their own client. (The discussion
> came up when SAP-DB users were distressed that they would no longer be
> able to get a LGPL-licensed client library, and were discussing the
> possibility of writing their own...)
>
> "In this case, I would suspect that the intent of your middleware is
> what would matter most in a court case. If the middleware appears to
> mostly be in place to circumvent licensing restrictions, then it (I
> believe) would not circumvent the license. If the middleware is an
> abstraction layer that simply allows for convenient access to a
> variety of different data sources, then the license might be
> circumvented." -- Zak Greant <zak@mysql.com>
Yikes! That just hits me as rather vague. Perhaps I need to look at
it more closely and think it through when my daughter's not watching the
Teletubbies. =D
> What is also very interesting is that many/most of the uses of "client
> libraries" get embedded into PHP/Perl/Python modules, which leads to a
> mishmash of licenses that may (as with PHP) make redistribution of the
> client libraries nonpermissible.
>
> Long and short... No, I don't see that the GPL has been "violated."
>
> But if the GPL is intended as a 'protector/encourager of free
> software,' their use of it seems to me to be about as distant from
> that _intent_ as possible.
Keep in mind that (at least in Canada) contractual agreements are only
valid when an aspect called "consideration" exists, which means that both
parties benefit in some way (which must not be grossly unfair to one side).
With all this mish-mash of various licenses, I wonder how
"consideration" would fit in to it all. My feeling is that a court would
likely be considering this (along with many other factors) when examining
the bigger picture of intent in order to determine if there really was any
damage done to all parties involved. Certainly one important aspect of
such a decision would be to understand what the various license owners knew
about how the industry works at present, which would probably keep the
lawyers busy for months if not years since most are non-technical.
DISCLAIMER: I'm not a lawyer so I'm just going by assumptions based on
what I've learned about the law as a layperson over the years (and from
watching The People's Court).
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
In the last exciting episode, Randolf Richardson <rr@8x.ca> wrote: > Of course I'll attempt to get an official response from the > legal department of such a company before jumping to any > conclusions. In the case of MySQL, if I wanted to develop a project > that was not open source and didn't comply with the GPL, I'd send a > letter (or eMail) to MySQL and ask for clarity on what my > obligations would be with regards to their licensing and my product > (and would also include a general outline of how my product will use > MySQL). I'm reasonably sure that their answer would point you to the "brief description," namely: "This is our licensing policy in brief: Our software is 100% GPL, and if yours is also 100% GPL (or OSI compliant), then you never have to pay us for the licences. In all other instances, you are better served by our commercial licence." Their "licensing page" says it quite explicitly: "To anyone in doubt, we recommend the commercial licence. It is never wrong." Which gives the pretty clear underlying message: It's not really "open source" or "free software;" to anyone in doubt, reality is that it's traditionally-licensed commercial software, at several hundred dollars a pop. I can't see them being particularly interested in giving explanations that would lead to people _not_ sending in a cheque... >> <http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2> > > Yikes! That just hits me as rather vague. Perhaps I need to > look at it more closely and think it through when my daughter's not > watching the Teletubbies. =D It was a pretty stunning claim to see, yes, indeed... > Keep in mind that (at least in Canada) contractual agreements > are only valid when an aspect called "consideration" exists, which > means that both parties benefit in some way (which must not be > grossly unfair to one side). In the US, I believe it is common for contracts to have a clause reading something like "with the exchange of one dollar plus other valuable consideration." I don't see it being a big problem to consider that there is some kind of benefit to both sides in the use of free software. - The use of the software is presumably somewhat valuable to the users; - If the producers of the software do not receive an express "value," the fact that they offered it freely for use would make it seem very peculiar for them to complain of abuse. > With all this mish-mash of various licenses, I wonder how > "consideration" would fit in to it all. My feeling is that a court > would likely be considering this (along with many other factors) > when examining the bigger picture of intent in order to determine if > there really was any damage done to all parties involved. Certainly > one important aspect of such a decision would be to understand what > the various license owners knew about how the industry works at > present, which would probably keep the lawyers busy for months if > not years since most are non-technical. In the case of the "M guys," it isn't likely to be Canadian law that would be relevant, in that the company is based in Sweden. In the case of PostgreSQL, the lack of a "legal team" would suggest that the 'relevant jurisdiction' for any legal conflict would likely be established by whomever started a case... > DISCLAIMER: I'm not a lawyer so I'm just going by assumptions based > on what I've learned about the law as a layperson over the years > (and from watching The People's Court). Good 'ol Judge Wapnner... :-) Of course, he's expressing a parody of US law, which, in a number of ways, is conspicuously different from Canadian law, just as the respective political processes are rather different. (Canada, by use of low-tech voting processes, seems to have a vastly more robust electoral process due to the absence of such problems as "hanging chad." On the other hand, prime ministers can behave as near dictators during their tenures, absent of the US "checks and balances"...) And in the post-OJ era, it is pretty evident that a vital component is that he who has the most expensive team of lawyers and/or lobbyists will substantially influence the process. This month, we're seeing the "entertainment" of what's going on with SCO and Michael Jackson, and it is evident that there is _massive_ perversity going on in both cases, irrespective of the factual merits of the cases. Whether MJ's "Truly Bad" or not, he's pretty loopy. And the recent threats against BSD projects demonstrates that NO free software project can consider itself safe from legal attack. If the Debian project had decided to drop PostgreSQL due to "paranoid readings" of its license, that might be pooh-poohed as the ravings of GPL fans. It is most interesting when it's the OpenBSD guys that turn up the paranoid ones this week... -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://www3.sympatico.ca/cbbrowne/languages.html Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly
On Sat, 2003-11-29 at 04:26, Randolf Richardson wrote: ... > Keep in mind that (at least in Canada) contractual agreements are only > valid when an aspect called "consideration" exists, which means that both > parties benefit in some way (which must not be grossly unfair to one side). > > With all this mish-mash of various licenses, I wonder how > "consideration" would fit in to it all. Consideration is a concept in contract law. It has no relevance to licences, which are NOT contracts. The essence of a contract is that each party gives something (the consideration) to the other. A licence is one-sided. (However, a licence may itself be the consideration, as when you pay for commercial software.) -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "But grow in grace, and in the knowledge of our Lord and Saviour Jesus Christ. To him be glory both now and for ever. Amen." II Peter 3:18
"Randal L. Schwartz" <merlyn@stonehenge.com> Wrote: > > The biggest advantage MySQL still has over PostgreSQL is the same > advantage Microsoft has over Unix - entrenchment, both in > software and mindshare. There is another thing too-- MySQL manages connection permissions entirely within the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes managing a database server in a shared hosting environment a bit harder. While I appreciate the PostgreSQL way of doing things, I realize that it is a bit harder to make work for the average web hosting provider. I am currently looking at the possibility of building a solution, but no one has expressed interest, so I am not sure. FWIW, here is what I have in mind: A PostgreSQL database with hooks into the pg_hba.conf so that new user accounts can be created, along with databases, etc. and all permissions properly managed. Whether the pg_hba should be parsed and treated as an external table using PL/PerlU or whether it should be recreated on demand is a question I am still considering (pro's and cons of doing things either way). Obviously this would not have a wide audience, but it would go a LONG way towards challenging both MS SQL and MySQL in the web hosting space. Another opportunity here is helping port "legacy" MySQL applications to PostgreSQL, ensuring demand for the RDBMS continues to grow. Best Wishes, Chris Travers
There is another thing too-- MySQL manages connection permissions entirely >within the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes >managing a database server in a shared hosting environment a bit harder. >While I appreciate the PostgreSQL way of doing things, I realize that it is >a bit harder to make work for the average web hosting provider. I am >currently looking at the possibility of building a solution, but no one has >expressed interest, so I am not sure. > > > Ahh just run different instances for each customer. >FWIW, here is what I have in mind: >A PostgreSQL database with hooks into the pg_hba.conf so that new user >accounts can be created, along with databases, etc. and all permissions >properly managed. Whether the pg_hba should be parsed and treated as an >external table using PL/PerlU > I would use pl/c because you won't have the external perl requirement. >or whether it should be recreated on demand is >a question I am still considering (pro's and cons of doing things either >way). Obviously this would not have a wide audience, but it would go a LONG >way towards challenging both MS SQL and MySQL in the web hosting space. > >Another opportunity here is helping port "legacy" MySQL applications to >PostgreSQL, ensuring demand for the RDBMS continues to grow. > >Best Wishes, >Chris Travers > > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
On Sun, 30 Nov 2003, Joshua D. Drake wrote: > There is another thing too-- MySQL manages connection permissions entirely > > >within the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes > >managing a database server in a shared hosting environment a bit harder. > >While I appreciate the PostgreSQL way of doing things, I realize that it is > >a bit harder to make work for the average web hosting provider. I am > >currently looking at the possibility of building a solution, but no one has > >expressed interest, so I am not sure. > > > > > > > Ahh just run different instances for each customer. This wouldn't really work for a ISP would it? A fairly low spec machine with a few hundred low-hit websites, maybe 60 of them wanting a database for their blogs? My ISP runs mysql, I don't get shell access :((, but I can remotely connect to their mysql server from home. If running sixty instances of PostgreSQL, wouldn't you have to have 60 different port numbers, not to mention a whole lot of RAM? I've asked them to put up PostgreSQL as an alternative, but they just say "too hard" and don't want to talk about it.
"too hard" ??? That really amazes me. We've been running PostgreSQL for our clients since before 7.1. We only run one instance. We generally manage the actually web sites but clients gets their own db user user and shell account so they could manager their database remotely if they want (with SSL enforced of course) with something like pgAdmin III. I honestly think that ISP's who offer MySQL instead of PostgreSQL with such reasons are doing their clients a disservice since 1) "too hard" is hardly a reason to not run a product and 2) MySQL as a replacement is for PostgreSQL is NOT acceptable (though the reverse substitution would be more so). Quoting Craig O'Shannessy <craig@ucw.com.au>: > On Sun, 30 Nov 2003, Joshua D. Drake wrote: > > > There is another thing too-- MySQL manages connection permissions entirely > > > > >within the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes > > >managing a database server in a shared hosting environment a bit harder. > > >While I appreciate the PostgreSQL way of doing things, I realize that it > is > > >a bit harder to make work for the average web hosting provider. I am > > >currently looking at the possibility of building a solution, but no one > has > > >expressed interest, so I am not sure. > > > > > > > > > > > Ahh just run different instances for each customer. > > This wouldn't really work for a ISP would it? A fairly low spec machine > with a few hundred low-hit websites, maybe 60 of them wanting a database > for their blogs? > > My ISP runs mysql, I don't get shell access :((, but I can remotely > connect to their mysql server from home. If running sixty instances of > PostgreSQL, wouldn't you have to have 60 different port numbers, not to > mention a whole lot of RAM? > > I've asked them to put up PostgreSQL as an alternative, but they just say > "too hard" and don't want to talk about it. > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
Hiya,
As I've mentioned before, we happilly run and offer PostgreSQL and MySQL hosting to our customers. We also offer shell access which simplifies things a little. I'm a little confused as to why people find having auth control from pg_hba.conf a problem? We never use the same passwords or pam for our DBs either, since it offers a little more security should one or the other be compromised. If you use a tool like webmin, it not really any more complicated. Anyone who complains about it being "too hard" to offer PG as a shared hosting option just hasn't investigated the possibility.
In my experience, many ISPs and hosts don't offer it because they beleive the ROI (time, learning, extra maintenance, patching, updates,etc) will not good.
Regards
Tony.
Craig O'Shannessy wrote:
As I've mentioned before, we happilly run and offer PostgreSQL and MySQL hosting to our customers. We also offer shell access which simplifies things a little. I'm a little confused as to why people find having auth control from pg_hba.conf a problem? We never use the same passwords or pam for our DBs either, since it offers a little more security should one or the other be compromised. If you use a tool like webmin, it not really any more complicated. Anyone who complains about it being "too hard" to offer PG as a shared hosting option just hasn't investigated the possibility.
In my experience, many ISPs and hosts don't offer it because they beleive the ROI (time, learning, extra maintenance, patching, updates,etc) will not good.
Regards
Tony.
Craig O'Shannessy wrote:
On Sun, 30 Nov 2003, Joshua D. Drake wrote:There is another thing too-- MySQL manages connection permissions entirelywithin the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes managing a database server in a shared hosting environment a bit harder. While I appreciate the PostgreSQL way of doing things, I realize that it is a bit harder to make work for the average web hosting provider. I am currently looking at the possibility of building a solution, but no one has expressed interest, so I am not sure.Ahh just run different instances for each customer.This wouldn't really work for a ISP would it? A fairly low spec machine with a few hundred low-hit websites, maybe 60 of them wanting a database for their blogs? My ISP runs mysql, I don't get shell access :((, but I can remotely connect to their mysql server from home. If running sixty instances of PostgreSQL, wouldn't you have to have 60 different port numbers, not to mention a whole lot of RAM? I've asked them to put up PostgreSQL as an alternative, but they just say "too hard" and don't want to talk about it. ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
> > I've asked them to put up PostgreSQL as an alternative, but they just > say > "too hard" and don't want to talk about it. > > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > I think we may translate 'too hard' into 'I'm too lazy to learn something different and provide better service to my customers'. Or, in the interests of simplicity, 'I'm too dumb'. -------------------- Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd. (740) 587-0114 www.ravensfield.com
I'd agree that this is probably laziness, or to be fairer, a ROI issue, and again comes down to MySql having more mindshare. I was mainly saying that the statement "Ahh just run different instances for each customer." doesn't sit very well with me, and I doubt it would for any ISP. I can't see much problem with pg_hba.conf, it would make the installation automation a bit more "hacky" probably, because you'd probably write shell/sed/awk scripts to modify the pg_hba.conf, and have to SIGHUP postmaster. It'd also makes it a bit hard to query the information in said file from an automated website admin program, but doesn't seem like a biggie. I wasn't meaning to imply that *I* thought it was "too hard", just what I got told by my ISP. They could have meant many kinds of "hard", from "too little time, too much to do" through to "I'm not so bright and the database contractors too expensive". Craig. On Mon, 1 Dec 2003, Unihost Web Hosting wrote: > Hiya, > > As I've mentioned before, we happilly run and offer PostgreSQL and MySQL > hosting to our customers. We also offer shell access which simplifies > things a little. I'm a little confused as to why people find having > auth control from pg_hba.conf a problem? We never use the same > passwords or pam for our DBs either, since it offers a little more > security should one or the other be compromised. If you use a tool like > webmin, it not really any more complicated. Anyone who complains about > it being "too hard" to offer PG as a shared hosting option just hasn't > investigated the possibility. > > In my experience, many ISPs and hosts don't offer it because they > beleive the ROI (time, learning, extra maintenance, patching, > updates,etc) will not good. > > Regards > > Tony. > > Craig O'Shannessy wrote: > > >On Sun, 30 Nov 2003, Joshua D. Drake wrote: > > > > > > > >>There is another thing too-- MySQL manages connection permissions entirely > >> > >> > >> > >>>within the RDBMS, while PostgreSQL relies on the pg_hba.conf. This makes > >>>managing a database server in a shared hosting environment a bit harder. > >>>While I appreciate the PostgreSQL way of doing things, I realize that it is > >>>a bit harder to make work for the average web hosting provider. I am > >>>currently looking at the possibility of building a solution, but no one has > >>>expressed interest, so I am not sure. > >>> > >>> > >>> > >>> > >>> > >>Ahh just run different instances for each customer. > >> > >> > > > >This wouldn't really work for a ISP would it? A fairly low spec machine > >with a few hundred low-hit websites, maybe 60 of them wanting a database > >for their blogs? > > > >My ISP runs mysql, I don't get shell access :((, but I can remotely > >connect to their mysql server from home. If running sixty instances of > >PostgreSQL, wouldn't you have to have 60 different port numbers, not to > >mention a whole lot of RAM? > > > >I've asked them to put up PostgreSQL as an alternative, but they just say > >"too hard" and don't want to talk about it. > > > > > >---------------------------(end of broadcast)--------------------------- > >TIP 7: don't forget to increase your free space map settings > > > > >
> [sNip] > >> In summary, you could be charging them for some very expensive courier > >> services, if for which they don't pay then you won't deliver. =) > > > > Of course a competitor could purchase a copy or get it from a customer > > and set up shop right away selling it too. > > Ah, so even the GPL has a few loop holes! =D I don't think that is a loophole I think that is the whole point of it. rg
[sNip]
> The biggest advantage MySQL still has over PostgreSQL is the same
> advantage Microsoft has over Unix - entrenchment, both in
> software and mindshare.
Ah yes, but in Microsoft's case many people are hate them because
there is a perception that their products are the only choice.
At least with MySQL most users are generally happy with it, so the
situation, although very similar, will be an even more difficult battle in
this database world because there is a general consensus among many Windows
OS users to move to something else (be it Linux-based or not) as long as it
doesn't prevent them from doing all the things they need to do with their
computer on a daily basis.
SQL standards are certainly a move in the right direction with regards
to preventing the same drastic situation Microsoft has created from
occurring, but since this isn't 100% possible at this time it should at
least be a goal that's promoted throughout the community so as to ensure an
interoperable future -- those who resist it can be questioned about their
motives since it will obviously result in preventing compatibility which
would make it more difficult for users to switch between RDBMSes.
> The marketplace often does the right thing, but when one "was right"
> thing dominates the market, the "new right" thing rarely has an easy
> time.
The marketplace "used to" do the right thing. Now the vast majority
of decision makers are impressed by fancy looking marketing campaigns and
stupidly believe everything that's published by well-known brand names,
even when no brand name loyalty exists. The worst problem with regards to
this is that decisions are often made based on "what the majority of other
people are supposedly doing" rather than "what actually best fits the needs
of the project."
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 29 November 2003 01:27 pm, Randolf Richardson wrote:
> [sNip]
>
> > The biggest advantage MySQL still has over PostgreSQL is the same
> > advantage Microsoft has over Unix - entrenchment, both in
> > software and mindshare.
>
> Ah yes, but in Microsoft's case many people are hate them because
> there is a perception that their products are the only choice.
>
> At least with MySQL most users are generally happy with it, so the
> situation, although very similar, will be an even more difficult battle in
> this database world because there is a general consensus among many Windows
> OS users to move to something else (be it Linux-based or not) as long as it
> doesn't prevent them from doing all the things they need to do with their
> computer on a daily basis.
>
> SQL standards are certainly a move in the right direction with regards
> to preventing the same drastic situation Microsoft has created from
> occurring, but since this isn't 100% possible at this time it should at
> least be a goal that's promoted throughout the community so as to ensure an
> interoperable future -- those who resist it can be questioned about their
> motives since it will obviously result in preventing compatibility which
> would make it more difficult for users to switch between RDBMSes.
>
> > The marketplace often does the right thing, but when one "was right"
> > thing dominates the market, the "new right" thing rarely has an easy
> > time.
>
> The marketplace "used to" do the right thing. Now the vast majority
> of decision makers are impressed by fancy looking marketing campaigns and
> stupidly believe everything that's published by well-known brand names,
> even when no brand name loyalty exists. The worst problem with regards to
> this is that decisions are often made based on "what the majority of other
> people are supposedly doing" rather than "what actually best fits the needs
> of the project."
Actually what I saw a lot is that the decision is made by middle to upper
management. In order to avoid being blamed for "wrong decision" a lot of thos
decision makers simply stick to the market leaders. If the stuff then doesn't
work, their boss will always accept the excuse "but it's the market leader".
Therefor the decisionmakers job is safe.
UC
- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/zBm9jqGXBvRToM4RAhWlAJ0brKdZc1Cg20fRnDDpom1zkCMIwgCfbQGQ
O7tQ1exVXLHZKARBf1gTwVA=
=ed57
-----END PGP SIGNATURE-----
Uwe C. Schroeder wrote: > On Saturday 29 November 2003 01:27 pm, Randolf Richardson wrote: >> >> The marketplace "used to" do the right thing. Now the vast majority >>of decision makers are impressed by fancy looking marketing campaigns and >>stupidly believe everything that's published by well-known brand names, >>even when no brand name loyalty exists. The worst problem with regards to >>this is that decisions are often made based on "what the majority of other >>people are supposedly doing" rather than "what actually best fits the needs >>of the project." > > Actually what I saw a lot is that the decision is made by middle to upper > management. In order to avoid being blamed for "wrong decision" a lot of thos > decision makers simply stick to the market leaders. If the stuff then doesn't > work, their boss will always accept the excuse "but it's the market leader". > Therefor the decisionmakers job is safe. It's not an entirely irrational response either. The supply of labor that has sufficient knowledge to support the better, but less well known technology is more restricted, less commoditized, and therefore pricier. Additionally, the risk associated with a product line which is not a market leader assumes a possibility of incurring large switching costs in the event that the product line fails. The benefits of the superior niche technology have to outweigh those risks. Some firms will take the risk, others won't. Over the long term, if the superior technology + small market share proponents are correct, those firms that take the risk will be rewarded and those that don't, running inefficient legacy systems will be punished for their less-than-stellar productivity. But it could be that taking the risk was unwarranted, and those firms that did will be punished for choosing an arcane, unsupportable technology... In other words, I'm still waiting for an office suite for my Amiga... ;-) Mike Mascari mascarm@mascari.com
Uwe C. Schroeder wrote: >Actually what I saw a lot is that the decision is made by middle to upper >management. In order to avoid being blamed for "wrong decision" a lot of thos >decision makers simply stick to the market leaders. If the stuff then doesn't >work, their boss will always accept the excuse "but it's the market leader". >Therefor the decisionmakers job is safe. > > In the Real World (TM) things are far more sinister than this. Consider the life of this middle management dude. He has "advice" being shoved down his throat by people who have no idea how to do his job. Even if he does the Right Thing (TM) and it's a blazing success, politics rules says he has lost as the perception is that he is not a team player. He will soon be out of a job - UNDER ALL CIRCUMSTANCES. I've actually witnessed this happen more than once - successful product, incredible achievement yet unpopular decisions and CTO/Director and management quietly disappear.
unsubscribe
Christopher Browne wrote: <blockquote cite="midm3k75jcmbq.fsf@wolfe.cbbrowne.com" type="cite"><pre wrap="">In the last excitingepisode, Randolf Richardson <a class="moz-txt-link-rfc2396E" href="mailto:rr@8x.ca"><rr@8x.ca></a> wrote: </pre><blockquotetype="cite"><pre wrap=""> Of course I'll attempt to get an official response from the legal department of such a company before jumping to any conclusions. In the case of MySQL, if I wanted to develop a project that was not open source and didn't comply with the GPL, I'd send a letter (or eMail) to MySQL and ask for clarity on what my obligations would be with regards to their licensing and my product (and would also include a general outline of how my product will use MySQL). </pre></blockquote><pre wrap=""> I'm reasonably sure that their answer would point you to the "brief description," namely: "This is our licensing policy in brief: Our software is 100% GPL, and if yours is also 100% GPL (or OSI compliant), thenyou never have to pay us for the licences. In all other instances, you are better served by our commercial licence." Their "licensing page" says it quite explicitly: "To anyone in doubt, we recommend the commercial licence. It is never wrong." Which gives the pretty clear underlying message: It's not really "open source" or "free software;" to anyone in doubt, reality is that it's traditionally-licensed commercial software, at several hundred dollars a pop. I can't see them being particularly interested in giving explanations that would lead to people _not_ sending in a cheque...</pre></blockquote> A few quotes with links:<br /><br /><a class="moz-txt-link-freetext" href="http://www.mysql.com/products/licensing-examples.html">http://www.mysql.com/products/licensing-examples.html</a><br /><br/> <quote>You need a license if you sell a product designed specifically for use with MySQL or that requires theMySQL server to function at all. This is true whether or not you provide MySQL for your client as part of your productdistribution.<tt></quote></tt><br /><br /><a class="moz-txt-link-freetext" href="http://archives.postgresql.org/pgsql-general/2003-09/msg01400.php">http://archives.postgresql.org/pgsql-general/2003-09/msg01400.php</a><br /><br/><tt><guote>"Your PHP app that requires MySQL, if distributed, will either have to be GPL (or another OSI-approvedand MySQL-approved open source licence ) or you will need a commercial licence of MySQL." </tt><br /><br /><tt>Sometimespeople say "But I cannot open source my application!" and they may have valid reasons for this. Our responseis then: "If you have a valid reason not to be open source, wouldn't that same reasoning apply to us?".</tt><br /><br/><tt>This goes to the core of MySQL AB's business idea of Quid pro Quo - if you are open source, we are open source- if you are closed source, we are commercial.</quote><br /><br /> Doesn't leave open much questions imho.<br/><br /> Kaarel<br /></tt>
In the last exciting episode, Randolf Richardson <rr@8x.ca> wrote: > Of course I'll attempt to get an official response from the > legal department of such a company before jumping to any > conclusions. In the case of MySQL, if I wanted to develop a project > that was not open source and didn't comply with the GPL, I'd send a > letter (or eMail) to MySQL and ask for clarity on what my > obligations would be with regards to their licensing and my product > (and would also include a general outline of how my product will use > MySQL). I'm reasonably sure that their answer would point you to the "brief description," namely: "This is our licensing policy in brief: Our software is 100% GPL, and if yours is also 100% GPL (or OSI compliant), then you never have to pay us for the licences. In all other instances, you are better served by our commercial licence." Their "licensing page" says it quite explicitly: "To anyone in doubt, we recommend the commercial licence. It is never wrong." Which gives the pretty clear underlying message: It's not really "open source" or "free software;" to anyone in doubt, reality is that it's traditionally-licensed commercial software, at several hundred dollars a pop. I can't see them being particularly interested in giving explanations that would lead to people _not_ sending in a cheque... >> <http://marc.theaimsgroup.com/?l=sapdb-general&m=106045880005921&w=2> > > Yikes! That just hits me as rather vague. Perhaps I need to > look at it more closely and think it through when my daughter's not > watching the Teletubbies. =D It was a pretty stunning claim to see, yes, indeed... > Keep in mind that (at least in Canada) contractual agreements > are only valid when an aspect called "consideration" exists, which > means that both parties benefit in some way (which must not be > grossly unfair to one side). In the US, I believe it is common for contracts to have a clause reading something like "with the exchange of one dollar plus other valuable consideration." I don't see it being a big problem to consider that there is some kind of benefit to both sides in the use of free software. - The use of the software is presumably somewhat valuable to the users; - If the producers of the software do not receive an express "value," the fact that they offered it freely for use would make it seem very peculiar for them to complain of abuse. > With all this mish-mash of various licenses, I wonder how > "consideration" would fit in to it all. My feeling is that a court > would likely be considering this (along with many other factors) > when examining the bigger picture of intent in order to determine if > there really was any damage done to all parties involved. Certainly > one important aspect of such a decision would be to understand what > the various license owners knew about how the industry works at > present, which would probably keep the lawyers busy for months if > not years since most are non-technical. In the case of the "M guys," it isn't likely to be Canadian law that would be relevant, in that the company is based in Sweden. In the case of PostgreSQL, the lack of a "legal team" would suggest that the 'relevant jurisdiction' for any legal conflict would likely be established by whomever started a case... > DISCLAIMER: I'm not a lawyer so I'm just going by assumptions based > on what I've learned about the law as a layperson over the years > (and from watching The People's Court). Good 'ol Judge Wapnner... :-) Of course, he's expressing a parody of US law, which, in a number of ways, is conspicuously different from Canadian law, just as the respective political processes are rather different. (Canada, by use of low-tech voting processes, seems to have a vastly more robust electoral process due to the absence of such problems as "hanging chad." On the other hand, prime ministers can behave as near dictators during their tenures, absent of the US "checks and balances"...) And in the post-OJ era, it is pretty evident that a vital component is that he who has the most expensive team of lawyers and/or lobbyists will substantially influence the process. This month, we're seeing the "entertainment" of what's going on with SCO and Michael Jackson, and it is evident that there is _massive_ perversity going on in both cases, irrespective of the factual merits of the cases. Whether MJ's "Truly Bad" or not, he's pretty loopy. And the recent threats against BSD projects demonstrates that NO free software project can consider itself safe from legal attack. If the Debian project had decided to drop PostgreSQL due to "paranoid readings" of its license, that might be pooh-poohed as the ravings of GPL fans. It is most interesting when it's the OpenBSD guys that turn up the paranoid ones this week... -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://www3.sympatico.ca/cbbrowne/languages.html Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly