On Fri, 21 Jan 2005, Troy Engel wrote:

I've also read that with 4.1 server binaries, the 3.x client apps will no longer work?

If the client apps are running on a different host where the entire installation is still mysql 3, it has been my experience so far that they are able to successfully communicate with a remote msyql 4 server.

Running mysql 3 apps with a localhost mysql 4 server, I have not tried.

On Fri, 2005-01-21 at 12:46 -0600, Johnny Hughes wrote:

On Fri, January 21, 2005 12:19 pm, Troy Engel said:

...

Thanks for the URL, Donovan. Ok this really is not good, is it still the licensing snafu/issue with MySQL 4.x that Redhat doesn't like? Something about a change regarding to linking to 4.x libs and the LGPL I remember reading...

Increasing we're having to hybrid all our servers (run the mysql client RPMS for 3.x, but server binaries for 4.0 over in /usr/local/) for more and more projects that need the 4.0 features. I've also read that with 4.1 server binaries, the 3.x client apps will no longer work?

sigh. They're killin us out here in the trenches...

-te

The mysql in 4.0beta is indeed 3.23.58, but there is now a mysql-4.1.9 in rawhide, so it seems that they have worked out the licensing issues.

It is possible that 4.1.x can be released in RHEL 4 (and so in CentOS-4 as well). If it is not, I'll build a mysql-4 and make it an extras or contrib build for CentOS-4 final ... because I want to use the new administrator and it is only for mysql-4.

...

donavan nelson wrote:

...

I haven't seen an update one the mysql4 issues for RH. You and everyone else can check current package releases here:

mysql is the 3.whatever release in CentOS4b2

http://beta.centos.org/centos/4.0beta/os/i386/RedHat/RPMS/

-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com _______________________________________________ CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos

Wondering if this has something to do with AB coming after people for licensing revenue, in violation of the mysql EULA.

After seeing a buddy of mine's firm get nailed for 1.5 million dollars I learned at his firms expense.

Ted

On Fri, 2005-01-21 at 13:33 -0600, Johnny Hughes wrote:

On Fri, January 21, 2005 1:13 pm, Ted Kaczmarek said:

...

Wondering if this has something to do with AB coming after people for licensing revenue, in violation of the mysql EULA.

After seeing a buddy of mine's firm get nailed for 1.5 million dollars I learned at his firms expense.

Ted

More info please. The basic way I read the MySQL AB license is:

If you release Open Source software, you can use the Open Source mysql license. If you release your software closed source, you have to use the Commericial License.

So, if the company in question released close source software (that they charged for) then they must have a commercial license.

Most companies do not release their source code for their in house proprietary applications. I suspect the majority of the corporate world will probably always be like this, sure lets give all our competitors are code, lol.

I would be willing to bet that most people using mysql are in violation of its license, show me all the Open Source projects submitted by all those mysql users.

This type of manipulation of the spirit of the GPL is a big reason many companies are leery of Open Source.

Regards, Ted

On 26/01/2005 2:49 p.m., Simon Garner wrote:

The license is referring to software that makes use of the MySQL source code. If you write an application that takes source from MySQL, then you are bound by the MySQL license.

This does not apply to creating an application that interfaces with a MySQL database. You can do whatever you want with your own source code. The MySQL license certainly does not require everyone using MySQL databases to release their applications as open source, that would be ridiculous!

I should clarify the first part. According to the MySQL web site, the license restrictions apply if you distribute the MySQL Software, whether modified or not. The vast majority of MySQL users would not be distributing MySQL (and most wouldn't even be distributing their own application), so they are safe under the GPL.

http://www.mysql.com/company/legal/licensing/opensource-license.html

"Free use for those who never copy, modify or distribute. As long as you never distribute the MySQL Software in any way, you are free to use it for powering your application, irrespective of whether your application is under GPL license or not."

-Simon

Paul wrote:

I'm not sure about that if your linking to the client libraries since the 4.0 ones are now GPL instead of LGPL. If it's an in-house created software then yeah it probably does not really matter. If on the other hand if it's a non-GPL licensed app you are distributing that is linked against the MySQL client libraries then you have an issue such as with PHP.

Or that is how I under stand the issue.

Paul

That's how I read it as well. From mysql.com: "...if you use MySQL in an application you redistribute, the complete source code for your application must be available and freely redistributable under reasonable conditions." I think the real issue is the release of the application. If it's internal, and never released, then there's no problem.

Simon Garner wrote:

In any case PHP is not GPL but its own PHP License, and MySQL has a specific exception in their license for PHP. Which is why Fedora are now including MySQL 4.1 and PHP 5 in FC3.

Exactly. That was the issue, that PHP is not GPL.

As an aside, the MySQL people have always felt that if your application depended on MySQL, then that would be considered "linking" under the GPL. So to them, it didn't matter that you were using their LGPL libraries. Nobody else really bought their argument though, so they changed the libraries to GPL in an effort to clarify their position. I think they were under the impression that PHP was GPL-compatible, and didn't realize that GPL'ing their libraries would cause such a fuss.

On Wed, January 26, 2005 8:11 am, Peter Arremann said:

On Tuesday 25 January 2005 22:23, Simon Garner wrote:

...

In any case PHP is not GPL but its own PHP License, and MySQL has a specific exception in their license for PHP. Which is why Fedora are now including MySQL 4.1 and PHP 5 in FC3.

I believe you mean FC4...

Peter.

Actually, it is in rawhide (the Fedora/RedHat development branch) ... which at some point in time will take a snapshot that will become the FC4 branch.

Simon Garner wrote:

I simply upgraded MySQL using the 4.1.x RPMs from mysql.com, haven't seen any problems (with CentOS-3).

The issue really isn't of technical problems per se, more logistical. Many other RPMS are linked to the 3.x libs (it's been awhile since I looked, but think PHP mysql for instance). So depending on what you have installed and need, you may have to have the 3.x lib RPMs in place, or start recompiling more and more until you get a "clean" 4.x linking.

