Slashdot Mirror
CA Advantage Ingres To Be Released As Open Source
Bruce Perens writes "Computer Associates is releasing CA Advantage Ingres as Open Source under a variant of the Common Public License. The press release is here. This is a commercial fork of the public-domain University Ingres of the '80's, probably the first real relational database. CA's product added SQL and in general brought the program up to enterprise quality. So has the PostgreSQL project. It will be interesting to see if there can be any synergies between the two products. The BSD licensing on PostgreSQL would allow it."
Here's an article at CRN on this and a few other open source moves announced today by CA; can anyone find a link to the text of CA's "Trusted Open Source License"? Related news, contributed by an semi-anonymous reader, is that CA has established "a new open-source foundation that will support Plone, the content management system built on the free Zope Application server," and that Plone's license will change as a result.
MySQL, PostgreSQL, Firebird, now "Ingres". I guess it's better than having none, but it's becoming a pain to support the perculiarities of each of these products in, for example, a PHP script intended for general use, which you want to make work with as many different database systems as possible. It's a pity each of them aren't more compliant with the now 12 year old SQL-92 standard or the now 5 year old SQL-99 standard.
You wouldn't. The source code is so that existing legacy customers can fix their own bugs.
you and your "logic" and your "knowledge" of "computers" and "stuff."
When I was in college back in 89-93, we replaced an aging IBM mainframe with some brand new Sun equipment; one of the classes was a database class, and after the 4361 was retired, we put Ingres on SunOS 4.2 for that class.
The thing kept falling over when the CS students would try to work with it - in any given time period, if there were more than 2 or 3 students using it, it would just shrivel up and die.
It was so notorious for this that when we obtained source code to DikuMUD and implemented our own MUD server, we created a character called "Ingres". If you attacked it with any of the vast array of weaponry available, you could never cause any damage. It would never damage back (as it was harmless), but there was one way to kill it:
LOOK AT INGRES
Ah, the memories....
Insanity is a gradual process; don't rush it.
This parent post is indeed flamebait, but it very accurately describes the life-cycle of Ingres. I worked for several years at CA, and everybody, internally and externally, knew what a boatload of crap Ingres was. Most of our products were written to SQL Server, although Ingres was free to integrate in, since no one would go near the crap.
Now it says that CA added SQL which if I'm remembering isn't true, SQL was in the product well before CA bought it.
Ingres was made by Relational Technology Inc. (at one point in the early eighties there were three database companies that had names containing "relational" and they all eventually changed their names to that of their product (Ingres, Oracle and Informix).
I wrote an application in PC-Ingres in 1986 that used QUEL, I stopped paying attention shortly after that as I went to work for Oracle. Then in 1991 when I left Oracle to go to DEC Ingres was on my radar again as we resold it as "ULTRIX-SQL" and obviously by that point it had gained SQL capabilities. Sometime after that Ingres was in financial trouble and got bought by ASK because they had an application that was based on Ingres and felt they couldn't afford to have them go out of business. Later CA bought ASK.
Ingres was made by Relational Technology Inc
Actually, it began it's life circa 1974 as a research project at UCB and was originally released with source under a BSD license.
The more things change, the more they remain the same I guess.
KFG
Joel Burton best sums it up on ZopeZen:
"eweek.com reported on the Plone Foundation and CA's involvement, but their information about Plone moving away from the GPL is not correct. This has not happened. For our FAQs on the foundation, please see http://plone.org/foundation/faq.
I'm sitting here with Alan, Paul, and Mark Murphy, and we really want to make sure that every knows that this is a real mistake and we're trying to reach eweek to let them know to issue a retraction. We want to make certain that everyone understands that no changes have been made and that a change like this would never happen with discussion with the community as a whole. The Foundation is an exciting change for our community, and we don't want this mistaken information to let people lose site of that."
MySQL is the backend on them all, too. Works great for what they need.
Good for you. Frankly, I think that in many cases the features of MySQL would be enough for me too. Now let me explain why I prefer PostgreSQL:
1. I've used both, and IMHO both are about equally easy to use. So at least for me, the often made claim that MySQL is easier to use is bollocks.
2. I don't run the DB on Windows, so the fact that MySQL has a native Windows port and PostgreSQL hasn't, doesn't bother me. If you care, the next PostgreSQL release is supposed to include a native Windows version.
3. The PostgreSQL client libraries are BSD, while the MySQL libraries are GPL. If I make commercial apps, I would have to buy a commercial license from MySQL Ab.
4. MySQL is often supposed to have superior performance compared to PostgreSQL in the case of a single user doing simple queries. But IMHO this doesn't really matter, since in almost all cases a single user doing simple queries means a simple application, where any low end PC provides enough juice. Where performance matters is a situation with many users doing complicated queries (including writes as well as reads), a situation that PostgreSQL handles much better than MySQL.
5. Features. The PostgreSQL query language supports a much larger subset of the latest SQL standard (SQL:2003) than MySQL. If I find that I need some specific feature, it is quite probable that it exists in PostgreSQL but not in MySQL. Such as subselects, how can you live without them?
And no, beta versions of MySQL don't count. Or stored procedures.
6. ACID properties, something that the PostgreSQL development team takes very seriously. E.g. does MySQL check foreign key constraints, or are they still no-ops?
In short, I feel that MySQL provides no benefit compared to PostgreSQL at the low end (such as ease of use etc.), and if you need more high-end features you'll run out of steam with MySQL way before PostgreSQL does.