What I could see as a solution is a compat-* or mysql3-* type of thing, just like db3, db4, etc. This would seem pretty clean at first thought.

hashing algorithm. If you use an old format mysql privileges database or run mysqld with --old-passwords (add old-passwords to the [mysqld] section of /etc/my.cnf) there is no problem.

http://dev.mysql.com/doc/mysql/en/Password_hashing.html

Thanks! Good to know, tucking this tidbit away in the brain. :)

-te

On Fri, 2005-01-21 at 15:39 -0600, Benjamin J. Weiss wrote:

I'm beginning to wonder whether PostgresSQL wouldn't be the better solution...

PostgreSQL is much better (in my opinion) as a database. It has triggers and stored procedures. But, many apps already use MySQL.

I like Firebird better than MySQL as well ... strictly speaking from a database features perspective.

However, MySQL is the standard open source database right now.

William Hooper wrote:

...

Troy Engel said:

...

The recent thread about the mysql/postgres RPMS had me wonder -- is Redhat (ergo CentOS) moving to MySQL 4.x in the new RHES4 release? You folks with the beta, what's on the CD/ISOs?

https://www.redhat.com/archives/fedora-devel-list/2004-November/msg00197.htm...

Note that this was posted a couple months after the RHEL 4 Beta announcement.

---

CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos

On Fri, 2005-01-21 at 15:39 -0600, Benjamin J. Weiss wrote:

I'm beginning to wonder whether PostgresSQL wouldn't be the better solution...

I've thought it is ... the only reason to prefer MySQL in the past has been better read performance. By every other metric I've felt that PostgresSQL is a "better" database and have wondered why everybody was using MySQL for everything. The only reason I can think of is the "network effect" which is one of the reasons Windows is popular (everybody knows somebody that knows it).

Paul

Peter Arremann wrote:

On Friday 21 January 2005 21:28, Paul wrote:

...

On Fri, 2005-01-21 at 15:39 -0600, Benjamin J. Weiss wrote:

...

I'm beginning to wonder whether PostgresSQL wouldn't be the better solution...

I've thought it is ... the only reason to prefer MySQL in the past has been better read performance. By every other metric I've felt that PostgresSQL is a "better" database and have wondered why everybody was using MySQL for everything. The only reason I can think of is the "network effect" which is one of the reasons Windows is popular (everybody knows somebody that knows it).

<snip>

Anyway, I would be careful with statements like "x is better than y because it supports feature z" - that's not a "better" its a "more fitting for...". Yes, Mysql doesn't support some/many features that other database engines have - but there is a large set of appliations where you'll be hard pressed to find something that beats mysql. Its simply an issue of selecting the tool that fits best into your environment.

I've never used Postgres. The reason I was thinking that it might be better actually didn't have anything to do with technical merit, but on the games that the MySQL folks have started playing with the licensing. It reminds me of the whole XFree86 debacle. Look at what happened to them...now everybody's switching to X.org.

That's one of the things I love about open source. If somebody gets too big for their britches (*cough* MySQL = Microsoft *cough*) then there's somebody else who'll step into play and take over for those of us who don't like the fecal matter spewing forth.

Ben

Steve Meyers said:

In any case, it probably wouldn't take a genius to rewrite the MySQL libraries from scratch and release it under the LGPL. Eventually, someone will probably do that.

The current tactic with Rawhide and Debian is to just link php against the older v3 LGPL libraries. It is a workable solution as long as nothing gets added that will break v3 clients talking to v4 servers or the overhead in maintaining older v3 libraries becomes too much.

Michael Best wrote:

What or how does some mail client produces this as the subject?

It only appears to happen when I reply to an email on a mailing list. With normal email, person-to-person email, that never happens. I don't really understand it. It looks like the references header is being appended to the Subject, perhaps the headers are being reordered poorly or something.

I'm using Thunderbird 1.0, btw.

On Friday 21 January 2005 21:28, Paul wrote:

On Fri, 2005-01-21 at 15:39 -0600, Benjamin J. Weiss wrote:

...

I'm beginning to wonder whether PostgresSQL wouldn't be the better solution...

I've thought it is ... the only reason to prefer MySQL in the past has been better read performance. By every other metric I've felt that PostgresSQL is a "better" database and have wondered why everybody was using MySQL for everything. The only reason I can think of is the "network effect" which is one of the reasons Windows is popular (everybody knows somebody that knows it).

While I am somewhat biased (google me and find out, or just read the PostgreSQL RPM changelog), I have watched PostgreSQL improve to the point that there remain very few compelling reasons to use MySQL.

IMO, they are: 1.) If your cache is big enough, the mysql backend can fit in the cache (but that's not the most used part of a database server; the kernel is, and it's likely to be in cache more);

2.) Existing applications that rely on MySQL nonstandard extensions or can't easily be modified to use some other backend (PostgreSQL's SQL standards compliance is closer, so if things are coded in an ANSI SQL compliant way it should be a low-level driver type change only, with the SQL itself not requiring much modification);

3.) You need high single-user read performance (PostgreSQL's multiuser read/write mix has higher performance on identical hardware under most situations, and where the advanced features of the backend can be used, performance can be dramatically increased by simply using the backend's features instead of having to issue two or more SQL queries);

4.) You just simply prefer MySQL (which is OK, you are certainly free to choose the wrong tool for the job if you want to).

PostgreSQL, being BSD licensed, doesn't and won't have the licensing gotcha that caused Red Hat to significantly delay release of MySQL 4.x RPMs. This gotcha is simply due to MySQL AB wanting to get more commercial licenses; their whole dual license approach is quite scary, and their insistence on them retaining copyright over additions and patches means that they could take future versions to a commercial license only. PostgreSQL's code has multiple copyrights and each developer would have to agree to a license change. OTOH, commercial versions can be produced and released easily due to the BSD license; Pervasive Postgres for instance, or SRA Powergres, or Command Prompt's Mammoth PostgreSQL, each of which is value-added and each developer of which contributes to the larger community.

PostgreSQL commercial support is available from several different companies, including database heavyweight Pervasive (the guys behind mainframe Btrieve), PostgreSQL Inc, Command Prompt Inc, Software Research Associates (SRA), amongst others. PostgreSQL is not owned by a single company (unlike MySQL) and has an extensive track record spanning nearly 20 years.

Without extensive evaluation of the latest and greatest of each database you cannot categorically say that you just use the best tool for the job; you need to determine the best tool empricially, and increasingly MySQL is no longer the best tool for many jobs that it once was.

Also, MySQL's data integrity is not that great; see www.sql-info.de for some comparisons, gotchas, and explanations of the difference in the design philosophies of the two most popular open source databases. Firebird is coming on strong to be number three, though. The biggest problem I see with MySQL is the 'quick and dirty' attitude; that is, don't throw errors or warnings since they take time, just do what the client said even if it violates data integrity.

PostgreSQL has won the Linux Journal Editors Choice awards for I think three years running for best database. MySQL has won the Readers choice for about the same time.

MySQL's biggest competition on the low end is shaping up to be sqlite, which is extremely fast and lightweight. PostgreSQL's competition is Oracle; as each release occurs, PostgreSQL gains more enterprise class features and make it competitive in the space that DB2, Oracle, and Sybase play.

And with version 8.0 Windows is natively supported (and works great on Win2k3 at least, which I have tested).

PostgreSQL is the backend behind Affilias' .info and .org domain whois and registration databases.

PostgreSQL is so flexible that industrial strength replication can be made as a third party module; one of which is the Slony 1 replication engine which can replicate between differing versions of the backend. (Incidentally, the Slony name means 'elephants'; 'slon' is the singular, and the elephant is the PostgreSQL mascot....). By not forcing a particular integrated replication scheme, users can choose the right replication tool for the job, whether they need master slave, connection pooling, HA, or soon even multi-master.

With the WxWindows-based multiplatform pgAdmin GUI, the phppgadmin Web gui, and easy to install RPMs, DEB's, and other packages, PostgreSQL is now as easy or even easier to administer than MySQL. The only sticky point is version upgrades, but even there PostgreSQL is as easy as Oracle or DB2.

Not only does PostgreSQL have stored procedures, but you have choice in language in which to write them. You can write them in pl/pgsql (almost like Oracle's pl/sql), tcl, perl, python, even R and bash. And you can develop new languages yourself, or write them in C for that matter.

You can write and integrate brand new datatypes and operators, even, that can be easily used from straight SQL queries; the PostGIS module does this for Geographical Information Systems objects, for instance.

PostgreSQL is extremely fexible, fast, reliable, meets ACID requirements, is well supported both by the community and by companies, and is incredibly extensible. There really is no better open source choice for 99.9% of applications. And the mindshare is coming......